[prev in list] [next in list] [prev in thread] [next in thread]
List: lyx-devel
Subject: Re: Staging Branches [REVISED]
From: Peter_Kümmel <syntheticpp () gmx ! net>
Date: 2016-04-18 20:35:11
Message-ID: C19ED481-E4A8-456A-BFBB-155DE9544C17 () gmx ! net
[Download RAW message or body]
Am 18. April 2016 22:29:51 MESZ, schrieb "Peter Kümmel" <syntheticpp@gmx.net>:
>Am 18. April 2016 21:28:04 MESZ, schrieb Georg Baum
><Georg.Baum@post.rwth-aachen.de>:
>>Richard Heck wrote:
>>
>>> We now have three staging branches. These are:
>>>
>>> 2.3-staging
>>> 2.2.1-staging
>>> 2.2.2-staging
>>
>>That makes 5 active branches in total (please correct me if I
>>misunderstood
>>something):
>>
>>2.1.x => will become 2.1.5
>>master => will become 2.2.0
>>2.2.1-staging => will become 2.2.1
>>2.2.2-staging => will become 2.2.2
>>2.3-staging => will become 2.3.0
>>
>>Am I the only one who thinks that this is too much? IMHO this results
>>in a
>>lot of additional book keeping work that eats from our valuable
>>resources.
>>In addition, there are the trac keyword problems. Currently it is not
>>possible to map these branches to trac, if we wanted to do that we'd
>>need
>>three additional keywords for the staging branches. If we do not add
>>these
>>keywords then bugs might be closed for the wrong milestone and/or we
>>need
>>manual work to find out from trac whether a particular bug will be
>>fixed
>>e.g. for 2.2.1 or not.
>>
>>Such a structure is good for large organizations. It does not make
>>sense for
>>such a small group of part time developers like us IMHO. We do not
>have
>>the
>>resources to think about four stable releases in parallel. IMHO we
>>should
>>concentrate on one branch for 2.2.0 and one for 2.3 development, and
>>refrain
>>from big refactoring projects in 2.3 until 2.2.1 is out. Nobody will
>>try out
>>all these different 2.2 branches, so these fixes won't get additional
>>testing. In the contrary, I believe that they would get more testing
>if
>>they
>>were all in one 2.3 branch. Also, I doubt that we can now plan ahead
>>for
>>2.2.2, these plans are likely to become obsolete. We have a simple
>tool
>>to
>>schedule bug fixes: Milestones in trac. If we put all bug fixes in the
>>2.3
>>branch and set the bug milestones it is easy to get a list of all
>fixes
>>that
>>need backporting.
>>
>>
>>Georg
>
>I also think these branches are overkill.
>
>I would only use master and 2.2. No 2.3, it is so far away that it
>could be in master.
>
>2.2 should be always stable so that at any time a short living 2.2.x
>could be branched until the release is done. After the tag 2.2.x will
>be deleted then.
>
>Similar to
>https://wiki.qt.io/Branch_Guidelines
>
>Peter
We should already be on 2.2 and not on master, which is the future: 2.3
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic