On 02/02/12 12:31, Ross Gardler wrote:
On 2 February 2012 10:51, Paolo Castagna<[email protected]> wrote:On the other hand, I think for a project, in particular at the beginning, it is good to have one "release manager" (who can change/rotate with time).Most projects I know about do not define a formal release manager role. What happens is someone decides they need a new release, appoint themselves as RM for that release and get on with it.The questions I have are: - does Apache Jena has a release manager?pass- do we need one?It a complex process, someone has to lead it, so yes.- how/when we decide it's time to release a module? - how often do we want to roll-out releases?Two approaches I can see: - project states it will (aim to?) release every x months - project states it will release whenever someone curs a release The first can only really work is someone has resources they will commit to delivering that release come rain or shine.
We have a poor track record on finishing things to a schedule. :-)At the moment, its unrealistic without people having ongoing committed day-job time.
For this reason I prefer the second. In the second model you make it clear that *anyone* can cut a release and call the vote. They don't need to be committers. So if someone needs a new release they just get on with doing it.
> > > RossI prefer the second. Actually, I though that was the project way because Leo described it awhile back and no one pushed back or commented on it.
(Technicality - our release process requires SVN update access to tag the release, and needs staging upload rights. When we graduate, AIUI, that means a project security group; currently its all polling committers. It would be possible to do a correct-but-different process.)
I'm more than happy not be release manage next time. It will be less work, and even less with JENA-191.
Andy
