[PC-BSD Testing] Rolling release criticism
claudio at hpgcc3.org
Wed Dec 18 04:44:45 PST 2013
On 12/17/2013 14:55, Joe Maloney wrote:
> This also seems like a good idea to me if it doesn't cause too much
> overhead or slow the project down a bunch I suppose.
Good point, we don't want to increase overhead. But if it's done in an
organized way it can actually be done without putting too much extra work.
* Let's say the 1st of each month they do a "package freeze", where they
select the packages that will be pushed in the next cycle.
* The 15th of the month they finish preparing the set of packages and it
gets pushed out to one branch.
* There's 1 and a half months to fix any problems with this set of
packages. And if a package can't be fixed within this time, it is
removed from the set.
* The last day of the second month, they push the package set out to the
more stable branch.
* ... and it loops ad infinitum...
So they reduce the frequency of packages to a 2-month cycle, that should
help Kris et al. to pace themselves (vs. the frenzy they have today with
a monthly cycle or even faster), and we get a second branch with
relatively low effort and a more polished set of packages.
The 2-month cycle would introduce a delay of up to 2 months for the
bleeding edge packages and up to 4 months for the stable one (this is a
worst case scenario, for a package that comes out the day after they do
the package freeze). I think it's reasonable.
> That's why I was suggesting security and critical updates for RELEASE
But that would essentially freeze that branch for its life cycle, which
goes against the idea of a rolling release. In my opinion it should lag
behind the other one, but still roll. The static nature of FreeBSD gets
a lot of criticism and it's one of the differentiating reasons to use
PCBSD (or TrueOS) versus plain FreeBSD.
> That way things like VirtualBox don't get borked when that package
> get's updated. Like it is now. :( I know what you mean about spending
> extra time fixing little things on what should be a production system.
> Perhaps this every 2 months idea could work. I'd still say apply the
> idea you just mentioned about the every 2 months to STABLE, and roll a
> CURRENT release with the more current packages instead that can
> trickle down into STABLE after they have recieved testing.
That's slightly different from what I proposed above, it could work as well.
Well, the ideas are now out there. I think we did our part, now it's up
to the team to decide if and how they want to implement any of this. I'm
positive that in 2014 we'll get back the stability we need.
More information about the Testing