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