You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Justin Mclean <ju...@classsoftware.com> on 2019/06/01 03:28:42 UTC
Podling releases and release policy
Hi,
It been suggested a few times by several people on several lists that podling releases (particularly early one’s) don’t need to comply with release and distribution policy even if they have serious issues. The question has been asked to the board several times but we’ve never got a clear answer (as the question is hypothetical) or the answer is no that’s not allowed. The incubator does not set those policies, the board and infra do. I’m going to ask the board to give us a clear answer on this to see if they are OK to grant an exception to those policies for podling releases and if our current DISCLAIMER covers those sort of issues.
Anyone have anything to add or any objections to this before I ask them?
The serious issues I’m talking about here include compiled source or inclusion of GPL (or other Category X) code in a source release or a Category X dependancy or include code that the podling doesn’t have permission to distribute i.e. the ones that people constantly vote -1 for. Last time I calculated the stats for 300+ released I found 1 in 5 podling releases had a serious issue like this.
If the board (and infra) does say this is OK, podlings would still have to have releases that copy with policy on graduation, so this puts more responsibility on the mentors and the projects themselves. Worse case the IPMC may have to reject graduation of a project that hasn’t got its releases in order.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling releases and release policy
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
>> That is demonstrably not true, as (historically) the Incubator has made
>> releases with GPL'd code in them (eg. Hibernate).
>
> I don’t understand the choice of words :(
That’s because while it was a software a release is was not an Apache releases. The word release has several different meaning here.
I’ve also seen a number of podlings do this and it's not a big deal. It’s usually only allowed for a one (perhaps 2) non-Apache releases however, although I think a few podling made more than that, one made about 200 releases before it was pointed out that perhaps they needed to make an Apache one.
And where we’re we, come people have ben saying podling releasee, they are actually IPMC releases and it’s the IPMC that can vote and make official Apache releases. Hopefully those 3 +1 votes come from the mentors, but often teh wider IPMC is needed.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling releases and release policy
Posted by Brian Spector <br...@qredo.com>.
Yes it is. We’ll be appropriating this concept.
On 5 Jun 2019, at 1:17, Greg Stein wrote:
> On Tue, Jun 4, 2019 at 7:12 PM Adrian Cole <ad...@gmail.com> wrote:
>> ...
>
>> https://github.com/apache/incubator-zipkin/issues/2544
>
>
> That is pretty damned awesome.
Re: Podling releases and release policy
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Jun 4, 2019 at 7:12 PM Adrian Cole <ad...@gmail.com> wrote:
>...
> https://github.com/apache/incubator-zipkin/issues/2544
That is pretty damned awesome.
Re: Podling releases and release policy
Posted by Adrian Cole <ad...@gmail.com>.
> > As others have mentioned, such release bugs would be labelled as blocking
> > for graduation. Ideally the bug ticket numbers would be listed in a
> > disclaimer file within the release.
>
> Interesting idea, that list would need to be kept up to date in there. It might be easier to just tag the issues with a “blocking-graduation” tag? Of course each PPMC could come up with their own may of doing thi as long as it easy for reviewers to check.
FWIW as we have 10 repos, but no central issue repository specific to
ASF graduation tracking, Zipkin decided to make one issue with tick
boxes. We've added this issue to the bottom of vote requests in
attempts to reduce effort mutually around known and/or in progress
things
https://github.com/apache/incubator-zipkin/issues/2544
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling releases and release policy
Posted by Justin Mclean <ju...@me.com>.
Hi,
> Perhaps one approach is to maintain a list of "release issues" which are
> deemed "minor offences". As long as there are bugs raised against such
> "release issues", then no further permission would be required. Anything
> outside the "minor offences" would require explicit permission.
+1
But also see what going in this months board report. [1] If the board happy with anything outside “minor offences” not requiring permission then I am as well it is after all their policy.
> As others have mentioned, such release bugs would be labelled as blocking
> for graduation. Ideally the bug ticket numbers would be listed in a
> disclaimer file within the release.
Interesting idea, that list would need to be kept up to date in there. It might be easier to just tag the issues with a “blocking-graduation” tag? Of course each PPMC could come up with their own may of doing thi as long as it easy for reviewers to check.
Thanks,
Justin
1. https://cwiki.apache.org/confluence/display/INCUBATOR/June2019
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling releases and release policy
Posted by Paul King <pa...@asert.com.au>.
Perhaps one approach is to maintain a list of "release issues" which are
deemed "minor offences". As long as there are bugs raised against such
"release issues", then no further permission would be required. Anything
outside the "minor offences" would require explicit permission.
As others have mentioned, such release bugs would be labelled as blocking
for graduation. Ideally the bug ticket numbers would be listed in a
disclaimer file within the release. This would make it easier for reviewers
and act as a reminder for project members and users. IANAL, but I think it
would help too in terms of legal shield etc. to have such a file within the
release not just a generic disclaimer "on some web site at one point in
time".
Cheers, Paul.
On Tue, Jun 4, 2019 at 7:16 PM Justin Mclean <ju...@me.com> wrote:
> Hi,
>
> > Historically, demonstrably, we have applied a different policy to
> "podling
> > releases" that is a bit more lenient. Once the podling graduates, it must
> > conform to the formal Apache release guidelines.
>
> 1. There is no seperate incubator release policy for podling/IPMC
> releases, well no formal written down one anyway.
> 2. The IPMC does currenly give podlings a lot of leeway and treats IPMC
> releases differently to TLP releases. A look at recent IPMC release votes
> will find +1 votes on issues that would probably be -1 on a TLP release.
>
> Perhaps read what going in the board report [1] (still draft) as I think
> that captures it well.
>
> Thanks,
> Justin
>
> 1. https://cwiki.apache.org/confluence/display/INCUBATOR/June2019
Re: Podling releases and release policy
Posted by Justin Mclean <ju...@me.com>.
Hi,
> Historically, demonstrably, we have applied a different policy to "podling
> releases" that is a bit more lenient. Once the podling graduates, it must
> conform to the formal Apache release guidelines.
1. There is no seperate incubator release policy for podling/IPMC releases, well no formal written down one anyway.
2. The IPMC does currenly give podlings a lot of leeway and treats IPMC releases differently to TLP releases. A look at recent IPMC release votes will find +1 votes on issues that would probably be -1 on a TLP release.
Perhaps read what going in the board report [1] (still draft) as I think that captures it well.
Thanks,
Justin
1. https://cwiki.apache.org/confluence/display/INCUBATOR/June2019
Re: Podling releases and release policy
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Jun 4, 2019 at 12:08 AM Hen <ba...@apache.org> wrote:
> On Sun, Jun 2, 2019 at 11:53 Greg Stein <gs...@gmail.com> wrote:
> > On Sun, Jun 2, 2019 at 1:22 PM Hen <ba...@apache.org> wrote:
> > >...
> > > * Incubating releases are Apache releases.
> >
> > That is demonstrably not true, as (historically) the Incubator has made
> > releases with GPL'd code in them (eg. Hibernate).
>
> I don’t understand the choice of words :(
>
> To me that is an Apache release which did not adhere, or had an exception,
> to foundation policy. I assume it was offered from an Apache url.
>
> If it wasn’t from an Apache url, then it wasn’t an Incubating release.
>
Tarballs on our server, falling under different release guidelines. In my
emails on this topic, I've been trying to distinguish between "podling
releases" and "Apache releases". As Ralph said, why a disclaimer, if there
isn't a difference in the nature of these tarballs/releases?
Historically, demonstrably, we have applied a different policy to "podling
releases" that is a bit more lenient. Once the podling graduates, it must
conform to the formal Apache release guidelines.
Cheers,
-g
Re: Podling releases and release policy
Posted by Hen <ba...@apache.org>.
On Sun, Jun 2, 2019 at 11:53 Greg Stein <gs...@gmail.com> wrote:
> On Sun, Jun 2, 2019 at 1:22 PM Hen <ba...@apache.org> wrote:
> >...
>
> > * Incubating releases are Apache releases.
> >
>
> That is demonstrably not true, as (historically) the Incubator has made
> releases with GPL'd code in them (eg. Hibernate).
I don’t understand the choice of words :(
To me that is an Apache release which did not adhere, or had an exception,
to foundation policy. I assume it was offered from an Apache url.
If it wasn’t from an Apache url, then it wasn’t an Incubating release.
Hen
>
Re: Podling releases and release policy
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Jun 3, 2019 at 7:54 PM Craig Russell <ap...@gmail.com> wrote:
> > On Jun 3, 2019, at 5:40 PM, Greg Stein <gs...@gmail.com> wrote:
> >
> > On Mon, Jun 3, 2019 at 7:24 PM Craig Russell <ap...@gmail.com>
> wrote:
> >
> >>> On Jun 3, 2019, at 2:33 PM, Justin Mclean <ju...@classsoftware.com>
> >> wrote:
> >>
> >> ...
> >
> >>> I agree, but if you read the disclaimer is says nothing about releases,
> >> perhaps that needs to change?
> >>
> >> Yes, I'd like to change the disclaimer to state that releases cannot be
> >> considered completely reliable, should not be depended on for
> production,
> >
> >
> > I believe the above two phrases would be unfair to mature projects. In
> > fact, to 95% of all the projects that arrive in the Incubator. The
> projects
> > *are* reliable and *are* used in production.
>
> Mature projects arrive here and go into incubation. I'd like to see
> production cases use the existing mature project distributions and use the
> incubator releases as test subjects. YMMV.
>
I took part in that exact situation: *Subversion 1.6* was produced
"outside" the Foundation, and was the recommended version, while *Apache
Subversion 1.7* was being incubated.
> The only difference is they are learning how to become an Apache-style
> > community. The software doesn't magically "degrade".
>
> Once the community makes changes to the "mature" software they have in
> production, it not-magically does "degrade".
>
> Maybe you and I have different standards for production. Take a mature
> project, add a few hundred lines of code, and it's no longer the mature
> project you are using in production.
>
We do have different standards, and I would maintain it is not the IPMC's
place to make such judgements. If myself and my fellow community members
say certain changes retain its "production" status, then that is how it
should be remain labeled. Your/IPMC standards do not apply.
Cheers,
-g
Re: Podling releases and release policy
Posted by Adrian Cole <ad...@gmail.com>.
wouldnt it be fair to keep the incubator benefit adjectives away from words
like reliable and production ready?
If I am not mistaken, almost all of the efforts are around ceremony around
the code, not whether it works. In fact the slowing of the community hurts
production ness as it is far slower to fix actual bugs in a way people can
consume those fixes.
It is fair to say incubator helps with process, community, provenance and
many other things. however, I dont think it is relevant or even correct to
say it helps make the code more reliable in an operations way.
On Tue, Jun 4, 2019, 8:54 AM Craig Russell <ap...@gmail.com> wrote:
>
>
> > On Jun 3, 2019, at 5:40 PM, Greg Stein <gs...@gmail.com> wrote:
> >
> > On Mon, Jun 3, 2019 at 7:24 PM Craig Russell <ap...@gmail.com>
> wrote:
> >
> >>> On Jun 3, 2019, at 2:33 PM, Justin Mclean <ju...@classsoftware.com>
> >> wrote:
> >>
> >> ...
> >
> >>> I agree, but if you read the disclaimer is says nothing about releases,
> >> perhaps that needs to change?
> >>
> >> Yes, I'd like to change the disclaimer to state that releases cannot be
> >> considered completely reliable, should not be depended on for
> production,
> >
> >
> > I believe the above two phrases would be unfair to mature projects. In
> > fact, to 95% of all the projects that arrive in the Incubator. The
> projects
> > *are* reliable and *are* used in production.
>
> Mature projects arrive here and go into incubation. I'd like to see
> production cases use the existing mature project distributions and use the
> incubator releases as test subjects. YMMV.
> >
> > The only difference is they are learning how to become an Apache-style
> > community. The software doesn't magically "degrade".
>
> Once the community makes changes to the "mature" software they have in
> production, it not-magically does "degrade".
>
> Maybe you and I have different standards for production. Take a mature
> project, add a few hundred lines of code, and it's no longer the mature
> project you are using in production.
>
> Regards,
> Craig
> >
> >
> >> might not have passed all normal Apache reviews, etc.
> >>
> >
> > Concur.
> >
> >
> >> I am of the opinion that the board should not need to be involved in
> >> telling the incubator what particular release deficiencies can stop
> >> releases. The incubator can certainly ask the board for advice on
> proposed
> >> change to policy.
> >>
> >
> > Concur.
> >
> > Cheers,
> > -g
>
> Craig L Russell
> clr@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Podling releases and release policy
Posted by Craig Russell <ap...@gmail.com>.
> On Jun 3, 2019, at 5:40 PM, Greg Stein <gs...@gmail.com> wrote:
>
> On Mon, Jun 3, 2019 at 7:24 PM Craig Russell <ap...@gmail.com> wrote:
>
>>> On Jun 3, 2019, at 2:33 PM, Justin Mclean <ju...@classsoftware.com>
>> wrote:
>>
>> ...
>
>>> I agree, but if you read the disclaimer is says nothing about releases,
>> perhaps that needs to change?
>>
>> Yes, I'd like to change the disclaimer to state that releases cannot be
>> considered completely reliable, should not be depended on for production,
>
>
> I believe the above two phrases would be unfair to mature projects. In
> fact, to 95% of all the projects that arrive in the Incubator. The projects
> *are* reliable and *are* used in production.
Mature projects arrive here and go into incubation. I'd like to see production cases use the existing mature project distributions and use the incubator releases as test subjects. YMMV.
>
> The only difference is they are learning how to become an Apache-style
> community. The software doesn't magically "degrade".
Once the community makes changes to the "mature" software they have in production, it not-magically does "degrade".
Maybe you and I have different standards for production. Take a mature project, add a few hundred lines of code, and it's no longer the mature project you are using in production.
Regards,
Craig
>
>
>> might not have passed all normal Apache reviews, etc.
>>
>
> Concur.
>
>
>> I am of the opinion that the board should not need to be involved in
>> telling the incubator what particular release deficiencies can stop
>> releases. The incubator can certainly ask the board for advice on proposed
>> change to policy.
>>
>
> Concur.
>
> Cheers,
> -g
Craig L Russell
clr@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling releases and release policy
Posted by Myrle Krantz <my...@apache.org>.
On Tue, Jun 4, 2019 at 2:40 AM Greg Stein <gs...@gmail.com> wrote:
> >
> > Yes, I'd like to change the disclaimer to state that releases cannot be
> > considered completely reliable, should not be depended on for production,
>
>
> I believe the above two phrases would be unfair to mature projects. In
> fact, to 95% of all the projects that arrive in the Incubator. The projects
> *are* reliable and *are* used in production.
>
> The only difference is they are learning how to become an Apache-style
> community. The software doesn't magically "degrade".
>
The real issue is not the reliability of the software. It's the
reliability of the licensing of the software.
The ASF name stands for stronger guarantees about your rights to use the IP
than most podlings can give when they join the incubator. Talking about
reliability and production is not only probably untrue, it could also
distract from the real risks.
Best,
Myrle
IPMC Member
Re: Podling releases and release policy
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Jun 3, 2019 at 7:24 PM Craig Russell <ap...@gmail.com> wrote:
> > On Jun 3, 2019, at 2:33 PM, Justin Mclean <ju...@classsoftware.com>
> wrote:
>
>...
> > I agree, but if you read the disclaimer is says nothing about releases,
> perhaps that needs to change?
>
> Yes, I'd like to change the disclaimer to state that releases cannot be
> considered completely reliable, should not be depended on for production,
I believe the above two phrases would be unfair to mature projects. In
fact, to 95% of all the projects that arrive in the Incubator. The projects
*are* reliable and *are* used in production.
The only difference is they are learning how to become an Apache-style
community. The software doesn't magically "degrade".
> might not have passed all normal Apache reviews, etc.
>
Concur.
> I am of the opinion that the board should not need to be involved in
> telling the incubator what particular release deficiencies can stop
> releases. The incubator can certainly ask the board for advice on proposed
> change to policy.
>
Concur.
Cheers,
-g
Re: Podling releases and release policy
Posted by Craig Russell <ap...@gmail.com>.
> On Jun 3, 2019, at 2:33 PM, Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
>> If we required that podling releases adhered to ASF release policy there would be no need for the disclaimer
>
> I agree, but if you read the disclaimer is says nothing about releases, perhaps that needs to change?
Yes, I'd like to change the disclaimer to state that releases cannot be considered completely reliable, should not be depended on for production, might not have passed all normal Apache reviews, etc.
I am of the opinion that the board should not need to be involved in telling the incubator what particular release deficiencies can stop releases. The incubator can certainly ask the board for advice on proposed change to policy.
Craig
>
> Thanks,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig L Russell
clr@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling releases and release policy
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> If we required that podling releases adhered to ASF release policy there would be no need for the disclaimer
I agree, but if you read the disclaimer is says nothing about releases, perhaps that needs to change?
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling releases and release policy
Posted by Kenneth Knowles <ke...@apache.org>.
On Mon, Jun 3, 2019 at 8:31 AM Ralph Goers <ra...@dslextreme.com>
wrote:
> Placing the disclaimer on the project’s site and labeling the release as
> incubating is done so that downstream users are aware the release may be be
> up to ASF standards.
>
"may *not* be up to ASF standards" ?
Kenn
> If we required that podling releases adhered to ASF release policy there
> would be no need for the disclaimer. At the same time, we would probably
> have a lot of projects leave the incubator because it would take them so
> long to get their first release out.
>
> Ralph
>
> > On Jun 2, 2019, at 3:06 PM, Justin Mclean <ju...@me.com> wrote:
> >
> > Hi,
> >
> >> That is demonstrably not true, as (historically) the Incubator has made
> >> releases with GPL'd code in them (eg. Hibernate).
> >
> > I assume you mean a dependancy on? I can think of 2 occasions this has
> occurred, both times permission of VP legal was required.
> >
> > Thanks,
> > 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: Podling releases and release policy
Posted by Ralph Goers <ra...@dslextreme.com>.
Ask yourself this question - “What is the point of the Incubator”?
One of the goals is to teach projects how to create a release that complies with ASF policy. But we would be stupid to expect that on the first Incubator release as we expect projects to come in with already working source code and their own build & release methodology. Placing the disclaimer on the project’s site and labeling the release as incubating is done so that downstream users are aware the release may be be up to ASF standards.
If we required that podling releases adhered to ASF release policy there would be no need for the disclaimer. At the same time, we would probably have a lot of projects leave the incubator because it would take them so long to get their first release out.
Ralph
> On Jun 2, 2019, at 3:06 PM, Justin Mclean <ju...@me.com> wrote:
>
> Hi,
>
>> That is demonstrably not true, as (historically) the Incubator has made
>> releases with GPL'd code in them (eg. Hibernate).
>
> I assume you mean a dependancy on? I can think of 2 occasions this has occurred, both times permission of VP legal was required.
>
> Thanks,
> 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: Podling releases and release policy
Posted by Justin Mclean <ju...@me.com>.
Hi,
> That is demonstrably not true, as (historically) the Incubator has made
> releases with GPL'd code in them (eg. Hibernate).
I assume you mean a dependancy on? I can think of 2 occasions this has occurred, both times permission of VP legal was required.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling releases and release policy
Posted by Greg Stein <gs...@gmail.com>.
On Sun, Jun 2, 2019 at 1:22 PM Hen <ba...@apache.org> wrote:
>...
> * Incubating releases are Apache releases.
>
That is demonstrably not true, as (historically) the Incubator has made
releases with GPL'd code in them (eg. Hibernate).
Cheers,
-g
Re: Podling releases and release policy
Posted by David Nalley <da...@gnsa.us>.
On Sun, Jun 2, 2019 at 2:23 PM Hen <ba...@apache.org> wrote:
>
> Wrote a long thing... decided it wasn't useful :)
>
> The tldr;
>
> * Incubating releases are Apache releases. No user cares if they are
> endorsed or official (for whatever they may mean). Perhaps if we said GA we
> might be clearer.
Agreed.
We distribute it, we promote it to users, that is absolutely an act of
the Foundation. Whether we call it a release or not is semantics IMO.
> * We end up having an argument about easiness of release vs
> reproducible/provable releases.
Yes - I think there is an assumption by folks that it will take time
and effort for a incubating project to conform to the standard of an
Apache project. This is why the incubating disclaimer is important.
That said, the Foundation (which is the only legal entity that exists
in this context) has certain expectations to fulfill. One of the
things that users revere us for is our IP policies, and IMO we should
strive not to surprise our users.
That said, podlings aren't TLPs, they have disclaimers with each of
their releases for a reason. Personally, I think that as long as their
is a plan in place to come into conformance with our standards, that
much can be overlooked temporarily. I think ongoing releases with no
reduction in problem scope would be an issue, but I also think that
the guidance for podlings has been entrusted to the IPMC, and
specifically to the mentors guiding the project. I'd expect the
mentors to keep the IPMC in the loop, etc.
> ** We too easily -1 a release because of something that could be easily
> fixed by a human. We don't think about that human element when we stack on
> more requirements.
> ** But we want perfection of the process. If I miss a DISCLAIMER; I can't
> just fix it and publish, there is a whole rigmarole and revote I have to
> do.
>
> I'm thinking that should be solved with a standard source release. Press a
> button and a tar.gz will be created, checking for a few standard files and
> using the private key you supply. Have it require the PMC Chair to moderate
> the release to confirm that the Apache Way was followed (and PPMCs need
> chairs).
>
> (and we need an entire conference to figure out binary releases)
>
Agreed, but no comment.
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling releases and release policy
Posted by Hen <ba...@apache.org>.
Wrote a long thing... decided it wasn't useful :)
The tldr;
* Incubating releases are Apache releases. No user cares if they are
endorsed or official (for whatever they may mean). Perhaps if we said GA we
might be clearer.
* We end up having an argument about easiness of release vs
reproducible/provable releases.
** We too easily -1 a release because of something that could be easily
fixed by a human. We don't think about that human element when we stack on
more requirements.
** But we want perfection of the process. If I miss a DISCLAIMER; I can't
just fix it and publish, there is a whole rigmarole and revote I have to
do.
I'm thinking that should be solved with a standard source release. Press a
button and a tar.gz will be created, checking for a few standard files and
using the private key you supply. Have it require the PMC Chair to moderate
the release to confirm that the Apache Way was followed (and PPMCs need
chairs).
(and we need an entire conference to figure out binary releases)
Hen
On Sun, Jun 2, 2019 at 10:10 AM Kevin A. McGrail <km...@apache.org>
wrote:
> I think the fact that incubating releases are not official ASF releases
> covers this issue. The full effect of the shield is more a risk for the
> programmers in the limbo state of incubating from my perspective.
>
> On 6/1/2019 11:27 PM, Justin Mclean wrote:
> > Hi,
> >
> > The other though that occurred to me is if we do this, are the people
> involved covered by ASF’s legal shield? i.e Does it pass the clean line
> mentioned in [1].
> >
> > "Deviations from this policy may have an adverse effect on the legal
> shield's effectiveness, or the insurance premiums Apache pays to protect
> officers and directors, so are strongly discouraged without prior, explicit
> board approval. "
> >
> > Thanks,
> > Justin
> >
> > 1. http://www.apache.org/legal/release-policy.html#why
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
> --
> Kevin A. McGrail
> Member, Apache Software Foundation
> Chair Emeritus Apache SpamAssassin Project
> https://www.linkedin.com/in/kmcgrail - 703.798.0171
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Podling releases and release policy
Posted by "Kevin A. McGrail" <km...@apache.org>.
I think the fact that incubating releases are not official ASF releases
covers this issue. The full effect of the shield is more a risk for the
programmers in the limbo state of incubating from my perspective.
On 6/1/2019 11:27 PM, Justin Mclean wrote:
> Hi,
>
> The other though that occurred to me is if we do this, are the people involved covered by ASF’s legal shield? i.e Does it pass the clean line mentioned in [1].
>
> "Deviations from this policy may have an adverse effect on the legal shield's effectiveness, or the insurance premiums Apache pays to protect officers and directors, so are strongly discouraged without prior, explicit board approval. "
>
> Thanks,
> Justin
>
> 1. http://www.apache.org/legal/release-policy.html#why
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling releases and release policy
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
The other though that occurred to me is if we do this, are the people involved covered by ASF’s legal shield? i.e Does it pass the clean line mentioned in [1].
"Deviations from this policy may have an adverse effect on the legal shield's effectiveness, or the insurance premiums Apache pays to protect officers and directors, so are strongly discouraged without prior, explicit board approval. "
Thanks,
Justin
1. http://www.apache.org/legal/release-policy.html#why
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling releases and release policy
Posted by Justin Mclean <ju...@me.com>.
HI,
> For example it would help heaps if there was a list of violations podling releases make, and which are immediate showstoppers
That is fairly well documented and these issues consistently get -1 in release votes, they are (off the top of my head):
- Missing incubating from name
- Signatures or hashes not correct
- Missing DISCLAIMER
- Missing Apache LICENSE or NOTICE
- Including Category X code or Category B code
- Dependancy on Category X code
- Including compiled code in a source release
- Include code or assets you don’t have permission to distribute
- Artefacts need to be in the right place
And probably a couple of other very rare things, like including cryptography code or PPMC vote issues. Other IPMC members lists may be a little different, and in one or two cases it may depend on the exact situation, but it’s generally consistent. See also the talks and other materials mentioned previously on this list, as they go into more detail about this.
All except two of these are from the release and distribution policies not set by the incubator. All the incubator asks on top of those is add a DISCLAIMER, put incubating in name and an IPMC vote.
If you think it helps I’ll put that list together on the site or wiki.
> and which need to be noted (filed as tickets) and fixed in a release before graduation.
All other issues, but the expectation historical has been that they are generally fixed in the next release, not just before graduation. It’s important to show progress.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling releases and release policy
Posted by Mick Semb Wever <mc...@apache.org>.
I agree.
For example it would help heaps if there was a list of violations podling releases make, and which are immediate showstoppers and which need to be noted (filed as tickets) and fixed in a release before graduation.
Certainly, having that list would help land this discussion a bit better.
Justin, I think above all others you are the one sitting on a ton, the real wealth, of knowledge here.
I appreciate the need to "know exactly what the rules are", but culturally I hope the emphasis remains on figuring out how the incubator can improve at helping podlings get to and through graduation without having to police them along the way.
A lot of work has gone into improving the Incubator recently and it has been very much appreciated.
I'm uncertain though as to whether seeking such explicit approval from the board and infra is but in the spirit of further policing podlings, or if in putting at ease some of the more serious concerns that the incubator has it allows it to better focus on what services it can better provide.
I can't speak for all, but I know some folk really get the benefit from the public praise of catching podlings doing it right. The incubator's documentation isn't perfect, and it'll also be shifting sands and slightly out of date, so making it easy for newcomers in the incubator to know what are the good examples to be learning from always goes a long way.
regards,
Mick
On Sat, 1 Jun 2019, at 13:55, Dave Fisher wrote:
> Kevin and Justin,
>
> This is spot on.
>
> Disclaimer, signatures/checksums, Apache license, and a start to notes
> are the minimum.
>
> Acceptance of issues to fix is also a requirement.
>
> Full compliance with Apache Release and Distribution Policies are some
> of our agreed Incubation requirements for graduation recommendation.
>
> Do we need to confirm all requirements or should we limit to this
> discussion to Releases?
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On May 31, 2019, at 8:45 PM, Kevin A. McGrail <km...@apache.org> wrote:
> >
> > Hi Justin,
> >
> > Before putting it to the board, have we ever had a IPMC vote on the
> > matter? I think the board wants to delegate because legally, there
> > isn't a chance in hell they are going to vote on it any way but
> > negatively because to me, they have no choice but to formally say no.
> > This is a possible example of purposefully turning a blind eye because
> > it's hard for podlings to come up to speed.
> >
> > So perhaps if we set an incubator policy of a podling release being a
> > little more lenient, the board would delegate because the legal issues
> > are about nil. It's like making a law where 20% of America is a
> > criminal. Is it really enforceable and especially without prejudicial
> > or preferential treatment?
> >
> > What I like to see from a podling is: acknowledgment of the issues,
> > tickets on the issues, and consistent improvement.
> >
> > What we cannot see is: a podling NOT saying "incubating" in a release or
> > saying no, we will not fix these issues.
> >
> > Perhaps we need a podling disclaimer for all podling releases that
> > explains more about what is a podlings and what is an incubating
> > release. Perhaps it can contain appropriate caveats that the release
> > may have issues that are being worked on that up to and including
> > licensing issues. Links to Jira as well would be good. Then if we
> > enforce tickets about known issues, we can both hold podlings
> > accountable and enlighten users about the risks.
> >
> > I agree there are some examples where podlings are pushing our good
> > faith on not fixing issues. But there are others that are just
> > overwhelmed and we need to help more with the podlings where English is
> > a second language. Perhaps something to ask the new D&I committee to
> > assist with. Lots of discussion about overcoming language barriers of
> > late on board-chat too.
> >
> > Regards,
> > KAM
> >> On 5/31/2019 11:28 PM, Justin Mclean wrote:
> >> Hi,
> >>
> >> It been suggested a few times by several people on several lists that podling releases (particularly early one’s) don’t need to comply with release and distribution policy even if they have serious issues. The question has been asked to the board several times but we’ve never got a clear answer (as the question is hypothetical) or the answer is no that’s not allowed. The incubator does not set those policies, the board and infra do. I’m going to ask the board to give us a clear answer on this to see if they are OK to grant an exception to those policies for podling releases and if our current DISCLAIMER covers those sort of issues.
> >>
> >> Anyone have anything to add or any objections to this before I ask them?
> >>
> >> The serious issues I’m talking about here include compiled source or inclusion of GPL (or other Category X) code in a source release or a Category X dependancy or include code that the podling doesn’t have permission to distribute i.e. the ones that people constantly vote -1 for. Last time I calculated the stats for 300+ released I found 1 in 5 podling releases had a serious issue like this.
> >>
> >> If the board (and infra) does say this is OK, podlings would still have to have releases that copy with policy on graduation, so this puts more responsibility on the mentors and the projects themselves. Worse case the IPMC may have to reject graduation of a project that hasn’t got its releases in order.
> >>
> >> Thanks,
> >> Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling releases and release policy
Posted by Dave Fisher <da...@comcast.net>.
Kevin and Justin,
This is spot on.
Disclaimer, signatures/checksums, Apache license, and a start to notes are the minimum.
Acceptance of issues to fix is also a requirement.
Full compliance with Apache Release and Distribution Policies are some of our agreed Incubation requirements for graduation recommendation.
Do we need to confirm all requirements or should we limit to this discussion to Releases?
Regards,
Dave
Sent from my iPhone
> On May 31, 2019, at 8:45 PM, Kevin A. McGrail <km...@apache.org> wrote:
>
> Hi Justin,
>
> Before putting it to the board, have we ever had a IPMC vote on the
> matter? I think the board wants to delegate because legally, there
> isn't a chance in hell they are going to vote on it any way but
> negatively because to me, they have no choice but to formally say no.
> This is a possible example of purposefully turning a blind eye because
> it's hard for podlings to come up to speed.
>
> So perhaps if we set an incubator policy of a podling release being a
> little more lenient, the board would delegate because the legal issues
> are about nil. It's like making a law where 20% of America is a
> criminal. Is it really enforceable and especially without prejudicial
> or preferential treatment?
>
> What I like to see from a podling is: acknowledgment of the issues,
> tickets on the issues, and consistent improvement.
>
> What we cannot see is: a podling NOT saying "incubating" in a release or
> saying no, we will not fix these issues.
>
> Perhaps we need a podling disclaimer for all podling releases that
> explains more about what is a podlings and what is an incubating
> release. Perhaps it can contain appropriate caveats that the release
> may have issues that are being worked on that up to and including
> licensing issues. Links to Jira as well would be good. Then if we
> enforce tickets about known issues, we can both hold podlings
> accountable and enlighten users about the risks.
>
> I agree there are some examples where podlings are pushing our good
> faith on not fixing issues. But there are others that are just
> overwhelmed and we need to help more with the podlings where English is
> a second language. Perhaps something to ask the new D&I committee to
> assist with. Lots of discussion about overcoming language barriers of
> late on board-chat too.
>
> Regards,
> KAM
>> On 5/31/2019 11:28 PM, Justin Mclean wrote:
>> Hi,
>>
>> It been suggested a few times by several people on several lists that podling releases (particularly early one’s) don’t need to comply with release and distribution policy even if they have serious issues. The question has been asked to the board several times but we’ve never got a clear answer (as the question is hypothetical) or the answer is no that’s not allowed. The incubator does not set those policies, the board and infra do. I’m going to ask the board to give us a clear answer on this to see if they are OK to grant an exception to those policies for podling releases and if our current DISCLAIMER covers those sort of issues.
>>
>> Anyone have anything to add or any objections to this before I ask them?
>>
>> The serious issues I’m talking about here include compiled source or inclusion of GPL (or other Category X) code in a source release or a Category X dependancy or include code that the podling doesn’t have permission to distribute i.e. the ones that people constantly vote -1 for. Last time I calculated the stats for 300+ released I found 1 in 5 podling releases had a serious issue like this.
>>
>> If the board (and infra) does say this is OK, podlings would still have to have releases that copy with policy on graduation, so this puts more responsibility on the mentors and the projects themselves. Worse case the IPMC may have to reject graduation of a project that hasn’t got its releases in order.
>>
>> Thanks,
>> Justin
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> --
> Kevin A. McGrail
> Member, Apache Software Foundation
> Chair Emeritus Apache SpamAssassin Project
> https://www.linkedin.com/in/kmcgrail - 703.798.0171
>
>
> ---------------------------------------------------------------------
> 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: Podling releases and release policy
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I was providing the converse: has the IPMC been told *not* to make podling
> releases?
For ones that don’t comply with release policy? Yes they have.
> I'm stipulating that "podling release" != "Foundation release", so
> different policies apply.
That’s the first time I’ve head it put that way. The IPMC is a PMC and make’s those releases. it seem odd they as a TLP don’t have to comply to policy, without the boards approval, especially if that not documented anywhere.
> The disclaimer says "the project has yet to be fully endorsed by the ASF”.
Which is a little vague and doesn’t IMO explicitly say anything about releases.
But rather than disagreeing about this why don’t we get it changed / confirmed by that the current board that this is the case?
I for one are uncomfortable that the legal protections may not apply to IPMC members (and podlings involved) if we don’t follow release policy.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling releases and release policy
Posted by Greg Stein <gs...@gmail.com>.
On Sat, Jun 1, 2019 at 6:50 PM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > Point me to where you are not allowed to make non-official podling
> releases
> > that conform to Incubator policy.
>
> I find that hard to parse and perhaps you meant don’t conform to incubator
> policy? But either way it’s not incubators policy, it’s the boards and
> infra policy.
>
I was providing the converse: has the IPMC been told *not* to make podling
releases? Where such releases conform to its own policy, rather than the
Foundation policy?
I'm stipulating that "podling release" != "Foundation release", so
different policies apply.
> I think that approving a release [1], or publication [2] might be your
> answer, where it states “Projects SHALL publish official releases and SHALL
> NOT publish unreleased materials outside the development community.”. Does
> that cover it?
>
I'm saying that a "podling release" is not an "official [Foundation]
release".
> > Throw on a disclaimer that the podling release is not a Foundation
> > release (already being done!) and you're good to go.
>
> The disclaimer doesn’t state that or anything about releases. [3] Perhaps
> it should?
>
The disclaimer says "the project has yet to be fully endorsed by the ASF".
So I'm saying that the podling release does not have to conform to ASF
release policy because it is *explicitly stated* that it is not a release
endorsed by the Foundation.
Cheers,
-g
Re: Podling releases and release policy
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Given that [1] says "may" and not "will" and that Roy has said that if it isn't illegal and better than the last release it is ok to ship a release candidate, maybe the ASF should adopt the approach that every release policy issue that isn't about the legal right to distribute some IP can be addressed in the next release if a TLP, and by graduation if a podling.
My 2 cents,
-Alex
On 6/4/19, 8:00 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
Hi,
Thanks Sam for the advice.
> Been lurking. Before I proceed, I will note that you have two members
> of the board and one infrastructure representative participating.
> Each has either explicitly or implicitly supported the idea of the
> incubator setting direction for podlings.
Set direction sure, but does that include ignoring board policy? While we do currently for minor issues, I’m reasonably sure the board is OK with that, well none have complained. I’m not sure if doing that for serious issues is overstepping the mark or not.
See, for example, "why a foundation wide policy is needed”: [1]
"Deviations from this policy may have an adverse effect on the legal shield's effectiveness, or the insurance premiums Apache pays to protect officers and directors, so are strongly discouraged without prior, explicit board approval”
> Now my observation. My experience is that when a PMC comes to the
> board with an open ended question asking for advice, the responses are
> not crisp.
Understood. I was asked by a board member to ask the question in the next report, although they may not of been wearing that hat at the time.
> An approach I have found much more successful: come up with a
> proposal. Often times it will get approved. Some times you will be
> asked to make changes.
OK I've written down what we currently do and that some have expressed an opinion that podling should be able to ignore distribution policy up until graduation in the current report. There is some support for it and no strong objection if that is OK by the board which is I think close to consensus.
If I am mistaken there please speak up.
Personally I don’t really care either way other than A) if I vote on or am a release manger for a release do I have the ASF legal protection (even if that release has serious issues) and B) it’s clearer when podlings need to fix issues.
I’m happy to change what I’ve written in the report into a proposal with the view that, from now on that IPMC will allow serious issues in podling releases, so the board only needs to say yes/no either explicitly or implicitly rather than choose from a list of options a sit currently worded.
If permission is given, then we’ll modify documentation and the DISCLAIMER to cover this and you’ll see fewer -1 votes. Podlings will be expected (as before) to fix all issues before graduation, so this may potentially block some podlings from graduation.
If they say no then we'll refine the list of serious issues we vote -1 on and communicate that to podlings. I think we can reasonably agree on that list with perhaps one possible exception (compiled code in binaries).
If anyone disagrees with this approach, or has an alternative suggestion, please speak up.
Thanks,
Justin
1. https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23why&data=02%7C01%7Caharui%40adobe.com%7Cbc987bf1219d42bfa17e08d6e961fdd1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636953004417339794&sdata=6yunnE%2BTZmQrD1mYiDpmgMRblswB4D1FX3NIYIrvX%2Fk%3D&reserved=0
---------------------------------------------------------------------
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: Podling releases and release policy
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Thanks Sam for the advice.
> Been lurking. Before I proceed, I will note that you have two members
> of the board and one infrastructure representative participating.
> Each has either explicitly or implicitly supported the idea of the
> incubator setting direction for podlings.
Set direction sure, but does that include ignoring board policy? While we do currently for minor issues, I’m reasonably sure the board is OK with that, well none have complained. I’m not sure if doing that for serious issues is overstepping the mark or not.
See, for example, "why a foundation wide policy is needed”: [1]
"Deviations from this policy may have an adverse effect on the legal shield's effectiveness, or the insurance premiums Apache pays to protect officers and directors, so are strongly discouraged without prior, explicit board approval”
> Now my observation. My experience is that when a PMC comes to the
> board with an open ended question asking for advice, the responses are
> not crisp.
Understood. I was asked by a board member to ask the question in the next report, although they may not of been wearing that hat at the time.
> An approach I have found much more successful: come up with a
> proposal. Often times it will get approved. Some times you will be
> asked to make changes.
OK I've written down what we currently do and that some have expressed an opinion that podling should be able to ignore distribution policy up until graduation in the current report. There is some support for it and no strong objection if that is OK by the board which is I think close to consensus.
If I am mistaken there please speak up.
Personally I don’t really care either way other than A) if I vote on or am a release manger for a release do I have the ASF legal protection (even if that release has serious issues) and B) it’s clearer when podlings need to fix issues.
I’m happy to change what I’ve written in the report into a proposal with the view that, from now on that IPMC will allow serious issues in podling releases, so the board only needs to say yes/no either explicitly or implicitly rather than choose from a list of options a sit currently worded.
If permission is given, then we’ll modify documentation and the DISCLAIMER to cover this and you’ll see fewer -1 votes. Podlings will be expected (as before) to fix all issues before graduation, so this may potentially block some podlings from graduation.
If they say no then we'll refine the list of serious issues we vote -1 on and communicate that to podlings. I think we can reasonably agree on that list with perhaps one possible exception (compiled code in binaries).
If anyone disagrees with this approach, or has an alternative suggestion, please speak up.
Thanks,
Justin
1. http://www.apache.org/legal/release-policy.html#why
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling releases and release policy
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Jun 1, 2019 at 7:50 PM Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
> > Point me to where you are not allowed to make non-official podling releases
> > that conform to Incubator policy.
>
> I find that hard to parse and perhaps you meant don’t conform to incubator policy? But either way it’s not incubators policy, it’s the boards and infra policy.
Been lurking. Before I proceed, I will note that you have two members
of the board and one infrastructure representative participating.
Each has either explicitly or implicitly supported the idea of the
incubator setting direction for podlings.
Now my observation. My experience is that when a PMC comes to the
board with an open ended question asking for advice, the responses are
not crisp. This is by design. We are not a top down organization.
No one Director is authorized to speak for the board.
An approach I have found much more successful: come up with a
proposal. Often times it will get approved. Some times you will be
asked to make changes. And some times you will get yelled at.
But one thing you will get is a crisp answer.
- Sam Ruby
P.S. Don't take this advice as recommending that you create a board
resolution. In most cases, coming to consensus in a transparent way
and informing the board in a sentence or a paragraph in the next board
report that unless you hear otherwise, the Incubator will be
implementing X is sufficient.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling releases and release policy
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Point me to where you are not allowed to make non-official podling releases
> that conform to Incubator policy.
I find that hard to parse and perhaps you meant don’t conform to incubator policy? But either way it’s not incubators policy, it’s the boards and infra policy.
I think that approving a release [1], or publication [2] might be your answer, where it states “Projects SHALL publish official releases and SHALL NOT publish unreleased materials outside the development community.”. Does that cover it?
> Throw on a disclaimer that the podling release is not a Foundation
> release (already being done!) and you're good to go.
The disclaimer doesn’t state that or anything about releases. [3] Perhaps it should?
Thanks,
Justin
1. http://www.apache.org/legal/release-policy.html#release-approval
2. http://www.apache.org/legal/release-policy.html#publication
3. https://incubator.apache.org/guides/branding.html#disclaimers
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling releases and release policy
Posted by Greg Stein <gs...@gmail.com>.
On Sat, Jun 1, 2019 at 4:14 AM Justin Mclean <ju...@classsoftware.com>
wrote:
>...
> > release policy to something that **is not a Foundation release**
>
> But don’t these releases become foundation releases when the IPMC vote on
> them?
>
Why should they? The vote is to make a podling release.
> They do not need to conform to the Foundation’s policy.
>
> If you could point me to where this is documented, that would be great.
Point me to where you are not allowed to make non-official podling releases
that conform to Incubator policy.
I don't have a pointer to your request, nor one to my request. Just get on
with it. I think you're getting too hung up on "rules", rather than what
the Incubator should be about. And part of that is recognizing that
projects are in transition, and cannot meet the Foundation release policy
on Day One. Yet we also want to demonstrate to podlings what/how to make a
release. Throw on a disclaimer that the podling release is not a Foundation
release (already being done!) and you're good to go. Bob's your uncle.
If it is disturbing you greatly, then codify the position as IPMC policy
somewhere, and include a link in your next Board report. I seriously doubt
the Board will take issue. It is the stance that I've always understood for
the Incubator. Podlings are in a transitional state and are *not* part of
the Foundation.
Cheers,
-g
Re: Podling releases and release policy
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> It is always best to handle at the PMC-level first, rather than skipping
> from community discussion straight to the Board.
I 100% agreed.
> I believe the key issue is that you're attempting to apply the Foundation's
> release policy to something that **is not a Foundation release**
But don’t these releases become foundation releases when the IPMC vote on them?
> They do not need to conform to the Foundation’s policy.
If you could point me to where this is documented, that would be great.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling releases and release policy
Posted by Greg Stein <gs...@gmail.com>.
On Sat, Jun 1, 2019 at 12:02 AM <ju...@classsoftware.com> wrote:
> HI,
>
> > Before putting it to the board, have we ever had a IPMC vote on the
> matter?
>
> Sure if you think one is needed, but probably best to have some discussion
> about it first.
>
It is always best to handle at the PMC-level first, rather than skipping
from community discussion straight to the Board.
> So perhaps if we set an incubator policy of a podling release being a
> > little more lenient
>
> We do not own the release policy so I don’t think we can change it like
> that, but we could ask the board to do so.
>
I believe the key issue is that you're attempting to apply the Foundation's
release policy to something that **is not a Foundation release**
That is what the Incubator disclaimer is for. These are podlings' releases.
Not Foundation releases. They do not need to conform to the Foundation's
policy. Merely the Incubator's policy, whatever that may be (Dave sets out
a great list).
When a podling graduates and becomes part of the formal structure of the
Foundation, *then* the release policy must apply.
Cheers,
-g
Re: Podling releases and release policy
Posted by ju...@classsoftware.com.
HI,
> Before putting it to the board, have we ever had a IPMC vote on the matter?
Sure if you think one is needed, but probably best to have some discussion about it first.
> So perhaps if we set an incubator policy of a podling release being a
> little more lenient
We do not own the release policy so I don’t think we can change it like that, but we could ask the board to do so.
We are already lenient on minor issues (missing headers, missing stuff in licenses and the like), this is more about the more serious issues, see for example the vote today on Tuweni. I don’t think we can ignore these without board permision to ignore their release policy. It may be that having that DISCLAIMER is good enough for them to be OK with that.
For instance a podling a few months back went directly to board when we voted -1 on their release for including a jar in it and we’ve had some people express the opinion that everything is allowed in a release if it's fixed before the project graduates. Again I’m not sure we can do that without the board’s permission given it's their policy not ours. There has only been a couple of cases where this has come up given most podlings cancel the vote and make another release when a serious issue is found / someone IPMC member votes -1 on a release.
> Perhaps we need a podling disclaimer for all podling releases that
> explains more about what is a podlings and what is an incubating
> release.
That a good idea and having a list of know issues that are being worked on in the release sounds like it would help. Quite often the podling may not be aware of the issues until the IPMC finds them, possibly related to mentor engagement, or where there is a conflict of interest that might cloud mentors judgment.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podling releases and release policy
Posted by "Kevin A. McGrail" <km...@apache.org>.
Hi Justin,
Before putting it to the board, have we ever had a IPMC vote on the
matter? I think the board wants to delegate because legally, there
isn't a chance in hell they are going to vote on it any way but
negatively because to me, they have no choice but to formally say no.
This is a possible example of purposefully turning a blind eye because
it's hard for podlings to come up to speed.
So perhaps if we set an incubator policy of a podling release being a
little more lenient, the board would delegate because the legal issues
are about nil. It's like making a law where 20% of America is a
criminal. Is it really enforceable and especially without prejudicial
or preferential treatment?
What I like to see from a podling is: acknowledgment of the issues,
tickets on the issues, and consistent improvement.
What we cannot see is: a podling NOT saying "incubating" in a release or
saying no, we will not fix these issues.
Perhaps we need a podling disclaimer for all podling releases that
explains more about what is a podlings and what is an incubating
release. Perhaps it can contain appropriate caveats that the release
may have issues that are being worked on that up to and including
licensing issues. Links to Jira as well would be good. Then if we
enforce tickets about known issues, we can both hold podlings
accountable and enlighten users about the risks.
I agree there are some examples where podlings are pushing our good
faith on not fixing issues. But there are others that are just
overwhelmed and we need to help more with the podlings where English is
a second language. Perhaps something to ask the new D&I committee to
assist with. Lots of discussion about overcoming language barriers of
late on board-chat too.
Regards,
KAM
On 5/31/2019 11:28 PM, Justin Mclean wrote:
> Hi,
>
> It been suggested a few times by several people on several lists that podling releases (particularly early one’s) don’t need to comply with release and distribution policy even if they have serious issues. The question has been asked to the board several times but we’ve never got a clear answer (as the question is hypothetical) or the answer is no that’s not allowed. The incubator does not set those policies, the board and infra do. I’m going to ask the board to give us a clear answer on this to see if they are OK to grant an exception to those policies for podling releases and if our current DISCLAIMER covers those sort of issues.
>
> Anyone have anything to add or any objections to this before I ask them?
>
> The serious issues I’m talking about here include compiled source or inclusion of GPL (or other Category X) code in a source release or a Category X dependancy or include code that the podling doesn’t have permission to distribute i.e. the ones that people constantly vote -1 for. Last time I calculated the stats for 300+ released I found 1 in 5 podling releases had a serious issue like this.
>
> If the board (and infra) does say this is OK, podlings would still have to have releases that copy with policy on graduation, so this puts more responsibility on the mentors and the projects themselves. Worse case the IPMC may have to reject graduation of a project that hasn’t got its releases in order.
>
> Thanks,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org