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

Yuri Momotiuk yurkis at gmail.com
Wed Jun 4 05:18:30 PDT 2014


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>:

> 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
>>>
>>>
>>
>
> _______________________________________________
> Testing mailing list
> Testing at lists.pcbsd.org
> http://lists.pcbsd.org/mailman/listinfo/testing
>
>


-- 
Best regards, Yuri Momotyuk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pcbsd.org/pipermail/testing/attachments/20140604/cef2ce8f/attachment.html>


More information about the Testing mailing list