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