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

Joe Maloney jmaloney at pcbsd.org
Tue Jun 3 19:34:25 PDT 2014

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/9cc37b27/attachment.html>

More information about the Testing mailing list