Re: pkgsrc stability vs. updates

[Greg Troxel <gdt%lexort.com@localhost>]

Benny Siegert <bsiegert%gmail.com@localhost> writes:

>> Quarterly branches were always a way to avoid these issue, albeit
>> not an ideal one.  Preventing regressions in the first place is a
>> much better solution.  We can't prevent every regression, of course,
>> but allowing a regression can almost always be a deliberate decision
>> if we have the right tools and procedures in-place.
>
> Why do you keep talking about quarterly branches in the past tense. I
> fully intend to keep quarterly branches alive, through volunteering.

Perhaps more importantly, there has so far not even been a missed
quarterly branch, let alone the appearance of discontinuation.

Jason is mixing two issues.

One issue (which I see as totally valid) is about the degree of
stability of trunk.

The other is that branches are a way for users to use pkgsrc such that
the only changes are security fixes, bug fixes, and build fixes, and for
the most part no other changes.  Even if the trunk never had
build/functional regressions, stable branches are still a good thing for
users, who can update production systems along stable branches with
little to no fear, and then qualify the next branch and switch to it.

I have always viewed quarterly branches as being about providing a
branch (with fixes for serious security issues) that is usable in
production.

Whether we should have 4, 3 or 2 branches a year is discussion we should
have.  (More than 4 and only 1 don't seem like a good idea.)  As someone
who has managed branches, I'd say that the effort that is not about
ensuring that the trunk is stable is quite small.  Almost all of the
effort has gone into ensuring that trunk builds and that the packages
run ok.  That's been a bit of old-fashioned Change Control Board, which
has felt useful and reasonable, and a fair bit of controlling updates
that people should have had the judgement not to make anyway, which has
been useful but not felt reasonable.

As for handling pullups, the other side of the stable branch equation, I
would guess that longer branch lifetimes likely would lead to somewhat
more pullups, as in practice people tend to say "the new branch will be
here soon, and this issue isn't that important".

I would also expect fewer branches to be bad for stability, as people
will feel more pressure to rush updates before a branch.