Re: [DISCUSSION] Modifications to Aries release process

[Holly Cummins <ho...@googlemail.com>]

Re-opening a slightly old conversation, just to ensure we have a
record of the advantages and disadvantages of each approach to
releasing groups of bundles. (I'm also updating the 'Releasing Aries'
web page with the pros and cons of each way of doing it.)

On Thu, Jun 28, 2012 at 6:12 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> I think you made a wrong assumption which is that the staging repo has
> to be backed by a single svn revision (which is btw not really the
> case because it comes from several tags anyway).
> What I'd suggest is doing the api bundles release and have them
> uploaded to nexus, then upgrade the implementations  and all other
> components to use those releases, commit,  release those other
> projects, THEN, close the staging repo and call for a vote.
> So we'd have a single staging repo / vote with a set of testable bundles in it.

This approach will break trunk unless we do an extra step.

Say we release an API bundle, at version 1.0.0. The release plugin
will change the version of the API bundle in trunk to be
1.0.1-SNAPSHOT. Normally, you'd just upgrade everything to depend on
1.0.1-SNAPSHOT of the API bundle (and if we weren't doing release by
bundle, the release plugin would automatically update the dependencies
for us). However, it's important that things which depend on the API
bundle continue depending on 1.0.0, unless there's a good reason to
change (like they use a new method). Otherwise, we lose a lot of the
benefits of semantic versioning. Why? If we add a new method to the
API, the package version changes to 1.1, and anything compiling
against 1.0.1-SNAPSHOT won't resolve against 1.0.0, even if it would
actually *work* fine against 1.0.0. In order to avoid restricting our
modularity, we need to depend on 1.0.0 unless the 1.0.1-SNAPSHOT
methods are actually being used.

So, continuing the example, in trunk, as part of the release, we've
switched to depending on 1.0.0 of the API. This compiles in the tagged
release, as long as bundles are compiled in a specific order. In
trunk, it won't compile at all, because nothing in trunk is building
API-1.0.0, and version 1.0.0 isn't in a maven repository yet. Instead,
trunk is building 1.0.1-SNAPSHOT. So to patch trunk up, we need to add
an extra step in which we switch back to depending on 1.0.0-SNAPSHOT,
and then a second extra step once the release is promoted, to depend
on 1.0.0.

I think this is sensible to do occasionally, but it's error prone and
makes more work for the release manager. Obviously, the big advantage
of it is that the release gets voted through over a period of a few
days, rather than a month or two, for a big release. :)

Holly



