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. -- Sl�vek