You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by J Aaron Farr <fa...@apache.org> on 2006/09/13 15:22:24 UTC
Podling Release Requirement (WAS: Re: [VOTE] Graduate Felix to TLP status)
On 9/13/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On 9/12/06, Niclas Hedhman <ni...@hedhman.org> wrote:
> > As Leo pointed out, 'codebase quality' is not a graduation criteria. And
> > (hopefully) with Upayvira as the initial PMC Chair, I am not worried that the
> > PMC will overlook release requirements. If ASF Members feel that to be a
> > concern, they are both free to monitor and participate in the PMC work.
>
> My concern has nothing to do with 'codebase quality', but asking for a
> demonstration that the Felix community understands how to conduct a
> release that meets the ASF's criteria.
>
> If the community produces a release that is perfect on first shot,
> great - they're truly ready to graduate. If not, well, then, they'll
> learn from those mistakes and once they can produce a release that
> meets our criteria, then they'll be ready to graduate.
>
> Remember that a major task for a TLP is conducting a release.
> Therefore, it's reasonable for the Incubator PMC to ask for proof that
> they will execute that task successfully rather than taking it on
> blind faith. -- justin
And I'm fine with that. I think it's a good idea for Incubating
projects to do at least one release before graduating.
My concerns are:
1) The policy regarding podling releases has never been explicit and
always been conflicting
2) Let's not (again) fall into the trap of changing the requirements
of graduation (or entry for that matter) on a vote thread
So could we move these discussions to a new thread?
--
jaaron
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Re: Podling Release Requirement
Posted by robert burrell donkin <ro...@gmail.com>.
On 9/15/06, Daniel Kulp <da...@iona.com> wrote:
> On Wednesday September 13 2006 3:22 pm, Leo Simons wrote:
> > You know my incubator mantra (well maybe not), "Simpler rules, more
> > clarity".
> >
> > For example, we instate a rule
> >
> > "Podlings should do a release while in incubation that satisfies all the
> > generic ASF release policy guidelines and criteria (in particular legal
> > ones) as well as all the incubator-specific rules."
> >
> > that is simple, clear, and easily verifiable (in so far as those policies
> > and rules are simple and clear). Its also rather different from what we
> > said in the past.
>
> I'm not sure I would go so far as requiring a full release. I think the rule
> would be:
>
> "Podlings should produce a release candidate while in incubation that
> satisfies all the generic ASF release policy guidelines and criteria (in
> particular legal ones) as well as all the incubator-specific rules. The
> candidate should be presented to the incubator PMC for verification and
> approval, but the podling will not be required to release such candidate."
>
> Basically, get things "ready" while in the incubator and show the process is
> understood, but allow it to be fully released after graduation when
> the "incubator" branding can be removed if the PPMC of the podling thinks
> that's best for their project.
+1
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling Release Requirement
Posted by Daniel Kulp <da...@iona.com>.
On Wednesday September 13 2006 3:22 pm, Leo Simons wrote:
> You know my incubator mantra (well maybe not), "Simpler rules, more
> clarity".
>
> For example, we instate a rule
>
> "Podlings should do a release while in incubation that satisfies all the
> generic ASF release policy guidelines and criteria (in particular legal
> ones) as well as all the incubator-specific rules."
>
> that is simple, clear, and easily verifiable (in so far as those policies
> and rules are simple and clear). Its also rather different from what we
> said in the past.
I'm not sure I would go so far as requiring a full release. I think the rule
would be:
"Podlings should produce a release candidate while in incubation that
satisfies all the generic ASF release policy guidelines and criteria (in
particular legal ones) as well as all the incubator-specific rules. The
candidate should be presented to the incubator PMC for verification and
approval, but the podling will not be required to release such candidate."
Basically, get things "ready" while in the incubator and show the process is
understood, but allow it to be fully released after graduation when
the "incubator" branding can be removed if the PPMC of the podling thinks
that's best for their project.
That's my non-binding opinion. :-)
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194 F:781-902-8001
daniel.kulp@iona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling Release Requirement
Posted by Leo Simons <ma...@leosimons.com>.
On Wed, Sep 13, 2006 at 02:05:08PM -0400, Noel J. Bergman wrote:
> So the real question, in my view, is whether or not they demonstrate an
> awareness that there ARE issues, and that they may CHANGE, and are being
> RESPONSIBLE about making sure that what they do is in compliance with ASF
> policy at the time.
+1. Well said.
> So, how do we go about deciding whether or not a given project has so
> demonstrated this characteristic? Do we need to make a rule for how we
> determine it, or just make sure that the question is asked and answered to
> our satisfaction?
You know my incubator mantra (well maybe not), "Simpler rules, more clarity".
For example, we instate a rule
"Podlings should do a release while in incubation that satisfies all the
generic ASF release policy guidelines and criteria (in particular legal
ones) as well as all the incubator-specific rules."
that is simple, clear, and easily verifiable (in so far as those policies and
rules are simple and clear). Its also rather different from what we said in
the past.
LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
[REVOKED] Felix Gradutation Vote (was Re: Podling Release Requirement)
Posted by Upayavira <uv...@odoko.co.uk>.
Based upon the below feedback from Justin, the Felix PPMC have agreed
that there is additional work to be done on Felix before the project is
ready for graduation, including making a release so as to clarify issues
that the release process throws up.
On that basis, I revoke the graduation vote for Felix until such a time
as we have resolved any outstanding issues.
Regards, Upayavira
Justin Erenkrantz wrote:
> On 9/13/06, Upayavira <uv...@odoko.co.uk> wrote:
>> So how does Felix proceed now? Accept that the rules have just changed
>> on it, after spending some months under the view that a release _wasn't_
>> necessary to graduation, and go back and do something it would have done
>> months ago had it not been told to do otherwise?
>
> The issue, as I see it, is that the Incubator PMC is being asked to
> certify that the Felix PPMC is able to manage itself as a top-level
> project. A critical activity of a PMC is to conduct a release.
> Another point with conducting a release while in the Incubator is that
> it generally flags any legal issues as people check it. So when a
> PPMC decides not to conduct a release and asks to graduate immediately
> as a TLP, we needs to be doubly sure that the due diligence has been
> completed. Hence, it's fair to expect probing questions - especially
> when the last status report indicated that a release was forthcoming.
>
> First off, Felix doesn't seem to have a NOTICE or LICENSE files in its
> trunk (hint: it's in the wrong directory and in the wrong format), nor
> does Felix have the appropriate license blocks (hint: see
> http://www.apache.org/legal/src-headers.html).
>
> Based on a quick superficial glance, I also see files in the tree that
> aren't ours, such as:
>
> http://svn.apache.org/repos/asf/incubator/felix/trunk/http.jetty/src/main/java/org/osgi/service/http/HttpContext.java
>
>
> Yes, it's licensed under the ALv2, but AFAICT, there is no documented
> provenance for these files: it bears a CVS tag and refers to the OSGi
> Alliance as the copyright owner. We should be citing that in the
> LICENSE and NOTICE files. Instead, all I see in FELIX-9
> (https://issues.apache.org/jira/browse/FELIX-9) is a discussion that
> some code should be donated - no reference is made in the file or
> commit message or JIRA as to where it came from. It sounds like there
> might be an IP clearance form on file somewhere if this code was
> donated - then those copyright blocks can go away in favor of our
> standard one. If we don't have clearance, then we have to make sure
> that we do not ever remove that license block in those files. But, if
> we make any changes to those files, then our license block needs to be
> added as well.
>
> It also seems that Felix has forked Tomcat's servlet code - which is okay:
>
> http://svn.apache.org/repos/asf/incubator/felix/trunk/javax.servlet/src/main/java/javax/servlet/GenericServlet.java
>
>
> However, the copyright years have been altered from the original file
> - removing 2004 and adding 2005 - which isn't okay:
>
> http://svn.apache.org/repos/asf/tomcat/servletapi/branches/servlet2.3-jsp1.2-tc4.x/src/share/javax/servlet/GenericServlet.java
>
>
> (Ideally, Felix should resync with Tomcat once they update their
> license block to remove the copyright years; but Tomcat may not be
> updating Servlet 2.3. I'm unsure if an ASF project can relicense
> forked code from another project - I'll ask on legal-discuss@...)
>
> These instances cause my antennae to be raised to there being more
> issues throughout the Felix codebase. I don't believe these are
> serious issues at all, but these are issues that must be cleaned up
> before graduation should be considered. (I don't have the time to do
> a more thorough review: that's the job of the Felix PPMC.)
>
> Finally, as Noel pointed out, we have not seen a proposed Felix PMC
> roster or who the PMC chair will be. The Board requires that before
> even placing such an item on its agenda.
>
> HTH. -- justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Tomcat's servlet code in Felix (WAS: Re: Podling Release Requirement)
Posted by Upayavira <uv...@odoko.co.uk>.
Richard S. Hall wrote:
>
>> Justin Erenkrantz wrote:
>>
>>> It also seems that Felix has forked Tomcat's servlet code - which is
>>> okay:
>>>
>>> http://svn.apache.org/repos/asf/incubator/felix/trunk/javax.servlet/src/main/java/javax/servlet/GenericServlet.java
>>>
>>>
>>> However, the copyright years have been altered from the original file
>>> - removing 2004 and adding 2005 - which isn't okay:
>>>
>>> http://svn.apache.org/repos/asf/tomcat/servletapi/branches/servlet2.3-jsp1.2-tc4.x/src/share/javax/servlet/GenericServlet.java
>>>
>>>
>>>
>>> (Ideally, Felix should resync with Tomcat once they update their
>>> license block to remove the copyright years; but Tomcat may not be
>>> updating Servlet 2.3. I'm unsure if an ASF project can relicense
>>> forked code from another project - I'll ask on legal-discuss@...)
>>>
>
> I am a little confused as to the exact solution to Felix' use of
> Tomcat's javax.servlet code.
>
> The reason why the copyright was changed is because the subproject is a
> derivative work based on Tomcat's javax.servlet 2.4 code. The subproject
> downgraded javax.servlet 2.4 to 2.1, which is the version used by the
> OSGi HTTP Service. BJ Hargrave did the downgrade and said he used the
> servlet 2.4 code because it was licensed under Apache license v2, where
> servlet 2.3 and older was under Apache license v1.
>
> Because servlet 2.1 is required, I doubt there will ever be a re-syncing
> of code with Tomcat.
>
> So, what is the appropriate thing to do here? Leave the header unchanged
> or to change it? If we are not supposed to change it, then we can easily
> revert to the old header, but it seems misleading since we modified it.
> If we are supposed to change it, then I imagine we should change it to
> reflect the header at http://www.apache.org/legal/src-headers.html.
>
> Clarification is desired.
Or, should we dig an ASL 1 licensed tomcat servlet spec from SVN/CVS and
relicense it as AL2.0?
Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Tomcat's servlet code in Felix (WAS: Re: Podling Release Requirement)
Posted by "Richard S. Hall" <he...@ungoverned.org>.
> Justin Erenkrantz wrote:
>
>> It also seems that Felix has forked Tomcat's servlet code - which is okay:
>>
>> http://svn.apache.org/repos/asf/incubator/felix/trunk/javax.servlet/src/main/java/javax/servlet/GenericServlet.java
>>
>> However, the copyright years have been altered from the original file
>> - removing 2004 and adding 2005 - which isn't okay:
>>
>> http://svn.apache.org/repos/asf/tomcat/servletapi/branches/servlet2.3-jsp1.2-tc4.x/src/share/javax/servlet/GenericServlet.java
>>
>>
>> (Ideally, Felix should resync with Tomcat once they update their
>> license block to remove the copyright years; but Tomcat may not be
>> updating Servlet 2.3. I'm unsure if an ASF project can relicense
>> forked code from another project - I'll ask on legal-discuss@...)
>>
I am a little confused as to the exact solution to Felix' use of
Tomcat's javax.servlet code.
The reason why the copyright was changed is because the subproject is a
derivative work based on Tomcat's javax.servlet 2.4 code. The subproject
downgraded javax.servlet 2.4 to 2.1, which is the version used by the
OSGi HTTP Service. BJ Hargrave did the downgrade and said he used the
servlet 2.4 code because it was licensed under Apache license v2, where
servlet 2.3 and older was under Apache license v1.
Because servlet 2.1 is required, I doubt there will ever be a re-syncing
of code with Tomcat.
So, what is the appropriate thing to do here? Leave the header unchanged
or to change it? If we are not supposed to change it, then we can easily
revert to the old header, but it seems misleading since we modified it.
If we are supposed to change it, then I imagine we should change it to
reflect the header at http://www.apache.org/legal/src-headers.html.
Clarification is desired.
-> richard
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling Release Requirement (WAS: Re: [VOTE] Graduate Felix to
TLP status)
Posted by Upayavira <uv...@odoko.co.uk>.
Justin Erenkrantz wrote:
> On 9/13/06, Upayavira <uv...@odoko.co.uk> wrote:
>> So how does Felix proceed now? Accept that the rules have just changed
>> on it, after spending some months under the view that a release _wasn't_
>> necessary to graduation, and go back and do something it would have done
>> months ago had it not been told to do otherwise?
>
> The issue, as I see it, is that the Incubator PMC is being asked to
> certify that the Felix PPMC is able to manage itself as a top-level
> project. A critical activity of a PMC is to conduct a release.
> Another point with conducting a release while in the Incubator is that
> it generally flags any legal issues as people check it. So when a
> PPMC decides not to conduct a release and asks to graduate immediately
> as a TLP, we needs to be doubly sure that the due diligence has been
> completed. Hence, it's fair to expect probing questions - especially
> when the last status report indicated that a release was forthcoming.
>
> First off, Felix doesn't seem to have a NOTICE or LICENSE files in its
> trunk (hint: it's in the wrong directory and in the wrong format), nor
> does Felix have the appropriate license blocks (hint: see
> http://www.apache.org/legal/src-headers.html).
>
> Based on a quick superficial glance, I also see files in the tree that
> aren't ours, such as:
>
> http://svn.apache.org/repos/asf/incubator/felix/trunk/http.jetty/src/main/java/org/osgi/service/http/HttpContext.java
>
> Yes, it's licensed under the ALv2, but AFAICT, there is no documented
> provenance for these files: it bears a CVS tag and refers to the OSGi
> Alliance as the copyright owner. We should be citing that in the
> LICENSE and NOTICE files. Instead, all I see in FELIX-9
> (https://issues.apache.org/jira/browse/FELIX-9) is a discussion that
> some code should be donated - no reference is made in the file or
> commit message or JIRA as to where it came from. It sounds like there
> might be an IP clearance form on file somewhere if this code was
> donated - then those copyright blocks can go away in favor of our
> standard one. If we don't have clearance, then we have to make sure
> that we do not ever remove that license block in those files. But, if
> we make any changes to those files, then our license block needs to be
> added as well.
>
> It also seems that Felix has forked Tomcat's servlet code - which is okay:
>
> http://svn.apache.org/repos/asf/incubator/felix/trunk/javax.servlet/src/main/java/javax/servlet/GenericServlet.java
>
> However, the copyright years have been altered from the original file
> - removing 2004 and adding 2005 - which isn't okay:
>
> http://svn.apache.org/repos/asf/tomcat/servletapi/branches/servlet2.3-jsp1.2-tc4.x/src/share/javax/servlet/GenericServlet.java
>
>
> (Ideally, Felix should resync with Tomcat once they update their
> license block to remove the copyright years; but Tomcat may not be
> updating Servlet 2.3. I'm unsure if an ASF project can relicense
> forked code from another project - I'll ask on legal-discuss@...)
>
> These instances cause my antennae to be raised to there being more
> issues throughout the Felix codebase. I don't believe these are
> serious issues at all, but these are issues that must be cleaned up
> before graduation should be considered. (I don't have the time to do
> a more thorough review: that's the job of the Felix PPMC.)
Thank you for your comments. This now is clearly enough feedback to show
that we've got more work to do.
I will recall the vote until we have done a release in order to clear up
the sort, and have shown that release to the incubator PMC.
> Finally, as Noel pointed out, we have not seen a proposed Felix PMC
> roster or who the PMC chair will be. The Board requires that before
> even placing such an item on its agenda.
That part is easy, and I agree that not mentioning the proposed PMC
chair was an omission. We've already discussed (and voted on) the issue,
and plan to follow the Jackrabbit model - I would be the initial PMC
chair. I will then be grooming Richard Hall to take over the role, as he
is clearly the best suited individual for the job - just needs more
experience of working within an ASF environment (don't we all, but
that's another question :-) )
Regards, Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling Release Requirement (WAS: Re: [VOTE] Graduate Felix to TLP status)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 9/13/06, Upayavira <uv...@odoko.co.uk> wrote:
> So how does Felix proceed now? Accept that the rules have just changed
> on it, after spending some months under the view that a release _wasn't_
> necessary to graduation, and go back and do something it would have done
> months ago had it not been told to do otherwise?
The issue, as I see it, is that the Incubator PMC is being asked to
certify that the Felix PPMC is able to manage itself as a top-level
project. A critical activity of a PMC is to conduct a release.
Another point with conducting a release while in the Incubator is that
it generally flags any legal issues as people check it. So when a
PPMC decides not to conduct a release and asks to graduate immediately
as a TLP, we needs to be doubly sure that the due diligence has been
completed. Hence, it's fair to expect probing questions - especially
when the last status report indicated that a release was forthcoming.
First off, Felix doesn't seem to have a NOTICE or LICENSE files in its
trunk (hint: it's in the wrong directory and in the wrong format), nor
does Felix have the appropriate license blocks (hint: see
http://www.apache.org/legal/src-headers.html).
Based on a quick superficial glance, I also see files in the tree that
aren't ours, such as:
http://svn.apache.org/repos/asf/incubator/felix/trunk/http.jetty/src/main/java/org/osgi/service/http/HttpContext.java
Yes, it's licensed under the ALv2, but AFAICT, there is no documented
provenance for these files: it bears a CVS tag and refers to the OSGi
Alliance as the copyright owner. We should be citing that in the
LICENSE and NOTICE files. Instead, all I see in FELIX-9
(https://issues.apache.org/jira/browse/FELIX-9) is a discussion that
some code should be donated - no reference is made in the file or
commit message or JIRA as to where it came from. It sounds like there
might be an IP clearance form on file somewhere if this code was
donated - then those copyright blocks can go away in favor of our
standard one. If we don't have clearance, then we have to make sure
that we do not ever remove that license block in those files. But, if
we make any changes to those files, then our license block needs to be
added as well.
It also seems that Felix has forked Tomcat's servlet code - which is okay:
http://svn.apache.org/repos/asf/incubator/felix/trunk/javax.servlet/src/main/java/javax/servlet/GenericServlet.java
However, the copyright years have been altered from the original file
- removing 2004 and adding 2005 - which isn't okay:
http://svn.apache.org/repos/asf/tomcat/servletapi/branches/servlet2.3-jsp1.2-tc4.x/src/share/javax/servlet/GenericServlet.java
(Ideally, Felix should resync with Tomcat once they update their
license block to remove the copyright years; but Tomcat may not be
updating Servlet 2.3. I'm unsure if an ASF project can relicense
forked code from another project - I'll ask on legal-discuss@...)
These instances cause my antennae to be raised to there being more
issues throughout the Felix codebase. I don't believe these are
serious issues at all, but these are issues that must be cleaned up
before graduation should be considered. (I don't have the time to do
a more thorough review: that's the job of the Felix PPMC.)
Finally, as Noel pointed out, we have not seen a proposed Felix PMC
roster or who the PMC chair will be. The Board requires that before
even placing such an item on its agenda.
HTH. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
[howto] felix fast forward (was: Re: Podling Release Requirement)
Posted by Leo Simons <ma...@leosimons.com>.
On Thu, Sep 14, 2006 at 04:00:37AM +0100, Upayavira wrote:
> Justin Erenkrantz wrote:
> > On 9/13/06, robert burrell donkin <ro...@gmail.com> wrote:
> >> personally speaking, i would not support the gradudation any project
> >> that has not demonstrated that they understand the apache releases
> >> policy. doing this is much easier and quicker than creating a proper
> >> release. just nominate a release manager and post a compliant example
> >> to the people.apache.org webspace using the current code base so that
> >> it can be checked.
> >
> > +1 - though I would strongly like to see the community *vote* on the
> > release because I see many ASF projects completely skipping that part
> > nowadays. -- justin
>
> So how does Felix proceed now? Accept that the rules have just changed
> on it, after spending some months under the view that a release _wasn't_
> necessary to graduation, and go back and do something it would have done
> months ago had it not been told to do otherwise?
The rules have not changed. In order to graduate you need votes by the
incubator PMC, some of whom have expressed some conditionals for a +1. You're
not likely to get the requisite amount of +1s, probably because the silent
majority of the people with votes to cast think there's merit to the
conditionals.
As this thread shows, actually having a release is not the "real"
conditional, the conditional is having done all those things properly that
are normally double-checked during a release process. And those things being
ok *is* required, and that has been the case for ages.
Basically felix doesn't quite have its legal agenda in order (Justin just
listed a few problems, others listed earlier ones before, with enough
examples to show a "legal audit" has not been done), therefore the felix
status file does not quite reflect reality (it seems to assert there are
no problems).
> Upayavira (who is expressing his frustration on behalf of all Felix folks)
>
> P.S. Though expressed with some irony and irritation, it is in fact a
> real question.
I can imagine a few ways going forward.
First, send an e-mail on the [VOTE] thread that its cancelled as you take
care of a few things.
I suggest you take a good critical look at all your source files, establish
provenance, ownership, licenses, copyright, etc, for each of them, and then
based on that information and the various legal policies we have around here
go and fix everything, including making sure your build process does the
right things to legal files. Once done, write a little report that lists all
the different things you fixed and let that bubble up somehow, eg send the
incubator PMC a little status report. Make sure to assert there's no further
problems.
If you want a detailed example of taking care of all the legal things precisely
and properly, I'd suggest looking at the harmony podling, which is probably the
one of the cleanest (legally!) open source project on the planet.
Then, send a heads-up ("[PROPOSAL]" would do) to this mailing list that
you'll be requesting graduation in a bit and whether anyone sees any
outstanding things to worry about. After taking care of those concerns, start
a new series of [VOTE]s.
"you" in the above does not mean "you, upayavira", but "you, felix community".
Being a contributor to apache means being and staying aware and on top of this
kind of legal stuff, annoying as it all is. Blame the screwed up legal systems
of the world and the IP sharks that abuse it, not the people helping you to
stay safe.
cheers,
Leo
PS: Irony and irritation is not the best way to get a useful answer. I could
find it irritating that a bunch of ASF members that are on the felix PPMC
have not paid more attention to dotting legal i's and crossing legal t's,
or that an incubator PMC member goes around venting irritation in public.
If the incubator PMC is not functioning the way you want it to, you know
exactly what to do to change it. In the meantime, I suggest a more open-minded
approach to it all.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling Release Requirement (WAS: Re: [VOTE] Graduate Felix to
TLP status)
Posted by Upayavira <uv...@odoko.co.uk>.
Justin Erenkrantz wrote:
> On 9/13/06, robert burrell donkin <ro...@gmail.com> wrote:
>> personally speaking, i would not support the gradudation any project
>> that has not demonstrated that they understand the apache releases
>> policy. doing this is much easier and quicker than creating a proper
>> release. just nominate a release manager and post a compliant example
>> to the people.apache.org webspace using the current code base so that
>> it can be checked.
>
> +1 - though I would strongly like to see the community *vote* on the
> release because I see many ASF projects completely skipping that part
> nowadays. -- justin
So how does Felix proceed now? Accept that the rules have just changed
on it, after spending some months under the view that a release _wasn't_
necessary to graduation, and go back and do something it would have done
months ago had it not been told to do otherwise?
Upayavira (who is expressing his frustration on behalf of all Felix folks)
P.S. Though expressed with some irony and irritation, it is in fact a
real question.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling Release Requirement (WAS: Re: [VOTE] Graduate Felix to
TLP status)
Posted by Alex Karasulu <ao...@bellsouth.net>.
Justin Erenkrantz wrote:
> On 9/13/06, robert burrell donkin <ro...@gmail.com> wrote:
>> personally speaking, i would not support the gradudation any project
>> that has not demonstrated that they understand the apache releases
>> policy. doing this is much easier and quicker than creating a proper
>> release. just nominate a release manager and post a compliant example
>> to the people.apache.org webspace using the current code base so that
>> it can be checked.
>
> +1 - though I would strongly like to see the community *vote* on the
> release because I see many ASF projects completely skipping that part
> nowadays. -- justin
>
Yeah I think we should just freeze the Felix vote and try for a real
release. It's well worth going through the entire process completely.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling Release Requirement (WAS: Re: [VOTE] Graduate Felix to TLP status)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 9/13/06, robert burrell donkin <ro...@gmail.com> wrote:
> personally speaking, i would not support the gradudation any project
> that has not demonstrated that they understand the apache releases
> policy. doing this is much easier and quicker than creating a proper
> release. just nominate a release manager and post a compliant example
> to the people.apache.org webspace using the current code base so that
> it can be checked.
+1 - though I would strongly like to see the community *vote* on the
release because I see many ASF projects completely skipping that part
nowadays. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling Release Requirement (WAS: Re: [VOTE] Graduate Felix to TLP status)
Posted by robert burrell donkin <ro...@gmail.com>.
On 9/13/06, Craig L Russell <Cr...@sun.com> wrote:
> On Sep 13, 2006, at 10:24 AM, robert burrell donkin wrote:
<snip>
> > since we started checking releases in detail, it's become clear that
> > most projects struggle to create a compliant release at the first
> > attempt. nearly every first attempt checked turns out not be
> > compliant. i didn't expect this (since the rules are really pretty
> > simple).
>
> I only slightly beg to differ over Robert's characterization of the
> Apache release rules as "simple". Not.
it's the lack of rules that causes the difficulty - nearly everything
written about releases is neither policy nor rules. there are so few
rules that many projects feel the need to create more process for
themselves.
formal rules:
1 every official release must be approved by the project responsible
for the code
policy:
1 all source files must have license headers
2 all dependencies shipped must have approved licenses
3 all released artifacts must contain LICENSE and NOTICE files
4 all released artifacts must have signatures and checksums
the interpretation of these rules and policies changes from time to
time and application of these in borderline cases can be difficult.
however, the principles have changed rarely.
there are quite a lot more guidelines which are not quite policy.
projects that do not follow these may become unpopular with the
infrastructure team. but they are neither policy nor rules.
there are lots and lots of traditions, conventions and practices which
are neither guidelines, policy nor formal rules. there is a lot to be
said for learning from other people's mistakes and i would hope that
(once they are written down and collated) projects would elect to
adopt a lot of these practices but they are free to adopt any or none
as they choose.
when i review a release i try to indicate which category each point falls into.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling Release Requirement (WAS: Re: [VOTE] Graduate Felix to TLP
status)
Posted by Craig L Russell <Cr...@Sun.COM>.
On Sep 13, 2006, at 10:24 AM, robert burrell donkin wrote:
> On 9/13/06, Alex Karasulu <ao...@bellsouth.net> wrote:
>> J Aaron Farr wrote:
>> > On 9/13/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
>> >> On 9/12/06, Niclas Hedhman <ni...@hedhman.org> wrote:
>> >> > As Leo pointed out, 'codebase quality' is not a graduation
>> criteria.
>> >> And
>> >> > (hopefully) with Upayvira as the initial PMC Chair, I am not
>> worried
>> >> that the
>> >> > PMC will overlook release requirements. If ASF Members feel
>> that to
>> >> be a
>> >> > concern, they are both free to monitor and participate in the
>> PMC work.
>> >>
>> >> My concern has nothing to do with 'codebase quality', but
>> asking for a
>> >> demonstration that the Felix community understands how to
>> conduct a
>> >> release that meets the ASF's criteria.
>> >>
>> >> If the community produces a release that is perfect on first shot,
>> >> great - they're truly ready to graduate. If not, well, then,
>> they'll
>> >> learn from those mistakes and once they can produce a release that
>> >> meets our criteria, then they'll be ready to graduate.
>> >>
>> >> Remember that a major task for a TLP is conducting a release.
>> >> Therefore, it's reasonable for the Incubator PMC to ask for
>> proof that
>> >> they will execute that task successfully rather than taking it on
>> >> blind faith. -- justin
>> >
>> > And I'm fine with that. I think it's a good idea for Incubating
>> > projects to do at least one release before graduating.
>> >
>> > My concerns are:
>> >
>> > 1) The policy regarding podling releases has never been explicit
>> and
>> > always been conflicting
>
> the formal policy
> (http://incubator.apache.org/incubation/
> Incubation_Policy.html#Releases)
> isn't too bad (though i have tidied up the verbage surrounding it
> recently).
>
> the sentiment towards releases has definitely changed as we've leant
> more about the process. the PMC is now agnostic rather than
> antagonistics.
>
>> Originally we (the mentors) and even Noel had told Felix not to worry
>> about a release within the incubator:
>>
>> http://mail-archives.apache.org/mod_mbox/incubator-felix-dev/
>> 200604.mbox/%3cNBBBJGEAGJAKLIDBKJOPAEIPHMAC.noel@devtech.com%3e
>>
>> So both mentors and the Incubator PMC Chair told these folks that a
>> release was not the primary objective for graduation. We explicitly
>> told them *NOT* to worry about a release until after graduation. And
>> graduation, we thought, was right around the corner.
>
> i agree that releases should not be a primary objective for
> graduation.
+1
>
> IMO the question is not about performing a release (which is high
> ceremony) but about knowing how to perform a release that complies
> with ASF policy.
+1
>
> since we started checking releases in detail, it's become clear that
> most projects struggle to create a compliant release at the first
> attempt. nearly every first attempt checked turns out not be
> compliant. i didn't expect this (since the rules are really pretty
> simple).
I only slightly beg to differ over Robert's characterization of the
Apache release rules as "simple". Not.
>
>> > 2) Let's not (again) fall into the trap of changing the
>> requirements
>> > of graduation (or entry for that matter) on a vote thread
>> >
>> > So could we move these discussions to a new thread?
>>
>> Yeah good idea. Let's start off by discussing whether we make at
>> least
>> one incubator release a requirement for graduation? I think if we're
>> going to hold it as a blocker before graduation we must make it a
>> rule
>> to be absolutely clear.
>
> i do not think that having made a release should be a requirement;
+1
>
> personally speaking, i would not support the gradudation any project
> that has not demonstrated that they understand the apache releases
> policy. doing this is much easier and quicker than creating a proper
> release. just nominate a release manager and post a compliant example
> to the people.apache.org webspace using the current code base so that
> it can be checked.
Having struggled through the release process outside the incubator,
I can attest to the value that the incubator PMC brings to the
process. I'd support changing the incubator process to encourage
"what Robert said". That is, as a requirement (recommendation?) for
graduation, have the podling nominate a release manager, have her
build a candidate release that conforms to Apache policy, and post
it for review.
Craig
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
RE: Podling Release Requirement (WAS: Re: [VOTE] Graduate Felix to TLP status)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Robert Burrell Donkin wrote:
> IMO the question is not about performing a release (which is high
> ceremony) but about knowing how to perform a release that complies
> with ASF policy.
And, as I noted in my Felix-specific reply, over the past few years, we have
changed licensing, copyright notice, and other requirements at least twice.
Existing projects need to change, not just those in the Incubator. All
Release Managers have to keep abreast of current ASF policy, and PMCs have
to ensure that they implement it properly, and check with the Board and/or
VP Legal if there are questions.
So the real question, in my view, is whether or not they demonstrate an
awareness that there ARE issues, and that they may CHANGE, and are being
RESPONSIBLE about making sure that what they do is in compliance with ASF
policy at the time. Being a good ASF participant is about community, not
static rules compliance.
So, how do we go about deciding whether or not a given project has so
demonstrated this characteristic? Do we need to make a rule for how we
determine it, or just make sure that the question is asked and answered to
our satisfaction?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling Release Requirement (WAS: Re: [VOTE] Graduate Felix to TLP status)
Posted by robert burrell donkin <ro...@gmail.com>.
On 9/13/06, Alex Karasulu <ao...@bellsouth.net> wrote:
> J Aaron Farr wrote:
> > On 9/13/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> >> On 9/12/06, Niclas Hedhman <ni...@hedhman.org> wrote:
> >> > As Leo pointed out, 'codebase quality' is not a graduation criteria.
> >> And
> >> > (hopefully) with Upayvira as the initial PMC Chair, I am not worried
> >> that the
> >> > PMC will overlook release requirements. If ASF Members feel that to
> >> be a
> >> > concern, they are both free to monitor and participate in the PMC work.
> >>
> >> My concern has nothing to do with 'codebase quality', but asking for a
> >> demonstration that the Felix community understands how to conduct a
> >> release that meets the ASF's criteria.
> >>
> >> If the community produces a release that is perfect on first shot,
> >> great - they're truly ready to graduate. If not, well, then, they'll
> >> learn from those mistakes and once they can produce a release that
> >> meets our criteria, then they'll be ready to graduate.
> >>
> >> Remember that a major task for a TLP is conducting a release.
> >> Therefore, it's reasonable for the Incubator PMC to ask for proof that
> >> they will execute that task successfully rather than taking it on
> >> blind faith. -- justin
> >
> > And I'm fine with that. I think it's a good idea for Incubating
> > projects to do at least one release before graduating.
> >
> > My concerns are:
> >
> > 1) The policy regarding podling releases has never been explicit and
> > always been conflicting
the formal policy
(http://incubator.apache.org/incubation/Incubation_Policy.html#Releases)
isn't too bad (though i have tidied up the verbage surrounding it
recently).
the sentiment towards releases has definitely changed as we've leant
more about the process. the PMC is now agnostic rather than
antagonistics.
> Originally we (the mentors) and even Noel had told Felix not to worry
> about a release within the incubator:
>
> http://mail-archives.apache.org/mod_mbox/incubator-felix-dev/200604.mbox/%3cNBBBJGEAGJAKLIDBKJOPAEIPHMAC.noel@devtech.com%3e
>
> So both mentors and the Incubator PMC Chair told these folks that a
> release was not the primary objective for graduation. We explicitly
> told them *NOT* to worry about a release until after graduation. And
> graduation, we thought, was right around the corner.
i agree that releases should not be a primary objective for graduation.
IMO the question is not about performing a release (which is high
ceremony) but about knowing how to perform a release that complies
with ASF policy.
since we started checking releases in detail, it's become clear that
most projects struggle to create a compliant release at the first
attempt. nearly every first attempt checked turns out not be
compliant. i didn't expect this (since the rules are really pretty
simple).
> > 2) Let's not (again) fall into the trap of changing the requirements
> > of graduation (or entry for that matter) on a vote thread
> >
> > So could we move these discussions to a new thread?
>
> Yeah good idea. Let's start off by discussing whether we make at least
> one incubator release a requirement for graduation? I think if we're
> going to hold it as a blocker before graduation we must make it a rule
> to be absolutely clear.
i do not think that having made a release should be a requirement;
personally speaking, i would not support the gradudation any project
that has not demonstrated that they understand the apache releases
policy. doing this is much easier and quicker than creating a proper
release. just nominate a release manager and post a compliant example
to the people.apache.org webspace using the current code base so that
it can be checked.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling Release Requirement (WAS: Re: [VOTE] Graduate Felix to
TLP status)
Posted by Alex Karasulu <ao...@bellsouth.net>.
J Aaron Farr wrote:
> On 9/13/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
>> On 9/12/06, Niclas Hedhman <ni...@hedhman.org> wrote:
>> > As Leo pointed out, 'codebase quality' is not a graduation criteria.
>> And
>> > (hopefully) with Upayvira as the initial PMC Chair, I am not worried
>> that the
>> > PMC will overlook release requirements. If ASF Members feel that to
>> be a
>> > concern, they are both free to monitor and participate in the PMC work.
>>
>> My concern has nothing to do with 'codebase quality', but asking for a
>> demonstration that the Felix community understands how to conduct a
>> release that meets the ASF's criteria.
>>
>> If the community produces a release that is perfect on first shot,
>> great - they're truly ready to graduate. If not, well, then, they'll
>> learn from those mistakes and once they can produce a release that
>> meets our criteria, then they'll be ready to graduate.
>>
>> Remember that a major task for a TLP is conducting a release.
>> Therefore, it's reasonable for the Incubator PMC to ask for proof that
>> they will execute that task successfully rather than taking it on
>> blind faith. -- justin
>
> And I'm fine with that. I think it's a good idea for Incubating
> projects to do at least one release before graduating.
>
> My concerns are:
>
> 1) The policy regarding podling releases has never been explicit and
> always been conflicting
Originally we (the mentors) and even Noel had told Felix not to worry
about a release within the incubator:
http://mail-archives.apache.org/mod_mbox/incubator-felix-dev/200604.mbox/%3cNBBBJGEAGJAKLIDBKJOPAEIPHMAC.noel@devtech.com%3e
So both mentors and the Incubator PMC Chair told these folks that a
release was not the primary objective for graduation. We explicitly
told them *NOT* to worry about a release until after graduation. And
graduation, we thought, was right around the corner.
> 2) Let's not (again) fall into the trap of changing the requirements
> of graduation (or entry for that matter) on a vote thread
>
> So could we move these discussions to a new thread?
Yeah good idea. Let's start off by discussing whether we make at least
one incubator release a requirement for graduation? I think if we're
going to hold it as a blocker before graduation we must make it a rule
to be absolutely clear.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org