> On Thu, Jun 28, 2012 at 6:45 PM, Holly Cummins
> <ho...@googlemail.com> wrote:
>> Hi Guillaume,
>>
>> Thanks for your comments. Here are some of my thoughts ...
>>
>> On Thu, Jun 28, 2012 at 3:19 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>>> I think one problem, considering the current votes, is that it's
>>> really difficult to test anything.   Releasing api bundles with no
>>> implementation to test is definitely not helping imo.
>>
>> I know what you mean about the testing, and I'm not totally sure what
>> the best answer is. I know what I'm releasing comes from trunk, and is
>> being tested by the Jenkins builds, so I'm pretty confident it works
>> in a real system. However being tested in more environments and by
>> more systems is obviously a Good Thing.  I think the best way to test
>> the API bundles is with the current -SNAPSHOT bundles of the
>> implementation, either in something like the blog sample or some other
>> working system. If we weren't moving from 0.x to 1.0 you could also
>> test micro releases alongside existing impl bundles to ensure
>> everything resolves and works as claimed.
>>
>>> Holly, just a question: is there a specific reason why are you doing
>>> the release in multiple votes ? It would be simpler to just release
>>> everything in one go and wait for a longer time because there are more
>>> things to check, or at least, release the api + implementation so that
>>> we can actually try something.  Just my 2 cents.
>>
>> I agree that this sort of 'extended incremental' release is a bit
>> awkward, and I was wondering when someone would ask what on earth I
>> was doing :). IMO it's the cleanest way to work with with
>> release-by-bundle (which I know you disagree with). If I release
>> everything in one go, there's a problem with the dependencies between
>> bundles. At the moment in trunk, almost every dependency is a SNAPSHOT
>> dependency. In the past we've updated all bundles to use non-SNAPSHOT
>> (but not yet released) versions in a branch, and I could even do
>> something similar without using a branch by briefly having the trunk
>> builds produce 1.0.0 artefacts. However, I think this creates a
>> greater burden for testers. If there are compilation-order
>> dependencies between parts of a release which don't share a top-level
>> pom, everyone verifying a script has to compile them in the right
>> order. I count 118 bundles to release, so that's a lot of bundles to
>> get in the right order, and I didn't think any PMC member would want
>> to try. :) I guess this could be automated with a verification script
>> which either hardcodes or calculates the dependency graph, but it
>> seemed to me like more work for everyone and more risk for the
>> release. My hope was that if verifying individual mini-releases was
>> easy enough, doing multiple ones wouldn't be a problem (and in fact
>> would nicely distribute any effort, making it easier to vote).
>>
>> I know at this stage some of you are thinking "and *this* is why
>> release by bundle is a bad idea!", and that's not really a debate I
>> want to re-open. Among other things, I think any re-engineering of our
>> poms at this stage will further delay the release.
>>
>> The good news is I believe this problem will almost entirely go away
>> for 1.0.x and 1.x releases, because the impl bundle will, in most
>> cases, depend on an *already* released version of its API bundle or
>> another Aries component. This means a bunch of related bundles could
>> be released at the same time, without compile issues, or a meaningful
>> release really could consist of just a single bundle. That's true
>> modularity and it should give both us and our users big benefits.
>>
>>
>>>
>>> On Mon, Jun 25, 2012 at 8:07 PM, Daniel Kulp <dk...@apache.org> wrote:
>>>>
>>>> Honestly, with the change to using Nexus, the SHA1 and MD5 checks are
>>>> completely pointless.   Nexus generates them itself based on what's
>>>> uploaded.  The "is it a valid signature" part of the GPG testing is also
>>>> pointless as Nexus won't let you close the repo unless the signatures are
>>>> valid.   The only check you really need to do is to make sure the key that
>>>> was used is "trusted" by you.   (aka: was it really Holly who deployed those
>>>> artifacts)    So the monontonous parts of checking that stuff is really
>>>> irrelevant at this point.  (providing we trust that infra has Nexus
>>>> sufficiently locked down and secure)
>>>>
>>>>
>>>> I actually don't have a big issue with the difficulting in getting votes.
>>>> I'm involved in another community that has a PMC that is easily 4 times the
>>>> size of this one, yet we still have difficulting getting votes there.
>>>> While not ideal, life events can cause priority shifts and such so people
>>>> may not be able to be as responsive.
>>>>
>>>> My bigger problem is that the entire per bundle release process and symantic
>>>> versioning crap has put a HUGE burden on the release manager.   That makes
>>>> it much harder to get quality releases out and makes it less likely that
>>>> anyone will step up to get "minor fixes" released.   The only reason I
>>>> stepped up with the 0.3.1 bp stuff is that *MY*  customers are being
>>>> affected by it.   Like wise for the proxy stuff.   If *my* customers were
>>>> not affected, I don't think I would have spent the time and effort.    If
>>>> the process for getting fixes and releases out to users was smaller and
>>>> easier, I have no problem doing them.   For CXF, we do full releases on 3
>>>> branches every other month or so.   But that's because it's EASY to do.
>>>>
>>>> If it was up to me, I'd toss out the entire versioning thing with 1.0 and go
>>>> back to per module versioning thing.   So my fix to proxy would  have
>>>> involved checking out all of "proxy", fixing it, and releasing all of proxy
>>>> as a proxy "0.3.1", even the modules that haven't changed.   It's just a
>>>> huge hassle to track down which bundles have changed, which haven't which
>>>> version numbers need to be updated, etc....   If it's not quick and easy to
>>>> do releases as a release manager, very few people are going to step up to do
>>>> it.     It may not be 100% "proper OSGi", but IMO, getting fixes and such to
>>>> the users is more important than that.    But that's my opinion.
>>>>
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>> On Saturday, June 23, 2012 03:27:07 PM Holly Cummins wrote:
>>>>> Hi all,
>>>>>
>>>>> Now that Jeremy's taken the time to write up our release verification
>>>>> process, I'd like to propose we change it. :) I think it's too onerous
>>>>> on the pmc, which therefore also inhibits our ability to be responsive
>>>>> to our users.
>>>>>
>>>>>
>>>>> ------------------------------- Why what we have isn't working for the
>>>>> community -------------------------------
>>>>>
>>>>> I believe our users would like more frequent releases. We've had
>>>>> several keen requests and tweets and comments on the aries-user
>>>>> mailing list wishing we'd release more often. For example:
>>>>>
>>>>> * "Desperately waiting for an Aries release after loooong time.."
>>>>> * "The problem with Aries is they seem to be too busy coding to
>>>>> release anything."
>>>>> * "Compared to other projects (like Karaf and Camel) Aries releases
>>>>> tend to take quite some time."
>>>>> * "It's 2012 now and Aries 0.3 is almost a year old. Is there any
>>>>> chance of a new Aries JPA release any time soon? "
>>>>> * "Looks like Apache Aries has made no visible progress since Jan
>>>>> 2011, if the time stamps on the maven central artefacts are to be
>>>>> believed."
>>>>>
>>>>> ------------------------------- Why what we have isn't working for us
>>>>> -------------------------------
>>>>>
>>>>> Both Dan and I are trying to do releases at the moment, and struggling
>>>>> to get enough PMC votes. Dan's release is to back port a show-stopper
>>>>> proxy fix, so a release there is particularly pressing - he's got a
>>>>> non-binding +infinity vote, but that's all. My test support release
>>>>> vote has been open for about 64 hours, and only got one vote so far
>>>>> (thanks David B!). Obviously testsupport is less exciting than proxy,
>>>>> but that bundle does block more interesting releases.
>>>>>
>>>>> Why aren't people voting? My guess is that it's too much work to do
>>>>> the full set of verifications described at
>>>>> http://aries.apache.org/development/verifyingrelease.html. There are
>>>>> seven steps, and while they don't actually take that long to complete,
>>>>> it's enough of a burden that we tend to leave the voting to someone
>>>>> else unless we really care about a release. I'm as guilty of this as
>>>>> anyone - I think a release is a good idea, but I'm spending enough
>>>>> time working on the 1.0.0 release that I don't want to take time out
>>>>> to vote on another release. I suspect Dan might feel exactly the same
>>>>> about my 1.0.0 bundles. :)
>>>>>
>>>>> With release-by-bundle, there's a lot of verifications. Excluding the
>>>>> sandbox code, we have 123 bundles to release in 1.0.0. At three votes
>>>>> per bundle, that means the PMC need to do 369 MD5 checks, 369 PGP
>>>>> checks, 369 RAT checks, and so on, just to get 1.0.0 out the door.
>>>>> This just doesn't seem like it scales. Batching the bundle releases
>>>>> together eases some of this burden, but not all.
>>>>>
>>>>> ------------------------------- What I propose
>>>>> -------------------------------
>>>>>
>>>>> I suggest we move to a more trust-based system, where PMC members
>>>>> carefully check releases if they want, but where in general they're
>>>>> voting on the principle of the release, rather than the mechanics of
>>>>> the archives. In particular, they don't feel compelled to do checks
>>>>> before voting. If PMC members could say "Our users need this function,
>>>>> so +1", or "I know Holly has done sensible things in the past, so +1"
>>>>> or even "Do I want to check the SHAs on a test support bundle? Really?
>>>>> +1" it would get our releases moving better, and also save work for
>>>>> all of us.
>>>>>
>>>>> (At the moment I think what's happening is people are thinking "Do I
>>>>> want to check the SHAs on a test support bundle? Really?" and then
>>>>> skipping the +1 bit. :)  )
>>>>>
>>>>> To ensure that at least *someone* has run the checks, the release
>>>>> manager could include the output of the seven checks in an email to
>>>>> the list. I think this level of checking is perfectly compatible with
>>>>> the minimum Apache process, which is that the release manager signs
>>>>> the artefacts and three PMC members vote +1
>>>>> (http://www.apache.org/dev/release-publishing.html#voted).
>>>>>
>>>>> What do people think?
>>>>>
>>>>> Holly
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org - http://dankulp.com/blog
>>>> Talend Community Coder - http://coders.talend.com
>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> FuseSource, Integration everywhere
>>> http://fusesource.com
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> FuseSource, Integration everywhere
> http://fusesource.com

Re: [DISCUSSION] Modifications to Aries release process

[Guillaume Nodet <gn...@gmail.com>]

Git only has problems if you copy only a subtree (that's actually what is
done when tagging during the release process for a given module).  If you
branch the whole tree, it works perfectly with git and git-svn.  So I don't
think it would be worse on that side.

On Fri, Jul 6, 2012 at 3:51 PM, Holly Cummins <
holly.k.cummins@googlemail.com> wrote:

> Oh yes, I agree, that's the third approach, and it has a lot of
> advantages in terms of the stability of trunk. The disadvantage of
> that approach is that it doesn't seem to play well with the git
> mirroring. It also seems really wrong to me that we'd have to release
> mainline code from a branch, but that's just my personal feeling.
> There are advantages and disadvantages to each approach, and I don't
> think any of them are totally clean or totally simple, unfortunately.
>
> On Fri, Jul 6, 2012 at 2:31 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> > If the problem is to not destabilize trunk, one solution is to create a
> > branch and do all the release work in that branch.
> > That way, people are not impacted by the releases in progress.
> >
> > On Fri, Jul 6, 2012 at 3:24 PM, Holly Cummins <
> > holly.k.cummins@googlemail.com> wrote:
> >
> >> Re-opening a slightly old conversation, just to ensure we have a
> >> record of the advantages and disadvantages of each approach to
> >> releasing groups of bundles. (I'm also updating the 'Releasing Aries'
> >> web page with the pros and cons of each way of doing it.)
> >>
> >> On Thu, Jun 28, 2012 at 6:12 PM, Guillaume Nodet <gn...@gmail.com>
> wrote:
> >> > I think you made a wrong assumption which is that the staging repo has
> >> > to be backed by a single svn revision (which is btw not really the
> >> > case because it comes from several tags anyway).
> >> > What I'd suggest is doing the api bundles release and have them
> >> > uploaded to nexus, then upgrade the implementations  and all other
> >> > components to use those releases, commit,  release those other
> >> > projects, THEN, close the staging repo and call for a vote.
> >> > So we'd have a single staging repo / vote with a set of testable
> bundles
> >> in it.
> >>
> >> This approach will break trunk unless we do an extra step.
> >>
> >> Say we release an API bundle, at version 1.0.0. The release plugin
> >> will change the version of the API bundle in trunk to be
> >> 1.0.1-SNAPSHOT. Normally, you'd just upgrade everything to depend on
> >> 1.0.1-SNAPSHOT of the API bundle (and if we weren't doing release by
> >> bundle, the release plugin would automatically update the dependencies
> >> for us). However, it's important that things which depend on the API
> >> bundle continue depending on 1.0.0, unless there's a good reason to
> >> change (like they use a new method). Otherwise, we lose a lot of the
> >> benefits of semantic versioning. Why? If we add a new method to the
> >> API, the package version changes to 1.1, and anything compiling
> >> against 1.0.1-SNAPSHOT won't resolve against 1.0.0, even if it would
> >> actually *work* fine against 1.0.0. In order to avoid restricting our
> >> modularity, we need to depend on 1.0.0 unless the 1.0.1-SNAPSHOT
> >> methods are actually being used.
> >>
> >> So, continuing the example, in trunk, as part of the release, we've
> >> switched to depending on 1.0.0 of the API. This compiles in the tagged
> >> release, as long as bundles are compiled in a specific order. In
> >> trunk, it won't compile at all, because nothing in trunk is building
> >> API-1.0.0, and version 1.0.0 isn't in a maven repository yet. Instead,
> >> trunk is building 1.0.1-SNAPSHOT. So to patch trunk up, we need to add
> >> an extra step in which we switch back to depending on 1.0.0-SNAPSHOT,
> >> and then a second extra step once the release is promoted, to depend
> >> on 1.0.0.
> >>
> >> I think this is sensible to do occasionally, but it's error prone and
> >> makes more work for the release manager. Obviously, the big advantage
> >> of it is that the release gets voted through over a period of a few
> >> days, rather than a month or two, for a big release. :)
> >>
> >> Holly
> >>
> >>
> >>
> >> > On Thu, Jun 28, 2012 at 6:45 PM, Holly Cummins
> >> > <ho...@googlemail.com> wrote:
> >> >> Hi Guillaume,
> >> >>
> >> >> Thanks for your comments. Here are some of my thoughts ...
> >> >>
> >> >> On Thu, Jun 28, 2012 at 3:19 PM, Guillaume Nodet <gn...@gmail.com>
> >> wrote:
> >> >>> I think one problem, considering the current votes, is that it's
> >> >>> really difficult to test anything.   Releasing api bundles with no
> >> >>> implementation to test is definitely not helping imo.
> >> >>
> >> >> I know what you mean about the testing, and I'm not totally sure what
> >> >> the best answer is. I know what I'm releasing comes from trunk, and
> is
> >> >> being tested by the Jenkins builds, so I'm pretty confident it works
> >> >> in a real system. However being tested in more environments and by
> >> >> more systems is obviously a Good Thing.  I think the best way to test
> >> >> the API bundles is with the current -SNAPSHOT bundles of the
> >> >> implementation, either in something like the blog sample or some
> other
> >> >> working system. If we weren't moving from 0.x to 1.0 you could also
> >> >> test micro releases alongside existing impl bundles to ensure
> >> >> everything resolves and works as claimed.
> >> >>
> >> >>> Holly, just a question: is there a specific reason why are you doing
> >> >>> the release in multiple votes ? It would be simpler to just release
> >> >>> everything in one go and wait for a longer time because there are
> more
> >> >>> things to check, or at least, release the api + implementation so
> that
> >> >>> we can actually try something.  Just my 2 cents.
> >> >>
> >> >> I agree that this sort of 'extended incremental' release is a bit
> >> >> awkward, and I was wondering when someone would ask what on earth I
> >> >> was doing :). IMO it's the cleanest way to work with with
> >> >> release-by-bundle (which I know you disagree with). If I release
> >> >> everything in one go, there's a problem with the dependencies between
> >> >> bundles. At the moment in trunk, almost every dependency is a
> SNAPSHOT
> >> >> dependency. In the past we've updated all bundles to use non-SNAPSHOT
> >> >> (but not yet released) versions in a branch, and I could even do
> >> >> something similar without using a branch by briefly having the trunk
> >> >> builds produce 1.0.0 artefacts. However, I think this creates a
> >> >> greater burden for testers. If there are compilation-order
> >> >> dependencies between parts of a release which don't share a top-level
> >> >> pom, everyone verifying a script has to compile them in the right
> >> >> order. I count 118 bundles to release, so that's a lot of bundles to
> >> >> get in the right order, and I didn't think any PMC member would want
> >> >> to try. :) I guess this could be automated with a verification script
> >> >> which either hardcodes or calculates the dependency graph, but it
> >> >> seemed to me like more work for everyone and more risk for the
> >> >> release. My hope was that if verifying individual mini-releases was
> >> >> easy enough, doing multiple ones wouldn't be a problem (and in fact
> >> >> would nicely distribute any effort, making it easier to vote).
> >> >>
> >> >> I know at this stage some of you are thinking "and *this* is why
> >> >> release by bundle is a bad idea!", and that's not really a debate I
> >> >> want to re-open. Among other things, I think any re-engineering of
> our
> >> >> poms at this stage will further delay the release.
> >> >>
> >> >> The good news is I believe this problem will almost entirely go away
> >> >> for 1.0.x and 1.x releases, because the impl bundle will, in most
> >> >> cases, depend on an *already* released version of its API bundle or
> >> >> another Aries component. This means a bunch of related bundles could
> >> >> be released at the same time, without compile issues, or a meaningful
> >> >> release really could consist of just a single bundle. That's true
> >> >> modularity and it should give both us and our users big benefits.
> >> >>
> >> >>
> >> >>>
> >> >>> On Mon, Jun 25, 2012 at 8:07 PM, Daniel Kulp <dk...@apache.org>
> wrote:
> >> >>>>
> >> >>>> Honestly, with the change to using Nexus, the SHA1 and MD5 checks
> are
> >> >>>> completely pointless.   Nexus generates them itself based on what's
> >> >>>> uploaded.  The "is it a valid signature" part of the GPG testing is
> >> also
> >> >>>> pointless as Nexus won't let you close the repo unless the
> signatures
> >> are
> >> >>>> valid.   The only check you really need to do is to make sure the
> key
> >> that
> >> >>>> was used is "trusted" by you.   (aka: was it really Holly who
> >> deployed those
> >> >>>> artifacts)    So the monontonous parts of checking that stuff is
> >> really
> >> >>>> irrelevant at this point.  (providing we trust that infra has Nexus
> >> >>>> sufficiently locked down and secure)
> >> >>>>
> >> >>>>
> >> >>>> I actually don't have a big issue with the difficulting in getting
> >> votes.
> >> >>>> I'm involved in another community that has a PMC that is easily 4
> >> times the
> >> >>>> size of this one, yet we still have difficulting getting votes
> there.
> >> >>>> While not ideal, life events can cause priority shifts and such so
> >> people
> >> >>>> may not be able to be as responsive.
> >> >>>>
> >> >>>> My bigger problem is that the entire per bundle release process and
> >> symantic
> >> >>>> versioning crap has put a HUGE burden on the release manager.
> That
> >> makes
> >> >>>> it much harder to get quality releases out and makes it less likely
> >> that
> >> >>>> anyone will step up to get "minor fixes" released.   The only
> reason I
> >> >>>> stepped up with the 0.3.1 bp stuff is that *MY*  customers are
> being
> >> >>>> affected by it.   Like wise for the proxy stuff.   If *my*
> customers
> >> were
> >> >>>> not affected, I don't think I would have spent the time and effort.
> >>  If
> >> >>>> the process for getting fixes and releases out to users was smaller
> >> and
> >> >>>> easier, I have no problem doing them.   For CXF, we do full
> releases
> >> on 3
> >> >>>> branches every other month or so.   But that's because it's EASY to
> >> do.
> >> >>>>
> >> >>>> If it was up to me, I'd toss out the entire versioning thing with
> 1.0
> >> and go
> >> >>>> back to per module versioning thing.   So my fix to proxy would
>  have
> >> >>>> involved checking out all of "proxy", fixing it, and releasing all
> of
> >> proxy
> >> >>>> as a proxy "0.3.1", even the modules that haven't changed.   It's
> >> just a
> >> >>>> huge hassle to track down which bundles have changed, which haven't
> >> which
> >> >>>> version numbers need to be updated, etc....   If it's not quick and
> >> easy to
> >> >>>> do releases as a release manager, very few people are going to step
> >> up to do
> >> >>>> it.     It may not be 100% "proper OSGi", but IMO, getting fixes
> and
> >> such to
> >> >>>> the users is more important than that.    But that's my opinion.
> >> >>>>
> >> >>>>
> >> >>>> Dan
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> On Saturday, June 23, 2012 03:27:07 PM Holly Cummins wrote:
> >> >>>>> Hi all,
> >> >>>>>
> >> >>>>> Now that Jeremy's taken the time to write up our release
> verification
> >> >>>>> process, I'd like to propose we change it. :) I think it's too
> >> onerous
> >> >>>>> on the pmc, which therefore also inhibits our ability to be
> >> responsive
> >> >>>>> to our users.
> >> >>>>>
> >> >>>>>
> >> >>>>> ------------------------------- Why what we have isn't working for
> >> the
> >> >>>>> community -------------------------------
> >> >>>>>
> >> >>>>> I believe our users would like more frequent releases. We've had
> >> >>>>> several keen requests and tweets and comments on the aries-user
> >> >>>>> mailing list wishing we'd release more often. For example:
> >> >>>>>
> >> >>>>> * "Desperately waiting for an Aries release after loooong time.."
> >> >>>>> * "The problem with Aries is they seem to be too busy coding to
> >> >>>>> release anything."
> >> >>>>> * "Compared to other projects (like Karaf and Camel) Aries
> releases
> >> >>>>> tend to take quite some time."
> >> >>>>> * "It's 2012 now and Aries 0.3 is almost a year old. Is there any
> >> >>>>> chance of a new Aries JPA release any time soon? "
> >> >>>>> * "Looks like Apache Aries has made no visible progress since Jan
> >> >>>>> 2011, if the time stamps on the maven central artefacts are to be
> >> >>>>> believed."
> >> >>>>>
> >> >>>>> ------------------------------- Why what we have isn't working
> for us
> >> >>>>> -------------------------------
> >> >>>>>
> >> >>>>> Both Dan and I are trying to do releases at the moment, and
> >> struggling
> >> >>>>> to get enough PMC votes. Dan's release is to back port a
> show-stopper
> >> >>>>> proxy fix, so a release there is particularly pressing - he's got
> a
> >> >>>>> non-binding +infinity vote, but that's all. My test support
> release
> >> >>>>> vote has been open for about 64 hours, and only got one vote so
> far
> >> >>>>> (thanks David B!). Obviously testsupport is less exciting than
> proxy,
> >> >>>>> but that bundle does block more interesting releases.
> >> >>>>>
> >> >>>>> Why aren't people voting? My guess is that it's too much work to
> do
> >> >>>>> the full set of verifications described at
> >> >>>>> http://aries.apache.org/development/verifyingrelease.html. There
> are
> >> >>>>> seven steps, and while they don't actually take that long to
> >> complete,
> >> >>>>> it's enough of a burden that we tend to leave the voting to
> someone
> >> >>>>> else unless we really care about a release. I'm as guilty of this
> as
> >> >>>>> anyone - I think a release is a good idea, but I'm spending enough
> >> >>>>> time working on the 1.0.0 release that I don't want to take time
> out
> >> >>>>> to vote on another release. I suspect Dan might feel exactly the
> same
> >> >>>>> about my 1.0.0 bundles. :)
> >> >>>>>
> >> >>>>> With release-by-bundle, there's a lot of verifications. Excluding
> the
> >> >>>>> sandbox code, we have 123 bundles to release in 1.0.0. At three
> votes
> >> >>>>> per bundle, that means the PMC need to do 369 MD5 checks, 369 PGP
> >> >>>>> checks, 369 RAT checks, and so on, just to get 1.0.0 out the door.
> >> >>>>> This just doesn't seem like it scales. Batching the bundle
> releases
> >> >>>>> together eases some of this burden, but not all.
> >> >>>>>
> >> >>>>> ------------------------------- What I propose
> >> >>>>> -------------------------------
> >> >>>>>
> >> >>>>> I suggest we move to a more trust-based system, where PMC members
> >> >>>>> carefully check releases if they want, but where in general
> they're
> >> >>>>> voting on the principle of the release, rather than the mechanics
> of
> >> >>>>> the archives. In particular, they don't feel compelled to do
> checks
> >> >>>>> before voting. If PMC members could say "Our users need this
> >> function,
> >> >>>>> so +1", or "I know Holly has done sensible things in the past, so
> +1"
> >> >>>>> or even "Do I want to check the SHAs on a test support bundle?
> >> Really?
> >> >>>>> +1" it would get our releases moving better, and also save work
> for
> >> >>>>> all of us.
> >> >>>>>
> >> >>>>> (At the moment I think what's happening is people are thinking
> "Do I
> >> >>>>> want to check the SHAs on a test support bundle? Really?" and then
> >> >>>>> skipping the +1 bit. :)  )
> >> >>>>>
> >> >>>>> To ensure that at least *someone* has run the checks, the release
> >> >>>>> manager could include the output of the seven checks in an email
> to
> >> >>>>> the list. I think this level of checking is perfectly compatible
> with
> >> >>>>> the minimum Apache process, which is that the release manager
> signs
> >> >>>>> the artefacts and three PMC members vote +1
> >> >>>>> (http://www.apache.org/dev/release-publishing.html#voted).
> >> >>>>>
> >> >>>>> What do people think?
> >> >>>>>
> >> >>>>> Holly
> >> >>>> --
> >> >>>> Daniel Kulp
> >> >>>> dkulp@apache.org - http://dankulp.com/blog
> >> >>>> Talend Community Coder - http://coders.talend.com
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> ------------------------
> >> >>> Guillaume Nodet
> >> >>> ------------------------
> >> >>> Blog: http://gnodet.blogspot.com/
> >> >>> ------------------------
> >> >>> FuseSource, Integration everywhere
> >> >>> http://fusesource.com
> >> >
> >> >
> >> >
> >> > --
> >> > ------------------------
> >> > Guillaume Nodet
> >> > ------------------------
> >> > Blog: http://gnodet.blogspot.com/
> >> > ------------------------
> >> > FuseSource, Integration everywhere
> >> > http://fusesource.com
> >>
> >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > FuseSource, Integration everywhere
> > http://fusesource.com
>



-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

Re: [DISCUSSION] Modifications to Aries release process

[Holly Cummins <ho...@googlemail.com>]

Oh yes, I agree, that's the third approach, and it has a lot of
advantages in terms of the stability of trunk. The disadvantage of
that approach is that it doesn't seem to play well with the git
mirroring. It also seems really wrong to me that we'd have to release
mainline code from a branch, but that's just my personal feeling.
There are advantages and disadvantages to each approach, and I don't
think any of them are totally clean or totally simple, unfortunately.

On Fri, Jul 6, 2012 at 2:31 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> If the problem is to not destabilize trunk, one solution is to create a
> branch and do all the release work in that branch.
> That way, people are not impacted by the releases in progress.
>
> On Fri, Jul 6, 2012 at 3:24 PM, Holly Cummins <
> holly.k.cummins@googlemail.com> wrote:
>
>> Re-opening a slightly old conversation, just to ensure we have a
>> record of the advantages and disadvantages of each approach to
>> releasing groups of bundles. (I'm also updating the 'Releasing Aries'
>> web page with the pros and cons of each way of doing it.)
>>
>> On Thu, Jun 28, 2012 at 6:12 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>> > I think you made a wrong assumption which is that the staging repo has
>> > to be backed by a single svn revision (which is btw not really the
>> > case because it comes from several tags anyway).
>> > What I'd suggest is doing the api bundles release and have them
>> > uploaded to nexus, then upgrade the implementations  and all other
>> > components to use those releases, commit,  release those other
>> > projects, THEN, close the staging repo and call for a vote.
>> > So we'd have a single staging repo / vote with a set of testable bundles
>> in it.
>>
>> This approach will break trunk unless we do an extra step.
>>
>> Say we release an API bundle, at version 1.0.0. The release plugin
>> will change the version of the API bundle in trunk to be
>> 1.0.1-SNAPSHOT. Normally, you'd just upgrade everything to depend on
>> 1.0.1-SNAPSHOT of the API bundle (and if we weren't doing release by
>> bundle, the release plugin would automatically update the dependencies
>> for us). However, it's important that things which depend on the API
>> bundle continue depending on 1.0.0, unless there's a good reason to
>> change (like they use a new method). Otherwise, we lose a lot of the
>> benefits of semantic versioning. Why? If we add a new method to the
>> API, the package version changes to 1.1, and anything compiling
>> against 1.0.1-SNAPSHOT won't resolve against 1.0.0, even if it would
>> actually *work* fine against 1.0.0. In order to avoid restricting our
>> modularity, we need to depend on 1.0.0 unless the 1.0.1-SNAPSHOT
>> methods are actually being used.
>>
>> So, continuing the example, in trunk, as part of the release, we've
>> switched to depending on 1.0.0 of the API. This compiles in the tagged
>> release, as long as bundles are compiled in a specific order. In
>> trunk, it won't compile at all, because nothing in trunk is building
>> API-1.0.0, and version 1.0.0 isn't in a maven repository yet. Instead,
>> trunk is building 1.0.1-SNAPSHOT. So to patch trunk up, we need to add
>> an extra step in which we switch back to depending on 1.0.0-SNAPSHOT,
>> and then a second extra step once the release is promoted, to depend
>> on 1.0.0.
>>
>> I think this is sensible to do occasionally, but it's error prone and
>> makes more work for the release manager. Obviously, the big advantage
>> of it is that the release gets voted through over a period of a few
>> days, rather than a month or two, for a big release. :)
>>
>> Holly
>>
>>
>>
>> > On Thu, Jun 28, 2012 at 6:45 PM, Holly Cummins
>> > <ho...@googlemail.com> wrote:
>> >> Hi Guillaume,
>> >>
>> >> Thanks for your comments. Here are some of my thoughts ...
>> >>
>> >> On Thu, Jun 28, 2012 at 3:19 PM, Guillaume Nodet <gn...@gmail.com>
>> wrote:
>> >>> I think one problem, considering the current votes, is that it's
>> >>> really difficult to test anything.   Releasing api bundles with no
>> >>> implementation to test is definitely not helping imo.
>> >>
>> >> I know what you mean about the testing, and I'm not totally sure what
>> >> the best answer is. I know what I'm releasing comes from trunk, and is
>> >> being tested by the Jenkins builds, so I'm pretty confident it works
>> >> in a real system. However being tested in more environments and by
>> >> more systems is obviously a Good Thing.  I think the best way to test
>> >> the API bundles is with the current -SNAPSHOT bundles of the
>> >> implementation, either in something like the blog sample or some other
>> >> working system. If we weren't moving from 0.x to 1.0 you could also
>> >> test micro releases alongside existing impl bundles to ensure
>> >> everything resolves and works as claimed.
>> >>
>> >>> Holly, just a question: is there a specific reason why are you doing
>> >>> the release in multiple votes ? It would be simpler to just release
>> >>> everything in one go and wait for a longer time because there are more
>> >>> things to check, or at least, release the api + implementation so that
>> >>> we can actually try something.  Just my 2 cents.
>> >>
>> >> I agree that this sort of 'extended incremental' release is a bit
>> >> awkward, and I was wondering when someone would ask what on earth I
>> >> was doing :). IMO it's the cleanest way to work with with
>> >> release-by-bundle (which I know you disagree with). If I release
>> >> everything in one go, there's a problem with the dependencies between
>> >> bundles. At the moment in trunk, almost every dependency is a SNAPSHOT
>> >> dependency. In the past we've updated all bundles to use non-SNAPSHOT
>> >> (but not yet released) versions in a branch, and I could even do
>> >> something similar without using a branch by briefly having the trunk
>> >> builds produce 1.0.0 artefacts. However, I think this creates a
>> >> greater burden for testers. If there are compilation-order
>> >> dependencies between parts of a release which don't share a top-level
>> >> pom, everyone verifying a script has to compile them in the right
>> >> order. I count 118 bundles to release, so that's a lot of bundles to
>> >> get in the right order, and I didn't think any PMC member would want
>> >> to try. :) I guess this could be automated with a verification script
>> >> which either hardcodes or calculates the dependency graph, but it
>> >> seemed to me like more work for everyone and more risk for the
>> >> release. My hope was that if verifying individual mini-releases was
>> >> easy enough, doing multiple ones wouldn't be a problem (and in fact
>> >> would nicely distribute any effort, making it easier to vote).
>> >>
>> >> I know at this stage some of you are thinking "and *this* is why
>> >> release by bundle is a bad idea!", and that's not really a debate I
>> >> want to re-open. Among other things, I think any re-engineering of our
>> >> poms at this stage will further delay the release.
>> >>
>> >> The good news is I believe this problem will almost entirely go away
>> >> for 1.0.x and 1.x releases, because the impl bundle will, in most
>> >> cases, depend on an *already* released version of its API bundle or
>> >> another Aries component. This means a bunch of related bundles could
>> >> be released at the same time, without compile issues, or a meaningful
>> >> release really could consist of just a single bundle. That's true
>> >> modularity and it should give both us and our users big benefits.
>> >>
>> >>
>> >>>
>> >>> On Mon, Jun 25, 2012 at 8:07 PM, Daniel Kulp <dk...@apache.org> wrote:
>> >>>>
>> >>>> Honestly, with the change to using Nexus, the SHA1 and MD5 checks are
>> >>>> completely pointless.   Nexus generates them itself based on what's
>> >>>> uploaded.  The "is it a valid signature" part of the GPG testing is
>> also
>> >>>> pointless as Nexus won't let you close the repo unless the signatures
>> are
>> >>>> valid.   The only check you really need to do is to make sure the key
>> that
>> >>>> was used is "trusted" by you.   (aka: was it really Holly who
>> deployed those
>> >>>> artifacts)    So the monontonous parts of checking that stuff is
>> really
>> >>>> irrelevant at this point.  (providing we trust that infra has Nexus
>> >>>> sufficiently locked down and secure)
>> >>>>
>> >>>>
>> >>>> I actually don't have a big issue with the difficulting in getting
>> votes.
>> >>>> I'm involved in another community that has a PMC that is easily 4
>> times the
>> >>>> size of this one, yet we still have difficulting getting votes there.
>> >>>> While not ideal, life events can cause priority shifts and such so
>> people
>> >>>> may not be able to be as responsive.
>> >>>>
>> >>>> My bigger problem is that the entire per bundle release process and
>> symantic
>> >>>> versioning crap has put a HUGE burden on the release manager.   That
>> makes
>> >>>> it much harder to get quality releases out and makes it less likely
>> that
>> >>>> anyone will step up to get "minor fixes" released.   The only reason I
>> >>>> stepped up with the 0.3.1 bp stuff is that *MY*  customers are being
>> >>>> affected by it.   Like wise for the proxy stuff.   If *my* customers
>> were
>> >>>> not affected, I don't think I would have spent the time and effort.
>>  If
>> >>>> the process for getting fixes and releases out to users was smaller
>> and
>> >>>> easier, I have no problem doing them.   For CXF, we do full releases
>> on 3
>> >>>> branches every other month or so.   But that's because it's EASY to
>> do.
>> >>>>
>> >>>> If it was up to me, I'd toss out the entire versioning thing with 1.0
>> and go
>> >>>> back to per module versioning thing.   So my fix to proxy would  have
>> >>>> involved checking out all of "proxy", fixing it, and releasing all of
>> proxy
>> >>>> as a proxy "0.3.1", even the modules that haven't changed.   It's
>> just a
>> >>>> huge hassle to track down which bundles have changed, which haven't
>> which
>> >>>> version numbers need to be updated, etc....   If it's not quick and
>> easy to
>> >>>> do releases as a release manager, very few people are going to step
>> up to do
>> >>>> it.     It may not be 100% "proper OSGi", but IMO, getting fixes and
>> such to
>> >>>> the users is more important than that.    But that's my opinion.
>> >>>>
>> >>>>
>> >>>> Dan
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Saturday, June 23, 2012 03:27:07 PM Holly Cummins wrote:
>> >>>>> Hi all,
>> >>>>>
>> >>>>> Now that Jeremy's taken the time to write up our release verification
>> >>>>> process, I'd like to propose we change it. :) I think it's too
>> onerous
>> >>>>> on the pmc, which therefore also inhibits our ability to be
>> responsive
>> >>>>> to our users.
>> >>>>>
>> >>>>>
>> >>>>> ------------------------------- Why what we have isn't working for
>> the
>> >>>>> community -------------------------------
>> >>>>>
>> >>>>> I believe our users would like more frequent releases. We've had
>> >>>>> several keen requests and tweets and comments on the aries-user
>> >>>>> mailing list wishing we'd release more often. For example:
>> >>>>>
>> >>>>> * "Desperately waiting for an Aries release after loooong time.."
>> >>>>> * "The problem with Aries is they seem to be too busy coding to
>> >>>>> release anything."
>> >>>>> * "Compared to other projects (like Karaf and Camel) Aries releases
>> >>>>> tend to take quite some time."
>> >>>>> * "It's 2012 now and Aries 0.3 is almost a year old. Is there any
>> >>>>> chance of a new Aries JPA release any time soon? "
>> >>>>> * "Looks like Apache Aries has made no visible progress since Jan
>> >>>>> 2011, if the time stamps on the maven central artefacts are to be
>> >>>>> believed."
>> >>>>>
>> >>>>> ------------------------------- Why what we have isn't working for us
>> >>>>> -------------------------------
>> >>>>>
>> >>>>> Both Dan and I are trying to do releases at the moment, and
>> struggling
>> >>>>> to get enough PMC votes. Dan's release is to back port a show-stopper
>> >>>>> proxy fix, so a release there is particularly pressing - he's got a
>> >>>>> non-binding +infinity vote, but that's all. My test support release
>> >>>>> vote has been open for about 64 hours, and only got one vote so far
>> >>>>> (thanks David B!). Obviously testsupport is less exciting than proxy,
>> >>>>> but that bundle does block more interesting releases.
>> >>>>>
>> >>>>> Why aren't people voting? My guess is that it's too much work to do
>> >>>>> the full set of verifications described at
>> >>>>> http://aries.apache.org/development/verifyingrelease.html. There are
>> >>>>> seven steps, and while they don't actually take that long to
>> complete,
>> >>>>> it's enough of a burden that we tend to leave the voting to someone
>> >>>>> else unless we really care about a release. I'm as guilty of this as
>> >>>>> anyone - I think a release is a good idea, but I'm spending enough
>> >>>>> time working on the 1.0.0 release that I don't want to take time out
>> >>>>> to vote on another release. I suspect Dan might feel exactly the same
>> >>>>> about my 1.0.0 bundles. :)
>> >>>>>
>> >>>>> With release-by-bundle, there's a lot of verifications. Excluding the
>> >>>>> sandbox code, we have 123 bundles to release in 1.0.0. At three votes
>> >>>>> per bundle, that means the PMC need to do 369 MD5 checks, 369 PGP
>> >>>>> checks, 369 RAT checks, and so on, just to get 1.0.0 out the door.
>> >>>>> This just doesn't seem like it scales. Batching the bundle releases
>> >>>>> together eases some of this burden, but not all.
>> >>>>>
>> >>>>> ------------------------------- What I propose
>> >>>>> -------------------------------
>> >>>>>
>> >>>>> I suggest we move to a more trust-based system, where PMC members
>> >>>>> carefully check releases if they want, but where in general they're
>> >>>>> voting on the principle of the release, rather than the mechanics of
>> >>>>> the archives. In particular, they don't feel compelled to do checks
>> >>>>> before voting. If PMC members could say "Our users need this
>> function,
>> >>>>> so +1", or "I know Holly has done sensible things in the past, so +1"
>> >>>>> or even "Do I want to check the SHAs on a test support bundle?
>> Really?
>> >>>>> +1" it would get our releases moving better, and also save work for
>> >>>>> all of us.
>> >>>>>
>> >>>>> (At the moment I think what's happening is people are thinking "Do I
>> >>>>> want to check the SHAs on a test support bundle? Really?" and then
>> >>>>> skipping the +1 bit. :)  )
>> >>>>>
>> >>>>> To ensure that at least *someone* has run the checks, the release
>> >>>>> manager could include the output of the seven checks in an email to
>> >>>>> the list. I think this level of checking is perfectly compatible with
>> >>>>> the minimum Apache process, which is that the release manager signs
>> >>>>> the artefacts and three PMC members vote +1
>> >>>>> (http://www.apache.org/dev/release-publishing.html#voted).
>> >>>>>
>> >>>>> What do people think?
>> >>>>>
>> >>>>> Holly
>> >>>> --
>> >>>> Daniel Kulp
>> >>>> dkulp@apache.org - http://dankulp.com/blog
>> >>>> Talend Community Coder - http://coders.talend.com
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> ------------------------
>> >>> Guillaume Nodet
>> >>> ------------------------
>> >>> Blog: http://gnodet.blogspot.com/
>> >>> ------------------------
>> >>> FuseSource, Integration everywhere
>> >>> http://fusesource.com
>> >
>> >
>> >
>> > --
>> > ------------------------
>> > Guillaume Nodet
>> > ------------------------
>> > Blog: http://gnodet.blogspot.com/
>> > ------------------------
>> > FuseSource, Integration everywhere
>> > http://fusesource.com
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> FuseSource, Integration everywhere
> http://fusesource.com

Re: [DISCUSSION] Modifications to Aries release process

[Guillaume Nodet <gn...@gmail.com>]

If the problem is to not destabilize trunk, one solution is to create a
branch and do all the release work in that branch.
That way, people are not impacted by the releases in progress.

On Fri, Jul 6, 2012 at 3:24 PM, Holly Cummins <
holly.k.cummins@googlemail.com> wrote:

> Re-opening a slightly old conversation, just to ensure we have a
> record of the advantages and disadvantages of each approach to
> releasing groups of bundles. (I'm also updating the 'Releasing Aries'
> web page with the pros and cons of each way of doing it.)
>
> On Thu, Jun 28, 2012 at 6:12 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> > I think you made a wrong assumption which is that the staging repo has
> > to be backed by a single svn revision (which is btw not really the
> > case because it comes from several tags anyway).
> > What I'd suggest is doing the api bundles release and have them
> > uploaded to nexus, then upgrade the implementations  and all other
> > components to use those releases, commit,  release those other
> > projects, THEN, close the staging repo and call for a vote.
> > So we'd have a single staging repo / vote with a set of testable bundles
> in it.
>
> This approach will break trunk unless we do an extra step.
>
> Say we release an API bundle, at version 1.0.0. The release plugin
> will change the version of the API bundle in trunk to be
> 1.0.1-SNAPSHOT. Normally, you'd just upgrade everything to depend on
> 1.0.1-SNAPSHOT of the API bundle (and if we weren't doing release by
> bundle, the release plugin would automatically update the dependencies
> for us). However, it's important that things which depend on the API
> bundle continue depending on 1.0.0, unless there's a good reason to
> change (like they use a new method). Otherwise, we lose a lot of the
> benefits of semantic versioning. Why? If we add a new method to the
> API, the package version changes to 1.1, and anything compiling
> against 1.0.1-SNAPSHOT won't resolve against 1.0.0, even if it would
> actually *work* fine against 1.0.0. In order to avoid restricting our
> modularity, we need to depend on 1.0.0 unless the 1.0.1-SNAPSHOT
> methods are actually being used.
>
> So, continuing the example, in trunk, as part of the release, we've
> switched to depending on 1.0.0 of the API. This compiles in the tagged
> release, as long as bundles are compiled in a specific order. In
> trunk, it won't compile at all, because nothing in trunk is building
> API-1.0.0, and version 1.0.0 isn't in a maven repository yet. Instead,
> trunk is building 1.0.1-SNAPSHOT. So to patch trunk up, we need to add
> an extra step in which we switch back to depending on 1.0.0-SNAPSHOT,
> and then a second extra step once the release is promoted, to depend
> on 1.0.0.
>
> I think this is sensible to do occasionally, but it's error prone and
> makes more work for the release manager. Obviously, the big advantage
> of it is that the release gets voted through over a period of a few
> days, rather than a month or two, for a big release. :)
>
> Holly
>
>
>
> > On Thu, Jun 28, 2012 at 6:45 PM, Holly Cummins
> > <ho...@googlemail.com> wrote:
> >> Hi Guillaume,
> >>
> >> Thanks for your comments. Here are some of my thoughts ...
> >>
> >> On Thu, Jun 28, 2012 at 3:19 PM, Guillaume Nodet <gn...@gmail.com>
> wrote:
> >>> I think one problem, considering the current votes, is that it's
> >>> really difficult to test anything.   Releasing api bundles with no
> >>> implementation to test is definitely not helping imo.
> >>
> >> I know what you mean about the testing, and I'm not totally sure what
> >> the best answer is. I know what I'm releasing comes from trunk, and is
> >> being tested by the Jenkins builds, so I'm pretty confident it works
> >> in a real system. However being tested in more environments and by
> >> more systems is obviously a Good Thing.  I think the best way to test
> >> the API bundles is with the current -SNAPSHOT bundles of the
> >> implementation, either in something like the blog sample or some other
> >> working system. If we weren't moving from 0.x to 1.0 you could also
> >> test micro releases alongside existing impl bundles to ensure
> >> everything resolves and works as claimed.
> >>
> >>> Holly, just a question: is there a specific reason why are you doing
> >>> the release in multiple votes ? It would be simpler to just release
> >>> everything in one go and wait for a longer time because there are more
> >>> things to check, or at least, release the api + implementation so that
> >>> we can actually try something.  Just my 2 cents.
> >>
> >> I agree that this sort of 'extended incremental' release is a bit
> >> awkward, and I was wondering when someone would ask what on earth I
> >> was doing :). IMO it's the cleanest way to work with with
> >> release-by-bundle (which I know you disagree with). If I release
> >> everything in one go, there's a problem with the dependencies between
> >> bundles. At the moment in trunk, almost every dependency is a SNAPSHOT
> >> dependency. In the past we've updated all bundles to use non-SNAPSHOT
> >> (but not yet released) versions in a branch, and I could even do
> >> something similar without using a branch by briefly having the trunk
> >> builds produce 1.0.0 artefacts. However, I think this creates a
> >> greater burden for testers. If there are compilation-order
> >> dependencies between parts of a release which don't share a top-level
> >> pom, everyone verifying a script has to compile them in the right
> >> order. I count 118 bundles to release, so that's a lot of bundles to
> >> get in the right order, and I didn't think any PMC member would want
> >> to try. :) I guess this could be automated with a verification script
> >> which either hardcodes or calculates the dependency graph, but it
> >> seemed to me like more work for everyone and more risk for the
> >> release. My hope was that if verifying individual mini-releases was
> >> easy enough, doing multiple ones wouldn't be a problem (and in fact
> >> would nicely distribute any effort, making it easier to vote).
> >>
> >> I know at this stage some of you are thinking "and *this* is why
> >> release by bundle is a bad idea!", and that's not really a debate I
> >> want to re-open. Among other things, I think any re-engineering of our
> >> poms at this stage will further delay the release.
> >>
> >> The good news is I believe this problem will almost entirely go away
> >> for 1.0.x and 1.x releases, because the impl bundle will, in most
> >> cases, depend on an *already* released version of its API bundle or
> >> another Aries component. This means a bunch of related bundles could
> >> be released at the same time, without compile issues, or a meaningful
> >> release really could consist of just a single bundle. That's true
> >> modularity and it should give both us and our users big benefits.
> >>
> >>
> >>>
> >>> On Mon, Jun 25, 2012 at 8:07 PM, Daniel Kulp <dk...@apache.org> wrote:
> >>>>
> >>>> Honestly, with the change to using Nexus, the SHA1 and MD5 checks are
> >>>> completely pointless.   Nexus generates them itself based on what's
> >>>> uploaded.  The "is it a valid signature" part of the GPG testing is
> also
> >>>> pointless as Nexus won't let you close the repo unless the signatures
> are
> >>>> valid.   The only check you really need to do is to make sure the key
> that
> >>>> was used is "trusted" by you.   (aka: was it really Holly who
> deployed those
> >>>> artifacts)    So the monontonous parts of checking that stuff is
> really
> >>>> irrelevant at this point.  (providing we trust that infra has Nexus
> >>>> sufficiently locked down and secure)
> >>>>
> >>>>
> >>>> I actually don't have a big issue with the difficulting in getting
> votes.
> >>>> I'm involved in another community that has a PMC that is easily 4
> times the
> >>>> size of this one, yet we still have difficulting getting votes there.
> >>>> While not ideal, life events can cause priority shifts and such so
> people
> >>>> may not be able to be as responsive.
> >>>>
> >>>> My bigger problem is that the entire per bundle release process and
> symantic
> >>>> versioning crap has put a HUGE burden on the release manager.   That
> makes
> >>>> it much harder to get quality releases out and makes it less likely
> that
> >>>> anyone will step up to get "minor fixes" released.   The only reason I
> >>>> stepped up with the 0.3.1 bp stuff is that *MY*  customers are being
> >>>> affected by it.   Like wise for the proxy stuff.   If *my* customers
> were
> >>>> not affected, I don't think I would have spent the time and effort.
>  If
> >>>> the process for getting fixes and releases out to users was smaller
> and
> >>>> easier, I have no problem doing them.   For CXF, we do full releases
> on 3
> >>>> branches every other month or so.   But that's because it's EASY to
> do.
> >>>>
> >>>> If it was up to me, I'd toss out the entire versioning thing with 1.0
> and go
> >>>> back to per module versioning thing.   So my fix to proxy would  have
> >>>> involved checking out all of "proxy", fixing it, and releasing all of
> proxy
> >>>> as a proxy "0.3.1", even the modules that haven't changed.   It's
> just a
> >>>> huge hassle to track down which bundles have changed, which haven't
> which
> >>>> version numbers need to be updated, etc....   If it's not quick and
> easy to
> >>>> do releases as a release manager, very few people are going to step
> up to do
> >>>> it.     It may not be 100% "proper OSGi", but IMO, getting fixes and
> such to
> >>>> the users is more important than that.    But that's my opinion.
> >>>>
> >>>>
> >>>> Dan
> >>>>
> >>>>
> >>>>
> >>>> On Saturday, June 23, 2012 03:27:07 PM Holly Cummins wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> Now that Jeremy's taken the time to write up our release verification
> >>>>> process, I'd like to propose we change it. :) I think it's too
> onerous
> >>>>> on the pmc, which therefore also inhibits our ability to be
> responsive
> >>>>> to our users.
> >>>>>
> >>>>>
> >>>>> ------------------------------- Why what we have isn't working for
> the
> >>>>> community -------------------------------
> >>>>>
> >>>>> I believe our users would like more frequent releases. We've had
> >>>>> several keen requests and tweets and comments on the aries-user
> >>>>> mailing list wishing we'd release more often. For example:
> >>>>>
> >>>>> * "Desperately waiting for an Aries release after loooong time.."
> >>>>> * "The problem with Aries is they seem to be too busy coding to
> >>>>> release anything."
> >>>>> * "Compared to other projects (like Karaf and Camel) Aries releases
> >>>>> tend to take quite some time."
> >>>>> * "It's 2012 now and Aries 0.3 is almost a year old. Is there any
> >>>>> chance of a new Aries JPA release any time soon? "
> >>>>> * "Looks like Apache Aries has made no visible progress since Jan
> >>>>> 2011, if the time stamps on the maven central artefacts are to be
> >>>>> believed."
> >>>>>
> >>>>> ------------------------------- Why what we have isn't working for us
> >>>>> -------------------------------
> >>>>>
> >>>>> Both Dan and I are trying to do releases at the moment, and
> struggling
> >>>>> to get enough PMC votes. Dan's release is to back port a show-stopper
> >>>>> proxy fix, so a release there is particularly pressing - he's got a
> >>>>> non-binding +infinity vote, but that's all. My test support release
> >>>>> vote has been open for about 64 hours, and only got one vote so far
> >>>>> (thanks David B!). Obviously testsupport is less exciting than proxy,
> >>>>> but that bundle does block more interesting releases.
> >>>>>
> >>>>> Why aren't people voting? My guess is that it's too much work to do
> >>>>> the full set of verifications described at
> >>>>> http://aries.apache.org/development/verifyingrelease.html. There are
> >>>>> seven steps, and while they don't actually take that long to
> complete,
> >>>>> it's enough of a burden that we tend to leave the voting to someone
> >>>>> else unless we really care about a release. I'm as guilty of this as
> >>>>> anyone - I think a release is a good idea, but I'm spending enough
> >>>>> time working on the 1.0.0 release that I don't want to take time out
> >>>>> to vote on another release. I suspect Dan might feel exactly the same
> >>>>> about my 1.0.0 bundles. :)
> >>>>>
> >>>>> With release-by-bundle, there's a lot of verifications. Excluding the
> >>>>> sandbox code, we have 123 bundles to release in 1.0.0. At three votes
> >>>>> per bundle, that means the PMC need to do 369 MD5 checks, 369 PGP
> >>>>> checks, 369 RAT checks, and so on, just to get 1.0.0 out the door.
> >>>>> This just doesn't seem like it scales. Batching the bundle releases
> >>>>> together eases some of this burden, but not all.
> >>>>>
> >>>>> ------------------------------- What I propose
> >>>>> -------------------------------
> >>>>>
> >>>>> I suggest we move to a more trust-based system, where PMC members
> >>>>> carefully check releases if they want, but where in general they're
> >>>>> voting on the principle of the release, rather than the mechanics of
> >>>>> the archives. In particular, they don't feel compelled to do checks
> >>>>> before voting. If PMC members could say "Our users need this
> function,
> >>>>> so +1", or "I know Holly has done sensible things in the past, so +1"
> >>>>> or even "Do I want to check the SHAs on a test support bundle?
> Really?
> >>>>> +1" it would get our releases moving better, and also save work for
> >>>>> all of us.
> >>>>>
> >>>>> (At the moment I think what's happening is people are thinking "Do I
> >>>>> want to check the SHAs on a test support bundle? Really?" and then
> >>>>> skipping the +1 bit. :)  )
> >>>>>
> >>>>> To ensure that at least *someone* has run the checks, the release
> >>>>> manager could include the output of the seven checks in an email to
> >>>>> the list. I think this level of checking is perfectly compatible with
> >>>>> the minimum Apache process, which is that the release manager signs
> >>>>> the artefacts and three PMC members vote +1
> >>>>> (http://www.apache.org/dev/release-publishing.html#voted).
> >>>>>
> >>>>> What do people think?
> >>>>>
> >>>>> Holly
> >>>> --
> >>>> Daniel Kulp
> >>>> dkulp@apache.org - http://dankulp.com/blog
> >>>> Talend Community Coder - http://coders.talend.com
> >>>
> >>>
> >>>
> >>> --
> >>> ------------------------
> >>> Guillaume Nodet
> >>> ------------------------
> >>> Blog: http://gnodet.blogspot.com/
> >>> ------------------------
> >>> FuseSource, Integration everywhere
> >>> http://fusesource.com
> >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > FuseSource, Integration everywhere
> > http://fusesource.com
>



-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

Re: [DISCUSSION] Modifications to Aries release process

[Holly Cummins <ho...@googlemail.com>]

Things are easy for the release manager, and harder for everyone else.
Since there's one release manager and lots of other people, it doesn't
seem like the right balance to me. I think it's worth a bit of extra
work to avoid breaking the build.

(I don't understand what you mean by 'at the end of the release
process, everything will be consistent in a snapshot version in
trunk.' At the end of a release process, we need to have most
dependencies in trunk being *released* versions, not snapshot
versions. I also don't think we'd ever have a release process where at
the end of the process we left things inconsistent in trunk, would
we?)

On Fri, Jul 6, 2012 at 3:51 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> Holy, there's *no* extra-step for the release manager, you don't have to
> change your settings.xml or whatever.  It's just less work.
> It will even be easier for users because at the end of the release process,
> everything will be consistent in a snapshot version in trunk.
>
> On Fri, Jul 6, 2012 at 4:47 PM, Holly Cummins <
> holly.k.cummins@googlemail.com> wrote:
>
>> Hi David,
>>
>> [snip]
>>
>> > I don't understand the problem.  I thought Guillaume was suggesting that
>> you put a lot of released artifacts, built by the rm (you) in the same
>> nexus staging repo.  Since you just built API-1.0.0 on your build machine,
>> it will be in your local maven repo, and you can continue to build all the
>> other stuff that needs it on your repo.  No one else can get the 1.0.0
>> artifacts from a remote maven  repo until you close the staging repo, but
>> they can also build the 1.0.0 artifacts themselves, just like you did (they
>> won't have to change the versions, since the relevant code will already be
>> in a svn tag from running the release plugin).
>> >
>> > Once you close the staging repo, people can add it to their local nexus
>>  or settings.xml and fetch the under-vote 1.0.0 artifacts without building
>> them themselves.
>> >
>> > What am I missing?
>>
>> Those extra steps, to either adjust settings.xml, or check out a tag
>> and build it, seem non-ideal to me. I'd argue a build should just
>> work, or that any extra steps (like adjusting settings.xml) should be
>> 'one-off', rather than constantly variable. It means when someone
>> wants to do a release, it creates a bit of inconvenience for everyone
>> else, which - imo - tends to drag us back to a 'release only when
>> absolutely necessary' model. After all, no one wants to be the person
>> who breaks the build, even if there are workarounds ...
>>
>> We'd also need to add pre-build steps to Jenkins to populate the
>> repositories on the build machines, again increasing the complexity
>> and fragility of the automated build.
>>
>> Cheers,
>> Holly
>> >
>> > thanks
>> > david jencks
>> >
>> >
>> >>
>> >> I think this is sensible to do occasionally, but it's error prone and
>> >> makes more work for the release manager. Obviously, the big advantage
>> >> of it is that the release gets voted through over a period of a few
>> >> days, rather than a month or two, for a big release. :)
>> >>
>> >> Holly
>> >>
>> >>
>> >>
>> >>> On Thu, Jun 28, 2012 at 6:45 PM, Holly Cummins
>> >>> <ho...@googlemail.com> wrote:
>> >>>> Hi Guillaume,
>> >>>>
>> >>>> Thanks for your comments. Here are some of my thoughts ...
>> >>>>
>> >>>> On Thu, Jun 28, 2012 at 3:19 PM, Guillaume Nodet <gn...@gmail.com>
>> wrote:
>> >>>>> I think one problem, considering the current votes, is that it's
>> >>>>> really difficult to test anything.   Releasing api bundles with no
>> >>>>> implementation to test is definitely not helping imo.
>> >>>>
>> >>>> I know what you mean about the testing, and I'm not totally sure what
>> >>>> the best answer is. I know what I'm releasing comes from trunk, and is
>> >>>> being tested by the Jenkins builds, so I'm pretty confident it works
>> >>>> in a real system. However being tested in more environments and by
>> >>>> more systems is obviously a Good Thing.  I think the best way to test
>> >>>> the API bundles is with the current -SNAPSHOT bundles of the
>> >>>> implementation, either in something like the blog sample or some other
>> >>>> working system. If we weren't moving from 0.x to 1.0 you could also
>> >>>> test micro releases alongside existing impl bundles to ensure
>> >>>> everything resolves and works as claimed.
>> >>>>
>> >>>>> Holly, just a question: is there a specific reason why are you doing
>> >>>>> the release in multiple votes ? It would be simpler to just release
>> >>>>> everything in one go and wait for a longer time because there are
>> more
>> >>>>> things to check, or at least, release the api + implementation so
>> that
>> >>>>> we can actually try something.  Just my 2 cents.
>> >>>>
>> >>>> I agree that this sort of 'extended incremental' release is a bit
>> >>>> awkward, and I was wondering when someone would ask what on earth I
>> >>>> was doing :). IMO it's the cleanest way to work with with
>> >>>> release-by-bundle (which I know you disagree with). If I release
>> >>>> everything in one go, there's a problem with the dependencies between
>> >>>> bundles. At the moment in trunk, almost every dependency is a SNAPSHOT
>> >>>> dependency. In the past we've updated all bundles to use non-SNAPSHOT
>> >>>> (but not yet released) versions in a branch, and I could even do
>> >>>> something similar without using a branch by briefly having the trunk
>> >>>> builds produce 1.0.0 artefacts. However, I think this creates a
>> >>>> greater burden for testers. If there are compilation-order
>> >>>> dependencies between parts of a release which don't share a top-level
>> >>>> pom, everyone verifying a script has to compile them in the right
>> >>>> order. I count 118 bundles to release, so that's a lot of bundles to
>> >>>> get in the right order, and I didn't think any PMC member would want
>> >>>> to try. :) I guess this could be automated with a verification script
>> >>>> which either hardcodes or calculates the dependency graph, but it
>> >>>> seemed to me like more work for everyone and more risk for the
>> >>>> release. My hope was that if verifying individual mini-releases was
>> >>>> easy enough, doing multiple ones wouldn't be a problem (and in fact
>> >>>> would nicely distribute any effort, making it easier to vote).
>> >>>>
>> >>>> I know at this stage some of you are thinking "and *this* is why
>> >>>> release by bundle is a bad idea!", and that's not really a debate I
>> >>>> want to re-open. Among other things, I think any re-engineering of our
>> >>>> poms at this stage will further delay the release.
>> >>>>
>> >>>> The good news is I believe this problem will almost entirely go away
>> >>>> for 1.0.x and 1.x releases, because the impl bundle will, in most
>> >>>> cases, depend on an *already* released version of its API bundle or
>> >>>> another Aries component. This means a bunch of related bundles could
>> >>>> be released at the same time, without compile issues, or a meaningful
>> >>>> release really could consist of just a single bundle. That's true
>> >>>> modularity and it should give both us and our users big benefits.
>> >>>>
>> >>>>
>> >>>>>
>> >>>>> On Mon, Jun 25, 2012 at 8:07 PM, Daniel Kulp <dk...@apache.org>
>> wrote:
>> >>>>>>
>> >>>>>> Honestly, with the change to using Nexus, the SHA1 and MD5 checks
>> are
>> >>>>>> completely pointless.   Nexus generates them itself based on what's
>> >>>>>> uploaded.  The "is it a valid signature" part of the GPG testing is
>> also
>> >>>>>> pointless as Nexus won't let you close the repo unless the
>> signatures are
>> >>>>>> valid.   The only check you really need to do is to make sure the
>> key that
>> >>>>>> was used is "trusted" by you.   (aka: was it really Holly who
>> deployed those
>> >>>>>> artifacts)    So the monontonous parts of checking that stuff is
>> really
>> >>>>>> irrelevant at this point.  (providing we trust that infra has Nexus
>> >>>>>> sufficiently locked down and secure)
>> >>>>>>
>> >>>>>>
>> >>>>>> I actually don't have a big issue with the difficulting in getting
>> votes.
>> >>>>>> I'm involved in another community that has a PMC that is easily 4
>> times the
>> >>>>>> size of this one, yet we still have difficulting getting votes
>> there.
>> >>>>>> While not ideal, life events can cause priority shifts and such so
>> people
>> >>>>>> may not be able to be as responsive.
>> >>>>>>
>> >>>>>> My bigger problem is that the entire per bundle release process and
>> symantic
>> >>>>>> versioning crap has put a HUGE burden on the release manager.
>> That makes
>> >>>>>> it much harder to get quality releases out and makes it less likely
>> that
>> >>>>>> anyone will step up to get "minor fixes" released.   The only
>> reason I
>> >>>>>> stepped up with the 0.3.1 bp stuff is that *MY*  customers are being
>> >>>>>> affected by it.   Like wise for the proxy stuff.   If *my*
>> customers were
>> >>>>>> not affected, I don't think I would have spent the time and effort.
>>    If
>> >>>>>> the process for getting fixes and releases out to users was smaller
>> and
>> >>>>>> easier, I have no problem doing them.   For CXF, we do full
>> releases on 3
>> >>>>>> branches every other month or so.   But that's because it's EASY to
>> do.
>> >>>>>>
>> >>>>>> If it was up to me, I'd toss out the entire versioning thing with
>> 1.0 and go
>> >>>>>> back to per module versioning thing.   So my fix to proxy would
>>  have
>> >>>>>> involved checking out all of "proxy", fixing it, and releasing all
>> of proxy
>> >>>>>> as a proxy "0.3.1", even the modules that haven't changed.   It's
>> just a
>> >>>>>> huge hassle to track down which bundles have changed, which haven't
>> which
>> >>>>>> version numbers need to be updated, etc....   If it's not quick and
>> easy to
>> >>>>>> do releases as a release manager, very few people are going to step
>> up to do
>> >>>>>> it.     It may not be 100% "proper OSGi", but IMO, getting fixes
>> and such to
>> >>>>>> the users is more important than that.    But that's my opinion.
>> >>>>>>
>> >>>>>>
>> >>>>>> Dan
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On Saturday, June 23, 2012 03:27:07 PM Holly Cummins wrote:
>> >>>>>>> Hi all,
>> >>>>>>>
>> >>>>>>> Now that Jeremy's taken the time to write up our release
>> verification
>> >>>>>>> process, I'd like to propose we change it. :) I think it's too
>> onerous
>> >>>>>>> on the pmc, which therefore also inhibits our ability to be
>> responsive
>> >>>>>>> to our users.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> ------------------------------- Why what we have isn't working for
>> the
>> >>>>>>> community -------------------------------
>> >>>>>>>
>> >>>>>>> I believe our users would like more frequent releases. We've had
>> >>>>>>> several keen requests and tweets and comments on the aries-user
>> >>>>>>> mailing list wishing we'd release more often. For example:
>> >>>>>>>
>> >>>>>>> * "Desperately waiting for an Aries release after loooong time.."
>> >>>>>>> * "The problem with Aries is they seem to be too busy coding to
>> >>>>>>> release anything."
>> >>>>>>> * "Compared to other projects (like Karaf and Camel) Aries releases
>> >>>>>>> tend to take quite some time."
>> >>>>>>> * "It's 2012 now and Aries 0.3 is almost a year old. Is there any
>> >>>>>>> chance of a new Aries JPA release any time soon? "
>> >>>>>>> * "Looks like Apache Aries has made no visible progress since Jan
>> >>>>>>> 2011, if the time stamps on the maven central artefacts are to be
>> >>>>>>> believed."
>> >>>>>>>
>> >>>>>>> ------------------------------- Why what we have isn't working for
>> us
>> >>>>>>> -------------------------------
>> >>>>>>>
>> >>>>>>> Both Dan and I are trying to do releases at the moment, and
>> struggling
>> >>>>>>> to get enough PMC votes. Dan's release is to back port a
>> show-stopper
>> >>>>>>> proxy fix, so a release there is particularly pressing - he's got a
>> >>>>>>> non-binding +infinity vote, but that's all. My test support release
>> >>>>>>> vote has been open for about 64 hours, and only got one vote so far
>> >>>>>>> (thanks David B!). Obviously testsupport is less exciting than
>> proxy,
>> >>>>>>> but that bundle does block more interesting releases.
>> >>>>>>>
>> >>>>>>> Why aren't people voting? My guess is that it's too much work to do
>> >>>>>>> the full set of verifications described at
>> >>>>>>> http://aries.apache.org/development/verifyingrelease.html. There
>> are
>> >>>>>>> seven steps, and while they don't actually take that long to
>> complete,
>> >>>>>>> it's enough of a burden that we tend to leave the voting to someone
>> >>>>>>> else unless we really care about a release. I'm as guilty of this
>> as
>> >>>>>>> anyone - I think a release is a good idea, but I'm spending enough
>> >>>>>>> time working on the 1.0.0 release that I don't want to take time
>> out
>> >>>>>>> to vote on another release. I suspect Dan might feel exactly the
>> same
>> >>>>>>> about my 1.0.0 bundles. :)
>> >>>>>>>
>> >>>>>>> With release-by-bundle, there's a lot of verifications. Excluding
>> the
>> >>>>>>> sandbox code, we have 123 bundles to release in 1.0.0. At three
>> votes
>> >>>>>>> per bundle, that means the PMC need to do 369 MD5 checks, 369 PGP
>> >>>>>>> checks, 369 RAT checks, and so on, just to get 1.0.0 out the door.
>> >>>>>>> This just doesn't seem like it scales. Batching the bundle releases
>> >>>>>>> together eases some of this burden, but not all.
>> >>>>>>>
>> >>>>>>> ------------------------------- What I propose
>> >>>>>>> -------------------------------
>> >>>>>>>
>> >>>>>>> I suggest we move to a more trust-based system, where PMC members
>> >>>>>>> carefully check releases if they want, but where in general they're
>> >>>>>>> voting on the principle of the release, rather than the mechanics
>> of
>> >>>>>>> the archives. In particular, they don't feel compelled to do checks
>> >>>>>>> before voting. If PMC members could say "Our users need this
>> function,
>> >>>>>>> so +1", or "I know Holly has done sensible things in the past, so
>> +1"
>> >>>>>>> or even "Do I want to check the SHAs on a test support bundle?
>> Really?
>> >>>>>>> +1" it would get our releases moving better, and also save work for
>> >>>>>>> all of us.
>> >>>>>>>
>> >>>>>>> (At the moment I think what's happening is people are thinking "Do
>> I
>> >>>>>>> want to check the SHAs on a test support bundle? Really?" and then
>> >>>>>>> skipping the +1 bit. :)  )
>> >>>>>>>
>> >>>>>>> To ensure that at least *someone* has run the checks, the release
>> >>>>>>> manager could include the output of the seven checks in an email to
>> >>>>>>> the list. I think this level of checking is perfectly compatible
>> with
>> >>>>>>> the minimum Apache process, which is that the release manager signs
>> >>>>>>> the artefacts and three PMC members vote +1
>> >>>>>>> (http://www.apache.org/dev/release-publishing.html#voted).
>> >>>>>>>
>> >>>>>>> What do people think?
>> >>>>>>>
>> >>>>>>> Holly
>> >>>>>> --
>> >>>>>> Daniel Kulp
>> >>>>>> dkulp@apache.org - http://dankulp.com/blog
>> >>>>>> Talend Community Coder - http://coders.talend.com
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> ------------------------
>> >>>>> Guillaume Nodet
>> >>>>> ------------------------
>> >>>>> Blog: http://gnodet.blogspot.com/
>> >>>>> ------------------------
>> >>>>> FuseSource, Integration everywhere
>> >>>>> http://fusesource.com
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> ------------------------
>> >>> Guillaume Nodet
>> >>> ------------------------
>> >>> Blog: http://gnodet.blogspot.com/
>> >>> ------------------------
>> >>> FuseSource, Integration everywhere
>> >>> http://fusesource.com
>> >
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> FuseSource, Integration everywhere
> http://fusesource.com

Re: [DISCUSSION] Modifications to Aries release process

[Holly Cummins <ho...@googlemail.com>]

Hi David,

Thanks David, profiles are a good idea. I'll add them to the list of
possible strategies on the releasing page. My concern with them in
general is that it's another thing to maintain, and therefore another
thing to potentially forget to maintain. In this case, however, the
profile would either be deleted once the release is promoted, or we'd
be re-using the dev profile, so in either case the maintenance is much
less of an issue.

Holly

On Fri, Jul 6, 2012 at 4:12 PM, David Jencks <da...@yahoo.com> wrote:
> OK, so the release manager doesn't have a problem, but if we update trunk to use the under-vote 1.0.0 versions anyone else is going to need to either build the under-vote artifacts or add the staging repo while the vote is going on.
>
> At one point we talked about having profiles, one for the earliest usable dependency versions and one for the latest snapshots.  I even tried it somewhere and it seemed to work.  Would that solve this problem?  Even if the default profile was for the earliest, under-vote, 1.0.0 artifacts it's not too hard to specify a profile to get the build to work while the vote is happening.
>
> thanks
> david jencks
>
>
> On Jul 6, 2012, at 10:51 AM, Guillaume Nodet wrote:
>
>> Holy, there's *no* extra-step for the release manager, you don't have to
>> change your settings.xml or whatever.  It's just less work.
>> It will even be easier for users because at the end of the release process,
>> everything will be consistent in a snapshot version in trunk.
>>
>> On Fri, Jul 6, 2012 at 4:47 PM, Holly Cummins <
>> holly.k.cummins@googlemail.com> wrote:
>>
>>> Hi David,
>>>
>>> [snip]
>>>
>>>> I don't understand the problem.  I thought Guillaume was suggesting that
>>> you put a lot of released artifacts, built by the rm (you) in the same
>>> nexus staging repo.  Since you just built API-1.0.0 on your build machine,
>>> it will be in your local maven repo, and you can continue to build all the
>>> other stuff that needs it on your repo.  No one else can get the 1.0.0
>>> artifacts from a remote maven  repo until you close the staging repo, but
>>> they can also build the 1.0.0 artifacts themselves, just like you did (they
>>> won't have to change the versions, since the relevant code will already be
>>> in a svn tag from running the release plugin).
>>>>
>>>> Once you close the staging repo, people can add it to their local nexus
>>> or settings.xml and fetch the under-vote 1.0.0 artifacts without building
>>> them themselves.
>>>>
>>>> What am I missing?
>>>
>>> Those extra steps, to either adjust settings.xml, or check out a tag
>>> and build it, seem non-ideal to me. I'd argue a build should just
>>> work, or that any extra steps (like adjusting settings.xml) should be
>>> 'one-off', rather than constantly variable. It means when someone
>>> wants to do a release, it creates a bit of inconvenience for everyone
>>> else, which - imo - tends to drag us back to a 'release only when
>>> absolutely necessary' model. After all, no one wants to be the person
>>> who breaks the build, even if there are workarounds ...
>>>
>>> We'd also need to add pre-build steps to Jenkins to populate the
>>> repositories on the build machines, again increasing the complexity
>>> and fragility of the automated build.
>>>
>>> Cheers,
>>> Holly
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>>
>>>>>
>>>>> I think this is sensible to do occasionally, but it's error prone and
>>>>> makes more work for the release manager. Obviously, the big advantage
>>>>> of it is that the release gets voted through over a period of a few
>>>>> days, rather than a month or two, for a big release. :)
>>>>>
>>>>> Holly
>>>>>
>>>>>
>>>>>
>>>>>> On Thu, Jun 28, 2012 at 6:45 PM, Holly Cummins
>>>>>> <ho...@googlemail.com> wrote:
>>>>>>> Hi Guillaume,
>>>>>>>
>>>>>>> Thanks for your comments. Here are some of my thoughts ...
>>>>>>>
>>>>>>> On Thu, Jun 28, 2012 at 3:19 PM, Guillaume Nodet <gn...@gmail.com>
>>> wrote:
>>>>>>>> I think one problem, considering the current votes, is that it's
>>>>>>>> really difficult to test anything.   Releasing api bundles with no
>>>>>>>> implementation to test is definitely not helping imo.
>>>>>>>
>>>>>>> I know what you mean about the testing, and I'm not totally sure what
>>>>>>> the best answer is. I know what I'm releasing comes from trunk, and is
>>>>>>> being tested by the Jenkins builds, so I'm pretty confident it works
>>>>>>> in a real system. However being tested in more environments and by
>>>>>>> more systems is obviously a Good Thing.  I think the best way to test
>>>>>>> the API bundles is with the current -SNAPSHOT bundles of the
>>>>>>> implementation, either in something like the blog sample or some other
>>>>>>> working system. If we weren't moving from 0.x to 1.0 you could also
>>>>>>> test micro releases alongside existing impl bundles to ensure
>>>>>>> everything resolves and works as claimed.
>>>>>>>
>>>>>>>> Holly, just a question: is there a specific reason why are you doing
>>>>>>>> the release in multiple votes ? It would be simpler to just release
>>>>>>>> everything in one go and wait for a longer time because there are
>>> more
>>>>>>>> things to check, or at least, release the api + implementation so
>>> that
>>>>>>>> we can actually try something.  Just my 2 cents.
>>>>>>>
>>>>>>> I agree that this sort of 'extended incremental' release is a bit
>>>>>>> awkward, and I was wondering when someone would ask what on earth I
>>>>>>> was doing :). IMO it's the cleanest way to work with with
>>>>>>> release-by-bundle (which I know you disagree with). If I release
>>>>>>> everything in one go, there's a problem with the dependencies between
>>>>>>> bundles. At the moment in trunk, almost every dependency is a SNAPSHOT
>>>>>>> dependency. In the past we've updated all bundles to use non-SNAPSHOT
>>>>>>> (but not yet released) versions in a branch, and I could even do
>>>>>>> something similar without using a branch by briefly having the trunk
>>>>>>> builds produce 1.0.0 artefacts. However, I think this creates a
>>>>>>> greater burden for testers. If there are compilation-order
>>>>>>> dependencies between parts of a release which don't share a top-level
>>>>>>> pom, everyone verifying a script has to compile them in the right
>>>>>>> order. I count 118 bundles to release, so that's a lot of bundles to
>>>>>>> get in the right order, and I didn't think any PMC member would want
>>>>>>> to try. :) I guess this could be automated with a verification script
>>>>>>> which either hardcodes or calculates the dependency graph, but it
>>>>>>> seemed to me like more work for everyone and more risk for the
>>>>>>> release. My hope was that if verifying individual mini-releases was
>>>>>>> easy enough, doing multiple ones wouldn't be a problem (and in fact
>>>>>>> would nicely distribute any effort, making it easier to vote).
>>>>>>>
>>>>>>> I know at this stage some of you are thinking "and *this* is why
>>>>>>> release by bundle is a bad idea!", and that's not really a debate I
>>>>>>> want to re-open. Among other things, I think any re-engineering of our
>>>>>>> poms at this stage will further delay the release.
>>>>>>>
>>>>>>> The good news is I believe this problem will almost entirely go away
>>>>>>> for 1.0.x and 1.x releases, because the impl bundle will, in most
>>>>>>> cases, depend on an *already* released version of its API bundle or
>>>>>>> another Aries component. This means a bunch of related bundles could
>>>>>>> be released at the same time, without compile issues, or a meaningful
>>>>>>> release really could consist of just a single bundle. That's true
>>>>>>> modularity and it should give both us and our users big benefits.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Jun 25, 2012 at 8:07 PM, Daniel Kulp <dk...@apache.org>
>>> wrote:
>>>>>>>>>
>>>>>>>>> Honestly, with the change to using Nexus, the SHA1 and MD5 checks
>>> are
>>>>>>>>> completely pointless.   Nexus generates them itself based on what's
>>>>>>>>> uploaded.  The "is it a valid signature" part of the GPG testing is
>>> also
>>>>>>>>> pointless as Nexus won't let you close the repo unless the
>>> signatures are
>>>>>>>>> valid.   The only check you really need to do is to make sure the
>>> key that
>>>>>>>>> was used is "trusted" by you.   (aka: was it really Holly who
>>> deployed those
>>>>>>>>> artifacts)    So the monontonous parts of checking that stuff is
>>> really
>>>>>>>>> irrelevant at this point.  (providing we trust that infra has Nexus
>>>>>>>>> sufficiently locked down and secure)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I actually don't have a big issue with the difficulting in getting
>>> votes.
>>>>>>>>> I'm involved in another community that has a PMC that is easily 4
>>> times the
>>>>>>>>> size of this one, yet we still have difficulting getting votes
>>> there.
>>>>>>>>> While not ideal, life events can cause priority shifts and such so
>>> people
>>>>>>>>> may not be able to be as responsive.
>>>>>>>>>
>>>>>>>>> My bigger problem is that the entire per bundle release process and
>>> symantic
>>>>>>>>> versioning crap has put a HUGE burden on the release manager.
>>> That makes
>>>>>>>>> it much harder to get quality releases out and makes it less likely
>>> that
>>>>>>>>> anyone will step up to get "minor fixes" released.   The only
>>> reason I
>>>>>>>>> stepped up with the 0.3.1 bp stuff is that *MY*  customers are being
>>>>>>>>> affected by it.   Like wise for the proxy stuff.   If *my*
>>> customers were
>>>>>>>>> not affected, I don't think I would have spent the time and effort.
>>>   If
>>>>>>>>> the process for getting fixes and releases out to users was smaller
>>> and
>>>>>>>>> easier, I have no problem doing them.   For CXF, we do full
>>> releases on 3
>>>>>>>>> branches every other month or so.   But that's because it's EASY to
>>> do.
>>>>>>>>>
>>>>>>>>> If it was up to me, I'd toss out the entire versioning thing with
>>> 1.0 and go
>>>>>>>>> back to per module versioning thing.   So my fix to proxy would
>>> have
>>>>>>>>> involved checking out all of "proxy", fixing it, and releasing all
>>> of proxy
>>>>>>>>> as a proxy "0.3.1", even the modules that haven't changed.   It's
>>> just a
>>>>>>>>> huge hassle to track down which bundles have changed, which haven't
>>> which
>>>>>>>>> version numbers need to be updated, etc....   If it's not quick and
>>> easy to
>>>>>>>>> do releases as a release manager, very few people are going to step
>>> up to do
>>>>>>>>> it.     It may not be 100% "proper OSGi", but IMO, getting fixes
>>> and such to
>>>>>>>>> the users is more important than that.    But that's my opinion.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Dan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Saturday, June 23, 2012 03:27:07 PM Holly Cummins wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> Now that Jeremy's taken the time to write up our release
>>> verification
>>>>>>>>>> process, I'd like to propose we change it. :) I think it's too
>>> onerous
>>>>>>>>>> on the pmc, which therefore also inhibits our ability to be
>>> responsive
>>>>>>>>>> to our users.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ------------------------------- Why what we have isn't working for
>>> the
>>>>>>>>>> community -------------------------------
>>>>>>>>>>
>>>>>>>>>> I believe our users would like more frequent releases. We've had
>>>>>>>>>> several keen requests and tweets and comments on the aries-user
>>>>>>>>>> mailing list wishing we'd release more often. For example:
>>>>>>>>>>
>>>>>>>>>> * "Desperately waiting for an Aries release after loooong time.."
>>>>>>>>>> * "The problem with Aries is they seem to be too busy coding to
>>>>>>>>>> release anything."
>>>>>>>>>> * "Compared to other projects (like Karaf and Camel) Aries releases
>>>>>>>>>> tend to take quite some time."
>>>>>>>>>> * "It's 2012 now and Aries 0.3 is almost a year old. Is there any
>>>>>>>>>> chance of a new Aries JPA release any time soon? "
>>>>>>>>>> * "Looks like Apache Aries has made no visible progress since Jan
>>>>>>>>>> 2011, if the time stamps on the maven central artefacts are to be
>>>>>>>>>> believed."
>>>>>>>>>>
>>>>>>>>>> ------------------------------- Why what we have isn't working for
>>> us
>>>>>>>>>> -------------------------------
>>>>>>>>>>
>>>>>>>>>> Both Dan and I are trying to do releases at the moment, and
>>> struggling
>>>>>>>>>> to get enough PMC votes. Dan's release is to back port a
>>> show-stopper
>>>>>>>>>> proxy fix, so a release there is particularly pressing - he's got a
>>>>>>>>>> non-binding +infinity vote, but that's all. My test support release
>>>>>>>>>> vote has been open for about 64 hours, and only got one vote so far
>>>>>>>>>> (thanks David B!). Obviously testsupport is less exciting than
>>> proxy,
>>>>>>>>>> but that bundle does block more interesting releases.
>>>>>>>>>>
>>>>>>>>>> Why aren't people voting? My guess is that it's too much work to do
>>>>>>>>>> the full set of verifications described at
>>>>>>>>>> http://aries.apache.org/development/verifyingrelease.html. There
>>> are
>>>>>>>>>> seven steps, and while they don't actually take that long to
>>> complete,
>>>>>>>>>> it's enough of a burden that we tend to leave the voting to someone
>>>>>>>>>> else unless we really care about a release. I'm as guilty of this
>>> as
>>>>>>>>>> anyone - I think a release is a good idea, but I'm spending enough
>>>>>>>>>> time working on the 1.0.0 release that I don't want to take time
>>> out
>>>>>>>>>> to vote on another release. I suspect Dan might feel exactly the
>>> same
>>>>>>>>>> about my 1.0.0 bundles. :)
>>>>>>>>>>
>>>>>>>>>> With release-by-bundle, there's a lot of verifications. Excluding
>>> the
>>>>>>>>>> sandbox code, we have 123 bundles to release in 1.0.0. At three
>>> votes
>>>>>>>>>> per bundle, that means the PMC need to do 369 MD5 checks, 369 PGP
>>>>>>>>>> checks, 369 RAT checks, and so on, just to get 1.0.0 out the door.
>>>>>>>>>> This just doesn't seem like it scales. Batching the bundle releases
>>>>>>>>>> together eases some of this burden, but not all.
>>>>>>>>>>
>>>>>>>>>> ------------------------------- What I propose
>>>>>>>>>> -------------------------------
>>>>>>>>>>
>>>>>>>>>> I suggest we move to a more trust-based system, where PMC members
>>>>>>>>>> carefully check releases if they want, but where in general they're
>>>>>>>>>> voting on the principle of the release, rather than the mechanics
>>> of
>>>>>>>>>> the archives. In particular, they don't feel compelled to do checks
>>>>>>>>>> before voting. If PMC members could say "Our users need this
>>> function,
>>>>>>>>>> so +1", or "I know Holly has done sensible things in the past, so
>>> +1"
>>>>>>>>>> or even "Do I want to check the SHAs on a test support bundle?
>>> Really?
>>>>>>>>>> +1" it would get our releases moving better, and also save work for
>>>>>>>>>> all of us.
>>>>>>>>>>
>>>>>>>>>> (At the moment I think what's happening is people are thinking "Do
>>> I
>>>>>>>>>> want to check the SHAs on a test support bundle? Really?" and then
>>>>>>>>>> skipping the +1 bit. :)  )
>>>>>>>>>>
>>>>>>>>>> To ensure that at least *someone* has run the checks, the release
>>>>>>>>>> manager could include the output of the seven checks in an email to
>>>>>>>>>> the list. I think this level of checking is perfectly compatible
>>> with
>>>>>>>>>> the minimum Apache process, which is that the release manager signs
>>>>>>>>>> the artefacts and three PMC members vote +1
>>>>>>>>>> (http://www.apache.org/dev/release-publishing.html#voted).
>>>>>>>>>>
>>>>>>>>>> What do people think?
>>>>>>>>>>
>>>>>>>>>> Holly
>>>>>>>>> --
>>>>>>>>> Daniel Kulp
>>>>>>>>> dkulp@apache.org - http://dankulp.com/blog
>>>>>>>>> Talend Community Coder - http://coders.talend.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> ------------------------
>>>>>>>> Guillaume Nodet
>>>>>>>> ------------------------
>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>> ------------------------
>>>>>>>> FuseSource, Integration everywhere
>>>>>>>> http://fusesource.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> ------------------------
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> FuseSource, Integration everywhere
>>>>>> http://fusesource.com
>>>>
>>>
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> FuseSource, Integration everywhere
>> http://fusesource.com
>

Re: [DISCUSSION] Modifications to Aries release process

[David Jencks <da...@yahoo.com>]

OK, so the release manager doesn't have a problem, but if we update trunk to use the under-vote 1.0.0 versions anyone else is going to need to either build the under-vote artifacts or add the staging repo while the vote is going on.

At one point we talked about having profiles, one for the earliest usable dependency versions and one for the latest snapshots.  I even tried it somewhere and it seemed to work.  Would that solve this problem?  Even if the default profile was for the earliest, under-vote, 1.0.0 artifacts it's not too hard to specify a profile to get the build to work while the vote is happening.

thanks
david jencks


On Jul 6, 2012, at 10:51 AM, Guillaume Nodet wrote:

> Holy, there's *no* extra-step for the release manager, you don't have to
> change your settings.xml or whatever.  It's just less work.
> It will even be easier for users because at the end of the release process,
> everything will be consistent in a snapshot version in trunk.
> 
> On Fri, Jul 6, 2012 at 4:47 PM, Holly Cummins <
> holly.k.cummins@googlemail.com> wrote:
> 
>> Hi David,
>> 
>> [snip]
>> 
>>> I don't understand the problem.  I thought Guillaume was suggesting that
>> you put a lot of released artifacts, built by the rm (you) in the same
>> nexus staging repo.  Since you just built API-1.0.0 on your build machine,
>> it will be in your local maven repo, and you can continue to build all the
>> other stuff that needs it on your repo.  No one else can get the 1.0.0
>> artifacts from a remote maven  repo until you close the staging repo, but
>> they can also build the 1.0.0 artifacts themselves, just like you did (they
>> won't have to change the versions, since the relevant code will already be
>> in a svn tag from running the release plugin).
>>> 
>>> Once you close the staging repo, people can add it to their local nexus
>> or settings.xml and fetch the under-vote 1.0.0 artifacts without building
>> them themselves.
>>> 
>>> What am I missing?
>> 
>> Those extra steps, to either adjust settings.xml, or check out a tag
>> and build it, seem non-ideal to me. I'd argue a build should just
>> work, or that any extra steps (like adjusting settings.xml) should be
>> 'one-off', rather than constantly variable. It means when someone
>> wants to do a release, it creates a bit of inconvenience for everyone
>> else, which - imo - tends to drag us back to a 'release only when
>> absolutely necessary' model. After all, no one wants to be the person
>> who breaks the build, even if there are workarounds ...
>> 
>> We'd also need to add pre-build steps to Jenkins to populate the
>> repositories on the build machines, again increasing the complexity
>> and fragility of the automated build.
>> 
>> Cheers,
>> Holly
>>> 
>>> thanks
>>> david jencks
>>> 
>>> 
>>>> 
>>>> I think this is sensible to do occasionally, but it's error prone and
>>>> makes more work for the release manager. Obviously, the big advantage
>>>> of it is that the release gets voted through over a period of a few
>>>> days, rather than a month or two, for a big release. :)
>>>> 
>>>> Holly
>>>> 
>>>> 
>>>> 
>>>>> On Thu, Jun 28, 2012 at 6:45 PM, Holly Cummins
>>>>> <ho...@googlemail.com> wrote:
>>>>>> Hi Guillaume,
>>>>>> 
>>>>>> Thanks for your comments. Here are some of my thoughts ...
>>>>>> 
>>>>>> On Thu, Jun 28, 2012 at 3:19 PM, Guillaume Nodet <gn...@gmail.com>
>> wrote:
>>>>>>> I think one problem, considering the current votes, is that it's
>>>>>>> really difficult to test anything.   Releasing api bundles with no
>>>>>>> implementation to test is definitely not helping imo.
>>>>>> 
>>>>>> I know what you mean about the testing, and I'm not totally sure what
>>>>>> the best answer is. I know what I'm releasing comes from trunk, and is
>>>>>> being tested by the Jenkins builds, so I'm pretty confident it works
>>>>>> in a real system. However being tested in more environments and by
>>>>>> more systems is obviously a Good Thing.  I think the best way to test
>>>>>> the API bundles is with the current -SNAPSHOT bundles of the
>>>>>> implementation, either in something like the blog sample or some other
>>>>>> working system. If we weren't moving from 0.x to 1.0 you could also
>>>>>> test micro releases alongside existing impl bundles to ensure
>>>>>> everything resolves and works as claimed.
>>>>>> 
>>>>>>> Holly, just a question: is there a specific reason why are you doing
>>>>>>> the release in multiple votes ? It would be simpler to just release
>>>>>>> everything in one go and wait for a longer time because there are
>> more
>>>>>>> things to check, or at least, release the api + implementation so
>> that
>>>>>>> we can actually try something.  Just my 2 cents.
>>>>>> 
>>>>>> I agree that this sort of 'extended incremental' release is a bit
>>>>>> awkward, and I was wondering when someone would ask what on earth I
>>>>>> was doing :). IMO it's the cleanest way to work with with
>>>>>> release-by-bundle (which I know you disagree with). If I release
>>>>>> everything in one go, there's a problem with the dependencies between
>>>>>> bundles. At the moment in trunk, almost every dependency is a SNAPSHOT
>>>>>> dependency. In the past we've updated all bundles to use non-SNAPSHOT
>>>>>> (but not yet released) versions in a branch, and I could even do
>>>>>> something similar without using a branch by briefly having the trunk
>>>>>> builds produce 1.0.0 artefacts. However, I think this creates a
>>>>>> greater burden for testers. If there are compilation-order
>>>>>> dependencies between parts of a release which don't share a top-level
>>>>>> pom, everyone verifying a script has to compile them in the right
>>>>>> order. I count 118 bundles to release, so that's a lot of bundles to
>>>>>> get in the right order, and I didn't think any PMC member would want
>>>>>> to try. :) I guess this could be automated with a verification script
>>>>>> which either hardcodes or calculates the dependency graph, but it
>>>>>> seemed to me like more work for everyone and more risk for the
>>>>>> release. My hope was that if verifying individual mini-releases was
>>>>>> easy enough, doing multiple ones wouldn't be a problem (and in fact
>>>>>> would nicely distribute any effort, making it easier to vote).
>>>>>> 
>>>>>> I know at this stage some of you are thinking "and *this* is why
>>>>>> release by bundle is a bad idea!", and that's not really a debate I
>>>>>> want to re-open. Among other things, I think any re-engineering of our
>>>>>> poms at this stage will further delay the release.
>>>>>> 
>>>>>> The good news is I believe this problem will almost entirely go away
>>>>>> for 1.0.x and 1.x releases, because the impl bundle will, in most
>>>>>> cases, depend on an *already* released version of its API bundle or
>>>>>> another Aries component. This means a bunch of related bundles could
>>>>>> be released at the same time, without compile issues, or a meaningful
>>>>>> release really could consist of just a single bundle. That's true
>>>>>> modularity and it should give both us and our users big benefits.
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> On Mon, Jun 25, 2012 at 8:07 PM, Daniel Kulp <dk...@apache.org>
>> wrote:
>>>>>>>> 
>>>>>>>> Honestly, with the change to using Nexus, the SHA1 and MD5 checks
>> are
>>>>>>>> completely pointless.   Nexus generates them itself based on what's
>>>>>>>> uploaded.  The "is it a valid signature" part of the GPG testing is
>> also
>>>>>>>> pointless as Nexus won't let you close the repo unless the
>> signatures are
>>>>>>>> valid.   The only check you really need to do is to make sure the
>> key that
>>>>>>>> was used is "trusted" by you.   (aka: was it really Holly who
>> deployed those
>>>>>>>> artifacts)    So the monontonous parts of checking that stuff is
>> really
>>>>>>>> irrelevant at this point.  (providing we trust that infra has Nexus
>>>>>>>> sufficiently locked down and secure)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I actually don't have a big issue with the difficulting in getting
>> votes.
>>>>>>>> I'm involved in another community that has a PMC that is easily 4
>> times the
>>>>>>>> size of this one, yet we still have difficulting getting votes
>> there.
>>>>>>>> While not ideal, life events can cause priority shifts and such so
>> people
>>>>>>>> may not be able to be as responsive.
>>>>>>>> 
>>>>>>>> My bigger problem is that the entire per bundle release process and
>> symantic
>>>>>>>> versioning crap has put a HUGE burden on the release manager.
>> That makes
>>>>>>>> it much harder to get quality releases out and makes it less likely
>> that
>>>>>>>> anyone will step up to get "minor fixes" released.   The only
>> reason I
>>>>>>>> stepped up with the 0.3.1 bp stuff is that *MY*  customers are being
>>>>>>>> affected by it.   Like wise for the proxy stuff.   If *my*
>> customers were
>>>>>>>> not affected, I don't think I would have spent the time and effort.
>>   If
>>>>>>>> the process for getting fixes and releases out to users was smaller
>> and
>>>>>>>> easier, I have no problem doing them.   For CXF, we do full
>> releases on 3
>>>>>>>> branches every other month or so.   But that's because it's EASY to
>> do.
>>>>>>>> 
>>>>>>>> If it was up to me, I'd toss out the entire versioning thing with
>> 1.0 and go
>>>>>>>> back to per module versioning thing.   So my fix to proxy would
>> have
>>>>>>>> involved checking out all of "proxy", fixing it, and releasing all
>> of proxy
>>>>>>>> as a proxy "0.3.1", even the modules that haven't changed.   It's
>> just a
>>>>>>>> huge hassle to track down which bundles have changed, which haven't
>> which
>>>>>>>> version numbers need to be updated, etc....   If it's not quick and
>> easy to
>>>>>>>> do releases as a release manager, very few people are going to step
>> up to do
>>>>>>>> it.     It may not be 100% "proper OSGi", but IMO, getting fixes
>> and such to
>>>>>>>> the users is more important than that.    But that's my opinion.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Dan
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Saturday, June 23, 2012 03:27:07 PM Holly Cummins wrote:
>>>>>>>>> Hi all,
>>>>>>>>> 
>>>>>>>>> Now that Jeremy's taken the time to write up our release
>> verification
>>>>>>>>> process, I'd like to propose we change it. :) I think it's too
>> onerous
>>>>>>>>> on the pmc, which therefore also inhibits our ability to be
>> responsive
>>>>>>>>> to our users.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> ------------------------------- Why what we have isn't working for
>> the
>>>>>>>>> community -------------------------------
>>>>>>>>> 
>>>>>>>>> I believe our users would like more frequent releases. We've had
>>>>>>>>> several keen requests and tweets and comments on the aries-user
>>>>>>>>> mailing list wishing we'd release more often. For example:
>>>>>>>>> 
>>>>>>>>> * "Desperately waiting for an Aries release after loooong time.."
>>>>>>>>> * "The problem with Aries is they seem to be too busy coding to
>>>>>>>>> release anything."
>>>>>>>>> * "Compared to other projects (like Karaf and Camel) Aries releases
>>>>>>>>> tend to take quite some time."
>>>>>>>>> * "It's 2012 now and Aries 0.3 is almost a year old. Is there any
>>>>>>>>> chance of a new Aries JPA release any time soon? "
>>>>>>>>> * "Looks like Apache Aries has made no visible progress since Jan
>>>>>>>>> 2011, if the time stamps on the maven central artefacts are to be
>>>>>>>>> believed."
>>>>>>>>> 
>>>>>>>>> ------------------------------- Why what we have isn't working for
>> us
>>>>>>>>> -------------------------------
>>>>>>>>> 
>>>>>>>>> Both Dan and I are trying to do releases at the moment, and
>> struggling
>>>>>>>>> to get enough PMC votes. Dan's release is to back port a
>> show-stopper
>>>>>>>>> proxy fix, so a release there is particularly pressing - he's got a
>>>>>>>>> non-binding +infinity vote, but that's all. My test support release
>>>>>>>>> vote has been open for about 64 hours, and only got one vote so far
>>>>>>>>> (thanks David B!). Obviously testsupport is less exciting than
>> proxy,
>>>>>>>>> but that bundle does block more interesting releases.
>>>>>>>>> 
>>>>>>>>> Why aren't people voting? My guess is that it's too much work to do
>>>>>>>>> the full set of verifications described at
>>>>>>>>> http://aries.apache.org/development/verifyingrelease.html. There
>> are
>>>>>>>>> seven steps, and while they don't actually take that long to
>> complete,
>>>>>>>>> it's enough of a burden that we tend to leave the voting to someone
>>>>>>>>> else unless we really care about a release. I'm as guilty of this
>> as
>>>>>>>>> anyone - I think a release is a good idea, but I'm spending enough
>>>>>>>>> time working on the 1.0.0 release that I don't want to take time
>> out
>>>>>>>>> to vote on another release. I suspect Dan might feel exactly the
>> same
>>>>>>>>> about my 1.0.0 bundles. :)
>>>>>>>>> 
>>>>>>>>> With release-by-bundle, there's a lot of verifications. Excluding
>> the
>>>>>>>>> sandbox code, we have 123 bundles to release in 1.0.0. At three
>> votes
>>>>>>>>> per bundle, that means the PMC need to do 369 MD5 checks, 369 PGP
>>>>>>>>> checks, 369 RAT checks, and so on, just to get 1.0.0 out the door.
>>>>>>>>> This just doesn't seem like it scales. Batching the bundle releases
>>>>>>>>> together eases some of this burden, but not all.
>>>>>>>>> 
>>>>>>>>> ------------------------------- What I propose
>>>>>>>>> -------------------------------
>>>>>>>>> 
>>>>>>>>> I suggest we move to a more trust-based system, where PMC members
>>>>>>>>> carefully check releases if they want, but where in general they're
>>>>>>>>> voting on the principle of the release, rather than the mechanics
>> of
>>>>>>>>> the archives. In particular, they don't feel compelled to do checks
>>>>>>>>> before voting. If PMC members could say "Our users need this
>> function,
>>>>>>>>> so +1", or "I know Holly has done sensible things in the past, so
>> +1"
>>>>>>>>> or even "Do I want to check the SHAs on a test support bundle?
>> Really?
>>>>>>>>> +1" it would get our releases moving better, and also save work for
>>>>>>>>> all of us.
>>>>>>>>> 
>>>>>>>>> (At the moment I think what's happening is people are thinking "Do
>> I
>>>>>>>>> want to check the SHAs on a test support bundle? Really?" and then
>>>>>>>>> skipping the +1 bit. :)  )
>>>>>>>>> 
>>>>>>>>> To ensure that at least *someone* has run the checks, the release
>>>>>>>>> manager could include the output of the seven checks in an email to
>>>>>>>>> the list. I think this level of checking is perfectly compatible
>> with
>>>>>>>>> the minimum Apache process, which is that the release manager signs
>>>>>>>>> the artefacts and three PMC members vote +1
>>>>>>>>> (http://www.apache.org/dev/release-publishing.html#voted).
>>>>>>>>> 
>>>>>>>>> What do people think?
>>>>>>>>> 
>>>>>>>>> Holly
>>>>>>>> --
>>>>>>>> Daniel Kulp
>>>>>>>> dkulp@apache.org - http://dankulp.com/blog
>>>>>>>> Talend Community Coder - http://coders.talend.com
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> ------------------------
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> FuseSource, Integration everywhere
>>>>>>> http://fusesource.com
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> ------------------------
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> FuseSource, Integration everywhere
>>>>> http://fusesource.com
>>> 
>> 
> 
> 
> 
> -- 
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> FuseSource, Integration everywhere
> http://fusesource.com

Re: [DISCUSSION] Modifications to Aries release process

[Guillaume Nodet <gn...@gmail.com>]

Holy, there's *no* extra-step for the release manager, you don't have to
change your settings.xml or whatever.  It's just less work.
It will even be easier for users because at the end of the release process,
everything will be consistent in a snapshot version in trunk.

On Fri, Jul 6, 2012 at 4:47 PM, Holly Cummins <
holly.k.cummins@googlemail.com> wrote:

> Hi David,
>
> [snip]
>
> > I don't understand the problem.  I thought Guillaume was suggesting that
> you put a lot of released artifacts, built by the rm (you) in the same
> nexus staging repo.  Since you just built API-1.0.0 on your build machine,
> it will be in your local maven repo, and you can continue to build all the
> other stuff that needs it on your repo.  No one else can get the 1.0.0
> artifacts from a remote maven  repo until you close the staging repo, but
> they can also build the 1.0.0 artifacts themselves, just like you did (they
> won't have to change the versions, since the relevant code will already be
> in a svn tag from running the release plugin).
> >
> > Once you close the staging repo, people can add it to their local nexus
>  or settings.xml and fetch the under-vote 1.0.0 artifacts without building
> them themselves.
> >
> > What am I missing?
>
> Those extra steps, to either adjust settings.xml, or check out a tag
> and build it, seem non-ideal to me. I'd argue a build should just
> work, or that any extra steps (like adjusting settings.xml) should be
> 'one-off', rather than constantly variable. It means when someone
> wants to do a release, it creates a bit of inconvenience for everyone
> else, which - imo - tends to drag us back to a 'release only when
> absolutely necessary' model. After all, no one wants to be the person
> who breaks the build, even if there are workarounds ...
>
> We'd also need to add pre-build steps to Jenkins to populate the
> repositories on the build machines, again increasing the complexity
> and fragility of the automated build.
>
> Cheers,
> Holly
> >
> > thanks
> > david jencks
> >
> >
> >>
> >> I think this is sensible to do occasionally, but it's error prone and
> >> makes more work for the release manager. Obviously, the big advantage
> >> of it is that the release gets voted through over a period of a few
> >> days, rather than a month or two, for a big release. :)
> >>
> >> Holly
> >>
> >>
> >>
> >>> On Thu, Jun 28, 2012 at 6:45 PM, Holly Cummins
> >>> <ho...@googlemail.com> wrote:
> >>>> Hi Guillaume,
> >>>>
> >>>> Thanks for your comments. Here are some of my thoughts ...
> >>>>
> >>>> On Thu, Jun 28, 2012 at 3:19 PM, Guillaume Nodet <gn...@gmail.com>
> wrote:
> >>>>> I think one problem, considering the current votes, is that it's
> >>>>> really difficult to test anything.   Releasing api bundles with no
> >>>>> implementation to test is definitely not helping imo.
> >>>>
> >>>> I know what you mean about the testing, and I'm not totally sure what
> >>>> the best answer is. I know what I'm releasing comes from trunk, and is
> >>>> being tested by the Jenkins builds, so I'm pretty confident it works
> >>>> in a real system. However being tested in more environments and by
> >>>> more systems is obviously a Good Thing.  I think the best way to test
> >>>> the API bundles is with the current -SNAPSHOT bundles of the
> >>>> implementation, either in something like the blog sample or some other
> >>>> working system. If we weren't moving from 0.x to 1.0 you could also
> >>>> test micro releases alongside existing impl bundles to ensure
> >>>> everything resolves and works as claimed.
> >>>>
> >>>>> Holly, just a question: is there a specific reason why are you doing
> >>>>> the release in multiple votes ? It would be simpler to just release
> >>>>> everything in one go and wait for a longer time because there are
> more
> >>>>> things to check, or at least, release the api + implementation so
> that
> >>>>> we can actually try something.  Just my 2 cents.
> >>>>
> >>>> I agree that this sort of 'extended incremental' release is a bit
> >>>> awkward, and I was wondering when someone would ask what on earth I
> >>>> was doing :). IMO it's the cleanest way to work with with
> >>>> release-by-bundle (which I know you disagree with). If I release
> >>>> everything in one go, there's a problem with the dependencies between
> >>>> bundles. At the moment in trunk, almost every dependency is a SNAPSHOT
> >>>> dependency. In the past we've updated all bundles to use non-SNAPSHOT
> >>>> (but not yet released) versions in a branch, and I could even do
> >>>> something similar without using a branch by briefly having the trunk
> >>>> builds produce 1.0.0 artefacts. However, I think this creates a
> >>>> greater burden for testers. If there are compilation-order
> >>>> dependencies between parts of a release which don't share a top-level
> >>>> pom, everyone verifying a script has to compile them in the right
> >>>> order. I count 118 bundles to release, so that's a lot of bundles to
> >>>> get in the right order, and I didn't think any PMC member would want
> >>>> to try. :) I guess this could be automated with a verification script
> >>>> which either hardcodes or calculates the dependency graph, but it
> >>>> seemed to me like more work for everyone and more risk for the
> >>>> release. My hope was that if verifying individual mini-releases was
> >>>> easy enough, doing multiple ones wouldn't be a problem (and in fact
> >>>> would nicely distribute any effort, making it easier to vote).
> >>>>
> >>>> I know at this stage some of you are thinking "and *this* is why
> >>>> release by bundle is a bad idea!", and that's not really a debate I
> >>>> want to re-open. Among other things, I think any re-engineering of our
> >>>> poms at this stage will further delay the release.
> >>>>
> >>>> The good news is I believe this problem will almost entirely go away
> >>>> for 1.0.x and 1.x releases, because the impl bundle will, in most
> >>>> cases, depend on an *already* released version of its API bundle or
> >>>> another Aries component. This means a bunch of related bundles could
> >>>> be released at the same time, without compile issues, or a meaningful
> >>>> release really could consist of just a single bundle. That's true
> >>>> modularity and it should give both us and our users big benefits.
> >>>>
> >>>>
> >>>>>
> >>>>> On Mon, Jun 25, 2012 at 8:07 PM, Daniel Kulp <dk...@apache.org>
> wrote:
> >>>>>>
> >>>>>> Honestly, with the change to using Nexus, the SHA1 and MD5 checks
> are
> >>>>>> completely pointless.   Nexus generates them itself based on what's
> >>>>>> uploaded.  The "is it a valid signature" part of the GPG testing is
> also
> >>>>>> pointless as Nexus won't let you close the repo unless the
> signatures are
> >>>>>> valid.   The only check you really need to do is to make sure the
> key that
> >>>>>> was used is "trusted" by you.   (aka: was it really Holly who
> deployed those
> >>>>>> artifacts)    So the monontonous parts of checking that stuff is
> really
> >>>>>> irrelevant at this point.  (providing we trust that infra has Nexus
> >>>>>> sufficiently locked down and secure)
> >>>>>>
> >>>>>>
> >>>>>> I actually don't have a big issue with the difficulting in getting
> votes.
> >>>>>> I'm involved in another community that has a PMC that is easily 4
> times the
> >>>>>> size of this one, yet we still have difficulting getting votes
> there.
> >>>>>> While not ideal, life events can cause priority shifts and such so
> people
> >>>>>> may not be able to be as responsive.
> >>>>>>
> >>>>>> My bigger problem is that the entire per bundle release process and
> symantic
> >>>>>> versioning crap has put a HUGE burden on the release manager.
> That makes
> >>>>>> it much harder to get quality releases out and makes it less likely
> that
> >>>>>> anyone will step up to get "minor fixes" released.   The only
> reason I
> >>>>>> stepped up with the 0.3.1 bp stuff is that *MY*  customers are being
> >>>>>> affected by it.   Like wise for the proxy stuff.   If *my*
> customers were
> >>>>>> not affected, I don't think I would have spent the time and effort.
>    If
> >>>>>> the process for getting fixes and releases out to users was smaller
> and
> >>>>>> easier, I have no problem doing them.   For CXF, we do full
> releases on 3
> >>>>>> branches every other month or so.   But that's because it's EASY to
> do.
> >>>>>>
> >>>>>> If it was up to me, I'd toss out the entire versioning thing with
> 1.0 and go
> >>>>>> back to per module versioning thing.   So my fix to proxy would
>  have
> >>>>>> involved checking out all of "proxy", fixing it, and releasing all
> of proxy
> >>>>>> as a proxy "0.3.1", even the modules that haven't changed.   It's
> just a
> >>>>>> huge hassle to track down which bundles have changed, which haven't
> which
> >>>>>> version numbers need to be updated, etc....   If it's not quick and
> easy to
> >>>>>> do releases as a release manager, very few people are going to step
> up to do
> >>>>>> it.     It may not be 100% "proper OSGi", but IMO, getting fixes
> and such to
> >>>>>> the users is more important than that.    But that's my opinion.
> >>>>>>
> >>>>>>
> >>>>>> Dan
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Saturday, June 23, 2012 03:27:07 PM Holly Cummins wrote:
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>> Now that Jeremy's taken the time to write up our release
> verification
> >>>>>>> process, I'd like to propose we change it. :) I think it's too
> onerous
> >>>>>>> on the pmc, which therefore also inhibits our ability to be
> responsive
> >>>>>>> to our users.
> >>>>>>>
> >>>>>>>
> >>>>>>> ------------------------------- Why what we have isn't working for
> the
> >>>>>>> community -------------------------------
> >>>>>>>
> >>>>>>> I believe our users would like more frequent releases. We've had
> >>>>>>> several keen requests and tweets and comments on the aries-user
> >>>>>>> mailing list wishing we'd release more often. For example:
> >>>>>>>
> >>>>>>> * "Desperately waiting for an Aries release after loooong time.."
> >>>>>>> * "The problem with Aries is they seem to be too busy coding to
> >>>>>>> release anything."
> >>>>>>> * "Compared to other projects (like Karaf and Camel) Aries releases
> >>>>>>> tend to take quite some time."
> >>>>>>> * "It's 2012 now and Aries 0.3 is almost a year old. Is there any
> >>>>>>> chance of a new Aries JPA release any time soon? "
> >>>>>>> * "Looks like Apache Aries has made no visible progress since Jan
> >>>>>>> 2011, if the time stamps on the maven central artefacts are to be
> >>>>>>> believed."
> >>>>>>>
> >>>>>>> ------------------------------- Why what we have isn't working for
> us
> >>>>>>> -------------------------------
> >>>>>>>
> >>>>>>> Both Dan and I are trying to do releases at the moment, and
> struggling
> >>>>>>> to get enough PMC votes. Dan's release is to back port a
> show-stopper
> >>>>>>> proxy fix, so a release there is particularly pressing - he's got a
> >>>>>>> non-binding +infinity vote, but that's all. My test support release
> >>>>>>> vote has been open for about 64 hours, and only got one vote so far
> >>>>>>> (thanks David B!). Obviously testsupport is less exciting than
> proxy,
> >>>>>>> but that bundle does block more interesting releases.
> >>>>>>>
> >>>>>>> Why aren't people voting? My guess is that it's too much work to do
> >>>>>>> the full set of verifications described at
> >>>>>>> http://aries.apache.org/development/verifyingrelease.html. There
> are
> >>>>>>> seven steps, and while they don't actually take that long to
> complete,
> >>>>>>> it's enough of a burden that we tend to leave the voting to someone
> >>>>>>> else unless we really care about a release. I'm as guilty of this
> as
> >>>>>>> anyone - I think a release is a good idea, but I'm spending enough
> >>>>>>> time working on the 1.0.0 release that I don't want to take time
> out
> >>>>>>> to vote on another release. I suspect Dan might feel exactly the
> same
> >>>>>>> about my 1.0.0 bundles. :)
> >>>>>>>
> >>>>>>> With release-by-bundle, there's a lot of verifications. Excluding
> the
> >>>>>>> sandbox code, we have 123 bundles to release in 1.0.0. At three
> votes
> >>>>>>> per bundle, that means the PMC need to do 369 MD5 checks, 369 PGP
> >>>>>>> checks, 369 RAT checks, and so on, just to get 1.0.0 out the door.
> >>>>>>> This just doesn't seem like it scales. Batching the bundle releases
> >>>>>>> together eases some of this burden, but not all.
> >>>>>>>
> >>>>>>> ------------------------------- What I propose
> >>>>>>> -------------------------------
> >>>>>>>
> >>>>>>> I suggest we move to a more trust-based system, where PMC members
> >>>>>>> carefully check releases if they want, but where in general they're
> >>>>>>> voting on the principle of the release, rather than the mechanics
> of
> >>>>>>> the archives. In particular, they don't feel compelled to do checks
> >>>>>>> before voting. If PMC members could say "Our users need this
> function,
> >>>>>>> so +1", or "I know Holly has done sensible things in the past, so
> +1"
> >>>>>>> or even "Do I want to check the SHAs on a test support bundle?
> Really?
> >>>>>>> +1" it would get our releases moving better, and also save work for
> >>>>>>> all of us.
> >>>>>>>
> >>>>>>> (At the moment I think what's happening is people are thinking "Do
> I
> >>>>>>> want to check the SHAs on a test support bundle? Really?" and then
> >>>>>>> skipping the +1 bit. :)  )
> >>>>>>>
> >>>>>>> To ensure that at least *someone* has run the checks, the release
> >>>>>>> manager could include the output of the seven checks in an email to
> >>>>>>> the list. I think this level of checking is perfectly compatible
> with
> >>>>>>> the minimum Apache process, which is that the release manager signs
> >>>>>>> the artefacts and three PMC members vote +1
> >>>>>>> (http://www.apache.org/dev/release-publishing.html#voted).
> >>>>>>>
> >>>>>>> What do people think?
> >>>>>>>
> >>>>>>> Holly
> >>>>>> --
> >>>>>> Daniel Kulp
> >>>>>> dkulp@apache.org - http://dankulp.com/blog
> >>>>>> Talend Community Coder - http://coders.talend.com
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> ------------------------
> >>>>> Guillaume Nodet
> >>>>> ------------------------
> >>>>> Blog: http://gnodet.blogspot.com/
> >>>>> ------------------------
> >>>>> FuseSource, Integration everywhere
> >>>>> http://fusesource.com
> >>>
> >>>
> >>>
> >>> --
> >>> ------------------------
> >>> Guillaume Nodet
> >>> ------------------------
> >>> Blog: http://gnodet.blogspot.com/
> >>> ------------------------
> >>> FuseSource, Integration everywhere
> >>> http://fusesource.com
> >
>



-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

Re: [DISCUSSION] Modifications to Aries release process

[Holly Cummins <ho...@googlemail.com>]

Hi David,

[snip]

> I don't understand the problem.  I thought Guillaume was suggesting that you put a lot of released artifacts, built by the rm (you) in the same nexus staging repo.  Since you just built API-1.0.0 on your build machine, it will be in your local maven repo, and you can continue to build all the other stuff that needs it on your repo.  No one else can get the 1.0.0 artifacts from a remote maven  repo until you close the staging repo, but they can also build the 1.0.0 artifacts themselves, just like you did (they won't have to change the versions, since the relevant code will already be in a svn tag from running the release plugin).
>
> Once you close the staging repo, people can add it to their local nexus  or settings.xml and fetch the under-vote 1.0.0 artifacts without building them themselves.
>
> What am I missing?

