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
Received on 2019-10-23 07:21:02 CEST