Re: [Nano-devel] considering what is stable

[Chris Allegretta]

On Mon, Nov 23, 2015 at 11:47 AM, Benno Schulenberg
<address@hidden> wrote:
>
> On Fri, Nov 20, 2015, at 19:12, Chris Allegretta wrote:
>> but in my professional life there has definitely been a move, as Benno
>> points out, to having release live very close to trunk all the time.
>
> That is one thing.  The other thing is: they release at a quick pace.
> They don't wait three or four months before rolling another tarball.

In the general case, I think it makes sense to release tarballs
proportional to the development speed, and severity of the fixes in
trunk awaiting release.  I don't think a set schedule makes sense,
unless such release are completely automatic.  Or unless someone's
being paid to work on this editor that I don't know about.

>> We could as a compromise do something like: move the 'stability
>> indicator' in x.y.z from the y value to the z, and just say every
>> other release (i.e. the 'evens' excepting .0 of course) we'll focus on
>> bugs from user reports.
>
> Who's "we"?  Who's fixing the bugs?  :)

I'm sorry I wasn't specific: 'We' is you, me, and anyone else who has
commit access who might do either development or bug fixes in trunk
from now into the indefinite future.  DLR could be considered another
key voice here if he were doing active commits, but I think he's doing
just submitting patches nowadays.

> I mean: that's all I'm doing, fixing bugs from user reports.
> (Most reports coming from myself, by the way.)  There is no
> development going on.  Those little, tiny extra features that
> I've added, they can hardly be called development.  Or do you,
> Chris, have big things waiting, stacked up around the corner?

You are floating a patch to do marked text differently on the mailing
list right now.  In my mind that's absolutely new development.

Regardless, we need to decide what to do in the general case that
there is work happening to add new features, while at the same time
fixes for bugs which predate that work need to go in.  Having a stable
branch made this straightforward (backport), so without one we'd have
to decide what to do in said case.

> So, I don't see any need to destine certain versions as being
> stabler than others.  In my opinion HEAD is always stablest:
> it has the most bugs fixed.  And it was nice to see the 9999
> confirmation from Gentoo.

I'm not convinced that's the case, but the question is do our users
care.  It sounds from the thread that most distros are doing what I've
been doing with the stable series. and backporting specific fixes to a
version they maintain.  While I feel bad that we're sharding out the
same task to several different distribution maintainers who will each
likely do the task differently (talk about fragmentation), it sounds
like it's work that they are doing anyway.  So as long as release
quality is not suffering too terribly, it sounds like we do not need
to proceed with backports to stable branches.

So 2.4.3 can be the last stable-only branch release, and we can just
do both development and fixes in trunk. If there are urgent bugs we
can either freeze development temporarily if needed, or fork off a
branch temporarily if a bug is severe and trunk is in an indeterminate
state.  Anyone terribly opposed to this?