Those extra steps, to either adjust settings.xml, or check out a tag
and build it, seem non-ideal to me. I'd argue a build should just
work, or that any extra steps (like adjusting settings.xml) should be
'one-off', rather than constantly variable. It means when someone
wants to do a release, it creates a bit of inconvenience for everyone
else, which - imo - tends to drag us back to a 'release only when
absolutely necessary' model. After all, no one wants to be the person
who breaks the build, even if there are workarounds ...

We'd also need to add pre-build steps to Jenkins to populate the
repositories on the build machines, again increasing the complexity
and fragility of the automated build.

Cheers,
Holly
>
> thanks
> david jencks
>
>
>>
>> I think this is sensible to do occasionally, but it's error prone and
>> makes more work for the release manager. Obviously, the big advantage
>> of it is that the release gets voted through over a period of a few
>> days, rather than a month or two, for a big release. :)
>>
>> Holly
>>
>>
>>
>>> On Thu, Jun 28, 2012 at 6:45 PM, Holly Cummins
>>> <ho...@googlemail.com> wrote:
>>>> Hi Guillaume,
>>>>
>>>> Thanks for your comments. Here are some of my thoughts ...
>>>>
>>>> On Thu, Jun 28, 2012 at 3:19 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>> I think one problem, considering the current votes, is that it's
>>>>> really difficult to test anything.   Releasing api bundles with no
>>>>> implementation to test is definitely not helping imo.
>>>>
>>>> I know what you mean about the testing, and I'm not totally sure what
>>>> the best answer is. I know what I'm releasing comes from trunk, and is
>>>> being tested by the Jenkins builds, so I'm pretty confident it works
>>>> in a real system. However being tested in more environments and by
>>>> more systems is obviously a Good Thing.  I think the best way to test
>>>> the API bundles is with the current -SNAPSHOT bundles of the
>>>> implementation, either in something like the blog sample or some other
>>>> working system. If we weren't moving from 0.x to 1.0 you could also
>>>> test micro releases alongside existing impl bundles to ensure
>>>> everything resolves and works as claimed.
>>>>
>>>>> Holly, just a question: is there a specific reason why are you doing
>>>>> the release in multiple votes ? It would be simpler to just release
>>>>> everything in one go and wait for a longer time because there are more
>>>>> things to check, or at least, release the api + implementation so that
>>>>> we can actually try something.  Just my 2 cents.
>>>>
>>>> I agree that this sort of 'extended incremental' release is a bit
>>>> awkward, and I was wondering when someone would ask what on earth I
>>>> was doing :). IMO it's the cleanest way to work with with
>>>> release-by-bundle (which I know you disagree with). If I release
>>>> everything in one go, there's a problem with the dependencies between
>>>> bundles. At the moment in trunk, almost every dependency is a SNAPSHOT
>>>> dependency. In the past we've updated all bundles to use non-SNAPSHOT
>>>> (but not yet released) versions in a branch, and I could even do
>>>> something similar without using a branch by briefly having the trunk
>>>> builds produce 1.0.0 artefacts. However, I think this creates a
>>>> greater burden for testers. If there are compilation-order
>>>> dependencies between parts of a release which don't share a top-level
>>>> pom, everyone verifying a script has to compile them in the right
>>>> order. I count 118 bundles to release, so that's a lot of bundles to
>>>> get in the right order, and I didn't think any PMC member would want
>>>> to try. :) I guess this could be automated with a verification script
>>>> which either hardcodes or calculates the dependency graph, but it
>>>> seemed to me like more work for everyone and more risk for the
>>>> release. My hope was that if verifying individual mini-releases was
>>>> easy enough, doing multiple ones wouldn't be a problem (and in fact
>>>> would nicely distribute any effort, making it easier to vote).
>>>>
>>>> I know at this stage some of you are thinking "and *this* is why
>>>> release by bundle is a bad idea!", and that's not really a debate I
>>>> want to re-open. Among other things, I think any re-engineering of our
>>>> poms at this stage will further delay the release.
>>>>
>>>> The good news is I believe this problem will almost entirely go away
>>>> for 1.0.x and 1.x releases, because the impl bundle will, in most
>>>> cases, depend on an *already* released version of its API bundle or
>>>> another Aries component. This means a bunch of related bundles could
>>>> be released at the same time, without compile issues, or a meaningful
>>>> release really could consist of just a single bundle. That's true
>>>> modularity and it should give both us and our users big benefits.
>>>>
>>>>
>>>>>
>>>>> On Mon, Jun 25, 2012 at 8:07 PM, Daniel Kulp <dk...@apache.org> wrote:
>>>>>>
>>>>>> Honestly, with the change to using Nexus, the SHA1 and MD5 checks are
>>>>>> completely pointless.   Nexus generates them itself based on what's
>>>>>> uploaded.  The "is it a valid signature" part of the GPG testing is also
>>>>>> pointless as Nexus won't let you close the repo unless the signatures are
>>>>>> valid.   The only check you really need to do is to make sure the key that
>>>>>> was used is "trusted" by you.   (aka: was it really Holly who deployed those
>>>>>> artifacts)    So the monontonous parts of checking that stuff is really
>>>>>> irrelevant at this point.  (providing we trust that infra has Nexus
>>>>>> sufficiently locked down and secure)
>>>>>>
>>>>>>
>>>>>> I actually don't have a big issue with the difficulting in getting votes.
>>>>>> I'm involved in another community that has a PMC that is easily 4 times the
>>>>>> size of this one, yet we still have difficulting getting votes there.
>>>>>> While not ideal, life events can cause priority shifts and such so people
>>>>>> may not be able to be as responsive.
>>>>>>
>>>>>> My bigger problem is that the entire per bundle release process and symantic
>>>>>> versioning crap has put a HUGE burden on the release manager.   That makes
>>>>>> it much harder to get quality releases out and makes it less likely that
>>>>>> anyone will step up to get "minor fixes" released.   The only reason I
>>>>>> stepped up with the 0.3.1 bp stuff is that *MY*  customers are being
>>>>>> affected by it.   Like wise for the proxy stuff.   If *my* customers were
>>>>>> not affected, I don't think I would have spent the time and effort.    If
>>>>>> the process for getting fixes and releases out to users was smaller and
>>>>>> easier, I have no problem doing them.   For CXF, we do full releases on 3
>>>>>> branches every other month or so.   But that's because it's EASY to do.
>>>>>>
>>>>>> If it was up to me, I'd toss out the entire versioning thing with 1.0 and go
>>>>>> back to per module versioning thing.   So my fix to proxy would  have
>>>>>> involved checking out all of "proxy", fixing it, and releasing all of proxy
>>>>>> as a proxy "0.3.1", even the modules that haven't changed.   It's just a
>>>>>> huge hassle to track down which bundles have changed, which haven't which
>>>>>> version numbers need to be updated, etc....   If it's not quick and easy to
>>>>>> do releases as a release manager, very few people are going to step up to do
>>>>>> it.     It may not be 100% "proper OSGi", but IMO, getting fixes and such to
>>>>>> the users is more important than that.    But that's my opinion.
>>>>>>
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Saturday, June 23, 2012 03:27:07 PM Holly Cummins wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Now that Jeremy's taken the time to write up our release verification
>>>>>>> process, I'd like to propose we change it. :) I think it's too onerous
>>>>>>> on the pmc, which therefore also inhibits our ability to be responsive
>>>>>>> to our users.
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------- Why what we have isn't working for the
>>>>>>> community -------------------------------
>>>>>>>
>>>>>>> I believe our users would like more frequent releases. We've had
>>>>>>> several keen requests and tweets and comments on the aries-user
>>>>>>> mailing list wishing we'd release more often. For example:
>>>>>>>
>>>>>>> * "Desperately waiting for an Aries release after loooong time.."
>>>>>>> * "The problem with Aries is they seem to be too busy coding to
>>>>>>> release anything."
>>>>>>> * "Compared to other projects (like Karaf and Camel) Aries releases
>>>>>>> tend to take quite some time."
>>>>>>> * "It's 2012 now and Aries 0.3 is almost a year old. Is there any
>>>>>>> chance of a new Aries JPA release any time soon? "
>>>>>>> * "Looks like Apache Aries has made no visible progress since Jan
>>>>>>> 2011, if the time stamps on the maven central artefacts are to be
>>>>>>> believed."
>>>>>>>
>>>>>>> ------------------------------- Why what we have isn't working for us
>>>>>>> -------------------------------
>>>>>>>
>>>>>>> Both Dan and I are trying to do releases at the moment, and struggling
>>>>>>> to get enough PMC votes. Dan's release is to back port a show-stopper
>>>>>>> proxy fix, so a release there is particularly pressing - he's got a
>>>>>>> non-binding +infinity vote, but that's all. My test support release
>>>>>>> vote has been open for about 64 hours, and only got one vote so far
>>>>>>> (thanks David B!). Obviously testsupport is less exciting than proxy,
>>>>>>> but that bundle does block more interesting releases.
>>>>>>>
>>>>>>> Why aren't people voting? My guess is that it's too much work to do
>>>>>>> the full set of verifications described at
>>>>>>> http://aries.apache.org/development/verifyingrelease.html. There are
>>>>>>> seven steps, and while they don't actually take that long to complete,
>>>>>>> it's enough of a burden that we tend to leave the voting to someone
>>>>>>> else unless we really care about a release. I'm as guilty of this as
>>>>>>> anyone - I think a release is a good idea, but I'm spending enough
>>>>>>> time working on the 1.0.0 release that I don't want to take time out
>>>>>>> to vote on another release. I suspect Dan might feel exactly the same
>>>>>>> about my 1.0.0 bundles. :)
>>>>>>>
>>>>>>> With release-by-bundle, there's a lot of verifications. Excluding the
>>>>>>> sandbox code, we have 123 bundles to release in 1.0.0. At three votes
>>>>>>> per bundle, that means the PMC need to do 369 MD5 checks, 369 PGP
>>>>>>> checks, 369 RAT checks, and so on, just to get 1.0.0 out the door.
>>>>>>> This just doesn't seem like it scales. Batching the bundle releases
>>>>>>> together eases some of this burden, but not all.
>>>>>>>
>>>>>>> ------------------------------- What I propose
>>>>>>> -------------------------------
>>>>>>>
>>>>>>> I suggest we move to a more trust-based system, where PMC members
>>>>>>> carefully check releases if they want, but where in general they're
>>>>>>> voting on the principle of the release, rather than the mechanics of
>>>>>>> the archives. In particular, they don't feel compelled to do checks
>>>>>>> before voting. If PMC members could say "Our users need this function,
>>>>>>> so +1", or "I know Holly has done sensible things in the past, so +1"
>>>>>>> or even "Do I want to check the SHAs on a test support bundle? Really?
>>>>>>> +1" it would get our releases moving better, and also save work for
>>>>>>> all of us.
>>>>>>>
>>>>>>> (At the moment I think what's happening is people are thinking "Do I
>>>>>>> want to check the SHAs on a test support bundle? Really?" and then
>>>>>>> skipping the +1 bit. :)  )
>>>>>>>
>>>>>>> To ensure that at least *someone* has run the checks, the release
>>>>>>> manager could include the output of the seven checks in an email to
>>>>>>> the list. I think this level of checking is perfectly compatible with
>>>>>>> the minimum Apache process, which is that the release manager signs
>>>>>>> the artefacts and three PMC members vote +1
>>>>>>> (http://www.apache.org/dev/release-publishing.html#voted).
>>>>>>>
>>>>>>> What do people think?
>>>>>>>
>>>>>>> Holly
>>>>>> --
>>>>>> Daniel Kulp
>>>>>> dkulp@apache.org - http://dankulp.com/blog
>>>>>> Talend Community Coder - http://coders.talend.com
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ------------------------
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> FuseSource, Integration everywhere
>>>>> http://fusesource.com
>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> FuseSource, Integration everywhere
>>> http://fusesource.com
>

Re: [DISCUSSION] Modifications to Aries release process

[David Jencks <da...@yahoo.com>]

On Jul 6, 2012, at 9:24 AM, Holly Cummins wrote:

> Re-opening a slightly old conversation, just to ensure we have a
> record of the advantages and disadvantages of each approach to
> releasing groups of bundles. (I'm also updating the 'Releasing Aries'
> web page with the pros and cons of each way of doing it.)
> 
> On Thu, Jun 28, 2012 at 6:12 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>> I think you made a wrong assumption which is that the staging repo has
>> to be backed by a single svn revision (which is btw not really the
>> case because it comes from several tags anyway).
>> What I'd suggest is doing the api bundles release and have them
>> uploaded to nexus, then upgrade the implementations  and all other
>> components to use those releases, commit,  release those other
>> projects, THEN, close the staging repo and call for a vote.
>> So we'd have a single staging repo / vote with a set of testable bundles in it.
> 
> This approach will break trunk unless we do an extra step.
> 
> Say we release an API bundle, at version 1.0.0. The release plugin
> will change the version of the API bundle in trunk to be
> 1.0.1-SNAPSHOT. Normally, you'd just upgrade everything to depend on
> 1.0.1-SNAPSHOT of the API bundle (and if we weren't doing release by
> bundle, the release plugin would automatically update the dependencies
> for us). However, it's important that things which depend on the API
> bundle continue depending on 1.0.0, unless there's a good reason to
> change (like they use a new method). Otherwise, we lose a lot of the
> benefits of semantic versioning. Why? If we add a new method to the
> API, the package version changes to 1.1, and anything compiling
> against 1.0.1-SNAPSHOT won't resolve against 1.0.0, even if it would
> actually *work* fine against 1.0.0. In order to avoid restricting our
> modularity, we need to depend on 1.0.0 unless the 1.0.1-SNAPSHOT
> methods are actually being used.
> 
> So, continuing the example, in trunk, as part of the release, we've
> switched to depending on 1.0.0 of the API. This compiles in the tagged
> release, as long as bundles are compiled in a specific order. In
> trunk, it won't compile at all, because nothing in trunk is building
> API-1.0.0, and version 1.0.0 isn't in a maven repository yet. Instead,
> trunk is building 1.0.1-SNAPSHOT. So to patch trunk up, we need to add
> an extra step in which we switch back to depending on 1.0.0-SNAPSHOT,
> and then a second extra step once the release is promoted, to depend
> on 1.0.0.

I don't understand the problem.  I thought Guillaume was suggesting that you put a lot of released artifacts, built by the rm (you) in the same nexus staging repo.  Since you just built API-1.0.0 on your build machine, it will be in your local maven repo, and you can continue to build all the other stuff that needs it on your repo.  No one else can get the 1.0.0 artifacts from a remote maven  repo until you close the staging repo, but they can also build the 1.0.0 artifacts themselves, just like you did (they won't have to change the versions, since the relevant code will already be in a svn tag from running the release plugin).

