[PC-BSD Testing] Rolling release criticism
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.
> 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.
> Testing mailing list
> Testing at lists.pcbsd.org
More information about the Testing