[PC-BSD Testing] [please test] Control panel

Joe Maloney jmaloney at pcbsd.org
Tue Jun 3 20:16:51 PDT 2014


Sorry one of my fingers is indisposed from an accident.  I meant to say
push new features every 1st and 3rd quarter.

Quarterly updates for ISO’s / packages regardless

Build new features for 4 months

Test new features after for 2 months  (like major appcafe changes)

Push new features every 1st and 3rd quarter which is on schedule as of
now.  :)

Joe Maloney


On Tue, Jun 3, 2014 at 9:34 PM, Joe Maloney <jmaloney at pcbsd.org> wrote:

> Could this be done?
>
>
> Quarterly updates for ISO’s / packages regardless
>
> Build new features for 4 months
>
> Test new features after for 2 months  (like major appcafe changes)
>
> Push new features every 3rd quarter which is on schedule as of now.  :)
>
>
> Joe Maloney
>
>
> On Tue, Jun 3, 2014 at 4:57 PM, <claudio at hpgcc3.org> wrote:
>
>> I don't think you are misunderstanding, it's just a different way of
>> viewing it.
>> Yuri was asking for people to test the control panel because it just came
>> out and it will be into the production set with very little testing, and I
>> understand his concern.
>>
>> What I was thinking is that the current way of doing it allows a very
>> recent package to go out relatively quick if it was submitted the last days
>> before the freeze. Also, you need to consider that many developers will
>> "rush" their packages in right before the freeze, which increases the
>> chances they will send it with a bug.
>>
>> I think there should be a period of 2 months between the freeze and the
>> release, while EDGE keeps rolling.
>> Basically, in the 4-month cycle, you would have (if one letter represents
>> one month): F-R-F-R-F-R... (F=Freeze, R=Release), so you freeze on the
>> middle between releases.
>> If you release Production in June, your next freeze should be in August,
>> and those packages are released in October. Now this doesn't mean EDGE will
>> be frozen for 2 months. Any package changes coming into EDGE during the
>> freeze will be checked: if it's new, keep it on EDGE, if it's a bugfix of a
>> frozen package, then goes into both EDGE and the next production set. New
>> versions of packages that are needed to fix problems with frozen packages
>> can be accepted as well, but no major changes to the production candidate.
>> This way, PRODUCTION will always be 2 months behind EDGE on the release
>> date, and will be 6 months behind the day before the next release. It may
>> seem a lot, but this guarantees that any package was tested for 2 months at
>> least before going into production. It also gives developers of new code 2
>> months to polish their creations.
>> The way it is now, PRODUCTION "syncs" with EDGE every 4 months, but at
>> that point it's not behind, it's exactly the same as EDGE. That means the
>> last few packages from EDGE may not be mature enough. What if EDGE is
>> unstable at the moment you freeze? You only have 2 weeks to fix everything?
>> The new Control Panel is an excellent example of new code that will go
>> almost immediately into production, and you have the developer begging for
>> immediate testing.
>> This is just a suggestion, since the PRODUCTION/EDGE is a new feature of
>> PCBSD I think it can be organized so that things are more "relaxed" for
>> developers and more stable for the users that want stability.
>> So far the (only) one PRODUCTION release has been rock solid. I also
>> tested EDGE and it had some rough edges in the beginning but now it's very
>> solid. So in this case you have a solid EDGE to do the sync with PRODUCTION
>> so it works, but this will not always be the case in the future, especially
>> when EDGE moves to FreeBSD 11 for example.
>> FreeBSD has about 2 months from freeze to final release (right now they
>> froze 9.3 on May 23, planned for release on July 16), so I think 2 months
>> should be OK for PC-BSD too. You can make it as much or as little as you
>> want, in my opinion 2 weeks is too short, 2 months about the right amount.
>>
>> I don't intend to criticize, so far the EDGE/PRODUCTION is working very
>> well, I'm trying to bring ideas to keep it working well even when things
>> get complicated.
>>
>> Claudio
>>
>>
>>
>>  -------- Original Message --------
>> Subject: Re: [PC-BSD Testing] [please test] Control panel
>> From: Kris Moore <kris at pcbsd.org>
>> Date: Tue, June 03, 2014 11:30 am
>> To: testing at lists.pcbsd.org
>>
>> On 05/29/2014 05:40, Claudio L. wrote:
>>
>> I have a question:
>> Doesn't this defeat the purpose of having a production set?
>> I would think a production set of packages should be out for I don't
>> know, 2 months minimum?
>> So the package freeze should be a couple of months prior to the
>> production release, to give time for testing. Situations like this, where a
>> package is being released for testing a few days before production release,
>> in my opinion doesn't achieve the intent of the production set. The idea is
>> to allow for things to mature first, then release as production.
>> I'm not complaining or anything, just making an observation that the
>> releases should be spaced properly to achieve the goal, otherwise
>> PRODUCTION will go out with some packages that are too "green" and will
>> behave more or less like EDGE but with less frequent updates.
>>
>> On the other hand, the new Control Panel looks good! I tested it for a
>> little while and seemed to work well here.
>> Claudio
>>
>>
>> I guess I'm not understanding. We keep a set of production packages
>> frozen for 3 months at a time. While that production set is out, we are
>> updating EDGE almost weekly / biweekly, testing and fixing issues as they
>> occur. When it is time to roll another PRODUCTION set, we freeze the EDGE
>> set for about 2 weeks, work out any last kinks, then "promote" it to
>> PRODUCTION, and don't touch it for 3 months again.
>>
>> Or am I misunderstanding here?
>>
>> --
>> Kris Moore
>> PC-BSD Software
>> iXsystems
>>
>> ------------------------------
>> _______________________________________________
>> Testing mailing list
>> Testing at lists.pcbsd.org
>> http://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/20140603/3783073a/attachment-0001.html>


More information about the Testing mailing list