On 04/15/2018 03:25 AM, Yehuda Katz wrote:
> On Sat, Apr 14, 2018 at 9:48 AM, Jim Jagielski <j...@jagunet.com 
> <mailto:j...@jagunet.com>> wrote:
> 
>     IMO, the below ignores the impacts on OS distributors who
>     provide httpd. We have seen how long it takes for them
>     to go from 2.2 to 2.4... I can't imagine the impact for our
>     end user community if "new features" cause a minor
>     bump all the time and we "force" distributions for
>     2.4->2.6->2.8->2.10...
> 
>     Just my 2c
> 
> 
> That also assumes the OS distributions pick up the point releases. RedHat 
> certainly doesn't pick up the new features,
> only bug fixes.

But in this case users of those binaries shouldn't be affected by the 
regressions as they only receive bug fix backports
:-P.
Seriously, we also had regressions just in bug fixes and the feature 
backporting makes it sometimes harder to correctly
backport pure bug fixes for these distributions as the code changes are bigger 
in the stable branch because of the
feature backports. Of course this is not our direct issue and main concern here.
One idea that comes to my mind is whether we should have an "LTS" version that 
only receives bugfixes and another
"stable" branch that receives new feature (on the same level of API 
compatibility we currently grant for our stable
branches). E.g. you could go with a major release X.Y.0.Z and after some minor 
releases Z which still allow
feature and bugfixes to be backported in an API compatible way (to give the new 
major some time to stabilize) split of
X.Y.1.Z to allow feature backports in an API compatible way and allow only bug 
fix backports to X.Y.0.Z.
Questions that pop up with this are:

1. Is there enough manpower and willingness to maintain this?
2. How will the commercial 3rd parties handle this? Will they only support 
X.Y.0.Z or will they also support X.Y.1.Z?
   From an API point of view it doesn't matter as X.Y.0 and X.Y.1 follow the 
same API guarantee. X.Y.1 just has a
   bigger regression risk.


Other typical suspects are:

1. Improve testing suite(s).
2. Give the future release a broader real life testing exposure. The question 
is how we can get to this. I am not sure
   if RC release will help here, because it requires a sufficient amount of 
people to use and test them. Seeing RC on a
   release might make them saying: Nah, let others do that testing I will wait 
until RC is gone and take it then.
   So I am not sure if RC releases will improve the exposure compared to the 
current exposure during the voting.
   If it is just a matter of time (voting usually "only" takes 72 hours, 
compared to a RC release which would be around
   longer before the next RC or final release) it could help indeed.

Sorry for the rant.


Regards

RĂ¼diger

Reply via email to