Once you close the staging repo, people can add it to their local nexus  or settings.xml and fetch the under-vote 1.0.0 artifacts without building them themselves.

What am I missing?

thanks
david jencks


> 
> I think this is sensible to do occasionally, but it's error prone and
> makes more work for the release manager. Obviously, the big advantage
> of it is that the release gets voted through over a period of a few
> days, rather than a month or two, for a big release. :)
> 
> Holly
> 
> 
> 
>> On Thu, Jun 28, 2012 at 6:45 PM, Holly Cummins
>> <ho...@googlemail.com> wrote:
>>> Hi Guillaume,
>>> 
>>> Thanks for your comments. Here are some of my thoughts ...
>>> 
>>> On Thu, Jun 28, 2012 at 3:19 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>>>> I think one problem, considering the current votes, is that it's
>>>> really difficult to test anything.   Releasing api bundles with no
>>>> implementation to test is definitely not helping imo.
>>> 
>>> I know what you mean about the testing, and I'm not totally sure what
>>> the best answer is. I know what I'm releasing comes from trunk, and is
>>> being tested by the Jenkins builds, so I'm pretty confident it works
>>> in a real system. However being tested in more environments and by
>>> more systems is obviously a Good Thing.  I think the best way to test
>>> the API bundles is with the current -SNAPSHOT bundles of the
>>> implementation, either in something like the blog sample or some other
>>> working system. If we weren't moving from 0.x to 1.0 you could also
>>> test micro releases alongside existing impl bundles to ensure
>>> everything resolves and works as claimed.
>>> 
>>>> Holly, just a question: is there a specific reason why are you doing
>>>> the release in multiple votes ? It would be simpler to just release
>>>> everything in one go and wait for a longer time because there are more
>>>> things to check, or at least, release the api + implementation so that
>>>> we can actually try something.  Just my 2 cents.
>>> 
>>> I agree that this sort of 'extended incremental' release is a bit
>>> awkward, and I was wondering when someone would ask what on earth I
>>> was doing :). IMO it's the cleanest way to work with with
>>> release-by-bundle (which I know you disagree with). If I release
>>> everything in one go, there's a problem with the dependencies between
>>> bundles. At the moment in trunk, almost every dependency is a SNAPSHOT
>>> dependency. In the past we've updated all bundles to use non-SNAPSHOT
>>> (but not yet released) versions in a branch, and I could even do
>>> something similar without using a branch by briefly having the trunk
>>> builds produce 1.0.0 artefacts. However, I think this creates a
>>> greater burden for testers. If there are compilation-order
>>> dependencies between parts of a release which don't share a top-level
>>> pom, everyone verifying a script has to compile them in the right
>>> order. I count 118 bundles to release, so that's a lot of bundles to
>>> get in the right order, and I didn't think any PMC member would want
>>> to try. :) I guess this could be automated with a verification script
>>> which either hardcodes or calculates the dependency graph, but it
>>> seemed to me like more work for everyone and more risk for the
>>> release. My hope was that if verifying individual mini-releases was
>>> easy enough, doing multiple ones wouldn't be a problem (and in fact
>>> would nicely distribute any effort, making it easier to vote).
>>> 
>>> I know at this stage some of you are thinking "and *this* is why
>>> release by bundle is a bad idea!", and that's not really a debate I
>>> want to re-open. Among other things, I think any re-engineering of our
>>> poms at this stage will further delay the release.
>>> 
>>> The good news is I believe this problem will almost entirely go away
>>> for 1.0.x and 1.x releases, because the impl bundle will, in most
>>> cases, depend on an *already* released version of its API bundle or
>>> another Aries component. This means a bunch of related bundles could
>>> be released at the same time, without compile issues, or a meaningful
>>> release really could consist of just a single bundle. That's true
>>> modularity and it should give both us and our users big benefits.
>>> 
>>> 
>>>> 
>>>> On Mon, Jun 25, 2012 at 8:07 PM, Daniel Kulp <dk...@apache.org> wrote:
>>>>> 
>>>>> Honestly, with the change to using Nexus, the SHA1 and MD5 checks are
>>>>> completely pointless.   Nexus generates them itself based on what's
>>>>> uploaded.  The "is it a valid signature" part of the GPG testing is also
>>>>> pointless as Nexus won't let you close the repo unless the signatures are
>>>>> valid.   The only check you really need to do is to make sure the key that
>>>>> was used is "trusted" by you.   (aka: was it really Holly who deployed those
>>>>> artifacts)    So the monontonous parts of checking that stuff is really
>>>>> irrelevant at this point.  (providing we trust that infra has Nexus
>>>>> sufficiently locked down and secure)
>>>>> 
>>>>> 
>>>>> I actually don't have a big issue with the difficulting in getting votes.
>>>>> I'm involved in another community that has a PMC that is easily 4 times the
>>>>> size of this one, yet we still have difficulting getting votes there.
>>>>> While not ideal, life events can cause priority shifts and such so people
>>>>> may not be able to be as responsive.
>>>>> 
>>>>> My bigger problem is that the entire per bundle release process and symantic
>>>>> versioning crap has put a HUGE burden on the release manager.   That makes
>>>>> it much harder to get quality releases out and makes it less likely that
>>>>> anyone will step up to get "minor fixes" released.   The only reason I
>>>>> stepped up with the 0.3.1 bp stuff is that *MY*  customers are being
>>>>> affected by it.   Like wise for the proxy stuff.   If *my* customers were
>>>>> not affected, I don't think I would have spent the time and effort.    If
>>>>> the process for getting fixes and releases out to users was smaller and
>>>>> easier, I have no problem doing them.   For CXF, we do full releases on 3
>>>>> branches every other month or so.   But that's because it's EASY to do.
>>>>> 
>>>>> If it was up to me, I'd toss out the entire versioning thing with 1.0 and go
>>>>> back to per module versioning thing.   So my fix to proxy would  have
>>>>> involved checking out all of "proxy", fixing it, and releasing all of proxy
>>>>> as a proxy "0.3.1", even the modules that haven't changed.   It's just a
>>>>> huge hassle to track down which bundles have changed, which haven't which
>>>>> version numbers need to be updated, etc....   If it's not quick and easy to
>>>>> do releases as a release manager, very few people are going to step up to do
>>>>> it.     It may not be 100% "proper OSGi", but IMO, getting fixes and such to
>>>>> the users is more important than that.    But that's my opinion.
>>>>> 
>>>>> 
>>>>> Dan
>>>>> 
>>>>> 
>>>>> 
>>>>> On Saturday, June 23, 2012 03:27:07 PM Holly Cummins wrote:
>>>>>> Hi all,
>>>>>> 
>>>>>> Now that Jeremy's taken the time to write up our release verification
>>>>>> process, I'd like to propose we change it. :) I think it's too onerous
>>>>>> on the pmc, which therefore also inhibits our ability to be responsive
>>>>>> to our users.
>>>>>> 
>>>>>> 
>>>>>> ------------------------------- Why what we have isn't working for the
>>>>>> community -------------------------------
>>>>>> 
>>>>>> I believe our users would like more frequent releases. We've had
>>>>>> several keen requests and tweets and comments on the aries-user
>>>>>> mailing list wishing we'd release more often. For example:
>>>>>> 
>>>>>> * "Desperately waiting for an Aries release after loooong time.."
>>>>>> * "The problem with Aries is they seem to be too busy coding to
>>>>>> release anything."
>>>>>> * "Compared to other projects (like Karaf and Camel) Aries releases
>>>>>> tend to take quite some time."
>>>>>> * "It's 2012 now and Aries 0.3 is almost a year old. Is there any
>>>>>> chance of a new Aries JPA release any time soon? "
>>>>>> * "Looks like Apache Aries has made no visible progress since Jan
>>>>>> 2011, if the time stamps on the maven central artefacts are to be
>>>>>> believed."
>>>>>> 
>>>>>> ------------------------------- Why what we have isn't working for us
>>>>>> -------------------------------
>>>>>> 
>>>>>> Both Dan and I are trying to do releases at the moment, and struggling
>>>>>> to get enough PMC votes. Dan's release is to back port a show-stopper
>>>>>> proxy fix, so a release there is particularly pressing - he's got a
>>>>>> non-binding +infinity vote, but that's all. My test support release
>>>>>> vote has been open for about 64 hours, and only got one vote so far
>>>>>> (thanks David B!). Obviously testsupport is less exciting than proxy,
>>>>>> but that bundle does block more interesting releases.
>>>>>> 
>>>>>> Why aren't people voting? My guess is that it's too much work to do
>>>>>> the full set of verifications described at
>>>>>> http://aries.apache.org/development/verifyingrelease.html. There are
>>>>>> seven steps, and while they don't actually take that long to complete,
>>>>>> it's enough of a burden that we tend to leave the voting to someone
>>>>>> else unless we really care about a release. I'm as guilty of this as
>>>>>> anyone - I think a release is a good idea, but I'm spending enough
>>>>>> time working on the 1.0.0 release that I don't want to take time out
>>>>>> to vote on another release. I suspect Dan might feel exactly the same
>>>>>> about my 1.0.0 bundles. :)
>>>>>> 
>>>>>> With release-by-bundle, there's a lot of verifications. Excluding the
>>>>>> sandbox code, we have 123 bundles to release in 1.0.0. At three votes
>>>>>> per bundle, that means the PMC need to do 369 MD5 checks, 369 PGP
>>>>>> checks, 369 RAT checks, and so on, just to get 1.0.0 out the door.
>>>>>> This just doesn't seem like it scales. Batching the bundle releases
>>>>>> together eases some of this burden, but not all.
>>>>>> 
>>>>>> ------------------------------- What I propose
>>>>>> -------------------------------
>>>>>> 
>>>>>> I suggest we move to a more trust-based system, where PMC members
>>>>>> carefully check releases if they want, but where in general they're
>>>>>> voting on the principle of the release, rather than the mechanics of
>>>>>> the archives. In particular, they don't feel compelled to do checks
>>>>>> before voting. If PMC members could say "Our users need this function,
>>>>>> so +1", or "I know Holly has done sensible things in the past, so +1"
>>>>>> or even "Do I want to check the SHAs on a test support bundle? Really?
>>>>>> +1" it would get our releases moving better, and also save work for
>>>>>> all of us.
>>>>>> 
>>>>>> (At the moment I think what's happening is people are thinking "Do I
>>>>>> want to check the SHAs on a test support bundle? Really?" and then
>>>>>> skipping the +1 bit. :)  )
>>>>>> 
>>>>>> To ensure that at least *someone* has run the checks, the release
>>>>>> manager could include the output of the seven checks in an email to
>>>>>> the list. I think this level of checking is perfectly compatible with
>>>>>> the minimum Apache process, which is that the release manager signs
>>>>>> the artefacts and three PMC members vote +1
>>>>>> (http://www.apache.org/dev/release-publishing.html#voted).
>>>>>> 
>>>>>> What do people think?
>>>>>> 
>>>>>> Holly
>>>>> --
>>>>> Daniel Kulp
>>>>> dkulp@apache.org - http://dankulp.com/blog
>>>>> Talend Community Coder - http://coders.talend.com
>>>> 
>>>> 
>>>> 
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> FuseSource, Integration everywhere
>>>> http://fusesource.com
>> 
>> 
>> 
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> FuseSource, Integration everywhere
>> http://fusesource.com