[Systers-dev] Questions about Release Management Process

[Gloria W]

> We have a few items in our release management process that need to be
> improved and I'd love some suggestions/ideas how to approach.
>
> - Release Notes -- what is the best way to handle release notes?  Should
> this just be a "readme" file that is included with each release?
>
> - Release Numbering - anyone have any preferences on release numbering?
>
> - Patches for specific features - right now we pull the entire repo - which
> includes all of our modifications to mailman to our dev/prod server.  This
> makes it difficult for others to use the dlist functionality.  We originally
> had some patches -- just for dlists -- but those need to be updated and
> doc'd.  Anyone willing to be the dlist patch maintainer?  Essentially this
> would make it easier for someone else to port to newer (or older versions)
> of mailman and start working against MM 3 -- which has just had a new alpha
> release.
>
> - Commit access to the development branch and cli access to our test server.
>   I'm of the opinion that the more people who know how to do things -- the
> better.  The flipside is security, of course.  Anyone have any suggestions
> on how to balance the two?
>
> - Testing cycles -- how to get more people involved.  Any suggestions?
>
> -  Release team -- I'd like to put together an actual release-team that
> maybe rotates the release-manger job.  Anyone interested?
>
> Thanks,
> Jen
>
>    
Sorry for the late reply. I started a new job, and I've been swamped 
from the moment I sat down at this new desk until now.

Re: release notes, can they be generated from Bazaar Blueprint to an 
HTML and a readme? I'm not a regular user of Launchpad, and I didn't 
find any online notes about the use of a blueprint for this purpose.

Re: dlist maintainer, I don't have consistent time, but I'd be more than 
happy to mentor someone who wants to learn how to do this, and do it.

Re: security: I am all for cli access. I've given root access on my own 
servers, trusting in my backups (after testing a restore, and getting 
the procedure down, of course). If the test server is virtual, this is 
is a nice way to sandbox the work. If there is a security issue, just 
get rid of the image. VirtualBox installation has gotten much easier in 
the past 6 months, and I will definitely help set this up if you need it.

For testing cycles, maybe something like a virtualenv installation would 
work? People can download and test a complete set of egg files without 
wreaking havoc on their current Python environment. I'll volunteer to 
help set this up too.

Re: version numbers, just keep it at 0.9.something forever, like 
everyone else does 8P Seriosuly, a major/minor release number scheme 
should be fine, right?

Tangent: The Python class is not materializing, I guess because I am not 
sure what people need here, and if my class would be better than any 
other class online. Instead I was thinking of online code review 
sessions, where we get in chat, look at code related to the project, and 
discuss the syntax/semantics. This way there is a context for the 
learning. I've had good success with this approach in the past. If this 
is helpful, I can do this periodically. Let me know.

Gloria