Hi Andrey

Thanks for bringing this up.

Since the release train moved to a quarterly release cycle there was zero 
interest to contribute to the maintenance branches that get created when 
moving to the next release. It was only used by IBM and fed with backports 
by IBMers (maybe with some exceptions that I can't remember right now). 
Right from the beginning IBM wanted to make those fixes available for 
everyone and not keep them in a private branch. It would be great if other 
people use the maintenance branches (also old ones) to backport critical 
fixes, or fixes that are important to their work/product/company.

Given that the code is merged after RC2, the same rules must be followed 
as for RC2 in 
https://www.eclipse.org/eclipse/development/plans/freeze_plan_4_15.php. 
This also means: no API changes or feature work without PMC approval.

The Platform Releng team will not spend resources to do maintenance 
builds. However, anyone can use the source and build it but must not 
expect the Platform Releng team to hold hands.

So, welcome Andrey!
Dani



From:   Andrey Loskutov <losku...@gmx.de>
To:     "Eclipse platform release engineering list." 
<platform-releng-...@eclipse.org>, "Eclipse platform general developers 
list." <platform-dev@eclipse.org>
Date:   27.02.2020 21:03
Subject:        [EXTERNAL] [platform-releng-dev] 4.15 maintenance branch
Sent by:        platform-releng-dev-boun...@eclipse.org



Hi all,

since we've started with Eclipse quarterly release cadence we've
basically stopped development on maintenance branch. I saw that few
commits were done here and there, but I didn't found any strategy /
guidance.

In short, I maintain private 4.12 SDK branch with lot of backported
patches from master. I do this for our product, and I plan to start
another maintenance branch for 4.15 soon.

This time I believe it would make sense to not maintain my own private
branch, but just push backported patches we need to the "official"
R4_15_maintenance branch.

What would be the "right" way to do so? Do I need any approval from
component leads, do I need extra bugs opened to backport regression
fixes, any "+1" from other developers? Or can I just push, run gerrit
build, and if it is green, merge? Since no one seem to work on
maintenance branches anyway, this should be not a problem for anyone?

Another question would be if we could produce some regular SDK snapshot
builds from that branch, and if there are resources & interest for this?
I personally don't need that build, we build SDK locally, but it could
be something people are searching for.

I'm asking here because I believe it makes sense to give results of my
(paid) maintenance work back to community, and it is really sad to see
people searching for some fixes on a "known good" SDK version but seeing
only the way to get a new major SDK version with new unknown regressions
instead.

Please note, I do not plan to maintain backports branch for every major
SDK release, I have only resources (and plan) to do this for *some*
releases.

So there are basically two questions:

1) What are the rules for backporting patches to maintenance branch?
2) Any interest in producing SDK builds from this branch?

--
Kind regards,
Andrey Loskutov

https://www.eclipse.org/user/aloskutov
---------------------------------------------
Спасение утопающих - дело рук самих утопающих
---------------------------------------------
_______________________________________________
platform-releng-dev mailing list
platform-releng-...@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-releng-dev



_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Reply via email to