Proposal: Reorganization of the Project Management

Moran Goldboim mgoldboi at redhat.com
Mon Mar 11 23:06:07 UTC 2013


On 03/11/2013 05:07 PM, Dave Neary wrote:
> Hi Ayal,
>
> On 03/09/2013 10:31 PM, Ayal Baron wrote:
>>> General advice based on my experience with oVirt:
>>> * I recommend a 6 month cadence with ~4 months feature development
>>> and
>>> ~2 months release preparation
>
> <snip>
>
>>> * Make regular point releases (alpha, beta 1, beta 2, RC1, whatever
>>> they're called) before and after a release. I'm looking forward to
>>> 3.2.1!
>>
>> if we have a 6 month release cycle, do you envision 1-2 point releases?
>> e.g. 3.2.1 2 months after 3.2 and 3.2.2 2 months after that and then 
>> after another couple of months 3.3?
>
> I was thinking we could lower the cost of making a point release to 
> the point where we could have a release every month... like this:
>
> February: 3.2.0 released
> March: 3.2.1 released - contains fixes for important issues discovered 
> post-release in 3.2.0 - in the meantime, feature proposal and 
> prioritisation (and development) continues on the trunk
> April: 3.2.2 released - only if there are significant bug fixes or new 
> translations
> May: 3.3.alpha1 released - in-progress work, contains some early 
> features, aimed for testing to identify features that need additional 
> work early. Release branch is made now.
> June: 3.3.alpha2 released - corresponds to feature freeze. At this 
> stage, incomplete features should no longer be committed. Work can 
> start on testing, integration testing, bug day
> July: 3.3.beta1 released - Corresponds to UI and string freeze - 
> translations and docs, and release notes, should be underway already, 
> but can hit full speed. Testing and bug fixing continues
>
> August: 3.3.0 released
>
> The only release that should take longer than a couple of hours to put 
> out is 3.3.0 - the other releases are a tag in the source code, and a 
> pointer to specific nightly builds.
>
> Cheers,
> Dave.
>

+1 on release roadmap.

I was lacking some additional items on the release process of 3.2 and i 
would like to bring it up for 3.3:
-ovirt functional dev group involvement
      -representative on weekly meetings
      -communication on when a new feature is in the code (nightly 
builds) - to engage early testing from the community
      -wiki page with contacts/maintainers, features roadmap and status, 
howto, etc.
-lack of tracking/monitoring priority bugs/common issues
-weekly meetings has been ran by very few people mostly by doing 
monologues- we might want to change the agenda of the meetings.

I think the area coming from all above items is the need to improve 
communication between developers-> project PM ->community

Thanks,
Moran.




More information about the Arch mailing list