On 17 May 2012 15:50, Jesse McConnell <[email protected]> wrote: > if Mojo was a proper interrelated project where there was a vested > interest by all committers in the majority of all plugins...and if > issues on one plugin really reflected bad on others, then I can > understand the motivations of having a 72 hour vote and +1 buy-in from > other committers.
This is not Apache, it's OR not AND... on top of that the 72h is set by the person calling the vote, I don't see anyone having issue with defining criteria where the time can be shorter... > As it stands most of the plugins are handled by one > or two people each (afaik) and it makes little sense to me to have > other people just +1 someones desire to push out a new version with > some patches on it with a time intensive process behind it. > > Mojo is just a collection of diverse plugins, all grouped together at > the time so they could share in common top level configuration options > and the like and about the only thing that really helps having > projects here now is access to central on release, which can be worked > out many other ways as well. Reviewing documentation is a good example of where people's eyes are good... But quite frankly if the only reviewer I have is a blind man on a galloping horse, even he better than no reviewer. > > anyway, I just question the need for all this heavy process over a > project of discrete components that is intended as a convenience for > folks to get their plugins into central. How is: Step 1. Call a vote Step 2. Send a mail with results of vote Step 3. Click Release on nexus Step 4. Wait for sync to central Step 5. Update src/site/apt/plugins.apt & push mojo root site Step 6. Send [ANN] email for plugin release a Heavy process? Seriously? What are you proposing to cut out? Step 4 & 5 cannot be cut out without annoying our users. Step 3 & 6 are necessary to actually have a release. Steps 1 & 2 do not take more than 5-6 minutes of your time.... not exactly heavy IMHO > > its apparent I am in the minority on this though which is fine, I am > just commenting to supporting the OP on this because I ran across this > a year or so ago on the unix-maven-plugin and it was an annoyance > > cheers, > jesse > > -- > jesse mcconnell > [email protected] > > > On Thu, May 17, 2012 at 9:32 AM, Robert Scholte <[email protected]> > wrote: >> You can always deploy a SNAPSHOT and use that one untill the release is >> available. >> SNAPSHOTs are only a problem if you want to release. >> I can't imagine that you have to patch a plugin during those final and >> critical hours just before a release, unless the release cycle of those >> project is less than a couple of days. Patching under pressure makes the >> chance of introducing a bug higher. In such case I would at least show my >> code to somebody else to confirm I haven't made a mistake. >> If we go for the "or N times +1 whatever comes first", it is just a matter >> of finding some people who can look at it and give their +1. Could be done >> quite fast. >> >> -Robert >>> Date: Thu, 17 May 2012 16:07:22 +0200 >>> From: [email protected] >>> To: [email protected] >> >>> Subject: Re: [mojo-dev] [VOTE] Voting should not be a requirement for >>> patch releases >>> >>> Not sure I understand your point. If you fix the bugs, stage the >>> release and start the vote on Sunday, you could promote the release >>> (if voting is in favor) at any point. You don't have to close the vote >>> after exactly 48 hours (for example). >>> >>> But I understand that it could mentally feel good to do everything and >>> get the release out in the same go. But the cost of (new) errors is to >>> high IMHO. >>> >>> /Anders >>> >>> On Thu, May 17, 2012 at 11:59 AM, Christopher Hunt >>> <[email protected]> wrote: >>> > One final view if I may (looks as though the vote is dead anyhow). :-) >>> > >>> > Like many here I'm sure, I have a full-time job. For me to get in there, >>> > fix a few bugs, release and then exit, not requiring a vote makes this >>> > practical. If you require voting of 24, 48 or 72 hours, then that is >>> > another >>> > day. May be I fix the bugs on Sunday. I'm at work on Monday and Tuesday. >>> > Opportunity gone. This is my reality. >>> > >>> > Enough said though. I must naturally go with the consensus. >>> > >>> > Thanks for the hearing. >>> > --------------------------------------------------------------------- >>> > To unsubscribe from this list, please visit: >>> > >>> > http://xircles.codehaus.org/manage_email >>> > >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >>> > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
