-----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
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?
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
On Tuesday 14 of October 2014 19:54:51 Dr. Nikolaus Klepp wrote:
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
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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
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
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
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.
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
On Wednesday 15 of October 2014 04:30:15 Michele Calgaro wrote:
- 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'?
On 2014/10/15 12:12 PM, Slávek Banko wrote:
On Wednesday 15 of October 2014 04:30:15 Michele Calgaro wrote:
- 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:
- 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.
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
- 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'?
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
On Wednesday 15 of October 2014 06:23:33 Michele Calgaro wrote:
On 2014/10/15 12:12 PM, Slávek Banko wrote:
On Wednesday 15 of October 2014 04:30:15 Michele Calgaro wrote:
- 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:
- 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.
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
- 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'?
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
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/+pac... https://quickbuild.pearsoncomputing.net/~slavek-banko/+archive/main-r14/+pac...
<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
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.
On 10/16/2014 01:02 PM, Slávek Banko wrote:
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
Dne čt 4. prosince 2014 Michele Calgaro napsal(a):
On 10/16/2014 01:02 PM, Slávek Banko wrote:
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
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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
Dne čt 4. prosince 2014 Michele Calgaro napsal(a):
On 10/16/2014 01:02 PM, Slávek Banko wrote:
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
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.
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.
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
On Wednesday 10 of December 2014 00:31:09 Timothy Pearson wrote:
Dne čt 4. prosince 2014 Michele Calgaro napsal(a):
On 10/16/2014 01:02 PM, Slávek Banko wrote:
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
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.
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.
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.
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.
Thanks!
Tim
On 12/10/2014 09:47 AM, Slávek Banko wrote:
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.
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
On 12/10/2014 09:47 AM, Slávek Banko wrote:
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.
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
My two cents about bug and development through the freeze period.
- 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.
- 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
- 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.
I will not work on this bug since I want to complete bug 1859 first and eventually join bug 1850.
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
On Wednesday 15 of October 2014 10:58:58 Michele Calgaro wrote:
- 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.
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.
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.
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.
Cheers Michele
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 SIGNED MESSAGE----- Hash: SHA224
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
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
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
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.
<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
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
On Wednesday 15 of October 2014 23:20:54 François Andriot wrote:
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
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!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
On Wednesday 15 of October 2014 23:20:54 François Andriot wrote:
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
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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
On Wednesday 15 of October 2014 23:20:54 François Andriot wrote:
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
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
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
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 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?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
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
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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
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
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
-
Darrell -
Dr. Nikolaus Klepp -
François Andriot -
Michele Calgaro -
Slávek Banko -
Timothy Pearson