[PC-BSD Testing] Rolling release criticism

Joe Maloney jpm820 at gmail.com
Tue Dec 17 11:55:22 PST 2013


On Tue, 2013-12-17 at 14:00 -0500, Claudio L. wrote:
> On 12/17/2013 10:38, Kris Moore wrote:
> > Well, in this case I think Claudio has done plenty to push the project
> > along :) He's the author of the fantastic new "ZFS / Disk Manager GUI"
> > that has gone in recently.
> Thanks, you saved me from replying to that "if you want it fixed, learn 
> to code" comment, and you did it in a much more polite manner than I was 
> planning to.
> My intent was not to complain, but to start discussing ideas to fix what 
> I see doesn't work well (at least for me it isn't).

Disk manager is nice btw.

> 
> 
>  From all the great comments in this thread, I extracted a few clear things:
> 
> 1) Some people want stability, some people want bleeding edge even if 
> they bleed to death. We should find a way to please both types of users.
> 2) Now that boot environments is included out of the box, adding 
> automatic snapshots before applying updates is a great idea.
> 
> Now a new idea:
> The release/stable idea from FreeBSD could be adapted to PCBSD, but not 
> necessarily with the same meaning. For example, we could have the stable 
> branch just the same as it is now, with packages as fast as you can. 
> There could be another branch "release", that perhaps gets packages only 
> after they've been out for at least 2 months (just throwing a number) on 
> the stable branch.
> The way it seems to work now, you send the package out, then you get an 
> avalanche of complaints, and you get it fixed in a matter of days  by 
> pushing a package fix. So what if you let the package "mature" for two 
> months on "stable" (get all the complaints and fixes in those 2 months), 
> then the package is moved to the release branch (with any hot fixes 
> included). That would give you time to correct any wreckage before it 
> reaches people using the "release" repo.
> Will that please both the "bleeding edge" and the "stability first" users?

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.  That's why I was
suggesting security and critical updates for RELEASE only.  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.

Joe Maloney
> 
> In my case it will, I don't mind being 2 months behind if that let me 
> focus on what I'm doing because after all, I'm more of a developer than 
> a tester. And if I need a specific package updated and can't wait 2 
> months, I can just get it manually or from ports, then 2 months later 
> I'll catch up through the normal channels.
> 
> 
> Claudio
> 
> _______________________________________________
> Testing mailing list
> Testing at lists.pcbsd.org
> http://lists.pcbsd.org/mailman/listinfo/testing




More information about the Testing mailing list