14 Oct
2014
14 Oct
'14
5:08 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
All,
As you can probably see from the activity on the trinity-commits list
there have been multiple updates to both the common cmake/admin modules
and the icons across the entire tree over the past week or so.
This ongoing activity has forced essentially a full archive rebuild for
Debian/Ubuntu, our primary supported distributions.
I am announcing a ***hard freeze*** for R14 to allow the Debian/Ubuntu
rebuild to start generating our RC1 package sets. There are currently
three open bug reports blocking Bug 2014; patches that do not relate to
those three reports must be discussed on this list and approved by me
before being committed to GIT. Additionally, only patches that do not
affect the common cmake/admin modules will even be considered at this
time.
After the RC1 rebuilds are complete this soft freeze will thaw to accept
patches for bugs discovered before and during RC1 testing. This thaw will
be short lived to allow time for RC2 rebuilds, so all patches should be
ready within a week after RC1 release.
Each rebuild cycle takes around 2-3 weeks due to the multitude of
distributions supported. If no common cmake/admin modules are updated for
RC2 the resultant rebuild will take less time.
Onwards to the much-fabled R14 release! :-)
Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iFYEARELAAYFAlQ9WJAACgkQLaxZSoRZrGEBQgDdFjmryG8MwYCFIAb+KP5tpzPQ
AnbFoau0HP5VAgDfY+1PLlqolGwxLrYhrr06lSQuKbViZ0VpD5vMHg==
=GzuQ
-----END PGP SIGNATURE-----
14 Oct
14 Oct
5:42 p.m.
New subject: [trinity-devel] R14 hard freeze for RC1
On Tuesday 14 of October 2014 19:08:32 Timothy Pearson wrote:
All,
As you can probably see from the activity on the trinity-commits list
there have been multiple updates to both the common cmake/admin modules
and the icons across the entire tree over the past week or so.
This ongoing activity has forced essentially a full archive rebuild for
Debian/Ubuntu, our primary supported distributions.
I am announcing a ***hard freeze*** for R14 to allow the Debian/Ubuntu
rebuild to start generating our RC1 package sets. There are currently
three open bug reports blocking Bug 2014; patches that do not relate to
those three reports must be discussed on this list and approved by me
before being committed to GIT. Additionally, only patches that do not
affect the common cmake/admin modules will even be considered at this
time.
After the RC1 rebuilds are complete this soft freeze will thaw to accept
patches for bugs discovered before and during RC1 testing. This thaw will
be short lived to allow time for RC2 rebuilds, so all patches should be
ready within a week after RC1 release.
Each rebuild cycle takes around 2-3 weeks due to the multitude of
distributions supported. If no common cmake/admin modules are updated for
RC2 the resultant rebuild will take less time.
Onwards to the much-fabled R14 release! :-)
Tim
I'm currently a few days in processing patches from bug 2110 (tdebase on
openbsd). Most are just ifdef, or portions of code specific to OpenBSD. The
last that I will soon edit are patches to enable building without tdehwlib -
again just a few ifdefs.
Can I continue integrating these patches without discussion?
--
Slávek
5:54 p.m.
New subject: [trinity-devel] R14 hard freeze for RC1
Am Dienstag, 14. Oktober 2014 schrieb Slávek Banko:
I'm currently a few days in processing patches
from bug 2110 (tdebase on
openbsd). Most are just ifdef, or portions of code specific to OpenBSD. The
last that I will soon edit are patches to enable building without tdehwlib -
again just a few ifdefs.
Can I continue integrating these patches without discussion?
--
Slávek
Hi Slavek,
Will this by chance enable building TDE for FreeBSD, too?
Nik
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
6:10 p.m.
New subject: [trinity-devel] R14 hard freeze for RC1
On Tuesday 14 of October 2014 19:54:51 Dr. Nikolaus Klepp wrote:
Am Dienstag, 14. Oktober 2014 schrieb Slávek Banko:
Patch to enable build without tdehwlib will be useful for all non-Linux
systems. Unfortunately I do not know if FreeBSD will require further efforts.
François tested OpenBSD.
--
Slávek
I'm currently a few days in processing
patches from bug 2110 (tdebase on
openbsd). Most are just ifdef, or portions of code specific to OpenBSD.
The last that I will soon edit are patches to enable building without
tdehwlib - again just a few ifdefs.
Can I continue integrating these patches without discussion?
--
Slávek
Hi Slavek,
Will this by chance enable building TDE for FreeBSD, too?
Nik
6:02 p.m.
New subject: [trinity-devel] R14 hard freeze for RC1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
On Tuesday 14 of October 2014 19:08:32 Timothy Pearson
wrote:
Go ahead as long as admin and/or cmake are not touched, however please
wait to push until you can push all of the patches at once; i.e. commit
each patch normally to your local GIT tree, then after you have all
patches locally committed push in one large operation to the server. This
will minimize impact to the ongoing rebuild (and only works in this case
without a mess because you will be the only developer making commits at
this time)
Tim
All,
As you can probably see from the activity on the trinity-commits list
there have been multiple updates to both the common cmake/admin modules
and the icons across the entire tree over the past week or so.
This ongoing activity has forced essentially a full archive rebuild for
Debian/Ubuntu, our primary supported distributions.
I am announcing a ***hard freeze*** for R14 to allow the Debian/Ubuntu
rebuild to start generating our RC1 package sets. There are currently
three open bug reports blocking Bug 2014; patches that do not relate to
those three reports must be discussed on this list and approved by me
before being committed to GIT. Additionally, only patches that do not
affect the common cmake/admin modules will even be considered at this
time.
After the RC1 rebuilds are complete this soft freeze will thaw to accept
patches for bugs discovered before and during RC1 testing. This thaw
will
be short lived to allow time for RC2 rebuilds, so all patches should be
ready within a week after RC1 release.
Each rebuild cycle takes around 2-3 weeks due to the multitude of
distributions supported. If no common cmake/admin modules are updated
for
RC2 the resultant rebuild will take less time.
Onwards to the much-fabled R14 release! :-)
Tim
I'm currently a few days in processing patches from bug 2110 (tdebase on
openbsd). Most are just ifdef, or portions of code specific to OpenBSD.
The
last that I will soon edit are patches to enable building without tdehwlib
-
again just a few ifdefs.
Can I continue integrating these patches without discussion?
--
Slávek -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iFYEARELAAYFAlQ9ZU4ACgkQLaxZSoRZrGGrjgDgh/DpSO+lzw6+0mMbHbVfk6it
pBtugtvrow93kgDfdv28+yAa5hboNkzaEsxM5m3pPd/b3aRT+QlLIA==
=yOOw
-----END PGP SIGNATURE-----
6:18 p.m.
New subject: [trinity-devel] R14 hard freeze for RC1
On Tuesday 14 of October 2014 20:02:54 Timothy Pearson wrote:
Go ahead as long as admin and/or cmake are not
touched, however please
wait to push until you can push all of the patches at once; i.e. commit
each patch normally to your local GIT tree, then after you have all
patches locally committed push in one large operation to the server. This
will minimize impact to the ongoing rebuild (and only works in this case
without a mess because you will be the only developer making commits at
this time)
Ok, waiting patches do not cause changes in admin / cmake. I assumed that I
push patches in two waves - one wave for openbsd specific a second wave to
enable build without tdehwlib. However, there is no problem, I can pushed
everything at once when patches will be ready.
--
Slávek
15 Oct
15 Oct
2:30 a.m.
New subject: [trinity-devel] R14 hard freeze for RC1
On 2014/10/15 02:08 AM, Timothy Pearson wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
All,
As you can probably see from the activity on the trinity-commits list
there have been multiple updates to both the common cmake/admin modules
and the icons across the entire tree over the past week or so.
This ongoing activity has forced essentially a full archive rebuild for
Debian/Ubuntu, our primary supported distributions.
I am announcing a ***hard freeze*** for R14 to allow the Debian/Ubuntu
rebuild to start generating our RC1 package sets. There are currently
three open bug reports blocking Bug 2014; patches that do not relate to
those three reports must be discussed on this list and approved by me
before being committed to GIT. Additionally, only patches that do not
affect the common cmake/admin modules will even be considered at this
time.
After the RC1 rebuilds are complete this soft freeze will thaw to accept
patches for bugs discovered before and during RC1 testing. This thaw will
be short lived to allow time for RC2 rebuilds, so all patches should be
ready within a week after RC1 release.
Each rebuild cycle takes around 2-3 weeks due to the multitude of
distributions supported. If no common cmake/admin modules are updated for
RC2 the resultant rebuild will take less time.
Onwards to the much-fabled R14 release! :-)
Tim
My two cents about bug and development through the freeze period.
1) About the remaining 3 bugs.
- bug 1850: I don't see it as fully blocking. WE could release v14.0.0
even if not control module tabs have been updated to open the correct
handbook. Of course it would be nice to fully close the bug, but if not
we can leave the remaining things for the first subsequent maintenance
release v14.0.1
- bug 1859: documentation is almost fully updated (I still have a few
list to do, which I should be able (or at least I hope) to do within
this week. I can push all the doc updates in one cumulative push when
ready. After that there are two more things to do. One is sorting the
top level list (not critical, but should not be too long) and one is to
add a button for manually updating the top level list (this is more
important)
- bug 2152: I haven't look at the details, but based on the two commits
already made by Slavek it should not take long to fix.
2) about freezing, development and v14.0.x
Tim, is it possible to create a GIT branch for v14.0.0 so that we can
keep pushing patches *not to be in v14.0.0* to the main trunk? The main
question here is actually "how are we going to maintain the v14.0.x
branch when v14.0.0 has been release and the main trunk will be for
v14.1.0"?
Cheers
Michele
3:12 a.m.
New subject: Using branches in the future development (was Re: [trinity-devel] R14 hard freeze for RC1)
On Wednesday 15 of October 2014 04:30:15 Michele Calgaro wrote:
2) about freezing, development and v14.0.x
Tim, is it possible to create a GIT branch for v14.0.0 so that we can
keep pushing patches *not to be in v14.0.0* to the main trunk? The main
question here is actually "how are we going to maintain the v14.0.x
branch when v14.0.0 has been release and the main trunk will be for
v14.1.0"?
Cheers
Michele
This raises the question of the use of branches in the further
development. There are several options:
1) One extreme - do not use branches at all.
= R14.0.0 === R14.0.1 === R14.0.2 === R14.1.0 === R14.1.1 === R14.2.0 === R15.0.0
I assume that the experience from the maintenance branch
v3.5.13-sru excludes this option.
2) Create a branches for the minor/"feature" revisions:
__R14.1.1___R14.1.2___R14.1.3
/
/ __R15.0.1
/ /
= R14.0.0 === R14.1.0 === R14.2.0 === R15.0.0 === R15.1.0
\ \
\ \__R14.2.1___R14.2.2
\
\__R14.0.1___R14.0.2___R14.0.3
3) Create a branches for the major/"abi" revisions and
'sub' branches for minor/"feature" revisions:
___R15.1.0___R15.1.1
/
/__R15.0.1___R15.0.2
/
= R14.0.0 ====== R15.0.0 ====== R16.0.0
\
\__R14.0.1___R14.0.2___R14.0.3
\
\__R14.1.0___R14.1.1___R14.1.2
\
\__R14.2.0___R14.2.1
Based on the existing experience for me seems optimal option 2). In any
case, I suggest to not create a 'tags' for rc versions - solely for the
final releases, to avoid unnecessarily large number of tags.
The second question is "when is the time" to create a branch. As I
mentioned earlier, nightly-builds are designed to build on 'master'
branch. When we create new branch, then nightly-builds should start
with version numbers corresponding to the new target version - for
example, 14.1.0~preXXX. Thus, if a new branch will be created now -
with RC1, then I assume that this is the moment for me to start
worry about the preparation of stable-builds in my ppa.
I note: for some time I maintain 'preliminary-stable-builds' on my
mirror. At the same time I have already prepared PPA to maintain
'stable-builds' on the build-farm. That is to say, that I am ready
to maintain maintanance releases R14.0.x.
What is your opinion - when is the time to create branch and start
the 'maintanance mode'?
--
Slávek
4:23 a.m.
New subject: [trinity-devel] Using branches in the future development (was Re: [trinity-devel] R14 hard freeze for RC1)
On 2014/10/15 12:12 PM, Slávek Banko wrote:
On Wednesday 15 of October 2014 04:30:15 Michele
Calgaro wrote:
Hi Slavek,
thanks for spending the time to write such a detail email. It summarizes
very well my thoughts as well.
Option 3) would be the best choice if we had a clear roadmap for what to
do in the future releases and more developers, since it would allow to
work on v15.0.0, v14.x.y and maintanin v14.0.x at the same time.
Given the amount of resources that we have, I think that option 2) is
the most viable choice.
Regarding the time of branching, my view is that we should first rework
the nightly-building process to allow to choose which branch to build
from. This is in view of future builds of v14.0.x when the main trunk
will be on v14.1.0.
If we change the building process as explained, then the time of branch
is "now". We create a branch for v14.0.x, which will contain v14.0.0 and
all subsequent maintenance releases. Then we create a sub-branch v14.0.0
that will contain only v14.0.0.
I do not see the need to use tags for RC1, RC2 if we use this method.
In pictures:
== Main trunk --> work can continue for v14.1.0
\
\__R14.0.x --> work can continue for v14.0.x,
\ patches can be pushed any time but will
\ not go into v14.0.0
\
\__R14.0.0 --> branch for v14.0.0. When we want to
build RC1, instruct the nightly-build
process to build from here. Later do
the same for RC2 and for the final
v14.0.0 release.
At later stage, we will create sub branches for v14.0.1, v14.0.2 and so
on. Given that branches in GIT are cheap and that changes can easily be
merged from trunk or from the R14.0.x sub-trunk, this should be a
reasonable working solution.
Plus if one day we decide to do so, we can easily switch to option 3: we
just create the v14.x.y sub branch.
Just my 2 cents.
Cheers
Michele
2) about freezing, development and v14.0.x
Tim, is it possible to create a GIT branch for v14.0.0 so that we can
keep pushing patches *not to be in v14.0.0* to the main trunk? The main
question here is actually "how are we going to maintain the v14.0.x
branch when v14.0.0 has been release and the main trunk will be for
v14.1.0"?
Cheers
Michele
This raises the question of the use of branches in the further
development. There are several options:
1) One extreme - do not use branches at all.
= R14.0.0 === R14.0.1 === R14.0.2 === R14.1.0 === R14.1.1 === R14.2.0 === R15.0.0
I assume that the experience from the maintenance branch
v3.5.13-sru excludes this option.
2) Create a branches for the minor/"feature" revisions:
__R14.1.1___R14.1.2___R14.1.3
/
/ __R15.0.1
/ /
= R14.0.0 === R14.1.0 === R14.2.0 === R15.0.0 === R15.1.0
\ \
\ \__R14.2.1___R14.2.2
\
\__R14.0.1___R14.0.2___R14.0.3
3) Create a branches for the major/"abi" revisions and
'sub' branches for minor/"feature" revisions:
___R15.1.0___R15.1.1
/
/__R15.0.1___R15.0.2
/
= R14.0.0 ====== R15.0.0 ====== R16.0.0
\
\__R14.0.1___R14.0.2___R14.0.3
\
\__R14.1.0___R14.1.1___R14.1.2
\
\__R14.2.0___R14.2.1
Based on the existing experience for me seems optimal option 2). In any
case, I suggest to not create a 'tags' for rc versions - solely for the
final releases, to avoid unnecessarily large number of tags.
The second question is "when is the time" to create a branch. As I
mentioned earlier, nightly-builds are designed to build on 'master'
branch. When we create new branch, then nightly-builds should start
with version numbers corresponding to the new target version - for
example, 14.1.0~preXXX. Thus, if a new branch will be created now -
with RC1, then I assume that this is the moment for me to start
worry about the preparation of stable-builds in my ppa.
I note: for some time I maintain 'preliminary-stable-builds' on my
mirror. At the same time I have already prepared PPA to maintain
'stable-builds' on the build-farm. That is to say, that I am ready
to maintain maintanance releases R14.0.x.
What is your opinion - when is the time to create branch and start
the 'maintanance mode'?
16 Oct
16 Oct
1:15 a.m.
New subject: [trinity-devel] Using branches in the future development (was Re: [trinity-devel] R14 hard freeze for RC1)
On Wednesday 15 of October 2014 06:23:33 Michele Calgaro wrote:
On 2014/10/15 12:12 PM, Slávek Banko wrote:
Option 3) would have more weight if our team was larger and had also been
detailed roadmap of the upcoming development. In our situation, however, I
believe that for our small team would present higher demands to maintain.
For option 2) I had the intention of following sub-options:
2a) release major version from 'master' branch:
__R14.1.1___R14.1.2___R14.1.3
/
/ __R15.0.1
/ /
= R14.0.0 === R14.1.0 === R14.2.0 === R15.0.0 === R15.1.0
\ \
\ \__R14.2.1___R14.2.2
\
\__R14.0.1___R14.0.2___R14.0.3
2b) release all versions from 'maintanance' branches:
__R14.1.0___R14.1.1___R14.1.2
/
/ __R15.0.0
/ /
= R14.0.x === R14.1.x === R14.2.x === R15.0.x === R15.1.x
\ \
\ \__R14.2.1___R14.2.2
\
\__R14.0.0___R14.0.1___R14.0.2
I understand "nightly-builds" in the sense that their mission is to keep at
the forefront of the development branch. And I consider it to be correct. On
the primary site is running several automation processes, whose mission is
related to the maintenance of the development 'master' branch. For example,
automatic updating of the submodules in 'tde' repository, generate page with
commits, preparing packages for nightly-builds, update 'po' files,... all
these processes need git repository on "constantly same branch".
If should be addressed on the primary site also other branches, it would only
make sense that on the primary site was simultaneously more clones whole git
repositories and automation scripts separately for each such branch. Anything
else would be prone to confusion. However, this is not necessary. As I
mentioned in a previous email, I am ready to maintain new 'maintanance'
branch and provide the necessary automation processes. This way we have
successfully verified while working on v3.5.13-sru branch.
Incidentally, the corresponding PPA I have already created and updated
packages I'll upload soon:
https://quickbuild.pearsoncomputing.net/~slavek-banko/+archive/deps-r14/+pa…
https://quickbuild.pearsoncomputing.net/~slavek-banko/+archive/main-r14/+pa…
--
Slávek
On Wednesday 15 of October 2014 04:30:15 Michele
Calgaro wrote:
Hi Slavek,
thanks for spending the time to write such a detail email. It summarizes
very well my thoughts as well.
Option 3) would be the best choice if we had a clear roadmap for what to
do in the future releases and more developers, since it would allow to
work on v15.0.0, v14.x.y and maintanin v14.0.x at the same time.
Given the amount of resources that we have, I think that option 2) is
the most viable choice.
Regarding the time of branching, my view is that we should first rework
the nightly-building process to allow to choose which branch to build
from. This is in view of future builds of v14.0.x when the main trunk
will be on v14.1.0.
If we change the building process as explained, then the time of branch
is "now". We create a branch for v14.0.x, which will contain v14.0.0 and
all subsequent maintenance releases. Then we create a sub-branch v14.0.0
that will contain only v14.0.0.
I do not see the need to use tags for RC1, RC2 if we use this method.
In pictures:
== Main trunk --> work can continue for v14.1.0
\
\__R14.0.x --> work can continue for v14.0.x,
\ patches can be pushed any time but will
\ not go into v14.0.0
\
\__R14.0.0 --> branch for v14.0.0. When we want to
build RC1, instruct the nightly-build
process to build from here. Later do
the same for RC2 and for the final
v14.0.0 release.
At later stage, we will create sub branches for v14.0.1, v14.0.2 and so
on. Given that branches in GIT are cheap and that changes can easily be
merged from trunk or from the R14.0.x sub-trunk, this should be a
reasonable working solution.
Plus if one day we decide to do so, we can easily switch to option 3: we
just create the v14.x.y sub branch.
Just my 2 cents.
Cheers
Michele
2) about freezing, development and v14.0.x
Tim, is it possible to create a GIT branch for v14.0.0 so that we can
keep pushing patches *not to be in v14.0.0* to the main trunk? The main
question here is actually "how are we going to maintain the v14.0.x
branch when v14.0.0 has been release and the main trunk will be for
v14.1.0"?
Cheers
Michele
This raises the question of the use of branches in the further
development. There are several options:
1) One extreme - do not use branches at all.
= R14.0.0 === R14.0.1 === R14.0.2 === R14.1.0 === R14.1.1 === R14.2.0 ===
R15.0.0
I assume that the experience from the maintenance branch
v3.5.13-sru excludes this option.
2) Create a branches for the minor/"feature" revisions:
__R14.1.1___R14.1.2___R14.1.3
/
/ __R15.0.1
/ /
= R14.0.0 === R14.1.0 === R14.2.0 === R15.0.0 === R15.1.0
\ \
\ \__R14.2.1___R14.2.2
\
\__R14.0.1___R14.0.2___R14.0.3
3) Create a branches for the major/"abi" revisions and
'sub' branches for minor/"feature" revisions:
___R15.1.0___R15.1.1
/
/__R15.0.1___R15.0.2
/
= R14.0.0 ====== R15.0.0 ====== R16.0.0
\
\__R14.0.1___R14.0.2___R14.0.3
\
\__R14.1.0___R14.1.1___R14.1.2
\
\__R14.2.0___R14.2.1
Based on the existing experience for me seems optimal option 2). In any
case, I suggest to not create a 'tags' for rc versions - solely for the
final releases, to avoid unnecessarily large number of tags.
The second question is "when is the time" to create a branch. As I
mentioned earlier, nightly-builds are designed to build on 'master'
branch. When we create new branch, then nightly-builds should start
with version numbers corresponding to the new target version - for
example, 14.1.0~preXXX. Thus, if a new branch will be created now -
with RC1, then I assume that this is the moment for me to start
worry about the preparation of stable-builds in my ppa.
I note: for some time I maintain 'preliminary-stable-builds' on my
mirror. At the same time I have already prepared PPA to maintain
'stable-builds' on the build-farm. That is to say, that I am ready
to maintain maintanance releases R14.0.x.
What is your opinion - when is the time to create branch and start
the 'maintanance mode'?
3:14 a.m.
New subject: [trinity-devel] Using branches in the future development (was Re: [trinity-devel] R14 hard freeze for RC1)
<snip>
Option 3) would have more weight if our team was larger and had also been
detailed roadmap of the upcoming development. In our situation, however, I
believe that for our small team would present higher demands to maintain.
Agree in full, as I also said before. We can switch to option 3 at a
later stage if out team grows over time
For option 2) I had the intention of following
sub-options:
2a) release major version from 'master' branch:
__R14.1.1___R14.1.2___R14.1.3
/
/ __R15.0.1
/ /
= R14.0.0 === R14.1.0 === R14.2.0 === R15.0.0 === R15.1.0
\ \
\ \__R14.2.1___R14.2.2
\
\__R14.0.1___R14.0.2___R14.0.3
2b) release all versions from 'maintanance' branches:
__R14.1.0___R14.1.1___R14.1.2
/
/ __R15.0.0
/ /
= R14.0.x === R14.1.x === R14.2.x === R15.0.x === R15.1.x
\ \
\ \__R14.2.1___R14.2.2
\
\__R14.0.0___R14.0.1___R14.0.2
I prefer option 2b). The main trunk is the development trunk and so
should keep moving forward any time. When we want to release a new
version (major, minor, maintenance), we branch as described.
I understand "nightly-builds" in the sense
that their mission is to keep at
the forefront of the development branch. And I consider it to be correct. On
the primary site is running several automation processes, whose mission is
related to the maintenance of the development 'master' branch. For example,
automatic updating of the submodules in 'tde' repository, generate page with
commits, preparing packages for nightly-builds, update 'po' files,... all
these processes need git repository on "constantly same branch".
If should be addressed on the primary site also other
branches, it would only
make sense that on the primary site was simultaneously more clones whole git
repositories and automation scripts separately for each such branch. Anything
else would be prone to confusion. However, this is not necessary. As I
mentioned in a previous email, I am ready to maintain new 'maintanance'
branch and provide the necessary automation processes. This way we have
successfully verified while working on v3.5.13-sru branch.
I understand from Tim's mail that there are limitations on what it
possible to do on the primary nightly-build site and I won't argue
against them since I have no knowledge of the internal mechanisms involved.
It's ok for me if you want to maintain the new branches.
The only thing that is still a little blurry in my mind is this: once
v14.0.0 is release and we create the v14.0.0 branch, the main trunk will
be for v14.1.x. So how are we going to build v14.0.1 when the time for
the first maintenance release comes? Are we going to use your own
builder for this?
Cheers
Michele
4:02 a.m.
New subject: [trinity-devel] Using branches in the future development (was Re: [trinity-devel] R14 hard freeze for RC1)
On Thursday 16 of October 2014 05:14:49 Michele Calgaro wrote:
<snip>
Packages I upload to my PPA on build-farm, where they will build. This
corresponds to the links that I sent in the previous mail. From such a PPA
Tim then can copy the packages into the official repository - to the mirrors.
Now I have it so that the same source packages I'll send to the build-farm and
in addition also to my builder => my alternative mirror, where in addition
are builds for Wheezy on MIPS and PowerPC.
--
Slávek
Option 3) would have more weight if our team was
larger and had also been
detailed roadmap of the upcoming development. In our situation, however,
I believe that for our small team would present higher demands to
maintain.
Agree in full, as I also said before. We can switch to option 3 at a
later stage if out team grows over time
For option 2) I had the intention of following
sub-options:
2a) release major version from 'master' branch:
__R14.1.1___R14.1.2___R14.1.3
/
/ __R15.0.1
/ /
= R14.0.0 === R14.1.0 === R14.2.0 === R15.0.0 === R15.1.0
\ \
\ \__R14.2.1___R14.2.2
\
\__R14.0.1___R14.0.2___R14.0.3
2b) release all versions from 'maintanance' branches:
__R14.1.0___R14.1.1___R14.1.2
/
/ __R15.0.0
/ /
= R14.0.x === R14.1.x === R14.2.x === R15.0.x === R15.1.x
\ \
\ \__R14.2.1___R14.2.2
\
\__R14.0.0___R14.0.1___R14.0.2
I prefer option 2b). The main trunk is the development trunk and so
should keep moving forward any time. When we want to release a new
version (major, minor, maintenance), we branch as described.
I understand "nightly-builds" in the
sense that their mission is to keep
at the forefront of the development branch. And I consider it to be
correct. On the primary site is running several automation processes,
whose mission is related to the maintenance of the development 'master'
branch. For example, automatic updating of the submodules in 'tde'
repository, generate page with commits, preparing packages for
nightly-builds, update 'po' files,... all these processes need git
repository on "constantly same branch".
If should be addressed on the primary site also other branches, it would
only make sense that on the primary site was simultaneously more clones
whole git repositories and automation scripts separately for each such
branch. Anything else would be prone to confusion. However, this is not
necessary. As I mentioned in a previous email, I am ready to maintain new
'maintanance' branch and provide the necessary automation processes. This
way we have successfully verified while working on v3.5.13-sru branch.
I understand from Tim's mail that there are limitations on what it
possible to do on the primary nightly-build site and I won't argue
against them since I have no knowledge of the internal mechanisms involved.
It's ok for me if you want to maintain the new branches.
The only thing that is still a little blurry in my mind is this: once
v14.0.0 is release and we create the v14.0.0 branch, the main trunk will
be for v14.1.x. So how are we going to build v14.0.1 when the time for
the first maintenance release comes? Are we going to use your own
builder for this?
Cheers
Michele
4 Dec
4 Dec
4 a.m.
New subject: R14.0.x branch
On 10/16/2014 01:02 PM, Slávek Banko wrote:
On Thursday 16 of October 2014 05:14:49 Michele
Calgaro wrote:
Tim, Slavek,
I think it is now time we start thinking about the R14.0.x branch.
IMO, we can wait until R14.0.0 is released, given that we have waited until now. Then we
create a R14.0.x branch on the
main repo which will be the development branch for any R14.0.x maintenance release.
The trunk will remain the development branch for R14.1.0.
From earlier discussions we had some months ago, my understanding is that the build farm
will continue to build nightly
builds based on the main development branch, while Slavek's builder will take care of
building the R14.0.x releases when
ready (or perhaps some periodical nightly build as well). Is this still correct?
Cheers
Michele
<snip>
Packages I upload to my PPA on build-farm, where they will build. This
corresponds to the links that I sent in the previous mail. From such a PPA
Tim then can copy the packages into the official repository - to the mirrors.
Now I have it so that the same source packages I'll send to the build-farm and
in addition also to my builder => my alternative mirror, where in addition
are builds for Wheezy on MIPS and PowerPC.
Option 3) would have more weight if our team was
larger and had also been
detailed roadmap of the upcoming development. In our situation, however,
I believe that for our small team would present higher demands to
maintain.
Agree in full, as I also said before. We can switch to option 3 at a
later stage if out team grows over time
For option 2) I had the intention of following
sub-options:
2a) release major version from 'master' branch:
__R14.1.1___R14.1.2___R14.1.3
/
/ __R15.0.1
/ /
= R14.0.0 === R14.1.0 === R14.2.0 === R15.0.0 === R15.1.0
\ \
\ \__R14.2.1___R14.2.2
\
\__R14.0.1___R14.0.2___R14.0.3
2b) release all versions from 'maintanance' branches:
__R14.1.0___R14.1.1___R14.1.2
/
/ __R15.0.0
/ /
= R14.0.x === R14.1.x === R14.2.x === R15.0.x === R15.1.x
\ \
\ \__R14.2.1___R14.2.2
\
\__R14.0.0___R14.0.1___R14.0.2
I prefer option 2b). The main trunk is the development trunk and so
should keep moving forward any time. When we want to release a new
version (major, minor, maintenance), we branch as described.
I understand "nightly-builds" in the
sense that their mission is to keep
at the forefront of the development branch. And I consider it to be
correct. On the primary site is running several automation processes,
whose mission is related to the maintenance of the development 'master'
branch. For example, automatic updating of the submodules in 'tde'
repository, generate page with commits, preparing packages for
nightly-builds, update 'po' files,... all these processes need git
repository on "constantly same branch".
If should be addressed on the primary site also other branches, it would
only make sense that on the primary site was simultaneously more clones
whole git repositories and automation scripts separately for each such
branch. Anything else would be prone to confusion. However, this is not
necessary. As I mentioned in a previous email, I am ready to maintain new
'maintanance' branch and provide the necessary automation processes. This
way we have successfully verified while working on v3.5.13-sru branch.
I understand from Tim's mail that there are limitations on what it
possible to do on the primary nightly-build site and I won't argue
against them since I have no knowledge of the internal mechanisms involved.
It's ok for me if you want to maintain the new branches.
The only thing that is still a little blurry in my mind is this: once
v14.0.0 is release and we create the v14.0.0 branch, the main trunk will
be for v14.1.x. So how are we going to build v14.0.1 when the time for
the first maintenance release comes? Are we going to use your own
builder for this?
Cheers
Michele
8 Dec
8 Dec
6:04 p.m.
New subject: [trinity-devel] R14.0.x branch
Dne čt 4. prosince 2014 Michele Calgaro napsal(a):
On 10/16/2014 01:02 PM, Slávek Banko wrote:
Yes, I suppose it exactly the same. After tagging v14.0.0 and create branch
v14.0.x, nightly-builds will continue on 'master' branch to target R14.1.0,
while my ppa on build-farm as well as my alternate apt repository will
continue on 'v14.0.x' branch to target R14.0.1.
By the way, Tim, this will be an opportunity in the official nightly-build
switch to using '~' in the version numbers.
--
Slávek
On Thursday 16 of October 2014 05:14:49 Michele
Calgaro wrote:
Tim, Slavek,
I think it is now time we start thinking about the R14.0.x branch.
IMO, we can wait until R14.0.0 is released, given that we have waited until
now. Then we create a R14.0.x branch on the main repo which will be the
development branch for any R14.0.x maintenance release. The trunk will
remain the development branch for R14.1.0.
From earlier discussions we had some months ago, my understanding is that
the build farm will continue to build nightly builds based on the main
development branch, while Slavek's builder will take care of building the
R14.0.x releases when ready (or perhaps some periodical nightly build as
well). Is this still correct?
Cheers
Michele
<snip>
Packages I upload to my PPA on build-farm, where they will build. This
corresponds to the links that I sent in the previous mail. From such a
PPA Tim then can copy the packages into the official repository - to the
mirrors.
Now I have it so that the same source packages I'll send to the
build-farm and in addition also to my builder => my alternative mirror,
where in addition are builds for Wheezy on MIPS and PowerPC. Option 3) would have more weight if our team was
larger and had also
been detailed roadmap of the upcoming development. In our situation,
however, I believe that for our small team would present higher demands
to maintain.
Agree in full, as I also said before. We can switch to option 3 at a
later stage if out team grows over time
For option 2) I had the intention of following
sub-options:
2a) release major version from 'master' branch:
__R14.1.1___R14.1.2___R14.1.3
/
/ __R15.0.1
/ /
= R14.0.0 === R14.1.0 === R14.2.0 === R15.0.0 === R15.1.0
\ \
\ \__R14.2.1___R14.2.2
\
\__R14.0.1___R14.0.2___R14.0.3
2b) release all versions from 'maintanance' branches:
__R14.1.0___R14.1.1___R14.1.2
/
/ __R15.0.0
/ /
= R14.0.x === R14.1.x === R14.2.x === R15.0.x === R15.1.x
\ \
\ \__R14.2.1___R14.2.2
\
\__R14.0.0___R14.0.1___R14.0.2
I prefer option 2b). The main trunk is the development trunk and so
should keep moving forward any time. When we want to release a new
version (major, minor, maintenance), we branch as described.
I understand "nightly-builds" in the
sense that their mission is to
keep at the forefront of the development branch. And I consider it to
be correct. On the primary site is running several automation
processes, whose mission is related to the maintenance of the
development 'master' branch. For example, automatic updating of the
submodules in 'tde' repository, generate page with commits, preparing
packages for nightly-builds, update 'po' files,... all these processes
need git repository on "constantly same branch".
If should be addressed on the primary site also other branches, it
would only make sense that on the primary site was simultaneously more
clones whole git repositories and automation scripts separately for
each such branch. Anything else would be prone to confusion. However,
this is not necessary. As I mentioned in a previous email, I am ready
to maintain new 'maintanance' branch and provide the necessary
automation processes. This way we have successfully verified while
working on v3.5.13-sru branch.
I understand from Tim's mail that there are limitations on what it
possible to do on the primary nightly-build site and I won't argue
against them since I have no knowledge of the internal mechanisms
involved. It's ok for me if you want to maintain the new branches.
The only thing that is still a little blurry in my mind is this: once
v14.0.0 is release and we create the v14.0.0 branch, the main trunk will
be for v14.1.x. So how are we going to build v14.0.1 when the time for
the first maintenance release comes? Are we going to use your own
builder for this?
Cheers
Michele
9 Dec
9 Dec
11:31 p.m.
New subject: [trinity-devel] R14.0.x branch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
Dne čt 4. prosince 2014 Michele Calgaro napsal(a):
Tags and branches created. I did not create a branch for the
tde-packaging repository as I don't think it will be needed; if this
proves to be wrong in the future it can be easily corrected.
On 10/16/2014 01:02 PM, Slávek Banko wrote:
the
Yes, I suppose it exactly the same. After tagging v14.0.0 and create
branch
v14.0.x, nightly-builds will continue on 'master' branch to target
R14.1.0,
while my ppa on build-farm as well as my alternate apt repository will
continue on 'v14.0.x' branch to target R14.0.1. On Thursday 16 of October 2014 05:14:49 Michele
Calgaro wrote:
> <snip>
>
>> Option 3) would have more weight if our team was larger and had also
>> been detailed roadmap of the upcoming development. In our situation,
>> however, I believe that for our small team would present higher
demands
>> to maintain.
>
> Agree in full, as I also said before. We can switch to option 3 at a
> later stage if out team grows over time
>
>> For option 2) I had the intention of following sub-options:
>>
>> 2a) release major version from 'master' branch:
>>
>> __R14.1.1___R14.1.2___R14.1.3
>> /
>> / __R15.0.1
>> / /
>> = R14.0.0 === R14.1.0 === R14.2.0 === R15.0.0 === R15.1.0
>> \ \
>> \ \__R14.2.1___R14.2.2
>> \
>> \__R14.0.1___R14.0.2___R14.0.3
>>
>>
>> 2b) release all versions from 'maintanance' branches:
>>
>> __R14.1.0___R14.1.1___R14.1.2
>> /
>> / __R15.0.0
>> / /
>> = R14.0.x === R14.1.x === R14.2.x === R15.0.x === R15.1.x
>> \ \
>> \ \__R14.2.1___R14.2.2
>> \
>> \__R14.0.0___R14.0.1___R14.0.2
>
> I prefer option 2b). The main trunk is the development trunk and so
> should keep moving forward any time. When we want to release a new
> version (major, minor, maintenance), we branch as described.
>
>> I understand "nightly-builds" in the sense that their mission is to
>> keep at the forefront of the development branch. And I consider it
to
>> be correct. On the primary site is
running several automation
>> processes, whose mission is related to the maintenance of the
>> development 'master' branch. For example, automatic updating of the
>> submodules in 'tde' repository, generate page with commits,
preparing
>> packages for nightly-builds, update
'po' files,... all these
processes
>> need git repository on "constantly
same branch".
>>
>> If should be addressed on the primary site also other branches, it
>> would only make sense that on the primary site was simultaneously
more
>> clones whole git repositories and
automation scripts separately for
>> each such branch. Anything else would be prone to confusion.
However,
>> this is not necessary. As I mentioned in
a previous email, I am
ready
>> to maintain new 'maintanance'
branch and provide the necessary
>> automation processes. This way we have successfully verified while
>> working on v3.5.13-sru branch.
>
> I understand from Tim's mail that there are limitations on what it
> possible to do on the primary nightly-build site and I won't argue
> against them since I have no knowledge of the internal mechanisms
> involved. It's ok for me if you want to maintain the new branches.
> The only thing that is still a little blurry in my mind is this: once
> v14.0.0 is release and we create the v14.0.0 branch, the main trunk
will
> be for v14.1.x. So how are we going to build
v14.0.1 when the time
for
the first
maintenance release comes? Are we going to use your own
builder for this?
Cheers
Michele
Packages I upload to my PPA on build-farm, where they will build. This
corresponds to the links that I sent in the previous mail. From such a
PPA Tim then can copy the packages into the official repository - to mirrors.
Now I have it so that the same source packages I'll send to the
build-farm and in addition also to my builder => my alternative
mirror,
where in addition are builds for Wheezy on MIPS
and PowerPC.
Tim, Slavek,
I think it is now time we start thinking about the R14.0.x branch.
IMO, we can wait until R14.0.0 is released, given that we have waited
until
now. Then we create a R14.0.x branch on the main repo which will be the
development branch for any R14.0.x maintenance release. The trunk will
remain the development branch for R14.1.0.
From earlier discussions we had some months ago, my understanding is
that
the build farm will continue to build nightly builds based on the main
development branch, while Slavek's builder will take care of building
the
R14.0.x releases when ready (or perhaps some periodical nightly build as
well). Is this still correct?
Cheers
Michele
By the way, Tim, this will be an opportunity in the
official nightly-build
switch to using '~' in the version numbers.
Can you elaborate further? I don't recall a recent discussion on this.
Thanks!
Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iFYEARELAAYFAlSHhigACgkQLaxZSoRZrGEPWwDeI+1Eu2pXIECwl7BNGXFJwAfw
w7jElEgKsGgcPADfdGNbDkVUaCMFW/oSekGehJYQ78RkPdUpSvrY6A==
=jJOW
-----END PGP SIGNATURE-----
10 Dec
10 Dec
12:47 a.m.
New subject: [trinity-devel] R14.0.x branch
On Wednesday 10 of December 2014 00:31:09 Timothy Pearson wrote:
Branch on tde-packaging was necessary in v3.5.13.x era and we can assume that
it will be useful also for R14.0.x. However, it may be created when will be
ready also packages for other distributions.
I tested that I need to properly fix scripts/create_tarball, because due to
the initial character in tag name fails sort of tags by version number.
Remember to v3.5.13.2 branch: preliminary packages was version 3.5.13.2~preXXX
and thanks to using the character '~', packages for final version can have
version number simply 3.5.13.2 == clear final version number.
Dne čt 4.
prosince 2014 Michele Calgaro napsal(a):
Tags and branches created. I did not create a branch for the
tde-packaging repository as I don't think it will be needed; if this
proves to be wrong in the future it can be easily corrected.
On 10/16/2014 01:02 PM, Slávek Banko wrote:
Yes, I suppose it exactly the same. After tagging v14.0.0 and create
branch
v14.0.x, nightly-builds will continue on 'master' branch to target
R14.1.0,
while my ppa on build-farm as well as my alternate apt repository will
continue on 'v14.0.x' branch to target R14.0.1. On Thursday 16 of October 2014 05:14:49 Michele
Calgaro wrote:
> <snip>
>
>> Option 3) would have more weight if our team was larger and had also
>> been detailed roadmap of the upcoming development. In our situation,
>> however, I believe that for our small team would present higher
demands
>> to maintain.
>
> Agree in full, as I also said before. We can switch to option 3 at a
> later stage if out team grows over time
>
>> For option 2) I had the intention of following sub-options:
>>
>> 2a) release major version from 'master' branch:
>>
>> __R14.1.1___R14.1.2___R14.1.3
>> /
>> / __R15.0.1
>> / /
>> = R14.0.0 === R14.1.0 === R14.2.0 === R15.0.0 === R15.1.0
>> \ \
>> \ \__R14.2.1___R14.2.2
>> \
>> \__R14.0.1___R14.0.2___R14.0.3
>>
>>
>> 2b) release all versions from 'maintanance' branches:
>>
>> __R14.1.0___R14.1.1___R14.1.2
>> /
>> / __R15.0.0
>> / /
>> = R14.0.x === R14.1.x === R14.2.x === R15.0.x === R15.1.x
>> \ \
>> \ \__R14.2.1___R14.2.2
>> \
>> \__R14.0.0___R14.0.1___R14.0.2
>
> I prefer option 2b). The main trunk is the development trunk and so
> should keep moving forward any time. When we want to release a new
> version (major, minor, maintenance), we branch as described.
>
>> I understand "nightly-builds" in the sense that their mission is to
>> keep at the forefront of the development branch. And I consider it
to
>> be correct. On the primary site is
running several automation
>> processes, whose mission is related to the maintenance of the
>> development 'master' branch. For example, automatic updating of the
>> submodules in 'tde' repository, generate page with commits,
preparing
>> packages for nightly-builds, update
'po' files,... all these
processes
>> need git repository on "constantly
same branch".
>>
>> If should be addressed on the primary site also other branches, it
>> would only make sense that on the primary site was simultaneously
more
>> clones whole git repositories and
automation scripts separately for
>> each such branch. Anything else would be prone to confusion.
However,
>> this is not necessary. As I mentioned in
a previous email, I am
ready
>> to maintain new 'maintanance'
branch and provide the necessary
>> automation processes. This way we have successfully verified while
>> working on v3.5.13-sru branch.
>
> I understand from Tim's mail that there are limitations on what it
> possible to do on the primary nightly-build site and I won't argue
> against them since I have no knowledge of the internal mechanisms
> involved. It's ok for me if you want to maintain the new branches.
> The only thing that is still a little blurry in my mind is this: once
> v14.0.0 is release and we create the v14.0.0 branch, the main trunk
will
> be for v14.1.x. So how are we going to build
v14.0.1 when the time
for
> the first maintenance release comes? Are we
going to use your own
> builder for this?
>
> Cheers
> Michele
Packages I upload to my PPA on build-farm, where they will build. This
corresponds to the links that I sent in the previous mail. From such a
PPA Tim then can copy the packages into the official repository - to
the
mirrors.
Now I have it so that the same source packages I'll send to the
build-farm and in addition also to my builder => my alternative
mirror,
where in addition are builds for Wheezy on MIPS
and PowerPC.
Tim, Slavek,
I think it is now time we start thinking about the R14.0.x branch.
IMO, we can wait until R14.0.0 is released, given that we have waited
until
now. Then we create a R14.0.x branch on the main repo which will be the
development branch for any R14.0.x maintenance release. The trunk will
remain the development branch for R14.1.0.
From earlier discussions we had some months ago, my understanding is
that
the build farm will continue to build nightly builds based on the main
development branch, while Slavek's builder will take care of building
the
R14.0.x releases when ready (or perhaps some periodical nightly build as
well). Is this still correct?
Cheers
Michele By the way,
Tim, this will be an opportunity in the official
nightly-build switch to using '~' in the version numbers.
Can you elaborate further? I don't recall a recent discussion on this.
Thanks!
Tim
--
Slávek
2:34 a.m.
New subject: [trinity-devel] R14.0.x branch
On 12/10/2014 09:47 AM, Slávek Banko wrote:
IMO it is better to create a branch now rather than later.
Work on v14.1.0 and v14.0.x will probably progress in different ways sooner or later. For
example, if we do some package
or file renaming, the packaging files will need to be different for the two branches.
So better to keep things in order from the beginning and have a branch on the main repo
and on the packaging repo going
"side-by-side".
Just my 2 cents.
Cheers
Michele
Tags and
branches created. I did not create a branch for the
>tde-packaging repository as I don't think it will be needed; if this
>proves to be wrong in the future it can be easily corrected.
>
Branch on tde-packaging was necessary in v3.5.13.x era and we can assume
that
it will be useful also for R14.0.x. However, it may be created when will be
ready also packages for other distributions.
I tested that I need to properly fix scripts/create_tarball, because due to
the initial character in tag name fails sort of tags by version number.
3:28 a.m.
New subject: [trinity-devel] R14.0.x branch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
On 12/10/2014 09:47 AM, Slávek Banko wrote:
IMO it is better to create a branch now rather than later.
Work on v14.1.0 and v14.0.x will probably progress in different ways
sooner or later. For example, if we do some package
or file renaming, the packaging files will need to be different for the
two branches.
So better to keep things in order from the beginning and have a branch on
the main repo and on the packaging repo going
"side-by-side".
Just my 2 cents.
Cheers
Michele
OK, I think I see the point. Branched. :-)
Tim
Tags and
branches created. I did not create a branch for the
>tde-packaging repository as I don't think it will be needed; if this
>proves to be wrong in the future it can be easily corrected.
>
Branch on tde-packaging was necessary in v3.5.13.x era and we can assume
that
it will be useful also for R14.0.x. However, it may be created when will
be
ready also packages for other distributions.
I tested that I need to properly fix scripts/create_tarball, because due
to
the initial character in tag name fails sort of tags by version number.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iFYEARELAAYFAlSHvfQACgkQLaxZSoRZrGGf+gDgx6mMT1mhCOgL0/CQ7qN9/5rg
1tTY9dCq0iiRygDgsk5akG9fwSgd9kfD4JL/S9DHwnkw4iQPtkUc5g==
=ZUGb
-----END PGP SIGNATURE-----
15 Oct
15 Oct
4:09 a.m.
New subject: [trinity-devel] R14 hard freeze for RC1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
My two cents about bug and development through the
freeze period.
1) About the remaining 3 bugs.
- bug 1850: I don't see it as fully blocking. WE could release v14.0.0
even if not control module tabs have been updated to open the correct
handbook. Of course it would be nice to fully close the bug, but if not
we can leave the remaining things for the first subsequent maintenance
release v14.0.1
Considering the amount of time required for the archive rebuild I would
think we can close this report out for RC2/R14 final, especially with more
than one developer working on it as it is mostly grunt work.
- bug 1859: documentation is almost fully updated (I
still have a few
list to do, which I should be able (or at least I hope) to do within
this week. I can push all the doc updates in one cumulative push when
ready. After that there are two more things to do. One is sorting the
top level list (not critical, but should not be too long) and one is to
add a button for manually updating the top level list (this is more
important)
Sounds good!
- bug 2152: I haven't look at the details, but
based on the two commits
already made by Slavek it should not take long to fix.
Yeah, I was already looking at it. I'm tentatively working on digikam if
you or Slavek want to tackle koffice.
2) about freezing, development and v14.0.x
Tim, is it possible to create a GIT branch for v14.0.0 so that we can
keep pushing patches *not to be in v14.0.0* to the main trunk? The main
question here is actually "how are we going to maintain the v14.0.x
branch when v14.0.0 has been release and the main trunk will be for
v14.1.0"?
Ah yes, the branch issue. Slavek posted some good ideas in his reply to
this message; conceptually branching is a good idea but the devil is in
the details. We use several automated systems to not only provide
services (the build farm and patchset generator) but also to work around
GIT misfeatures such as the lack of automatically-tracking submodules. I
need to carefully consider the technical end of this (including
scalability and load on the already overtaxed servers) before jumping in
and committing to a particular scheme.
Short answer: If I can technically make branching work in a somewhat
intuitive manner without overloading the servers Slavek's option 2 sounds
best. This means we won't branch at this point anyway, so I have a bit of
breathing room to work on the site and such before RC1 release.
Cheers
Michele
Thanks for starting the discussion Michele!
Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iFYEARELAAYFAlQ983MACgkQLaxZSoRZrGEx5ADeNYtJaoJmUaRXV3HYDtrsXQu8
PvsdRiOpkr340gDghJzNpVIIylDuByl8o8lBdOMHQq279JCb/wbgcA==
=wm7b
-----END PGP SIGNATURE-----
8:58 a.m.
New subject: [trinity-devel] R14 hard freeze for RC1
- bug 2152: I
haven't look at the details, but based on the two commits
already made by Slavek it should not take long to fix.
Yeah, I was already looking at it. I'm tentatively working on digikam if
you or Slavek want to tackle koffice. Short answer: If I can technically make branching work
in a somewhat
intuitive manner without overloading the servers Slavek's option 2 sounds
best. This means we won't branch at this point anyway, so I have a bit of
breathing room to work on the site and such before RC1 release.
In the worst case,
I think it would be a good idea to at least create a
temporary "development branch" where patches can be pushed while the
hard freeze is in place for v14.0.0. After v14.0.0 is released, the
changes made can be merged into the main trunk.
Cheers
Michele
9:07 a.m.
New subject: [trinity-devel] R14 hard freeze for RC1
On Wednesday 15 of October 2014 10:58:58 Michele Calgaro wrote:
I will not work on this bug since I want to complete bug 1859 first and
eventually join bug 1850.
I have currently working on patches from bug 2110 and at the same time on the
modifications tdebase in tde-packaging. As a result of renaming the icons
need to be updated - now causes FTBFS.
I am afraid that with the branches is the same as with the tags - after
creating on the server branch synchronizes to users, but after remove on the
server users will have to worry about removing branch == all the users
themselves. This is not good. Therefore, I am not a fan of temporary branches
on the server.
- bug 2152: I haven't look at the details, but
based on the two commits
already made by Slavek it should not take long to fix.
Yeah, I was already looking at it. I'm tentatively working on digikam if
you or Slavek want to tackle koffice. Short answer:
If I can technically make branching work in a somewhat
intuitive manner without overloading the servers Slavek's option 2 sounds
best. This means we won't branch at this point anyway, so I have a bit
of breathing room to work on the site and such before RC1 release.
In the worst case, I think it would be a good idea to at least create a
temporary "development branch" where patches can be pushed while the
hard freeze is in place for v14.0.0. After v14.0.0 is released, the
changes made can be merged into the main trunk.
Cheers
Michele
--
Slávek
2:38 p.m.
New subject: [trinity-devel] R14 hard freeze for RC1
> In the worst case, I think it would be a good idea
to at least create a
> temporary "development branch" where patches can be pushed while the
> hard freeze is in place for v14.0.0. After v14.0.0 is released, the
> changes made can be merged into the main trunk.
>
I am afraid that with the branches is the same as with
the tags - after
creating on the server branch synchronizes to users, but after remove on the
server users will have to worry about removing branch == all the users
themselves. This is not good. Therefore, I am not a fan of temporary branches
on the server.
The temporary branch would be just for us developers, not for the main users, to be able
to comtinue development. And given that we are just 5 people, I tihnk it would be
managable.
Nevertheless I would still prefer to branch as you described in option 2 earlier today.
Tim, I don't know how the build farm works internally, but perhaps the following idea
could be useful.
- create a file with the list of all modules that should be built. For each module
indicate whether to build against the current source in the master branch or against a
particular GIT hash in a particular branch.
- modify the build process to read the file above and checkout the proper branch and
commit for each module, then build the module
In this way, when we want to build "standard" nightly build packages, we just
say to build againast the current source and master branch
When we want to build a specific image (for example RC1, RC2, v14.0.0 and later versions)
we use a different index file which contains the correct information for such build. This
would also to build different "versions" any time we want.
Just an idea, as I said I do not know the internal mechanisms of the build farm.
Cheers
Michele
3:01 p.m.
New subject: [trinity-devel] R14 hard freeze for RC1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
As I alluded to before while these things are certainly possible the sheer
size of TDE (well over 150 separate GIT repositories) tends to make
temporary anything impractical--I spend more time setting it up, managing
it, and tearing it down than any time saved in between.
There are limits to what I can do with the build farm due to Debian
requiring monotonically increasing version numbers. Likely there would
need to be a separate R14 PPA that tracks the "master" of the R14 branch;
this is not feasible at this time due to the sheer size of the R14 archive
and paucity of financial support. Look at it this way--if we started
doing things like this (multiple 30GB PPAs of the same project at slightly
different code revisions) on the free public Launchpad system we would be
restricted very rapidly if not kicked off entirely. PPAs on Launchpad are
only 2GB in size for a reason--it gets very expensive very fast to scale
out, and no one is directly paying for the space they use in Launchpad.
Same applies here. :-)
I am working on the new site right now, so I probably won't be tracking
this discussion closely. I'll come back to it once RC1 is out, so please
don't finalize anything in my absence.
Thanks!
Tim
> In the
worst case, I think it would be a good idea to at least create a
> temporary "development branch" where patches can be pushed while the
> hard freeze is in place for v14.0.0. After v14.0.0 is released, the
> changes made can be merged into the main trunk.
>
I am afraid that with the branches is the same as
with the tags - after
creating on the server branch synchronizes to users, but after remove on
the
server users will have to worry about removing branch == all the users
themselves. This is not good. Therefore, I am not a fan of temporary
branches
on the server.
The temporary branch would be just for us developers, not for the main
users, to be able to comtinue development. And given that we are just 5
people, I tihnk it would be managable.
Nevertheless I would still prefer to branch as you described in option 2
earlier today.
Tim, I don't know how the build farm works internally, but perhaps the
following idea could be useful.
- create a file with the list of all modules that should be built. For
each module indicate whether to build against the current source in the
master branch or against a particular GIT hash in a particular branch.
- modify the build process to read the file above and checkout the proper
branch and commit for each module, then build the module
In this way, when we want to build "standard" nightly build packages, we
just say to build againast the current source and master branch
When we want to build a specific image (for example RC1, RC2, v14.0.0 and
later versions) we use a different index file which contains the correct
information for such build. This would also to build different "versions"
any time we want.
Just an idea, as I said I do not know the internal mechanisms of the build
farm.
Cheers
Michele -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iFYEARELAAYFAlQ+jDEACgkQLaxZSoRZrGHsywDcD38UaCcDMgu8WzV3yJAi+fMT
p9T0p6dP17+OXwDfR+NuOyVbdBjqFaZtQpDDwv8sth8UTl67/YOK0w==
=DQcG
-----END PGP SIGNATURE-----
3:39 p.m.
New subject: [trinity-devel] R14 hard freeze for RC1
I appreciate the discussion about branching. I prefer a different view: no branches. Just
leave git as-is. Patches affecting post R14.0.0 are not pushed to git. If inadvertently
pushed, those patches are reverted until post R14.0.0. Attach all post R14.0.0 patches to
a respective bug report with a note not to push until post R14.0.0.
If uncertain during the freeze period, push privileges could be temporarily suspended or
limited to two people.
The whole branching topic makes my head hurt. Based on the discussion I suspect my head is
not the only that spins. Planes circle airports waiting to land because there is a limited
number of usable runways. Use the same analogy for pushing patches. Where is the rush?
Especially considering how long many Trinity patches tend to sit untouched in bug reports
anyway.
Regarding the three unfinished bug reports, just finish them. Again, where is the rush?
Darrell
16 Oct
16 Oct
12:11 a.m.
New subject: [trinity-devel] R14 hard freeze for RC1
On Wednesday 15 of October 2014 17:39:06 Darrell wrote:
I appreciate the discussion about branching. I prefer
a different view: no
branches. Just leave git as-is. Patches affecting post R14.0.0 are not
pushed to git. If inadvertently pushed, those patches are reverted until
post R14.0.0. Attach all post R14.0.0 patches to a respective bug report
with a note not to push until post R14.0.0.
If uncertain during the freeze period, push privileges could be temporarily
suspended or limited to two people.
The whole branching topic makes my head hurt. Based on the discussion I
suspect my head is not the only that spins. Planes circle airports waiting
to land because there is a limited number of usable runways. Use the same
analogy for pushing patches. Where is the rush? Especially considering how
long many Trinity patches tend to sit untouched in bug reports anyway.
Regarding the three unfinished bug reports, just finish them. Again, where
is the rush?
Darrell
I dare say that the work on v3.5.13-sru branch are obvious proof that it is
not a good idea to consider option 1) do not use branches at all.
--
Slávek
3:17 a.m.
New subject: [trinity-devel] R14 hard freeze for RC1
<snip>
As I alluded to before while these things are
certainly possible the sheer
size of TDE (well over 150 separate GIT repositories) tends to make
temporary anything impractical--I spend more time setting it up, managing
it, and tearing it down than any time saved in between.
There are limits to what I can do with the build farm due to Debian
requiring monotonically increasing version numbers. Likely there would
need to be a separate R14 PPA that tracks the "master" of the R14 branch;
this is not feasible at this time due to the sheer size of the R14 archive
and paucity of financial support. Look at it this way--if we started
doing things like this (multiple 30GB PPAs of the same project at slightly
different code revisions) on the free public Launchpad system we would be
restricted very rapidly if not kicked off entirely. PPAs on Launchpad are
only 2GB in size for a reason--it gets very expensive very fast to scale
out, and no one is directly paying for the space they use in Launchpad.
Same applies here. :-)
I am working on the new site right now, so I probably won't be tracking
this discussion closely. I'll come back to it once RC1 is out, so please
don't finalize anything in my absence.
Yeap, no problem Tim. As I said, mine was just an idea since I don't
have knowledge of how the primary nightly build site works internally.
Cheers
Michele
15 Oct
15 Oct
9:20 p.m.
New subject: [trinity-devel] R14 hard freeze for RC1
Le 14/10/2014 19:08, Timothy Pearson a écrit :
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
All,
As you can probably see from the activity on the trinity-commits list
there have been multiple updates to both the common cmake/admin modules
and the icons across the entire tree over the past week or so.
Hello,
nice to hear we are closer and closer to the release :-)
are you still working on the icons renaming ?
Using the current git tree, I've lost the "categories" icons in my
kicker menu, only for icons that were renamed ...
François
16 Oct
16 Oct
4:08 a.m.
New subject: [trinity-devel] R14 hard freeze for RC1
On Wednesday 15 of October 2014 23:20:54 François Andriot wrote:
Le 14/10/2014 19:08, Timothy Pearson a écrit :
I can confirm that with the current GIT versions tdelibs + tdebase also miss
many icons in the kicker menu and kcontrol. Exactly - all icons from
categories folder. It appears that it is suitable for filling a new bug!
--
Slávek
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
All,
As you can probably see from the activity on the trinity-commits list
there have been multiple updates to both the common cmake/admin modules
and the icons across the entire tree over the past week or so.
Hello,
nice to hear we are closer and closer to the release :-)
are you still working on the icons renaming ?
Using the current git tree, I've lost the "categories" icons in my
kicker menu, only for icons that were renamed ...
François
4:29 a.m.
New subject: [trinity-devel] R14 hard freeze for RC1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
On Wednesday 15 of October 2014 23:20:54 François
Andriot wrote:
I wasn't sure what the effect would be; if TDE was smart enough to go
hunting for the icons in the new categories folder or not. Guess not. :-)
The new bug report should block R14. I'll investigate as soon as I have a
basic build (tdelibs, tdebase, tdeartwork) out of the build farm to debug
with.
Tim
Le 14/10/2014 19:08, Timothy Pearson a écrit :
I can confirm that with the current GIT versions tdelibs + tdebase also
miss
many icons in the kicker menu and kcontrol. Exactly - all icons from
categories folder. It appears that it is suitable for filling a new bug!
--
Slávek -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
All,
As you can probably see from the activity on the trinity-commits list
there have been multiple updates to both the common cmake/admin
modules
and the icons across the entire tree over the
past week or so.
Hello,
nice to hear we are closer and closer to the release :-)
are you still working on the icons renaming ?
Using the current git tree, I've lost the "categories" icons in my
kicker menu, only for icons that were renamed ...
François
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iFYEARELAAYFAlQ/ScEACgkQLaxZSoRZrGHihwDeMLSptEg6MtHBvdGTC1UK56s/
C9pgAMihUdfc9ADeL7XMMj/mOG0f1HtAoh9pm3xFyRKtV03+R1lXDA==
=pWTV
-----END PGP SIGNATURE-----
2:51 p.m.
New subject: [trinity-devel] R14 hard freeze for RC1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
I'm pretty sure I found the problem but can't push a fix yet as it
involves tdelibs. I should be able to push it in the next few days.
Tim
On Wednesday 15 of October 2014 23:20:54 François
Andriot wrote:
I wasn't sure what the effect would be; if TDE was smart enough to go
hunting for the icons in the new categories folder or not. Guess not. :-)
The new bug report should block R14. I'll investigate as soon as I have a
basic build (tdelibs, tdebase, tdeartwork) out of the build farm to debug
with.
Tim Le 14/10/2014 19:08, Timothy Pearson a écrit :
I can confirm that with the current GIT versions tdelibs + tdebase also
miss
many icons in the kicker menu and kcontrol. Exactly - all icons from
categories folder. It appears that it is suitable for filling a new bug!
--
Slávek -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
All,
As you can probably see from the activity on the trinity-commits list
there have been multiple updates to both the common cmake/admin
modules
and the icons across the entire tree over the
past week or so.
Hello,
nice to hear we are closer and closer to the release :-)
are you still working on the icons renaming ?
Using the current git tree, I've lost the "categories" icons in my
kicker menu, only for icons that were renamed ...
François
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iFYEARELAAYFAlQ/21UACgkQLaxZSoRZrGGEXwDeNlj9Me6lPrXjTYQ4cFqILSTR
cyRydGxvprkLQQDeLaMnfuvAxUjpBmPjwAeFub5DcNfiWmaoN5/PCA==
=d0SA
-----END PGP SIGNATURE-----
11:35 p.m.
New subject: [trinity-devel] R14 hard freeze for RC1
On Thursday 16 of October 2014 16:51:01 Timothy Pearson wrote:
I'm pretty sure I found the problem but can't
push a fix yet as it
involves tdelibs. I should be able to push it in the next few days.
Please, can you attach patch to bug report 2166?
--
Slávek
23 Oct
23 Oct
3:02 a.m.
New subject: [trinity-devel] R14 hard freeze for RC1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
On Thursday 16 of October 2014 16:51:01 Timothy
Pearson wrote:
Just wanted to remind everyone that TDE is back in hard freeze while we
wait for the RC1 rebuilds after the recent changes to the common admin
module. The build farm should have R14 RC1 built in the next couple of
weeks.
As there were a number of changes to the icon names I need volunteers to
go through RC1 and carefully look for any missing icons (e.g. buttons,
dialogs, toolbars, etc. showing up with the default "unknown" icon instead
of the correct icon). I have scoured the tree carefully for errors as of
this point (there was a LOT of manual work involved in renaming the
icons), but it is possible that some incorrect names slipped through
anyway.
Thanks!
Tim
I'm pretty sure I found the problem but
can't push a fix yet as it
involves tdelibs. I should be able to push it in the next few days.
Please, can you attach patch to bug report 2166?
--
Slávek -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iFYEARELAAYFAlRIb9sACgkQLaxZSoRZrGFdnADg0VOKhEVGggwkcTvL9ES6lB0w
VybWTn30eiagswDfbIWjiPX360/P/uAkHNzM0Qb/qlU4WGFE5mSMfQ==
=SwRH
-----END PGP SIGNATURE-----
5:03 a.m.
New subject: [trinity-devel] R14 hard freeze for RC1
Le 23/10/2014 05:02, Timothy Pearson a écrit :
Just wanted to remind everyone that TDE is back in hard freeze while we
wait for the RC1 rebuilds after the recent changes to the common admin
module. The build farm should have R14 RC1 built in the next couple of
weeks.
As there were a number of changes to the icon names I need volunteers to
go through RC1 and carefully look for any missing icons (e.g. buttons,
dialogs, toolbars, etc. showing up with the default "unknown" icon instead
of the correct icon). I have scoured the tree carefully for errors as of
this point (there was a LOT of manual work involved in renaming the
icons), but it is possible that some incorrect names slipped through
anyway.
Thanks!
Tim
Hello,
FTBFS today in tdeaccessibility:
In file included from ksayit.all_cpp.cpp:15:0:
docbookclasses.cpp: In constructor
'KeywordSet::KeywordSet(ListViewInterface*, ListViewInterface*, TQString)':
docbookclasses.cpp:451:59: error: expected ')' before 'text'
TQPixmap pixmap = TDEGlobal::iconLoader()->loadIcon(""text-plain",
TDEIcon::Small);
^
In file included from DocTreeView.cpp:18:0,
from ksayit.all_cpp.cpp:19:
./DocTreeView.ui.h: At global scope:
./DocTreeView.ui.h:129:6: warning: unused parameter 'i' [-Wunused-parameter]
void DocTreeView::slotRightButtonPressed( TQListViewItem *i, const
TQPoint &, int )
^
In file included from ksayit.all_cpp.cpp:10:0:
ksayit.cpp: In member function 'void
KSayItApp::slotChangeBookmarkFilename(const TQString&)':
ksayit.cpp:297:38: warning: ignoring return value of 'int system(const
char*)', declared with attribute warn_unused_result [-Wunused-result]
system( command.ascii() );
^
make[4]: *** [ksayit.all_cpp.o] Error 1
make[4]: Leaving directory
`/dev/shm/BUILD.oss131.x86_64/trinity-tdeaccessibility-14.0.0~pre214+e0af5b18/ksayit/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/dev/shm/BUILD.oss131.x86_64/trinity-tdeaccessibility-14.0.0~pre214+e0af5b18/ksayit'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/dev/shm/BUILD.oss131.x86_64/trinity-tdeaccessibility-14.0.0~pre214+e0af5b18'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/dev/shm/BUILD.oss131.x86_64/trinity-tdeaccessibility-14.0.0~pre214+e0af5b18'
There is a type, duplicate "" in loadIcon
François
5:26 a.m.
New subject: [trinity-devel] R14 hard freeze for RC1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
Le 23/10/2014 05:02, Timothy Pearson a écrit :
Whoops! If anyone sees this kind of stuff feel free to fix it; it won't
hurt the ongoing builds as (obviously) they would fail on the build farm
as well.
Fixed in GIT.
Did I mention that the icon renaming was a lot of extremely tedious manual
work? ;-)
Tim
Just wanted to remind everyone that TDE is back in hard freeze while we
wait for the RC1 rebuilds after the recent changes to the common admin
module. The build farm should have R14 RC1 built in the next couple of
weeks.
As there were a number of changes to the icon names I need volunteers to
go through RC1 and carefully look for any missing icons (e.g. buttons,
dialogs, toolbars, etc. showing up with the default "unknown" icon
instead
of the correct icon). I have scoured the tree carefully for errors as
of
this point (there was a LOT of manual work involved in renaming the
icons), but it is possible that some incorrect names slipped through
anyway.
Thanks!
Tim
Hello,
FTBFS today in tdeaccessibility:
In file included from ksayit.all_cpp.cpp:15:0:
docbookclasses.cpp: In constructor
'KeywordSet::KeywordSet(ListViewInterface*, ListViewInterface*,
TQString)':
docbookclasses.cpp:451:59: error: expected ')' before 'text'
TQPixmap pixmap =
TDEGlobal::iconLoader()->loadIcon(""text-plain",
TDEIcon::Small);
^
In file included from DocTreeView.cpp:18:0,
from ksayit.all_cpp.cpp:19:
./DocTreeView.ui.h: At global scope:
./DocTreeView.ui.h:129:6: warning: unused parameter 'i'
[-Wunused-parameter]
void DocTreeView::slotRightButtonPressed( TQListViewItem *i, const
TQPoint &, int )
^
In file included from ksayit.all_cpp.cpp:10:0:
ksayit.cpp: In member function 'void
KSayItApp::slotChangeBookmarkFilename(const TQString&)':
ksayit.cpp:297:38: warning: ignoring return value of 'int system(const
char*)', declared with attribute warn_unused_result [-Wunused-result]
system( command.ascii() );
^
make[4]: *** [ksayit.all_cpp.o] Error 1
make[4]: Leaving directory
`/dev/shm/BUILD.oss131.x86_64/trinity-tdeaccessibility-14.0.0~pre214+e0af5b18/ksayit/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/dev/shm/BUILD.oss131.x86_64/trinity-tdeaccessibility-14.0.0~pre214+e0af5b18/ksayit'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/dev/shm/BUILD.oss131.x86_64/trinity-tdeaccessibility-14.0.0~pre214+e0af5b18'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/dev/shm/BUILD.oss131.x86_64/trinity-tdeaccessibility-14.0.0~pre214+e0af5b18'
There is a type, duplicate "" in loadIcon
François -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iFYEARELAAYFAlRIkXYACgkQLaxZSoRZrGEj/QDguAlwC3NiUHvoIKBA+0pg5QQS
36krzLNJX6F+AADfUWpfKtfYGplyFeqPT6zgz1B+XDP1nao7DDB2Wg==
=LJ22
-----END PGP SIGNATURE-----
3430
days inactive
3487
days old
33 comments
6 participants
participants (6)
-
Darrell -
Dr. Nikolaus Klepp -
François Andriot -
Michele Calgaro -
Slávek Banko -
Timothy Pearson