[PC-BSD Testing] Rolling release criticism

Hans Ruhe hansruhe1 at gmail.com
Sun Dec 22 11:06:09 PST 2013


Hi Kris, Team and Claudio,

Good thinking. I want to help testing as I like PCBSD as a very nice option
to run a stable OS on my desktop. This new idea I like a lot. I can run
production for a stable OS and help testing for the new bleeding packages.
For instance I really like the 10 for the possibility to run trim on a SSD.
That is a nice setup, A SSD with the PCBSD OS on it and a regular harddisk
for the data.

Real good work guys, I wish you all a very nice Christmas. I know the
discussion already resulted in a good thing, I wanted to give my support
for it again. As a relative newbie I am planning to study every day on
PCBSD - FreeBSD so I can help out more.

Best regards and best wishes,
Hans


2013/12/20 Claudio L. <claudio at hpgcc3.org>

>  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 listTesting at lists.pcbsd.orghttp://lists.pcbsd.org/mailman/listinfo/testing
>
>
>
> _______________________________________________
> 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/20131222/43d6fa21/attachment-0001.html>


More information about the Testing mailing list