[PC-BSD Testing] Rolling release criticism
kris at pcbsd.org
Thu Dec 19 06:20:56 PST 2013
On 12/18/2013 12:33, Joe Maloney wrote:
> On Wed, 2013-12-18 at 11:07 -0500, Kris Moore wrote:
>> On 12/18/2013 07:44, Claudio L. wrote:
>> > 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.
>> > For example:
>> > * 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
>> >> only.
>> > 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.
>> > Claudio
>> I think these ideas are great. I also agree 100% with the renaming,
>> since RELEASE/STABLE is confusing, and I think those terms are best left
>> to the FreeBSD world/kernel portions. So here's what I think we will do:
>> 1. As mentioned, create new PRODUCTION / EDGE set of packages.
>> - Update EDGE every 2~ weeks, depending upon breakage of ports upstream.
>> - Update PRODUCTION every quarter
>> * One month before release, freeze the most recent EDGE set of ports
>> * Begin testing / fixing major ports - Desktops/VirtualBox, etc
>> * Once testing is finished, push out new PRODUCTION set and unfreeze
>> EDGE again
>> - Add selection mechanism to system manager GUI, letting you switch
>> between these sets
>> Does this sound like a reasonable timeframe for us to work on?
> Sounds good to me. Will you branch the ports tree on github as well
> for this? Just curious for pc-sysmanager that I was working on
> whether or not branch detection for ports would need to be implemented
> depending on whether PRODUCTION / EDGE is being used?
> Joe Maloney
I will probably not branch the source tree, rather just hold off
updating it until we get a "stable" snapshot build, then tag the
resulting packages as "PRODUCTION" and upload.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Testing