Re: IP Clearance before releasing
On Thu, Dec 12, 2013 at 12:20 AM, Upayavira wrote: > We should probably be clear about *who* can relax the rules, because > again this could become a fighting ground amongst 180 of us. Perhaps we can avert potential disputes by blocking graduation rather than releases. Every review item in the following checklist is either required by Incubator policy or is documented outside the Incubator as required for all Apache releases: http://incubator.apache.org/guides/release_manifest.txt http://incubator.apache.org/guides/release.html#review-items Let's say that we start allowing more documented exceptions to the rules for incubating releases. Fine -- but the podling still needs to demonstrate that they can make a release worthy of a TLP, or they shouldn't graduate. The simple approach is to establish a policy that a podling must make a release which passes all the checklist items. I'm sure we'd end up making occassional exceptions under the "materiality" test, but that's no big deal. An "audit" prior to graduation has also been proposed, but forcing IPMC members to go rooting around in source trees, build scripts and issue trackers seems unattractive. Blocking graduation instead of release candidates would reduce strain on both podlings and reviewers. Suitable policy bugs could be fixed in between incubating releases during the normal course of development, rather than between release candidates -- so fewer release candidates would be needed. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP Clearance before releasing
A point which is often missed by new comers is that votes aren't final until they vote closes and is tallied. That allows a vote that uncovers a serious defect to trigger a bunch of defecting votes (if the vote isn't just canceled) On Thu, Dec 12, 2013 at 11:02 AM, Doug Cutting wrote: > On Thu, Dec 12, 2013 at 7:38 AM, Alex Harui wrote: > > > There's no whistleblower provision > > for someone who thinks they see something that puts the foundation at > risk > > from stopping those to don't see it. > > > > If there's a clear legal problem with a release candidate I'd expect others > to acknowledge it and cancel the vote. If they don't then that could be > escalated to the Incubator PMC. > > Doug >
Re: IP Clearance before releasing
On Thu, Dec 12, 2013 at 7:38 AM, Alex Harui wrote: > There's no whistleblower provision > for someone who thinks they see something that puts the foundation at risk > from stopping those to don't see it. > If there's a clear legal problem with a release candidate I'd expect others to acknowledge it and cancel the vote. If they don't then that could be escalated to the Incubator PMC. Doug
Re: IP Clearance before releasing
On 12/11/13 9:51 PM, "Marvin Humphrey" wrote: > >I'm curious what others think. There's room for us to disagree, since >release >votes do not require consensus... That's the part I've found curious. There's no whistleblower provision for someone who thinks they see something that puts the foundation at risk from stopping those to don't see it. Certainly, quality is subjective and thus consensus is too strict, but the process we use to get a consensus veto to change seems appropriate if a -1 vote is based on a foundation/law issue. Some of our policies do have wiggle room, but I don't think all of them do. -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP Clearance before releasing
This has a good feel about it. Clearer, with flexibility. We should probably be clear about *who* can relax the rules, because again this could become a fighting ground amongst 180 of us. As to putting the foundation at risk - breaching someone else's copyright does that. Breaching the foundation's policies doesn't. Upayavira On Thu, Dec 12, 2013, at 05:51 AM, Marvin Humphrey wrote: > On Tue, Dec 10, 2013 at 3:50 AM, ant elder wrote: > > > And the Incubator _is_ different and does have different policy and > > rules, hence on occasion podlings being permitted to do releases which > > include GPL dependencies while Incubating and just fixing those up as > > a graduation requirement. > > Over in another thread[1], Bertrand came up with a thoughtful > formulation: > > I have no problem with clear and documented decisions to relax some > of > the release checklist criteria for an incubating release, as long as > that doesn't put the foundation at risk. > > That's more lenient than either my "inconsequential" test or Benson's > "materiality", but it provides something else: a framework inside which > the Incubator may bend the rules. It had been hard for me to understand > how > we could justify exercising discretion about policy, given the > Incubator's > obligations as an ordinary Apache TLP, but perhaps "document how this > problem > doesn't put the Foundation at risk" is something I can get behind. > > I expect that an incubating release with a GPL dependency would have > necessitated the approval of VP Legal Affairs, right? That would fit > inside > Bertrand's framework. > > Similarly, licensing documentation bugs such as extra garbage in NOTICE > or > the occasional missing ALv2 header do not "put the foundation at risk" -- > or > put our downstream users at risk. For a release tagged with the > "incubating" > label and disclaimer, filing bugs rather than blocking seems reasonable. > > I'm curious what others think. There's room for us to disagree, since > release > votes do not require consensus... > > Marvin Humphrey > > [1] http://s.apache.org/r1F > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP Clearance before releasing
On Thu, Dec 12, 2013 at 5:51 AM, Marvin Humphrey wrote: For a release tagged with the "incubating" > label and disclaimer, filing bugs rather than blocking seems reasonable. > > I may have edited away more than you like but yes - "filing bugs rather than blocking" is the approach we should try using more, much more. All that stuff about putting the foundation at risk seems vastly over stated - are there any examples at all ever where the foundation has come to any harm from a duff release? The release voting is to make the release a collective action of the foundation to protect individuals not to protect the foundation. I'm curious what others think. There's room for us to disagree, since > release > votes do not require consensus... > > Podling release voting is one of the most problematic areas of the Incubator and has been for years. Its the disagreement over whats required that tosses podlings about with one person saying they must do one thing and others something else, and it puts off mentors from voting in case they're made to look like they don't know what they're doing. So I think we should try to find some consensus on approach rather than agreeing to disagree, ...ant
Re: IP Clearance before releasing
On Tue, Dec 10, 2013 at 3:50 AM, ant elder wrote: > And the Incubator _is_ different and does have different policy and > rules, hence on occasion podlings being permitted to do releases which > include GPL dependencies while Incubating and just fixing those up as > a graduation requirement. Over in another thread[1], Bertrand came up with a thoughtful formulation: I have no problem with clear and documented decisions to relax some of the release checklist criteria for an incubating release, as long as that doesn't put the foundation at risk. That's more lenient than either my "inconsequential" test or Benson's "materiality", but it provides something else: a framework inside which the Incubator may bend the rules. It had been hard for me to understand how we could justify exercising discretion about policy, given the Incubator's obligations as an ordinary Apache TLP, but perhaps "document how this problem doesn't put the Foundation at risk" is something I can get behind. I expect that an incubating release with a GPL dependency would have necessitated the approval of VP Legal Affairs, right? That would fit inside Bertrand's framework. Similarly, licensing documentation bugs such as extra garbage in NOTICE or the occasional missing ALv2 header do not "put the foundation at risk" -- or put our downstream users at risk. For a release tagged with the "incubating" label and disclaimer, filing bugs rather than blocking seems reasonable. I'm curious what others think. There's room for us to disagree, since release votes do not require consensus... Marvin Humphrey [1] http://s.apache.org/r1F - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP Clearance before releasing
ant elder wrote: > Benson Margulies wrote: > > > > If we deleted every > > release from the main Foundation distro area that had some divergence > > from some policy, no matter how tiny, my suspicion is that the distro > > area would become rather sparse. > > Yes quite. And lets not forget how the "rules" keep changing eg not so > long ago people were insisting that all sorts of stuff absolutely must > be put in the NOTICE file where as now it absolutely must NOT be > there, who know what it will be like next year. I disagree with that summary. The "principles and constraints" (not "rules") do not keep changing. Instead it is that people seem to not understand those, and it takes time to weed out the misguided behaviours and documentation. -David > And the Incubator _is_ different and does have different policy and > rules, hence on occasion podlings being permitted to do releases which > include GPL dependencies while Incubating and just fixing those up as > a graduation requirement. > >...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP Clearance before releasing
On Tue, Dec 10, 2013 at 11:30 AM, Benson Margulies wrote: > If we deleted every > release from the main Foundation distro area that had some divergence > from some policy, no matter how tiny, my suspicion is that the distro > area would become rather sparse. > Yes quite. And lets not forget how the "rules" keep changing eg not so long ago people were insisting that all sorts of stuff absolutely must be put in the NOTICE file where as now it absolutely must NOT be there, who know what it will be like next year. And the Incubator _is_ different and does have different policy and rules, hence on occasion podlings being permitted to do releases which include GPL dependencies while Incubating and just fixing those up as a graduation requirement. ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP Clearance before releasing
> > Therefore, when we say that incubating releases "can have small IP loose > ends", we mean: > > * This is an official release, created by an act of the Foundation. > * It is known to violate policy. > * It could be removed, but no one has done so yet. > > I'm comfortable with relying on "prosecutorial discretion" for inconsequential > small stuff, but not something major like source code provenance. > Well, that third line is not what I meant. In law, and so in Foundation policy, there is always a concept of materiality. Nothing is perfect. People make mistakes, and the legal framework that we're working in when we make a release has room for them. If some PMC makes a release with 10 lines of 'category X' code in it, I do not believe that anyone thinks that removing it is appropriate or necessary. I was really trying to talk about trivial issues. Maybe I should have written 'tiny' instead of small. Maybe I should have focussed on L&N problems, where there are many opportunities to make an immaterial error. The bottom line should be a repetition of your repetition of Doug - a release is a release, incubator or not. If we deleted every release from the main Foundation distro area that had some divergence from some policy, no matter how tiny, my suspicion is that the distro area would become rather sparse. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP Clearance before releasing
On Sun, Dec 8, 2013 at 7:25 AM, Benson Margulies wrote: > My understanding is that incubating releases can have small IP loose > ends, but not that they can proceed before the main clearance of an > initial code donation. It would be good to establish some clarity around this issue. Here is how I understand things... The "incubating" label, while useful in setting user expectations, is 100% marketing. Incubating releases *are* Apache releases, in that they are an act of the Foundation, provide indemnity to the individuals participating in their preparation, and are subject to all Foundation-wide release policies. Here's Board member Doug Cutting: http://s.apache.org/4kH Jukka Zitting wrote: > There is clearly a widely held feeling that incubating > releases are different than "normal" ASF releases. This is the crux of the issue. I fail to see how they are fundamentally different. Releases and the release process is one of the most standardized things in the ASF: 3+1 PMC votes, distributed on www.apache.org/dist, etc. Do releases from the Incubator project differ from those of other projects? I've always thought felt that the Incubator is just another project, one that specializes in nursing new projects to maturity. But it has no special privileges or responsibilities, does it? Doug When the Incubator PMC votes to approve release artifacts which violate ASF policy, the product is still an official ASF release -- whether the policy violation is minor (missing header) or severe (copyright violation). However, since the release violates policy, someone like Roy could come through and pull it off our servers: http://s.apache.org/l8p I consider them to be trojan horses. I wouldn't hesitate for a second to delete them outright. Actually, what I've done in the past (yes, I have done this before) is move them to a subdir of my homedir and then tell the relevant project to WTFU and do it right. Note, however, I would not delete the ones in archive -- that would be silly. Therefore, when we say that incubating releases "can have small IP loose ends", we mean: * This is an official release, created by an act of the Foundation. * It is known to violate policy. * It could be removed, but no one has done so yet. I'm comfortable with relying on "prosecutorial discretion" for inconsequential small stuff, but not something major like source code provenance. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP Clearance before releasing
My understanding is that incubating releases can have small IP loose ends, but not that they can proceed before the main clearance of an initial code donation. On Sun, Dec 8, 2013 at 9:38 AM, Marvin Humphrey wrote: > On Sun, Dec 8, 2013 at 6:14 AM, Bernd Fondermann > wrote: > >> That was also my understanding, that IP clearance is important, and >> neccessary for successful incubation, but incubator releases are orthogonal >> and therefore carry a disclaimer being not fully vetted Apache releases >> because of IP and other open issues. > > So it's OK to release even if we don't have rights to the source code? Surely > even the most liberal interpretation of what is permissible under "incubating" > has limits. > >> Have I missed a change here to our policie? > > No. > >> In the reference "[1]", what exactly are you referring to? >> >>> [1] http://incubator.apache.org/projects/tajo.html >>> http://incubator.apache.org/incubation/Incubation_Policy.html#Releases >>> http://incubator.apache.org/guides/mentor.html#initial-ip-clearance > > From the Incubation Policy page: > > http://incubator.apache.org/incubation/Incubation_Policy.html#Releases > > Such approval SHALL be given only after the Incubator PMC has followed the > process detailed in these guidelines, and SHALL NOT occur until all source > has been legally transferred to the ASF. > > Marvin Humphrey > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP Clearance before releasing
On Sun, Dec 8, 2013 at 6:14 AM, Bernd Fondermann wrote: > That was also my understanding, that IP clearance is important, and > neccessary for successful incubation, but incubator releases are orthogonal > and therefore carry a disclaimer being not fully vetted Apache releases > because of IP and other open issues. So it's OK to release even if we don't have rights to the source code? Surely even the most liberal interpretation of what is permissible under "incubating" has limits. > Have I missed a change here to our policie? No. > In the reference "[1]", what exactly are you referring to? > >> [1] http://incubator.apache.org/projects/tajo.html >> http://incubator.apache.org/incubation/Incubation_Policy.html#Releases >> http://incubator.apache.org/guides/mentor.html#initial-ip-clearance >From the Incubation Policy page: http://incubator.apache.org/incubation/Incubation_Policy.html#Releases Such approval SHALL be given only after the Incubator PMC has followed the process detailed in these guidelines, and SHALL NOT occur until all source has been legally transferred to the ASF. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP Clearance before releasing
On Sun, Dec 8, 2013 at 12:43 AM, Marvin Humphrey wrote: > Greets, > > I read in the Tajo report and I see on the dev list that the Tajo > developers > are now diligently tackling IP clearance: > > http://s.apache.org/00w > > In my view, IP clearance is only the remain work for graduation. > That was also my understanding, that IP clearance is important, and neccessary for successful incubation, but incubator releases are orthogonal and therefore carry a disclaimer being not fully vetted Apache releases because of IP and other open issues. Have I missed a change here to our policie? > However, the fact that this is only happening now represents a failure of > the > IPMC. Tajo made a release last month. That release should not have gotten > our go-ahead until IP clearance was completed[1]. > In the reference "[1]", what exactly are you referring to? > [1] http://incubator.apache.org/projects/tajo.html > http://incubator.apache.org/incubation/Incubation_Policy.html#Releases > http://incubator.apache.org/guides/mentor.html#initial-ip-clearance > Thanks, Bernd
IP Clearance before releasing
Greets, I read in the Tajo report and I see on the dev list that the Tajo developers are now diligently tackling IP clearance: http://s.apache.org/00w In my view, IP clearance is only the remain work for graduation. However, the fact that this is only happening now represents a failure of the IPMC. Tajo made a release last month. That release should not have gotten our go-ahead until IP clearance was completed[1]. To address the immediate problem, it's important to complete IP clearance for Tajo ASAP. If everything goes well, I don't foresee any long term consequences. Let's cross our fingers. For the future, the more rigorous release process being discussed in other threads, which incorporates checklists and aggressively enlists the PPMC, would have prevented this error. (It would also have prevented the recent Sirona error[2].) Marvin Humphrey [1] http://incubator.apache.org/projects/tajo.html http://incubator.apache.org/incubation/Incubation_Policy.html#Releases http://incubator.apache.org/guides/mentor.html#initial-ip-clearance [2] http://s.apache.org/zjp - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
