[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:32:55
Message-ID: AB93B7B3-40B6-4228-A4FB-D6627C987410 () 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]