[PC-BSD Testing] Rolling release criticism

Claudio L. claudio at hpgcc3.org
Fri Dec 20 04:26:23 PST 2013


This is what makes PCBSD stand out from other OSes. Some guy (me in this 
case) writes a post, and after 3 days of discussion Kris has a plan to 
implement all the new ideas, and I'm sure in a few months we'll see it 
all come together.

That's great community work, it makes your users feel they are being 
listened to.

Keep it up.

Claudio



On 12/19/2013 09:20, Kris Moore wrote:
> 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.
>
> -- 
> Kris Moore
> PC-BSD Software
> iXsystems
>
>
> _______________________________________________
> Testing mailing list
> Testing at lists.pcbsd.org
> http://lists.pcbsd.org/mailman/listinfo/testing

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pcbsd.org/pipermail/testing/attachments/20131220/7b512bf0/attachment.html>


More information about the Testing mailing list