You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2009/11/13 19:27:11 UTC

Incubator Releases: mandatory or optional? Purpose?

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.

	--- Noel



---------------------------------------------------------------------
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?

Posted by Gurkan Erdogdu <cg...@gmail.com>.
>>>the draconian release process. ;-)
Actually it is quite true. Last  time I released OpenWebBeans, it took
nearly 1 month :) Besides, it is also very helpful to understand Apache way
release procedures.

--Gurkan
2009/11/16 Jukka Zitting <ju...@gmail.com>

> Hi,
>
> On Mon, Nov 16, 2009 at 3:11 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> > On Nov 13, 2009, at 1:27 PM, Noel J. Bergman wrote:
> >> Ironically, when the Incubator first formed, podlings could NOT do a
> release
> >> and many yelled about it.
> >
> > Yes, the originally reason behind it, iirc, was so podlings had a reason
> > to graduate, the thought being if they could do a release, then what
> > incentive was there for them to ever leave? :)
>
> Nowadays it seems that one of the prime reasons for projects to leave
> the Incubator is to escape the draconian release process. ;-)
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: Incubator Releases: mandatory or optional? Purpose?

Posted by Jukka Zitting <ju...@gmail.com>.
Hi,

On Mon, Nov 16, 2009 at 3:11 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> On Nov 13, 2009, at 1:27 PM, Noel J. Bergman wrote:
>> Ironically, when the Incubator first formed, podlings could NOT do a release
>> and many yelled about it.
>
> Yes, the originally reason behind it, iirc, was so podlings had a reason
> to graduate, the thought being if they could do a release, then what
> incentive was there for them to ever leave? :)

Nowadays it seems that one of the prime reasons for projects to leave
the Incubator is to escape the draconian release process. ;-)

BR,

Jukka Zitting

---------------------------------------------------------------------
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?

Posted by Jim Jagielski <ji...@jaguNET.com>.
On Nov 13, 2009, at 1:27 PM, Noel J. Bergman 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.

Yes, the originally reason behind it, iirc, was so podlings had a reason
to graduate, the thought being if they could do a release, then what
incentive was there for them to ever leave? :)

>  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.

In general, the whole legal aspects of the ASF "kick in" when we release
code. That's what we exist to do and that when things like licensing and
the like make that connection between the development-side and the
"admin/legal"-side of the ASF.

Since releasing s/w is likely the most important and tangible thing
that ASF projects do, it is a Good Idea to ensure that projects know
how to do it, and this learning process does fit in well with the
whole goal of the Incubator.
---------------------------------------------------------------------
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?

Posted by 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?

Posted by "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


Re: Incubator Releases: mandatory or optional? Purpose?

Posted by 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