On 10/25/2019 12:52 PM, Yann Ylavic wrote:
> On Wed, Oct 23, 2019 at 11:06 AM Stefan Eissing
> <stefan.eiss...@greenbytes.de> wrote:
>>
>> As I said in the past, my idea would be to:
>> - trunk -> trunk-old,
>> - copy 2.4.x -> trunk
>> - any feature to bring from trunk-old to the new trunk needs a champion,
>> e.g. someone who does the work (porting and test cases)
>
> I'm not sure, possibly it would be easier to remove/restore from/to
> trunk than backport to 2.6.x. I think most things are in pretty good
> shape in trunk, core things at least.
> If we were to merge the missing/interesting bits in a
> 2.6.x-copy-of-2.4.x, it could be a mess to find all the commits in
> trunk for each feature.
> (Say something /me did, as you very well know it's very likely to be
> spread over multiple commits and back and forth in time :) )
>
>>
>> To some, that looks like we do not honour past work from people (that was
>> one of the arguments brought forward last time).
>
> If, due to the above difficulty for finding all the relevant bits to
> backport, it ends up being large replacement of code (nay whole files)
> with no real merge, I think that's a point though.
> Basing 2.6.x off trunk would preserve history on the things we want to
> keep and maintain, and possibly would be easier to start with (let's
> discuss that!), so best of both worlds?
>
>> But it is not only about honour of devs, but also about the sweat and tears
>> of the maintainers during 2.6.x releases. If a feature does not find someone
>> to merge from one branch to another, how could we support this feature in a
>> release?
>
> Agreed.
>
>> What do the 5-6 people who handle 99% of all PRs think about this?
>
> My feeling is that it's easier to start from trunk, no strong feeling
> (an intuitive one).
>
> So how about:
> 0. github workflow? meanwhile...
> 1. compare trunk/2.4.x (inventory)
> 2. discuss unused/deprecated in trunk to cleanup
> 3. address STALLED entries in trunk if it's not for compatibily reasons
> 4. do API/ABI breaking changes in trunk
> 5. improve trunk w/ things we want in 2.6.x (the real part!)
> 6. trunk => 2.6.x
> 7. remove from 2.6.x things not deprecated in 2. but w/ no champion either
> 8. 2.6.alpha/beta/gamma/rc/whatever
> 9. fix in trunk and backport to 2.6.x
> 10. if not good enough goto 8.
> 11. 2.6.0
> 12+ usual release cycle
> ?
>
> If in 1. we find that 2.4.x => 2.6.x is easier/better, well just
> replace 2. with that and drop 6. and 7.
+1 to the above, with a preference to branch from trunk if possible.
Regards
Rüdiger
