Toni Lamar ha scritto: > Stefano Bagnara-2 wrote: >> Unfortunately there hasn't been consensus on branching to start a >> release process from the trunk (in december) and the code didn't change >> to much in the mean time, so I don't think we can expect something >> different now. >> > But why a branch? Woudn't a tag be enough? I mean in the case of a Milestone > 1. > This would be just a little more than the nightly build, than later more one > tag for M2, an so on.
This may be an alternative approach. However I think that branching is better any time you want to manage a release. Btw I'm fine with tagging and releasing an M1 from current code (we did this for 2.3.0a1, IIRC): I just think that Robert should tell us the better moment wrt him IMAP work. And maybe we could even release a 3.0M1 without IMAP enabled by default. > Stefano Bagnara-2 wrote: >> Unfortunately, as far as I understand it currently no one of the active >> committers is willing to prepare a release from the current code (and to >> collect agreements for this). >> > But isn't the entire process automated? > I mean it already runs nightly. It would be only required to stick a 3.0M1 > label, tag that version and publish on the main site the collected JIRA > changes (there's a plug-in that does that automatically). Yes, but at Apache releasing means something more than building: we have to take care of any legal issue with code we release and we have to vote and agree on the number and the date. I know this seems to be some easy stuff, but in my experience it isn't. > Stefano Bagnara-2 wrote: >> So I think that if every user using/wanting trunk code to be released >> will put a list of new trunk features he is interested in and what >> features he is already using (testing) succesfully from trunk this could >> help the inactive PMC members to understand the quality and stability >> and usability of what we have in trunk. >> > Sorry but shoudn't be this reversed? I.e. developers to convince users about > the stability of their project and the importance to use it? LOL, you are right. Unfortunately I don't have any tool to convince others that the code in trunk was not so bad and not stable as Noel (or anyone else) thought. > If "inactive" members are such a bottleneck for the project(considering the > overused veto right), why don't they simply quit? Is it so important for > them that "membership"? ASF meritocracy: you gain some right, you deserve them forever. I think this is ok. It is ok that people that dedicated years to some project will keep vote rights for the future: as I think that my opinions/votes should be taken in considerations also after an year of inactivity. We all collect experience on this project: every "expert" opinion is important. The problem in JAMES has been that we didn't/don't understand what each one want: someone thinks I didn't compromise enough and I didn't listen to other opinions, strictly pushing only my goals. I never accepted/liked to be guilty for this, so I can simply tell I don't think I am/was the problem but I cannot ignore them as there are rules (and I'm happy there are rules). I think the only solution will come from the community: your message is an help. Other users/developers could try helping, too. What there is in trunk is really not important compared to the community: we need again an active/live community, then we can discuss about trunk and how to release. I really can't (and don't want to) push anything anymore. > Thanks, > > Toni. Thank you, and sorry if this doesn't help with the release you asked for. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
