trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: December 2014

Re: [trinity-devel] R14.0.x branch

From: "Timothy Pearson" <kb9vqf@...>
Date: Tue, 9 Dec 2014 17:31:09 -0600
-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iFYEARELAAYFAlSHhigACgkQLaxZSoRZrGEPWwDeI+1Eu2pXIECwl7BNGXFJwAfw
w7jElEgKsGgcPADfdGNbDkVUaCMFW/oSekGehJYQ78RkPdUpSvrY6A==
=jJOW
-----END PGP SIGNATURE-----