I'll respond to Mark, Julian, Stefan, and James below... Mark Phippard wrote: > 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.
I'd like to point out that I have made several proposals but was (politely) reminded that we are in a period of stabilization. So those items and others are on my TODO list for later. I think we need to clarify what being in a period of stabilization means. It better not mean forever! I assume it means that we don't want to rock the boat (too much) until after 1.14-LTS is released. After that, I assume we have 2 STS releases for new developments followed by 1 "stabilization" STS to iron out and polish everything for the next LTS. But this is all a subject for another thread. Also, very much to the point: Julian Foad wrote: > I would like to point out we have gained two new enthusiastic > contributors (Nathan, Yasuhito) this year. Yes! We wouldn't even be having this conversation, nor would we have swig- py3, if it were not for the beautiful work Yasuhito has been doing. We owe Yasuhito a very big Thank You! I'm the other new developer and I have quite a lot in the pipeline, much of it aimed at attracting new users and developers. I'm working on a redesign and reorganization of the website, with more big items planned afterwards. Regarding actual Subversion code, I'm focusing on code quality at this time. I've uncovered an edge case in the tree conflict resolver that I'm working to pinpoint. You'll see either a fix or at least a reproduction script soon. Julian suggested and I have promised to bring an old issue to the list every week. Last week we closed our first weekly old issue. This week I posted the second (SVN- 1804) and I'm working on a fix that I'll propose soon. Like timed releases, this process of "timed issue resolution" will continue for as long as it takes to get our issue tracker cleaned up. I believe that having 15 year old issues in there is a psychological drag on everyone. It will be cleaned up!! Also, we've recently reached out to a hackathon; not sure what (if any) will materialize from that, but it's a good first step and much more will follow. Stay tuned! Stefan Sperling wrote: > I also had concerns in the beginning when Julian brought up the > proposal of time-based releases. I didn't expect it to work. > > But I think what Julian has shown us is that the calendar keeps us honest > in our commitment to actually do releases. <snip> > It would be interesting to learn what our new developers think about this. > I am sure that getting their changes released is important to them. > Time-based releases provide a certain amount of anticipation and clarity when > a release is supposed to happen. In the past, we used to discuss what to > release and when, every single time, and often delayed releases for months. > That could put new contributors off because they might not feel like they > have a huge standing when arguing for their changes to be released soon. > While the results of their work are sitting on trunk which nobody is actually > running in production. That certainly would not motivate me, if I try to put > myself in their shoes. Stefan, that is exactly what I think. I couldn't have stated it better myself. We *should* do time-based releases. It's really important that we do. IIRC one of the motivations for time-based releases was the new tree conflict resolver. It has made Subversion so much better and so much easier to use, yet it waited, largely untested, for two years. That should never be allowed to happen! There are myriad reasons why the managers of any organization must keep things on schedule. For us, the developers: As you and others have said, it "keeps us honest." It imposes deadlines to get things done. It prevents procrastinating on making a release. It makes expectations clear. It avoids endless discussions on whether to make a release or not. For our customers, the end users, server operators, IT departments, decision makers, and packagers: It gives a tangible schedule to aid in planning. It also shows current and potential customers that Subversion is alive, being maintained, and that future releases are scheduled. I can't stress the importance of this point enough, especially given that we're in the version control business, where the key is long-term safekeeping of data and its history, and longevity of the version control software itself. I'd like to thank Julian for being diligent about driving the time- based releases and for standing firm that they should happen on schedule! James McCoy wrote: > FWIW, since we switched to the new release model, I (in my capacity as > packager for Debian) basically ignore non-LTS releases. It's easier to > ignore them, since I know I only want an LTS release in Debian's > release, and would rather not risk getting "stuck" with a non-LTS > release when Debian freezes. And this is completely okay! I use Debian myself. Most Debian packages "lag" behind the latest and greatest. The same is true of other stability-oriented OSes. When you have 50,000 packages in your repositories and a whole dependency hell between them (circular / diamond dependencies, anyone?), you have to move forward cautiously. This is where users must decide if they favor stability or new features and choose their distro accordingly. It's a trade-off. Thank you for maintaining the Debian package. It works great! And thanks to everyone here, for all that you do. Nathan
