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 wrote:
>> ...
>
>> https://github.com/apache/incubator-zipkin/issues/2544
>
>
> That is pretty damned awesome.
On Sun, Jun 2, 2019 at 2:23 PM Hen 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
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
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
On Sat, Jun 1, 2019 at 7:50 PM Justin Mclean 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
On Tue, Jun 4, 2019 at 7:12 PM Adrian Cole wrote:
>...
> https://github.com/apache/incubator-zipkin/issues/2544
That is pretty damned awesome.
> > 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
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
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
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
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
On Tue, Jun 4, 2019 at 12:08 AM Hen wrote:
> On Sun, Jun 2, 2019 at 11:53 Greg Stein wrote:
> > On Sun, Jun 2, 2019 at 1:22 PM Hen wrote:
> > >...
> > > * Incubating releases are Apache releases.
> >
> > That is demonstrably not true, as (historically) the Incubator has made
> > releases with
On Tue, Jun 4, 2019 at 2:40 AM Greg Stein 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
On Sun, Jun 2, 2019 at 11:53 Greg Stein wrote:
> On Sun, Jun 2, 2019 at 1:22 PM Hen 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
On Mon, Jun 3, 2019 at 7:54 PM Craig Russell wrote:
> > On Jun 3, 2019, at 5:40 PM, Greg Stein wrote:
> >
> > On Mon, Jun 3, 2019 at 7:24 PM Craig Russell
> wrote:
> >
> >>> On Jun 3, 2019, at 2:33 PM, Justin Mclean
> >> wrote:
> >>
> >> ...
> >
> >>> I agree, but if you read the disclaimer
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
> On Jun 3, 2019, at 5:40 PM, Greg Stein wrote:
>
> On Mon, Jun 3, 2019 at 7:24 PM Craig Russell wrote:
>
>>> On Jun 3, 2019, at 2:33 PM, Justin Mclean
>> wrote:
>>
>> ...
>
>>> I agree, but if you read the disclaimer is says nothing about releases,
>> perhaps that needs to change?
>>
On Mon, Jun 3, 2019 at 7:24 PM Craig Russell wrote:
> > On Jun 3, 2019, at 2:33 PM, Justin Mclean
> 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
> On Jun 3, 2019, at 2:33 PM, Justin Mclean 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,
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
On Mon, Jun 3, 2019 at 8:31 AM Ralph Goers
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
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
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
On Sun, Jun 2, 2019 at 1:22 PM Hen 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
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
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
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
On Sat, Jun 1, 2019 at 6:50 PM Justin Mclean
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
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
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
-
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
On Sat, Jun 1, 2019 at 4:14 AM Justin Mclean
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
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
On Sat, Jun 1, 2019 at 12:02 AM 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
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
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
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
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
38 matches
Mail list logo
