You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by ant elder <an...@gmail.com> on 2007/09/27 23:03:47 UTC
How strict should podling release reviews be?
What are people thoughts on how strict reviews should be when saying an
issue is serious enough to block a podling release?
Current incubator release policy is described at:
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
Some things said there are:
"No release made by a Podling will be endorsed by the ASF. Unendorsed
releases may be made by Podlings subject to the following policy...."
and the two constraints listed are:
* the release archive MUST contain the word "incubating" in the
filename; and
* the release archive MUST contain an Incubation disclaimer (as
described in the previous section), clearly visible in the main
documentation or README file.
So I'm wondering if as podling releases are not endorsed by the ASF and if
the "incubating" and the disclaimer text is everywhere as required then
could we be a little more lenient? Maybe just note any issues so they can be
fixed in the next release?
...ant
Re: How strict should podling release reviews be?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 28, 2007, at 4:16 AM, Bertrand Delacretaz wrote:
> On 9/27/07, ant elder <an...@gmail.com> wrote:
>
>> ...So I'm wondering if as podling releases are not endorsed by the
>> ASF and if
>> the "incubating" and the disclaimer text is everywhere as required
>> then
>> could we be a little more lenient? Maybe just note any issues so
>> they can be
>> fixed in the next release?...
>
> Do you mean technical issues ("code does not work") or legal stuff
> ("notice is missing for library XYZ")?
>
> IMHO the incubator PMC doesn't care much about technical issues in
> podling releases, at least for early releases.
>
> What we care about is that podlings get the "legal stuff" right, and
> letting releases out without this being ok is not an option, due to
> potential legal risks.
>
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How strict should podling release reviews be?
Posted by ant elder <an...@gmail.com>.
On 9/28/07, Guillaume Nodet <gn...@gmail.com> wrote:
>
> On 9/28/07, Bertrand Delacretaz <bd...@apache.org> wrote:
> >
> > What we care about is that podlings get the "legal stuff" right, and
> > letting releases out without this being ok is not an option, due to
> > potential legal risks.
>
> I thought projects in incubator were not endorsed by the ASF, hence
> the ASF could not be responsible for the legal stuff in podling
> releases... Did I miss something here ?
This is exactly the question i'm trying to clarify. The policy at
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases says:
- No release made by a Podling will be endorsed by the ASF
- (releases) SHALL NOT occur until all source has been legally transferred
to the ASF.
- the release archive MUST contain the word "incubating" in the filename
- the release archive MUST contain an Incubation disclaimer
and that seems to imply there is no constraint that every podling release
MUST met all the legal requirements expected of a non-incubating ASF
release.
...ant
Re: How strict should podling release reviews be?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Robert Burrell Donkin wrote:
> On 10/2/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>> Robert Burrell Donkin wrote:
>>> the responsibility for the release rests with those IPMCers who vote in favour
>> Correction, the responsibility rests with the Foundation once three
>> IPMC'ers have voted in favor and the release vote passed.
>
> IMHO the liability rests with the Foundation but the responsibility
> with those who voted
:)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How strict should podling release reviews be?
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 10/2/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Robert Burrell Donkin wrote:
> >
> > the responsibility for the release rests with those IPMCers who vote in favour
>
> Correction, the responsibility rests with the Foundation once three
> IPMC'ers have voted in favor and the release vote passed.
IMHO the liability rests with the Foundation but the responsibility
with those who voted
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How strict should podling release reviews be?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Robert Burrell Donkin wrote:
>
> the responsibility for the release rests with those IPMCers who vote in favour
Correction, the responsibility rests with the Foundation once three
IPMC'ers have voted in favor and the release vote passed.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How strict should podling release reviews be?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 03 October 2007 12:26, Kevan Miller wrote:
> IIUC, the external dependencies of an incubating project need not
> strictly conform to Apache policy. For instance, a project may enter
> incubation with dependencies on artifacts that have an excluded
> license (http://people.apache.org/~rubys/3party.html#category-x).
> It's my understanding that incubator releases could be created with
> these dependencies. However, the project would be expected to be
> working to remove these dependencies (certainly would be expected to
> be removed prior to graduation). Is my understanding correct?
>
> This relaxation of Apache policy towards external dependency policy
> does not translate to a relaxation of licensing requirements. Any
> Apache release must observe and follow the license requirements of
> the artifacts that it contains (no matter what category the license
> falls under). Failure to adhere to the license requirements of these
> dependencies are non-negotiable. Once identified, they must be
> addressed prior to release.
Somewhat correct, BUT the consequence of of "adhere to the license
requirements of these dependencies" would mean that for most of the excluded
licenses, we can NOT release under Apache License, which is not a leniency
tolerated.
So, the correct understanding would instead to be;
1. The podling is released under Apache License.
2. We fulfill all licensing requirements of dependencies.
3. No redistribution of sources other than category A licensed code.
4. Binary dependencies only on category A and category B licensed code.
I would personally also like to add;
5. Any code imported under a non-compatible (i.e. not Category A) license
has been removed from the codebase.
Probably other things as well.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How strict should podling release reviews be?
Posted by Kevan Miller <ke...@gmail.com>.
On Oct 2, 2007, at 5:33 PM, Robert Burrell Donkin wrote:
> On 9/28/07, Niclas Hedhman <ni...@hedhman.org> wrote:
>> On Friday 28 September 2007 17:12, Guillaume Nodet wrote:
>>> On 9/28/07, Bertrand Delacretaz <bd...@apache.org> wrote:
>>>> What we care about is that podlings get the "legal stuff" right,
>>>> and
>>>> letting releases out without this being ok is not an option, due to
>>>> potential legal risks.
>>>
>>> I thought projects in incubator were not endorsed by the ASF, hence
>>> the ASF could not be responsible for the legal stuff in podling
>>> releases... Did I miss something here ?
>>
>> Yes, you missed the fact that Incubator is part of ASF, and the
>> Incubator are
>> doing the releases on behalf of the podling.
>> AFAIUI, we are responsible of the legal aspects of the releases
>> (i.e. upstream
>> sources), but we have no practical responsibilities towards the
>> downstream
>> users.
>
> +1
>
> the disclaimer is really aimed at informing users and has no force
> in law
>
> the responsibility for the release rests with those IPMCers who
> vote in favour
I think most people would agree that reviews should be "strict" -- as
many problems as possible should be identified during a release
review. However, there seem to be some who feel that voting for
incubator releases can be a bit more "lenient".
If I understand the Incubator process correctly, there is some
relaxation of standards for incubator releases. Perhaps there is some
confusion on just what requirements are relaxed for incubator
releases. The following summarizes my understanding. Is it more or
less correct?
IIUC, the external dependencies of an incubating project need not
strictly conform to Apache policy. For instance, a project may enter
incubation with dependencies on artifacts that have an excluded
license (http://people.apache.org/~rubys/3party.html#category-x).
It's my understanding that incubator releases could be created with
these dependencies. However, the project would be expected to be
working to remove these dependencies (certainly would be expected to
be removed prior to graduation). Is my understanding correct?
This relaxation of Apache policy towards external dependency policy
does not translate to a relaxation of licensing requirements. Any
Apache release must observe and follow the license requirements of
the artifacts that it contains (no matter what category the license
falls under). Failure to adhere to the license requirements of these
dependencies are non-negotiable. Once identified, they must be
addressed prior to release.
--kevan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How strict should podling release reviews be?
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 9/28/07, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Friday 28 September 2007 17:12, Guillaume Nodet wrote:
> > On 9/28/07, Bertrand Delacretaz <bd...@apache.org> wrote:
> > > What we care about is that podlings get the "legal stuff" right, and
> > > letting releases out without this being ok is not an option, due to
> > > potential legal risks.
> >
> > I thought projects in incubator were not endorsed by the ASF, hence
> > the ASF could not be responsible for the legal stuff in podling
> > releases... Did I miss something here ?
>
> Yes, you missed the fact that Incubator is part of ASF, and the Incubator are
> doing the releases on behalf of the podling.
> AFAIUI, we are responsible of the legal aspects of the releases (i.e. upstream
> sources), but we have no practical responsibilities towards the downstream
> users.
+1
the disclaimer is really aimed at informing users and has no force in law
the responsibility for the release rests with those IPMCers who vote in favour
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How strict should podling release reviews be?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 28 September 2007 17:12, Guillaume Nodet wrote:
> On 9/28/07, Bertrand Delacretaz <bd...@apache.org> wrote:
> > What we care about is that podlings get the "legal stuff" right, and
> > letting releases out without this being ok is not an option, due to
> > potential legal risks.
>
> I thought projects in incubator were not endorsed by the ASF, hence
> the ASF could not be responsible for the legal stuff in podling
> releases... Did I miss something here ?
Yes, you missed the fact that Incubator is part of ASF, and the Incubator are
doing the releases on behalf of the podling.
AFAIUI, we are responsible of the legal aspects of the releases (i.e. upstream
sources), but we have no practical responsibilities towards the downstream
users.
If the Incubator was not part of ASF, then that would be a different story...
And I think the original intent was to come into that effect, but the legal
reality is different.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How strict should podling release reviews be?
Posted by Guillaume Nodet <gn...@gmail.com>.
On 9/28/07, Bertrand Delacretaz <bd...@apache.org> wrote:
>
> What we care about is that podlings get the "legal stuff" right, and
> letting releases out without this being ok is not an option, due to
> potential legal risks.
I thought projects in incubator were not endorsed by the ASF, hence
the ASF could not be responsible for the legal stuff in podling
releases... Did I miss something here ?
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How strict should podling release reviews be?
Posted by ant elder <an...@gmail.com>.
On 9/28/07, Niclas Hedhman <ni...@hedhman.org> wrote:
>
> On Friday 28 September 2007 16:16, Bertrand Delacretaz wrote:
> > IMHO the incubator PMC doesn't care much about technical issues in
> > podling releases, at least for early releases.
>
> This is an important observation. The reviewers has no opportunity to
> figure
> out if the release at all work. That is up to the Podling, and AFAIA
> concerned, the technical quality can be non-existent.
> IMHO, the mentors are responsible together with the PPMC to bring the
> technical quality to a level expected from ASF projects. But I feel it is
> at
> that group's discretion.
> AFAIR, technical quality hasn't been a problem in the past for
> graduations.
Yes, and there is some quality expectations for real (non-incubating) Apache
releases so Incubator release reviews help podlings learn about those, past
review discussions have brought up various non-legal aspects, for example
consistent artifact naming, distributions not unzipping to the current
folder etc.
...ant
Re: How strict should podling release reviews be?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 28 September 2007 16:16, Bertrand Delacretaz wrote:
> IMHO the incubator PMC doesn't care much about technical issues in
> podling releases, at least for early releases.
This is an important observation. The reviewers has no opportunity to figure
out if the release at all work. That is up to the Podling, and AFAIA
concerned, the technical quality can be non-existent.
IMHO, the mentors are responsible together with the PPMC to bring the
technical quality to a level expected from ASF projects. But I feel it is at
that group's discretion.
AFAIR, technical quality hasn't been a problem in the past for graduations.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How strict should podling release reviews be?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 9/27/07, ant elder <an...@gmail.com> wrote:
> ...So I'm wondering if as podling releases are not endorsed by the ASF and if
> the "incubating" and the disclaimer text is everywhere as required then
> could we be a little more lenient? Maybe just note any issues so they can be
> fixed in the next release?...
Do you mean technical issues ("code does not work") or legal stuff
("notice is missing for library XYZ")?
IMHO the incubator PMC doesn't care much about technical issues in
podling releases, at least for early releases.
What we care about is that podlings get the "legal stuff" right, and
letting releases out without this being ok is not an option, due to
potential legal risks.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How strict should podling release reviews be?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 28 September 2007 15:40, ant elder wrote:
> Anyway, so i'm thinking more of a benevolent educator than traffic warden
> style reviewer role.
*My* worry is that quality will drop if there is no expectations.
So we could turn this around and say; What are the expectations from the I PMC
reviewers?
I happen to think that a smaller, new project should be given a much more
lenient treatment, than the larger projects in their 5th release cycle.
Should such distinction be ratified in policy? I don't think that is
necessary. Personal judgement is IMHO enough on a case-by-case basis.
Podlings are capable of making the review process smoother. Run RAT, publish
the result, publish the "???" and protests of RAT, plus make a small list
with explaination of why things are the way they are, just indicating that
you are on top of the issue, and I think most of us would gladly pass thru
less than perfect releases, since that shows you know what you are doing
which is more important than doing it correctly.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How strict should podling release reviews be?
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 10/3/07, ant elder <an...@gmail.com> wrote:
> On 10/2/07, Robert Burrell Donkin <ro...@gmail.com> wrote:
> >
> > On 10/2/07, Noel J. Bergman <no...@devtech.com> wrote:
> > > > i'm thinking more of a benevolent educator than traffic warden
> > > > style reviewer role.
> > >
> > > When it comes to legal issues related to a release, the warden role is
> > the
> > > more appropriate. It benefits neither the project nor the ASF if we are
> > lax
> > > in that regard.
> > >
> > > Some of the things that they need to do are identified by RAT, and would
> > be
> > > non-issues if they would correct their build process to do them
> > > automatically, e.g., inserting the license and disclaimer files where
> > they
> > > are supposed to go.
> >
> > i do believe that there's a definite problem here. there's too much
> > energy wasted by everyone.
> >
> > the IPMC cannot actively oversee the code bases without automation.
> > so, the only real oversight happens at release time. this is bad for
> > everyone. really, we need to automatically scan and analyse the
> > incubator codebases.
> >
> > i hope that http://wiki.apache.org/incubator/RatProposal may help
>
>
> That RAT proposal looks really good, its just what we need. I can't promise
> to contribute much code but i'd definitely hang around and help test it on
> things.
hopefully it will be easy to contribute in small ways without too much
effort. this is particularly important since a lot of meta-data needs
to be collected. this probably isn't feasible without active help from
contributors.
for example, a good guessing algorithm for generated files needs good
meta-data about the ways common programs mark files as generated. so
release managers can contribute by submitting new patterns whenever
RAT doesn't correctly recognize a generated file.
another example, discordia aims to collect meta-data allowing
artifacts to be matched to license meta-data. when release managers
encounter a jar (or other binary artifact unknown to discordia) they
can submit meta-data.
> Until that gets implemented (or maybe as part of its design?) could there be
> a wiki page documenting each rule RAT would check?
RAT just automates tedious checks that reviewers carry out by hand.
again, this is going to require collection of meta-data analysis rules
for automation.
> That way we could have a
> complete list of each specific requirement in one place to make it easier
> for both podlings and reviewers to check manually till RAT is done. If we
> had such a list then it could be only the things documented there are
> release blockers, or at least if a release is blocked the reason should get
> added to the list so we eventually have a fairly compressive list of the
> rules so everyone knows what to expect.
different people have different ideas about what are blockers and IMHO
this is good
i've seen very few -1's, what's much more common is for people with
criticisms to post them and not offer a vote
i would expect a -1 only if the apache policies were broken
> I'd have a go at creating such wiki page with the rules I know about if
> people think its useful but i expect others would need to help out if its
> going to get very comprehensive :)
IMHO the wiki is just a distraction: the real problem is that the
release management page is very unfinished. if there are people with
time then improving would be great. volunteers?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How strict should podling release reviews be?
Posted by Niall Pemberton <ni...@gmail.com>.
On 10/3/07, ant elder <an...@gmail.com> wrote:
> On 10/2/07, Robert Burrell Donkin <ro...@gmail.com> wrote:
> >
> > On 10/2/07, Noel J. Bergman <no...@devtech.com> wrote:
> > > > i'm thinking more of a benevolent educator than traffic warden
> > > > style reviewer role.
> > >
> > > When it comes to legal issues related to a release, the warden role is
> > the
> > > more appropriate. It benefits neither the project nor the ASF if we are
> > lax
> > > in that regard.
> > >
> > > Some of the things that they need to do are identified by RAT, and would
> > be
> > > non-issues if they would correct their build process to do them
> > > automatically, e.g., inserting the license and disclaimer files where
> > they
> > > are supposed to go.
> >
> > i do believe that there's a definite problem here. there's too much
> > energy wasted by everyone.
> >
> > the IPMC cannot actively oversee the code bases without automation.
> > so, the only real oversight happens at release time. this is bad for
> > everyone. really, we need to automatically scan and analyse the
> > incubator codebases.
> >
> > i hope that http://wiki.apache.org/incubator/RatProposal may help
>
>
> That RAT proposal looks really good, its just what we need. I can't promise
> to contribute much code but i'd definitely hang around and help test it on
> things.
>
> Until that gets implemented (or maybe as part of its design?) could there be
Its not starting from scratch - theres already been a few releases -
currently living at google code:
http://code.google.com/p/arat/
Niall
> a wiki page documenting each rule RAT would check? That way we could have a
> complete list of each specific requirement in one place to make it easier
> for both podlings and reviewers to check manually till RAT is done. If we
> had such a list then it could be only the things documented there are
> release blockers, or at least if a release is blocked the reason should get
> added to the list so we eventually have a fairly compressive list of the
> rules so everyone knows what to expect.
>
> I'd have a go at creating such wiki page with the rules I know about if
> people think its useful but i expect others would need to help out if its
> going to get very comprehensive :)
>
> ...ant
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How strict should podling release reviews be?
Posted by ant elder <an...@gmail.com>.
On 10/2/07, Robert Burrell Donkin <ro...@gmail.com> wrote:
>
> On 10/2/07, Noel J. Bergman <no...@devtech.com> wrote:
> > > i'm thinking more of a benevolent educator than traffic warden
> > > style reviewer role.
> >
> > When it comes to legal issues related to a release, the warden role is
> the
> > more appropriate. It benefits neither the project nor the ASF if we are
> lax
> > in that regard.
> >
> > Some of the things that they need to do are identified by RAT, and would
> be
> > non-issues if they would correct their build process to do them
> > automatically, e.g., inserting the license and disclaimer files where
> they
> > are supposed to go.
>
> i do believe that there's a definite problem here. there's too much
> energy wasted by everyone.
>
> the IPMC cannot actively oversee the code bases without automation.
> so, the only real oversight happens at release time. this is bad for
> everyone. really, we need to automatically scan and analyse the
> incubator codebases.
>
> i hope that http://wiki.apache.org/incubator/RatProposal may help
That RAT proposal looks really good, its just what we need. I can't promise
to contribute much code but i'd definitely hang around and help test it on
things.
Until that gets implemented (or maybe as part of its design?) could there be
a wiki page documenting each rule RAT would check? That way we could have a
complete list of each specific requirement in one place to make it easier
for both podlings and reviewers to check manually till RAT is done. If we
had such a list then it could be only the things documented there are
release blockers, or at least if a release is blocked the reason should get
added to the list so we eventually have a fairly compressive list of the
rules so everyone knows what to expect.
I'd have a go at creating such wiki page with the rules I know about if
people think its useful but i expect others would need to help out if its
going to get very comprehensive :)
...ant
Re: How strict should podling release reviews be?
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 10/2/07, Noel J. Bergman <no...@devtech.com> wrote:
> > i'm thinking more of a benevolent educator than traffic warden
> > style reviewer role.
>
> When it comes to legal issues related to a release, the warden role is the
> more appropriate. It benefits neither the project nor the ASF if we are lax
> in that regard.
>
> Some of the things that they need to do are identified by RAT, and would be
> non-issues if they would correct their build process to do them
> automatically, e.g., inserting the license and disclaimer files where they
> are supposed to go.
i do believe that there's a definite problem here. there's too much
energy wasted by everyone.
the IPMC cannot actively oversee the code bases without automation.
so, the only real oversight happens at release time. this is bad for
everyone. really, we need to automatically scan and analyse the
incubator codebases.
i hope that http://wiki.apache.org/incubator/RatProposal may help
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: How strict should podling release reviews be?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> i'm thinking more of a benevolent educator than traffic warden
> style reviewer role.
When it comes to legal issues related to a release, the warden role is the
more appropriate. It benefits neither the project nor the ASF if we are lax
in that regard.
Some of the things that they need to do are identified by RAT, and would be
non-issues if they would correct their build process to do them
automatically, e.g., inserting the license and disclaimer files where they
are supposed to go.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How strict should podling release reviews be?
Posted by ant elder <an...@gmail.com>.
On 9/28/07, Niclas Hedhman <ni...@hedhman.org> wrote:
>
> On Friday 28 September 2007 05:12, Yoav Shapira wrote:
>
> > Personally, that's my take on it, and what I've done historically.
>
> I agree with Yoav, but would like to add that I personally have different
> standards for different podlings, i.e.
>
> - The sooner one can expect graduation -> higher bar.
> - Projects with many existing ASFers in it -> higher bar.
> - Projects with high visibility outside Incubator, such as
> some ws.apache.org sponsored ones -> higher bar.
>
> One problem we are facing is that we are unable to track the "delta" of
> issues
> from one release to the next. If we could, then things would be so much
> easier.
> And don't forget, many projects are aiming for one perfect release to
> graduate...
>
> I think the end result of "rather strict than lenient" improves ASF legal
> quality over time, as these concerns will "rub off" on less than perfect
> reviews in other projects through the participation of individuals.
>
>
> Cheers
> Niclas
It sounds reasonable to make part of the graduation criteria being able to
demonstrate some competence in making releases, and thats already on the
graduation checklist in the Incubator policy and graduation guide. I know
there's no simple way to keep track of all the issues over all the releases
but that could be part of the review required when deciding how to vote on a
graduation proposal - trawling through the mailing list to see how their
releases went. So couldn't the decision on whether or not to respin a
release still be left up to the the podling anyway? If they're thinking
about graduation and its important to them to be able to demonstrate a
perfect release let them choose to respin themselves.
I'm less keen on having different standards for different projects. One of
the difficulties for incubating projects is finding out about all the
release requirements. One way i've found to do that is by looking at what
other releases do but when the same issues aren't flagged for some releases
it can be quite confusing what the actual requirements are.
Making most issues non-blocking could actually improve reviews as in some
cases it could be easier to mention an issue it if its not going to force a
respin.
Anyway, so i'm thinking more of a benevolent educator than traffic warden
style reviewer role.
...ant
Re: How strict should podling release reviews be?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 28 September 2007 05:12, Yoav Shapira wrote:
> Personally, that's my take on it, and what I've done historically.
I agree with Yoav, but would like to add that I personally have different
standards for different podlings, i.e.
- The sooner one can expect graduation -> higher bar.
- Projects with many existing ASFers in it -> higher bar.
- Projects with high visibility outside Incubator, such as
some ws.apache.org sponsored ones -> higher bar.
One problem we are facing is that we are unable to track the "delta" of issues
from one release to the next. If we could, then things would be so much
easier.
And don't forget, many projects are aiming for one perfect release to
graduate...
I think the end result of "rather strict than lenient" improves ASF legal
quality over time, as these concerns will "rub off" on less than perfect
reviews in other projects through the participation of individuals.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: How strict should podling release reviews be?
Posted by Yoav Shapira <yo...@apache.org>.
Hey,
On 9/27/07, ant elder <an...@gmail.com> wrote:
> What are people thoughts on how strict reviews should be when saying an
> issue is serious enough to block a podling release?
This is somewhat subjective, which is not bad in my book. We're all
trying to balance at least two serious considerations: the importance
of cutting releases in order to increase adoption and community, and
the importance of learning "the Apache Way," one component of which is
proper attention to licensing, notices, disclaimers, etc.
> So I'm wondering if as podling releases are not endorsed by the ASF and if
> the "incubating" and the disclaimer text is everywhere as required then
> could we be a little more lenient? Maybe just note any issues so they can be
> fixed in the next release?
Personally, that's my take on it, and what I've done historically.
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org