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

Kris Moore kris at pcbsd.org
Thu Jun 5 08:22:39 PDT 2014


So, I don't think we have the human resources to maintain 3 branches of
ports / source trees. I'm also trying to keep the ports we push out for
production as "fresh" as possible, which is why we settled on a 2 week~
window before moving to production. However, what we can do for our
internal pc-bsd related ports and utils is go to a "soft-freeze" 3-4
weeks before, blocking new features and major changes, and instead focus
on bugfixes. I think we still still try to keep the window smaller for
ports updates, since we really want to avoid having a ports tree already
be a month stale by the time we push it out to production.


I will also try to keep up my stuff on the roadmap wiki, so we post
before the fact, not after a major change is made :)


On 06/04/2014 08:18, Yuri Momotiuk wrote:
> Hi guys
>
> I have several notes:
> At first I think I can not freeze Edge too long using current
> development philosophy and process. Of course we can develop new
> features in private repos. But also we will need to merge our changes
> often to test together. In that case we will got vcs layout simular to
> FreeBSD one:
> Current (developers only) -> Stable (testers, simular to Edge) ->
> Release (production). IMHO we still have too few developers to do
> something more complex than now we use currently. But it is possible
> solution however it is not an silver bullet.
> I see only one current problem. This is human problem. We trying to do
> maximum just before release. In my case this is control panel
> reimplementation. But I also have one explanation: with new PBI system
> some functionality of old control panel was broken. We all can have a
> reasons to brake something :) 
> Well, as conclusion: IMHO we can try to stay on current schedule and
> process, but we should take put attention on WHAT will be merged (we
> don't NEED to merge all master contains) and make release when it is
> will be really ready.
> Also we need little more planning. We should plan big changes
> implementation through the releases. Good point to start is filling
> this road map wiki page before coding but not ex post.
>
> PS I also have some things about wiki, translations and other. I'll
> make post in dev@
>
>
> 2014-06-04 6:16 GMT+03:00 Joe Maloney <jmaloney at pcbsd.org
> <mailto:jmaloney at pcbsd.org>>:
>
>     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
>     <mailto: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
>         <mailto: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 <mailto:kris at pcbsd.org>>
>                 Date: Tue, June 03, 2014 11:30 am
>                 To: testing at lists.pcbsd.org
>                 <mailto: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 <mailto:Testing at lists.pcbsd.org>
>                 http://lists.pcbsd.org/mailman/listinfo/testing
>
>
>             _______________________________________________
>             Testing mailing list
>             Testing at lists.pcbsd.org <mailto:Testing at lists.pcbsd.org>
>             http://lists.pcbsd.org/mailman/listinfo/testing
>
>
>
>
>     _______________________________________________
>     Testing mailing list
>     Testing at lists.pcbsd.org <mailto:Testing at lists.pcbsd.org>
>     http://lists.pcbsd.org/mailman/listinfo/testing
>
>
>
>
> -- 
> Best regards, Yuri Momotyuk
>
>
> _______________________________________________
> Testing mailing list
> Testing at lists.pcbsd.org
> http://lists.pcbsd.org/mailman/listinfo/testing


-- 
Kris Moore
PC-BSD Software
iXsystems

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pcbsd.org/pipermail/testing/attachments/20140605/f9143474/attachment-0001.html>


More information about the Testing mailing list