Re: Incubator Releases: mandatory or optional? Purpose?

[Robert Burrell Donkin <ro...@gmail.com>]

On Fri, Nov 13, 2009 at 6:27 PM, Noel J. Bergman <no...@devtech.com> wrote:
> Greg Stein wrote:
>
>> > IIRC, Martijn has offered a proper legal review in the place of a
> "release".
>> > This sounded pretty reasonable to me. I would agree to that.
>
>> Yup. I've already stated that I have no problems with running RAT and
>> working through those issues. Might have been hard to see in this long
>> thread
>
> Ironically, when the Incubator first formed, podlings could NOT do a release
> and many yelled about it.  Accordingly, after much discussion on how, that
> rule was changed so that a podling *could* do a release.  Later, some people
> felt that it was not only possible, but should be mandatory to see a project
> go through the release process, and (in another irony), I believe that some
> of those asking to skirt the issue for Subversion were amonst those pushing
> to see the projects do a release before graduation.  Later on, there was a
> push from the Infrastructure team (as noted already by Joe), wanting to make
> sure that the podling knew the processes for doing a release on ASF
> infrastructure.

IMHO a podling should know how to cut an ASF release (IIRC i've always
been reasonably consistent on this). the easiest way to demonstrate
this knowledge is to cut a release but it's not the only way.

but releases are now too big a hurdle. i'd like to see a track
approach (with IPMC approval votes at each stage)  introduced to
increase the chances of a release passing first time and reduce the
need for an actual release to be cut. this would mean three smaller
hurdles (licensing audit, source audit and build audit) rather than
hitting all these issues when the first release is cut.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Incubator Releases: mandatory or optional? Purpose?

[Robert Burrell Donkin <ro...@gmail.com>]

On Fri, Nov 13, 2009 at 6:47 PM, Noel J. Bergman <no...@devtech.com> wrote:
> Robert Burrell Donkin wrote:
>
>> IMHO a podling should know how to cut an ASF release
>> the easiest way to demonstrate this knowledge is to cut a release
>> but it's not the only way.
>
> I don't have an argument with any of those three points.
>
> I also suggest that there is a difference between preparing a release and
> actually doing a release.  In other words, one could prepare the proposed
> artifacts as if they were to be in a release, without releasing them.  That
> would allow audit of the key criteria.

this is effectively what they do now (at least for the first release)

in practice, this is too much for most podlings to get right first
time, and auditing on demand places too great a strain on the
available reviewing resources of the IPMC. so, it's slow and
difficult.

>> i'd like to see a track approach (with IPMC approval votes at each stage)
>>    [1] licensing audit
>>    [2] source audit
>>    [3] build audit
>> rather than hitting all these issues when the first release is cut.
>
> Please elaborate at your convenience.  And where do you feel that an audit
> of the release artifacts comes in?  Step 3?

the IPMC must review released artifacts to provide oversight but the
work required to approve each release could be reduce by only allowing
podlings who have demonstrated understanding to submit releases. this
could be done by using a track system containing the major checks made
at release time.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: Incubator Releases: mandatory or optional? Purpose?

["Noel J. Bergman" <no...@devtech.com>]

Robert Burrell Donkin wrote:

> IMHO a podling should know how to cut an ASF release
> the easiest way to demonstrate this knowledge is to cut a release
> but it's not the only way.

I don't have an argument with any of those three points.

I also suggest that there is a difference between preparing a release and
actually doing a release.  In other words, one could prepare the proposed
artifacts as if they were to be in a release, without releasing them.  That
would allow audit of the key criteria.

> i'd like to see a track approach (with IPMC approval votes at each stage)
>    [1] licensing audit
>    [2] source audit
>    [3] build audit
> rather than hitting all these issues when the first release is cut.

Please elaborate at your convenience.  And where do you feel that an audit
of the release artifacts comes in?  Step 3?

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org