[Framework-Team] Re: Review process: suggestions, and an offer

Wichert Akkerman wichert at wiggy.net
Fri Feb 8 06:30:28 UTC 2008


Christian Scholz wrote:
> Martin Aspeli wrote:
>> Christian Scholz wrote:
>>> To me it's unclear when coding should be happening. In practice it 
>>> might be in various ways. You might have a component already because 
>>> you needed it and want to get it into the core or you just have an 
>>> idea and only want to start coding once people think it's a good idea.
>>
>> I think there are two modes:
>>
>> 1) Code already exists (e.g. a third party product) and the PLIP 
>> submitter wants it improved and integrated into the core. In this 
>> case, there's little code to write, except some integration code maybe.
>>
>> 2) New functionality or improvement to existing core-only 
>> functionality. In this case, I don't think we should expect people to 
>> write much code before the PLIP is reviewed and accepted in 
>> principle, since otherwise they could be wasting their time.
>
> I think so, too. The question is of course how much time is available 
> between PLIP submission and code submission. Maybe for #2 we need some 
> slightly different process where people should talk about their ideas 
> a bit sooner, e.g. before they write the PLIP or at least somewhat 
> before they submit it.

People can already do that: that is what the mailinglists, sprints and 
irc are for. We also already have a separate decision point in the 
release process where the basic concept and desirability of a PLIP is 
decided upon. I am not convinced we need more process: complex processes 
do not work in a project like Plone. I think we have all the parts that 
we need to have already, but we just need to become better at using them 
properly.

>> We have rough timescales, and 3.1 has (had?) a published release 
>> date. However, that's no good when deadlines slip. We need to ensure 
>> we hit a certain amount of work (code + QA) otherwise our releases 
>> suck. The outside world is not going to look kindly on a release that 
>> is "on time" to a deadline we arbitrarily set but which is majorly 
>> buggy, completely underwhelming feature-wise or shoddily integrated.
>
> I meant more that we should define (and document) the timespans 
> between releases are happening so everybody knows when the next chance 
> and deadline is. For 3.1 I know now, for the next releases I don't.

We can't do that until a single release becomes more predictable. The 
3.0.x releases have been very predictable (every month around the 10th) 
except for 3.0 where the summit complicated things. 3.0 slipped for 
various reasons, and 3.1 which was completely designed to be simpler and 
more predictable is already slipping by two weeks. As long as that 
happens it is impossible to set useful schedules for releases beyond the 
upcoming release.

Wichert.

-- 
Wichert Akkerman <wichert at wiggy.net>   It is simple to make things.
http://www.wiggy.net/                  It is hard to make things simple.






More information about the Framework-Team mailing list