[Framework-Team] release schedule / phone conference

Rob Miller ra at burningman.com
Thu Nov 3 19:00:02 UTC 2005


On Nov 3, 2005, at 8:18 AM, whit wrote:

> Stefan H. Holek wrote:
>
>> I am +0 on this. In my experience, there is *no* way to plan a   
>> release in detail.
>
> I hear you loud and clear.  at some point, I think we would all  
> benefit from a post-mortem on the force of nature that was the 2.1  
> release from your perspective and perhaps these proposals are  
> premature without your input.
>
>> As all development is volunteer-driven, you have  to release what  
>> you have got come the time. So, if, say, people go to  the effort  
>> of organizing an AJAX sprint and produce great results, do  we  
>> really want to have their work sit around for a year?
>>
> Two things that bear clarifying.
>
> 1. This plan depends on quicker releases, between 4 - 6months, with  
> less features / release

this still means that work has the potential to sit in limbo for 8-12  
months.

> 2.  These are guidelines to encourage the community to think in  
> more organized terms of taking care of user/business needs and  
> developer/maintenance needs.
> This is saying what the release is *about* not saying what the  
> details of what goes in are.  If the community refuses to play  
> along, then that's fine, we continue with the status quo.   This is  
> an excercise in changing the way we think about release, not a  
> stick to beat people with...

i'm all for thinking in more organized terms, but i think it should  
be driven by an assessment of what the most pressing needs are at any  
given time, rather than an artificial structure laid over the top.

> The hope is that it will provide a minimal amount of structure,  
> some basic guiding principles for how we self organize for  
> releases, instead of having a plip race driven by whoever has  
> time.   If you know your PLIP fits better into the Developer/ 
> Infrastructure bucket or the UI Bucket, you know a general  
> timeframe for trying to get it included and you can code / plan  
> ahead.    Since most everyone who participates in Plone release has  
> both interests in mind, this hopefully helps pool these effort in  
> complementary areas.

i think we can provide some structure in other ways.  i'd rather have  
some top down identification of what the major shortcomings are that  
we'd like to see addressed over the course of the next couple of  
releases.  this can be driven by this body, at least for the under- 
the-hood stuff, and by another group for the front-end stuff.  this  
would have the same effect, but would be less restrictive.  it might  
even be useful to get feedback from the entire foundation membership  
re: some of this.

PLIPs of any sort can be submitted at any time, of course, and will  
be considered based on their feasibility, but PLIPs that are aligned  
w/ the identified goals will be encouraged.

-r





More information about the Framework-Team mailing list