On Mon, Oct 21, 2019 at 8:29 AM Julian Foad <[email protected]> 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/
