On Wed, Aug 17, 2011 at 11:51 AM, Stephen Connolly <[email protected]> wrote: > Well look all we need to do is say that for pom releases the vote can > be as short as getting 3 binding +1's and it can be guillotined once > those three binding +1's have been cast. That could give you the > release in short time. In any case you cannot commit to the next > release version without fear of breakage until you have confirmed that > the pom has been pushed to central, which is every 8 hours IIRC
Unless we made use of a 'mirror trick'? I'm not sure that the following hangs together. What if there was a repo group for us at repository.apache.org that aggregated the staging repos for a flock of pom changes, and maven developers knew where to find a settings.xml with a mirror-of-* (to avoid adding <repository> elements to poms) that searched it in place of central? Then a releaser of the flock could stage the first, commit to it, stage the second ..., and then call a vote. (Except that this would require 'open' staging repos to be visible, which I fear that they are not?) > > On 17 August 2011 16:28, Benson Margulies <[email protected]> wrote: >> On Wed, Aug 17, 2011 at 11:15 AM, Mark Struberg <[email protected]> wrote: >>> Maybe I'm missing something, but why you cannot checkin the upgrade to the >>> non-yet-released parent? Ok, our ITs would be broken, but else? >> >> Not only the ITs, but the private builds of everyone who does an svn >> up between the checkin and the promotion. No? >> >> >> >>> >>> Devs of course should test the new parent upgrade anyway, so the build is >>> not accidentally 'broken'. >>> >>> LieGrue, >>> strub >>> >>> --- On Wed, 8/17/11, Benson Margulies <[email protected]> wrote: >>> >>>> From: Benson Margulies <[email protected]> >>>> Subject: Re: Must a pom release be an ASF release? >>>> To: "Maven Developers List" <[email protected]> >>>> Date: Wednesday, August 17, 2011, 3:05 PM >>>> I don't see how. If I want to change >>>> the plugins parent to refer to a >>>> new version of the global maven parent, I can't even check >>>> in that >>>> change to svn until the new global parent is deployed to a >>>> repository. >>>> Now, we might imagine using an extra repository for this, I >>>> guess ... >>>> >>>> On Wed, Aug 17, 2011 at 11:02 AM, Mark Struberg <[email protected]> >>>> wrote: >>>> > But we can do this all in one go, isn't? >>>> > >>>> > Just stage the projects locally and call Votes which >>>> are depending on each other. >>>> > >>>> > LieGrue, >>>> > strub >>>> > >>>> > --- On Wed, 8/17/11, Benson Margulies <[email protected]> >>>> wrote: >>>> > >>>> >> From: Benson Margulies <[email protected]> >>>> >> Subject: Re: Must a pom release be an ASF >>>> release? >>>> >> To: "Maven Developers List" <[email protected]> >>>> >> Date: Wednesday, August 17, 2011, 2:56 PM >>>> >> On Wed, Aug 17, 2011 at 10:45 AM, >>>> >> Brian Fox <[email protected]> >>>> >> wrote: >>>> >> > Benson, what problem exactly are you trying >>>> to solve >>>> >> here? >>>> >> >>>> >> 1) If you want to make a set of coordinated >>>> changes up the >>>> >> chain of >>>> >> poms, it's extremely time-consuming, with a 3-day >>>> vote at >>>> >> each step. >>>> >> >>>> >> 2) Our automated builds break during the 3-day >>>> window. >>>> >> >>>> >> >>>> >> > >>>> >> > On Wed, Aug 17, 2011 at 7:50 AM, Benson >>>> Margulies >>>> >> <[email protected]> >>>> >> wrote: >>>> >> >> This tees off of a remark in the recent >>>> vote >>>> >> thread about the >>>> >> >> disruption to CI of pom releases. >>>> >> >> >>>> >> >> I don't believe that we need the full ASF >>>> release >>>> >> voting process for >>>> >> >> our internal shared POMs. >>>> >> >> >>>> >> >> I reason as follows: >>>> >> >> >>>> >> >> The Apache release process creates a >>>> particular >>>> >> legal status for a >>>> >> >> body of code. This has certain advantages >>>> for >>>> >> users and developers. >>>> >> >> >>>> >> >> However, that assumes that there are >>>> users! >>>> >> However, these POMs are >>>> >> >> not intended for use by anything except >>>> other >>>> >> pieces of Maven (the >>>> >> >> global ASF pom might be an exception). >>>> Thus, they >>>> >> should be viewed as >>>> >> >> part of the releases of Maven itself and >>>> the >>>> >> components and plugins, >>>> >> >> not as independent releases. >>>> >> >> >>>> >> >> To build any of our user-visible >>>> components from >>>> >> source, you need to >>>> >> >> use the right parent POM (give our take >>>> our friend >>>> >> at Gentoo). >>>> >> >> Arguably, what we need here is a tweak to >>>> the >>>> >> source plugin, or some >>>> >> >> other plugin, that could sweep the chain >>>> of >>>> >> parents into 'the >>>> >> >> release', or at least enumerate them. We >>>> could >>>> >> then argue that, >>>> >> >> maven-release-plugin aside, the shared >>>> poms are >>>> >> formally 'released' >>>> >> >> when the components that use them are >>>> releases. >>>> >> >> >>>> >> >> If this argument holds water, the shared >>>> poms >>>> >> could be pushed via the >>>> >> >> maven-release-plugin via lazy consensus, >>>> and the >>>> >> CI problems go away. >>>> >> >> >>>> >> >> >>>> >> >>>> --------------------------------------------------------------------- >>>> >> >> To unsubscribe, e-mail: [email protected] >>>> >> >> For additional commands, e-mail: [email protected] >>>> >> >> >>>> >> >> >>>> >> > >>>> >> > >>>> >> >>>> --------------------------------------------------------------------- >>>> >> > To unsubscribe, e-mail: [email protected] >>>> >> > For additional commands, e-mail: [email protected] >>>> >> > >>>> >> > >>>> >> >>>> >> >>>> --------------------------------------------------------------------- >>>> >> To unsubscribe, e-mail: [email protected] >>>> >> For additional commands, e-mail: [email protected] >>>> >> >>>> >> >>>> > >>>> > >>>> --------------------------------------------------------------------- >>>> > To unsubscribe, e-mail: [email protected] >>>> > For additional commands, e-mail: [email protected] >>>> > >>>> > >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
