On Mon, Oct 21, 2019 at 8:29 AM Julian Foad <julianfoad_at_apache.org> wrote:
> Mark Phippard wrote:
> > I think it is just another example that "regular" releases are not
> appropriate for this project at this stage of its life with a lack of
> regular activity.
> [...]
> > Also, as brane already pointed out, this would also be making a mockery
> of regular releases.
>
> Mark, I do understand that for your case, each minor release is a
> problem. So far, we haven't been able to understand and resolve how we
> could alleviate that, other than by making fewer or no minor releases.
> In the mean time, making an extra one would be sore.
>
FWIW, I am trying to remove that hat for this discussion and am just
speaking with my PMC hat on. Obviously my opinions may be colored by the
release pain I feel, but I am trying not to factor that in.
I thought the frequent release/LTS plan was a worth a try, I just do not
see where it is working out and yielding benefits. Our activity and
contributions continues to go down, not up. The releases are underwhelming.
The release notes for 1.13 are essentially empty. You note there are 2
important fixes.
We actually have something highly relevant now with the Python 3 support
and due to unfortunate timing our release policy is getting in the way.
> Given that you're about the only downstream maintainer who discusses the
> issues here, I take that seriously.
>
> So, that takes us back to
>
> 1.) Proposing we stop or change the way we do minor releases, and do
> something different?
>
Yes. Go back to having new releases when there is enough interesting
content to justify the release. We can lower the bar from the old days.
There does not need to always be a big ticket feature or two driving the
release, but if there is nothing worthy of a release we should not do one
just because the calendar says so. Important fixes should be backported to
supported releases and we can go back to issuing bug fix releases when
needed. I would backport these important fixes to 1.10 and 1.12 and do new
fix releases and then release 1.13 with the Python 3 changes when we think
it is ready.
Moving forward we could continue to backport fixes and do new 1.13 releases
and do a 1.14 only when there was enough interest in doing so.
I do not recall what these two fixes are, but putting them in a 1.13
release is kind of hiding them from our maintainers. I will not pretend to
be highly fluent in Red Hat policies, as an example, but I know they are
good at backporting security fixes. They seem to be including our current
LTS release in 1.10. If we backported these fixes to our 1.10 then it
seems a lot more likely someone at Red Hat might see and consider including
these fixes in their version. By just having them in our 1.13 release it
seems a lot less likely they would see them. I would assume that is true
for other maintainers.
Anyway, rolling releases make more sense when there is more activity. Even
if we did not have a big ticket feature you could justify a release just
based on the cumulative amount of activity. I do not think this is the
case for our project where things have slowed to a crawl for the most part.
> Julian Foad wrote:
> >> Surely the right approach is to release what we have got [...], then
> >> [...] a new minor release, calling it 1.14.
> >
> > Would this be the LTS release it is supposed to be?
>
> Do you mean, "Would this new '1.14' be an LTS release?" The answer to
> that is no. It would be neither LTS nor regular. The next LTS will be
> released next April; we previously assumed it would be numbered 1.14-LTS
> but if we do things this way then it would probably be numbered 1.15-LTS
> instead.
>
Yeah, I was basically just referencing our past "declarations" that 1.14
would be an LTS release.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2019-10-21 16:25:21 CEST