You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by David Nalley <da...@gnsa.us> on 2019/06/20 17:04:07 UTC
Podlings, the Incubator, relationships and Apache
There's been a lot of discussion in various threads about bureaucracy,
whether podlings are part of the ASF, etc. As a result of that I've
spent a good deal of time reading resolutions and older discussions
and organizing those thoughts from a legal and community perspective.
I've also read a number of conversations from the more august members
of our body about this subject. Altogether it has somewhat changed
some of my opinions and assumptions. I've also sensed that there is a
community/business/legal disconnect in our conversations. We're using
the same words to mean very different things in each of those
contexts. That said I am but one member of the IPMC, but maybe this
will be helpful to someone else - I've tried to avoid my assumptions
in this.
The IPMC's first 'job'[1] is "accepting new products into the
Foundation" The second 'job' of the IPMC is to "provide guidance and
support to ensure that the Incubator's sub-projects[2] develop
products according to the Foundation's philosophy and guidelines". The
final 'job' is evaluating the products and determining whether they
should be abandoned, continue to receive guidance and support, or be
promoted to "full project status".
So there are several realizations I gained from this from the
Incubator perspective.
1. Acceptance into the Incubator is acceptance of the product into the
Foundation.
2. That product is then a sub-project of the Incubator.
3. The IPMC has the "primary responsibility for the management of
those subprojects".
From the Foundation's perspective there are a number of things that
come to mind:
1. We aren't a github/sourceforge/google code type platform where
random people can upload/post what they want.
2. We do not have DMCA Safe Harbor protection - e.g. we are
responsible for everything that we publish or distribute. With the
exception of wikis and bug trackers anyone who can put something up on
an Apache property has some form of legal relationship with the
Foundation. This could be as simple as an ICLAs where you've
contractually said you won't contribute anything you don't have rights
to.
3. Most of the project's who have come to us aren't entities in and of
themselves. E.g. the 'project' doesn't truly exist from a legal entity
perspective - and even those who do are at best an unincorporated
association of individuals. From a legal perspective - projects can't
make or distribute a release - they don't exist - only the ASF and the
individual(s) doing the work. Given that one of the explicit reasons
the Foundation was created was to[5]: "provide a means for individual
volunteers to be sheltered from legal suits"; we want them to create
and distribute releases as the Foundation.
4. Whether we like it or not - the Foundation is judged on the output
from our projects and subprojects. We have a reputation of having
clean IP, permissively licensed open source code, with clear
provenance. Many people explicitly copy our standards, guidelines, and
policies because they are the gold standard for good open source
governance.
5. Disclaimers generally don't remove liability, and even if they did,
our disclaimer talks about the maturity of our projects. - And it
certainly doesn't remove the public's expectations from us - frankly -
losing the publics trust is as scary as the potential legal liability.
6. The Board has delegated the responsibility of managing and ensuring
adherence to policies and guidelines to the IPMC. I don't see this
responsibility as boolean. It's not perfect compliance vs. failure.
IMO, the IPMC has been delegated the decision making process, and may
often find themselves making the business decision that an imperfect
release is better than a community stalled for months or years. Don't
let the perfect be the enemy of the good.
From a podling's perspective:
1. Once you join the incubator you're a part of the ASF (Yay!?)
2. Your project is now a subproject of the IPMC.
3. There are rules, and you're entering a world of pain[4] In fact,
you're likely to find that the ASF has more rules and structure that
apply to projects than virtually any other home your project could
choose. This is good and bad.
4. The incubator has a long, storied history of producing successful
projects that flourish.
[1] http://apache.org/foundation/records/minutes/2002/board_minutes_2002_10_16.txt
[2] What we call Podlings, the initial resolution refers to as
subprojects of the Incubator
[3] It's worth noting that there were two resolutions proposed to
create the Incubator - small differences, but interesting to read the
differences.
[4] https://youtu.be/3vB9U2hx6Qg
[5] https://www.apache.org/foundation/faq.html#why
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by David Nalley <da...@gnsa.us>.
On Sat, Jun 22, 2019 at 6:31 PM Rich Bowen <rb...@rcbowen.com> wrote:
>
> A couple of thoughts:
>
> Podlings are not permitted to call themselves "Apache Foo" because they are
> not yet full Apache projects.
>
Actually we compel them to call themselves Apache Foo (incubating)
https://incubator.apache.org/guides/branding.html#naming
Another section in that same page contains "A podling MUST now be
called Apache Podling-Name" and the 'MUST' in that sentence is
bolded.
> While in the incubator we should expect podlibgs to fail at the rules.
> They're new to them and many of them feel arbitrary, even capricious, to
> those coming in from outside. We should make it safe to fail until they are
> ready to graduate. We should nurture them as long as they are moving
> towards that goal.
>
> I cannot disagree with your reading of our resolutions. But I wonder if
> that reality is producing good citizen projects or a bunch of resentful
> people following rules they don't understand or embrace because they know
> they have to.
>
I think in a substantial number of cases our existing process causes
people to fail to understand our culture because the focus is on the
rules (not saying that rules aren't important) and creates an
antagonistic relationship. I also think that to a large degree this is
won and lost based on initial expectations with the champion, and
ongoing support from mentors.
> Zipkin is only the latest project which clearly didn't get it and has left
> angry. I would rather a project realize that they don't fit and be able to
> leave with their dignity without having also to leave hating what we stand
> for.
>
> I want our new graduates to love and understand the ASF not merely tolerate
> it.
>
Agreed
> I want the incubator to respond to failure with gentle correction rather
> than scoldings.
>
> Specifically I think podlings should be able to produce releases that are
> not asf complient and have them clearly labeled as such. Because they are
> not TLPs yet and so cannot be held to the same standard. This must be
> accompanied by a movement towards being a TLP, not some eternal incubation.
>
Agreed - I think it's a process.
My reading of the resolution is that the the Board has delegated
management of this process to the IPMC.
I think our (the IPMC) tendencies, especially as developers, has
hindered our assumption of that management process. I think we tend to
like things being boolean - and of course it's far easier to check
boxes off on a checklist and have something clean, regardless of how
hard it is to get to that state.
> The incubator should be a mentor - an educator - not a jury.
>
>
I don't think we are far apart on this. I think that the IPMC has been
tasked with making a business decision of what should be allowed to
slide, though it's historically not been what we have done.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Dave Fisher <da...@comcast.net>.
I find TVM concentrating on moving their community to Apache first to be very refreshing. I think that may allow an eyes wide open approach to Apache governance.
I think a soft approach to policy compliance will yield better, happier Apache communities.
The Incubator should celebrate the achievement of an Apache Release Policy compliant release via some PR or Press Release. The achievement should outside of and retrospective of the release process.
I’d like for Legal Policy to consider the prospective nature of an Incubating Community carefully.
Regards,
Dave
Sent from my iPhone
> On Jun 22, 2019, at 3:30 PM, Rich Bowen <rb...@rcbowen.com> wrote:
>
> A couple of thoughts:
>
> Podlings are not permitted to call themselves "Apache Foo" because they are
> not yet full Apache projects.
>
> While in the incubator we should expect podlibgs to fail at the rules.
> They're new to them and many of them feel arbitrary, even capricious, to
> those coming in from outside. We should make it safe to fail until they are
> ready to graduate. We should nurture them as long as they are moving
> towards that goal.
>
> I cannot disagree with your reading of our resolutions. But I wonder if
> that reality is producing good citizen projects or a bunch of resentful
> people following rules they don't understand or embrace because they know
> they have to.
>
> Zipkin is only the latest project which clearly didn't get it and has left
> angry. I would rather a project realize that they don't fit and be able to
> leave with their dignity without having also to leave hating what we stand
> for.
>
> I want our new graduates to love and understand the ASF not merely tolerate
> it.
>
> I want the incubator to respond to failure with gentle correction rather
> than scoldings.
>
> Specifically I think podlings should be able to produce releases that are
> not asf complient and have them clearly labeled as such. Because they are
> not TLPs yet and so cannot be held to the same standard. This must be
> accompanied by a movement towards being a TLP, not some eternal incubation.
>
> The incubator should be a mentor - an educator - not a jury.
>
>
>> On Fri, Jun 21, 2019, 01:04 David Nalley <da...@gnsa.us> wrote:
>>
>> There's been a lot of discussion in various threads about bureaucracy,
>> whether podlings are part of the ASF, etc. As a result of that I've
>> spent a good deal of time reading resolutions and older discussions
>> and organizing those thoughts from a legal and community perspective.
>> I've also read a number of conversations from the more august members
>> of our body about this subject. Altogether it has somewhat changed
>> some of my opinions and assumptions. I've also sensed that there is a
>> community/business/legal disconnect in our conversations. We're using
>> the same words to mean very different things in each of those
>> contexts. That said I am but one member of the IPMC, but maybe this
>> will be helpful to someone else - I've tried to avoid my assumptions
>> in this.
>>
>> The IPMC's first 'job'[1] is "accepting new products into the
>> Foundation" The second 'job' of the IPMC is to "provide guidance and
>> support to ensure that the Incubator's sub-projects[2] develop
>> products according to the Foundation's philosophy and guidelines". The
>> final 'job' is evaluating the products and determining whether they
>> should be abandoned, continue to receive guidance and support, or be
>> promoted to "full project status".
>>
>> So there are several realizations I gained from this from the
>> Incubator perspective.
>> 1. Acceptance into the Incubator is acceptance of the product into the
>> Foundation.
>> 2. That product is then a sub-project of the Incubator.
>> 3. The IPMC has the "primary responsibility for the management of
>> those subprojects".
>>
>> From the Foundation's perspective there are a number of things that
>> come to mind:
>> 1. We aren't a github/sourceforge/google code type platform where
>> random people can upload/post what they want.
>> 2. We do not have DMCA Safe Harbor protection - e.g. we are
>> responsible for everything that we publish or distribute. With the
>> exception of wikis and bug trackers anyone who can put something up on
>> an Apache property has some form of legal relationship with the
>> Foundation. This could be as simple as an ICLAs where you've
>> contractually said you won't contribute anything you don't have rights
>> to.
>> 3. Most of the project's who have come to us aren't entities in and of
>> themselves. E.g. the 'project' doesn't truly exist from a legal entity
>> perspective - and even those who do are at best an unincorporated
>> association of individuals. From a legal perspective - projects can't
>> make or distribute a release - they don't exist - only the ASF and the
>> individual(s) doing the work. Given that one of the explicit reasons
>> the Foundation was created was to[5]: "provide a means for individual
>> volunteers to be sheltered from legal suits"; we want them to create
>> and distribute releases as the Foundation.
>> 4. Whether we like it or not - the Foundation is judged on the output
>> from our projects and subprojects. We have a reputation of having
>> clean IP, permissively licensed open source code, with clear
>> provenance. Many people explicitly copy our standards, guidelines, and
>> policies because they are the gold standard for good open source
>> governance.
>> 5. Disclaimers generally don't remove liability, and even if they did,
>> our disclaimer talks about the maturity of our projects. - And it
>> certainly doesn't remove the public's expectations from us - frankly -
>> losing the publics trust is as scary as the potential legal liability.
>> 6. The Board has delegated the responsibility of managing and ensuring
>> adherence to policies and guidelines to the IPMC. I don't see this
>> responsibility as boolean. It's not perfect compliance vs. failure.
>> IMO, the IPMC has been delegated the decision making process, and may
>> often find themselves making the business decision that an imperfect
>> release is better than a community stalled for months or years. Don't
>> let the perfect be the enemy of the good.
>>
>> From a podling's perspective:
>> 1. Once you join the incubator you're a part of the ASF (Yay!?)
>> 2. Your project is now a subproject of the IPMC.
>> 3. There are rules, and you're entering a world of pain[4] In fact,
>> you're likely to find that the ASF has more rules and structure that
>> apply to projects than virtually any other home your project could
>> choose. This is good and bad.
>> 4. The incubator has a long, storied history of producing successful
>> projects that flourish.
>>
>>
>> [1]
>> http://apache.org/foundation/records/minutes/2002/board_minutes_2002_10_16.txt
>> [2] What we call Podlings, the initial resolution refers to as
>> subprojects of the Incubator
>> [3] It's worth noting that there were two resolutions proposed to
>> create the Incubator - small differences, but interesting to read the
>> differences.
>> [4] https://youtu.be/3vB9U2hx6Qg
>> [5] https://www.apache.org/foundation/faq.html#why
>>
>> ---------------------------------------------------------------------
>> 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: Podlings, the Incubator, relationships and Apache
Posted by David Nalley <da...@gnsa.us>.
On Sun, Jun 23, 2019 at 11:26 PM Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Sat, Jun 22, 2019 at 3:31 PM Rich Bowen <rb...@rcbowen.com> wrote:
> >
> > A couple of thoughts:
>
> And a couple of thoughts on top of that.
>
> > Podlings are not permitted to call themselves "Apache Foo" because they are
> > not yet full Apache projects.
>
> Correct. The I way I see this thread is this: *when it comes to
> releases*, there's
> always been two camps in Incubator. One thinks that Incubator is a TLP just
> like Apache Commons that happens to produce release artifacts that have
> nothing in common (just like Apache Commons' JXPath has very little to do
> with Compress and). A second camp thinks that Incubator is actually a special
> construct within a foundation (after all, if it was just like Apache Commons why
> would we make them put DISCLAIMER into release tarballs?).
>
> It seems that David is closer to the 1st camp, and Rich and I are
> closer to the 2nd.
>
Hmmm, I must be poorly communicating.
I feel like I am closer to the second camp.
I think I explicitly said that my belief is that management of the
incubating products has been delegated to the Incubator, and the
incubator should be making 'business decisions' that balance the
interest of complying with the rules (perfection) with the inertia of
the community.
> Looking at the community benefits, I really think we should acknowledge that
> Incubator is a special construct and optimize that special construct
> for a particular
> outcome: which is effectiveness of the graduation process.
>
> > While in the incubator we should expect podlibgs to fail at the rules.
> > They're new to them and many of them feel arbitrary, even capricious, to
> > those coming in from outside. We should make it safe to fail until they are
> > ready to graduate. We should nurture them as long as they are moving
> > towards that goal.
>
> Yup.
>
> > I cannot disagree with your reading of our resolutions. But I wonder if
> > that reality is producing good citizen projects or a bunch of resentful
> > people following rules they don't understand or embrace because they know
> > they have to.
> >
> > Zipkin is only the latest project which clearly didn't get it and has left
> > angry. I would rather a project realize that they don't fit and be able to
> > leave with their dignity without having also to leave hating what we stand
> > for.
> >
> > I want our new graduates to love and understand the ASF not merely tolerate
> > it.
> >
> > I want the incubator to respond to failure with gentle correction rather
> > than scoldings.
> >
> > Specifically I think podlings should be able to produce releases that are
> > not asf complient and have them clearly labeled as such. Because they are
> > not TLPs yet and so cannot be held to the same standard. This must be
> > accompanied by a movement towards being a TLP, not some eternal incubation.
>
Yep - I think a large part of this should be the mentors working with
the project on a path towards meeting the standard of the TLP. I think
far too often the current path we tell projects is 'work towards the
first release - and then expecting the first release to meet all of
the standards. The first project I brought to the incubator spent 7
months trying to reach that acceptable state for release, so I am
familiar with the pain and the antagonism it breeds.
> With my IPMC member hat on -- huge +1 to the above.
>
> With my VP Legal hat on: I have no dog in this race. The IPMC needs to make
> a *business* (well, community in this case) decision and then we can work
> with a risk profile of that decision.
I wholeheartedly agree with you, and appreciate you making this
statement with the hat on.
IMO this should settle any concerns that the IPMC has about their
level of authority to make those decisions.
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Paul King <pa...@asert.com.au>.
My +1 to the 2nd camp. For me it's about transparency.
I don't see an issue if a podling release has some significant flaws. For
me, the ideal would be if it is easy for podling members, reviewers, and
downstream users to easily determine whether such flaws are known and what
they are. It can be as simple as a line in the release notes or release
email and/or an easily findable issue or two.
On Mon, Jun 24, 2019 at 9:01 PM Jim Jagielski <ji...@jagunet.com> wrote:
> ++1. I agree w/ Rich and Roman
>
> > On Jun 23, 2019, at 11:25 PM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
> >
> > On Sat, Jun 22, 2019 at 3:31 PM Rich Bowen <rbowen@rcbowen.com <mailto:
> rbowen@rcbowen.com>> wrote:
> >>
> >> A couple of thoughts:
> >
> > And a couple of thoughts on top of that.
> >
> >> Podlings are not permitted to call themselves "Apache Foo" because they
> are
> >> not yet full Apache projects.
> >
> > Correct. The I way I see this thread is this: *when it comes to
> > releases*, there's
> > always been two camps in Incubator. One thinks that Incubator is a TLP
> just
> > like Apache Commons that happens to produce release artifacts that have
> > nothing in common (just like Apache Commons' JXPath has very little to
> do
> > with Compress and). A second camp thinks that Incubator is actually a
> special
> > construct within a foundation (after all, if it was just like Apache
> Commons why
> > would we make them put DISCLAIMER into release tarballs?).
> >
> > It seems that David is closer to the 1st camp, and Rich and I are
> > closer to the 2nd.
> >
> > Looking at the community benefits, I really think we should acknowledge
> that
> > Incubator is a special construct and optimize that special construct
> > for a particular
> > outcome: which is effectiveness of the graduation process.
> >
> >> While in the incubator we should expect podlibgs to fail at the rules.
> >> They're new to them and many of them feel arbitrary, even capricious, to
> >> those coming in from outside. We should make it safe to fail until they
> are
> >> ready to graduate. We should nurture them as long as they are moving
> >> towards that goal.
> >
> > Yup.
> >
> >> I cannot disagree with your reading of our resolutions. But I wonder if
> >> that reality is producing good citizen projects or a bunch of resentful
> >> people following rules they don't understand or embrace because they
> know
> >> they have to.
> >>
> >> Zipkin is only the latest project which clearly didn't get it and has
> left
> >> angry. I would rather a project realize that they don't fit and be able
> to
> >> leave with their dignity without having also to leave hating what we
> stand
> >> for.
> >>
> >> I want our new graduates to love and understand the ASF not merely
> tolerate
> >> it.
> >>
> >> I want the incubator to respond to failure with gentle correction rather
> >> than scoldings.
> >>
> >> Specifically I think podlings should be able to produce releases that
> are
> >> not asf complient and have them clearly labeled as such. Because they
> are
> >> not TLPs yet and so cannot be held to the same standard. This must be
> >> accompanied by a movement towards being a TLP, not some eternal
> incubation.
> >
> > With my IPMC member hat on -- huge +1 to the above.
> >
> > With my VP Legal hat on: I have no dog in this race. The IPMC needs to
> make
> > a *business* (well, community in this case) decision and then we can work
> > with a risk profile of that decision.
> >
> > Like I said -- the decision to make is: 1st vs. 2nd camp.
> >
> > Thanks,
> > Roman.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> <ma...@incubator.apache.org>
> > For additional commands, e-mail: general-help@incubator.apache.org
> <ma...@incubator.apache.org>
>
Re: Podlings, the Incubator, relationships and Apache
Posted by Jim Jagielski <ji...@jaguNET.com>.
++1. I agree w/ Rich and Roman
> On Jun 23, 2019, at 11:25 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Sat, Jun 22, 2019 at 3:31 PM Rich Bowen <rbowen@rcbowen.com <ma...@rcbowen.com>> wrote:
>>
>> A couple of thoughts:
>
> And a couple of thoughts on top of that.
>
>> Podlings are not permitted to call themselves "Apache Foo" because they are
>> not yet full Apache projects.
>
> Correct. The I way I see this thread is this: *when it comes to
> releases*, there's
> always been two camps in Incubator. One thinks that Incubator is a TLP just
> like Apache Commons that happens to produce release artifacts that have
> nothing in common (just like Apache Commons' JXPath has very little to do
> with Compress and). A second camp thinks that Incubator is actually a special
> construct within a foundation (after all, if it was just like Apache Commons why
> would we make them put DISCLAIMER into release tarballs?).
>
> It seems that David is closer to the 1st camp, and Rich and I are
> closer to the 2nd.
>
> Looking at the community benefits, I really think we should acknowledge that
> Incubator is a special construct and optimize that special construct
> for a particular
> outcome: which is effectiveness of the graduation process.
>
>> While in the incubator we should expect podlibgs to fail at the rules.
>> They're new to them and many of them feel arbitrary, even capricious, to
>> those coming in from outside. We should make it safe to fail until they are
>> ready to graduate. We should nurture them as long as they are moving
>> towards that goal.
>
> Yup.
>
>> I cannot disagree with your reading of our resolutions. But I wonder if
>> that reality is producing good citizen projects or a bunch of resentful
>> people following rules they don't understand or embrace because they know
>> they have to.
>>
>> Zipkin is only the latest project which clearly didn't get it and has left
>> angry. I would rather a project realize that they don't fit and be able to
>> leave with their dignity without having also to leave hating what we stand
>> for.
>>
>> I want our new graduates to love and understand the ASF not merely tolerate
>> it.
>>
>> I want the incubator to respond to failure with gentle correction rather
>> than scoldings.
>>
>> Specifically I think podlings should be able to produce releases that are
>> not asf complient and have them clearly labeled as such. Because they are
>> not TLPs yet and so cannot be held to the same standard. This must be
>> accompanied by a movement towards being a TLP, not some eternal incubation.
>
> With my IPMC member hat on -- huge +1 to the above.
>
> With my VP Legal hat on: I have no dog in this race. The IPMC needs to make
> a *business* (well, community in this case) decision and then we can work
> with a risk profile of that decision.
>
> Like I said -- the decision to make is: 1st vs. 2nd camp.
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org <ma...@incubator.apache.org>
> For additional commands, e-mail: general-help@incubator.apache.org <ma...@incubator.apache.org>
Re: Podlings, the Incubator, relationships and Apache
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Only because IPMC said it must provide such votes.
Can you provide a reference to that? I realise that may be hard to do so given it was so long ago.
I searched and was unable to find where that happened in the the list history. The earliest reference I could find was this [1] (in 2004), and this a little later [3] refers to the incubator release process. It certainly seems that the current situation is not new e.g. [3] (2004) and [4] (2003). The Wayback Machine is a little more helpful and gives this in 2002 [5] which states incubating communities need to follow Apache voting rules, and this page [6] says that 3 +1 binding votes are required for releases. It seems that PPMC concept comes in a little later [4] (which is quite an interesting thread). From what I can see, 3+1 binding votes was either a community norm when the IPMC was founded (in 2002) or was introduced very shortly after (in 2003) and has continued to be used since then.
A lot of people have not been around that long and don’t know the history of this (including me).
The current voting process is the same as what any other TLP does and follows the foundation policy on voting on releases [4]
> Others disagree, and want an answer from Legal. Roman seems amenable, if the IPMC has the will to
> formally ask.
The question has already been asked and an answer given deepening on how you view podling releases. It might need some further discussion.
> But even if you ignore the age, a PMC was constructed by the Board with the
> *duty* to onboard new groups.
Consider seriously for a moment if another TLP project just announced that anyone's vote was binding, not only PMC members. How would the Board view that? Do the ASF bylaws even allow that?
Thanks,
Justin
1. https://lists.apache.org/thread.html/e56c6b37c1cace4689e92f7d7c3d53aadb1d57e01325883baf16af63@1098344049@%3Cpmc.incubator.apache.org%3E
2. https://lists.apache.org/thread.html/04a010f79694079c5ed555e98944770f0df9fae1684a526b5c5e7b9c@1134067119@%3Cpmc.incubator.apache.org%3E
3. https://lists.apache.org/thread.html/490ab2392c21843d941e1ccee03982f533cc512cd3356608333c549a@1074121745@%3Cgeneral.incubator.apache.org%3E
4. https://www.apache.org/foundation/voting.html#ReleaseVotes
5. https://web.archive.org/web/20030205015159/http://incubator.apache.org/process.html
6. https://web.archive.org/web/20030205072727/http://incubator.apache.org/drafts/voting.html
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Jun 27, 2019 at 4:24 PM Sam Ruby <ru...@intertwingly.net> wrote:
> On Thu, Jun 27, 2019 at 7:57 AM Greg Stein <gs...@gmail.com> wrote:
> >
> > On Thu, Jun 27, 2019 at 12:13 AM Justin Mclean <justin@classsoftware.com
> >
> > wrote:
> >
> > > > b) It listed as a TLP in Whimsy
> >
> > Whimsy is not canonical. Its label means absolutely nothing. Board
> > decisions are canonical.
>
> The canonical source is:
>
> https://svn.apache.org/repos/private/committers/board/committee-info.txt
Sure. The label "TLP" (aka "PMC") comes from the Board resolution, and
maintained on an ongoing basis in that file.
Just trying to answer Justin's 3 questions.
-g
Re: Podlings, the Incubator, relationships and Apache
Posted by Sam Ruby <ru...@intertwingly.net>.
On Thu, Jun 27, 2019 at 7:57 AM Greg Stein <gs...@gmail.com> wrote:
>
> On Thu, Jun 27, 2019 at 12:13 AM Justin Mclean <ju...@classsoftware.com>
> wrote:
>
> > > b) It listed as a TLP in Whimsy
>
> Whimsy is not canonical. Its label means absolutely nothing. Board
> decisions are canonical.
The canonical source is:
https://svn.apache.org/repos/private/committers/board/committee-info.txt
This source is nearly always updated via Whimsy roster tool as that
keeps LDAP in sync. The sectary also uses the Whimsy agenda tool to
update this information.
The Whimsy roster tool also provides a convenient mechanism to query
this information.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Jun 27, 2019 at 12:13 AM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > Which would be a reasonable assumption give:
> > a) That only IPMC votes are binding on releases.
>
Only because IPMC said it must provide such votes. I maintain it does not
have to. The Board gave the Incubator the range/duty for incubating
projects. That allows for podlings to use our infrastructure (mailing
lists, jira, dist.apache, cwiki, etc) and to make their releases. Within
that duty assigned by the Board, it can apply alternate rules to releases.
I state that permission is already given. Others disagree, and want an
answer from Legal. Roman seems amenable, if the IPMC has the will to
formally ask.
> > b) It listed as a TLP in Whimsy
>
Whimsy is not canonical. Its label means absolutely nothing. Board
decisions are canonical.
> > c) The resolution that formed it uses the same language as a TLP and
> talks abut forming a PMC and assigning a VP [1]
>
That was in 2002. Establishing any PMC was a pretty new thing.
But even if you ignore the age, a PMC was constructed by the Board with the
*duty* to onboard new groups. It says nothing about holding releases to any
specific policy.
-g
Re: Podlings, the Incubator, relationships and Apache
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Which would be a reasonable assumption give:
> a) That only IPMC votes are binding on releases.
> b) It listed as a TLP in Whimsy
> c) The resolution that formed it uses the same language as a TLP and talks abut forming a PMC and assigning a VP [1]
>
> Does anyone know the history behind this, in particular a)? Has it been that way from day one or way it something that was introduced due to some an issue of some sort?
Anyone?
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Correct. The I way I see this thread is this: *when it comes to
> releases*, there’s always been two camps in Incubator. One thinks that Incubator is a TLP…
Which would be a reasonable assumption give:
a) That only IPMC votes are binding on releases.
b) It listed as a TLP in Whimsy
c) The resolution that formed it uses the same language as a TLP and talks abut forming a PMC and assigning a VP [1]
Does anyone know the history behind this, in particular a)? Has it been that way from day one or way it something that was introduced due to some an issue of some sort?
Do people think it should be a president's committee instead? (ducks) :-)
Thanks,
Justin
1. https://svn.apache.org/repos/infra/websites/production/incubator/content/official/resolution.html
Re: Podlings, the Incubator, relationships and Apache
Posted by Alex Harui <ah...@adobe.com.INVALID>.
IMO, there's an actual test case going on right now. On 6/14, the Weex folks asked about an LGPL dependency which became LEGAL-464. Personally, I think it could be classified as a "runtime/platform" so that the CatX rules don't apply. But they have been held up for 9 days and counting.
Who could/should make the call that they should just put their packages on dist.a.o assuming it is a runtime and over time fix things, or must they wait for a careful analysis?
-Alex
On 6/23/19, 8:26 PM, "Roman Shaposhnik" <ro...@shaposhnik.org> wrote:
On Sat, Jun 22, 2019 at 3:31 PM Rich Bowen <rb...@rcbowen.com> wrote:
>
> A couple of thoughts:
And a couple of thoughts on top of that.
> Podlings are not permitted to call themselves "Apache Foo" because they are
> not yet full Apache projects.
Correct. The I way I see this thread is this: *when it comes to
releases*, there's
always been two camps in Incubator. One thinks that Incubator is a TLP just
like Apache Commons that happens to produce release artifacts that have
nothing in common (just like Apache Commons' JXPath has very little to do
with Compress and). A second camp thinks that Incubator is actually a special
construct within a foundation (after all, if it was just like Apache Commons why
would we make them put DISCLAIMER into release tarballs?).
It seems that David is closer to the 1st camp, and Rich and I are
closer to the 2nd.
Looking at the community benefits, I really think we should acknowledge that
Incubator is a special construct and optimize that special construct
for a particular
outcome: which is effectiveness of the graduation process.
> While in the incubator we should expect podlibgs to fail at the rules.
> They're new to them and many of them feel arbitrary, even capricious, to
> those coming in from outside. We should make it safe to fail until they are
> ready to graduate. We should nurture them as long as they are moving
> towards that goal.
Yup.
> I cannot disagree with your reading of our resolutions. But I wonder if
> that reality is producing good citizen projects or a bunch of resentful
> people following rules they don't understand or embrace because they know
> they have to.
>
> Zipkin is only the latest project which clearly didn't get it and has left
> angry. I would rather a project realize that they don't fit and be able to
> leave with their dignity without having also to leave hating what we stand
> for.
>
> I want our new graduates to love and understand the ASF not merely tolerate
> it.
>
> I want the incubator to respond to failure with gentle correction rather
> than scoldings.
>
> Specifically I think podlings should be able to produce releases that are
> not asf complient and have them clearly labeled as such. Because they are
> not TLPs yet and so cannot be held to the same standard. This must be
> accompanied by a movement towards being a TLP, not some eternal incubation.
With my IPMC member hat on -- huge +1 to the above.
With my VP Legal hat on: I have no dog in this race. The IPMC needs to make
a *business* (well, community in this case) decision and then we can work
with a risk profile of that decision.
Like I said -- the decision to make is: 1st vs. 2nd camp.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Tue, Jun 25, 2019 at 8:07 PM Sam Ruby <ru...@intertwingly.net> wrote:
>
> On Mon, Jun 24, 2019 at 12:12 PM Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> >
> > On Sun, Jun 23, 2019 at 11:03 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> > >
> > > But, IMO, the reason the question went to VP Legal is that it doesn't really matter what the IPMC thinks if their "business decision" will have an impact on the "Legal Shield" and the insurance premiums that go with it. So I think the question got lost on legal-discuss. The "space of options" should probably be constrained by the "Legal Shield".
> >
> > Nope. That's not how any of the legal works. Legal never makes policy
> > -- legal always evaluates risk profiles of the policy that business
> > stakeholders make.
> >
> > In fact, and thin may come as a shock, legal never *blocks* anything.
> > Legal doesn't have veto power simply because the business decision
> > always trupms legal.
>
> Please interpret the following statement extremely narrowly: the Legal
> Affairs committee is a board committee. Read section 5.9 of the ASF
> bylaws.
>
> I believe that the correct way to interpret this is that the Legal
> Committee (and therefore, VP, Legal) is empowered to make business
> decisions on behalf of the ASF. This would include pulling a release
> or disbanding a committee.
>
> Now I'm not suggesting that you start vetoing anything. I'm just
> saying that should you find yourself in a position where a veto is
> necessary, don't question whether or not you have that authority.
No disagreement there and good clarification.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Sam Ruby <ru...@intertwingly.net>.
On Mon, Jun 24, 2019 at 12:12 PM Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Sun, Jun 23, 2019 at 11:03 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> >
> > But, IMO, the reason the question went to VP Legal is that it doesn't really matter what the IPMC thinks if their "business decision" will have an impact on the "Legal Shield" and the insurance premiums that go with it. So I think the question got lost on legal-discuss. The "space of options" should probably be constrained by the "Legal Shield".
>
> Nope. That's not how any of the legal works. Legal never makes policy
> -- legal always evaluates risk profiles of the policy that business
> stakeholders make.
>
> In fact, and thin may come as a shock, legal never *blocks* anything.
> Legal doesn't have veto power simply because the business decision
> always trupms legal.
Please interpret the following statement extremely narrowly: the Legal
Affairs committee is a board committee. Read section 5.9 of the ASF
bylaws.
I believe that the correct way to interpret this is that the Legal
Committee (and therefore, VP, Legal) is empowered to make business
decisions on behalf of the ASF. This would include pulling a release
or disbanding a committee.
Now I'm not suggesting that you start vetoing anything. I'm just
saying that should you find yourself in a position where a veto is
necessary, don't question whether or not you have that authority.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Myrle Krantz <my...@apache.org>.
Hey Alex,
The Incubator plays a special role. We should be willing to take on some
risks in the process of helping newer, or older projects adjust to us. But
once those adjustments are complete, we should be able to expect TLP's to
"color in the lines".
If you believe that is impossible for your project for some reason, then
you may be trying to do something that just doesn't belong at Apache. Or
you may have found something about Apache that needs to change. Either
way, this isn't the right forum. Many others here have said it too: the
incubator is not the right place to be looking for an exception to the
rules for your favorite TLP. If you want answers to a concrete question,
please bring it to board@a.o, or, if you would prefer to ask in public,
consider dev@community.a.o.
Please don't be looking for ways to leverage decisions that are
special-made for the incubator to find loopholes for a TLP.
Best Regards,
Myrle
On Mon, Jul 1, 2019 at 7:45 AM Alex Harui <ah...@adobe.com.invalid> wrote:
> FWIW, I reconcile it as:
>
> Incubator is a PMC and must record a business decision to call something
> an ASF release in order to place that release under the legal protection of
> the ASF. ASF releases may have policy non-compliance issues. No TLP can
> decide on its own to never comply with policy. But the business decision
> of the costs of delaying a release to correct non-compliance vs risks of
> distributing a release with any non-compliance is up to the TLP. VP Legal
> will assert a risk profile for any non-compliance and VP Legal or any ASF
> Member or PMC Member should try to stop a release if a TLP decides to
> distribute something highly risky. But it is up to any TLP. Including
> the IPMC. And so the Incubator can do whatever it wants within limits.
> Any of us should protest if the IPMC starts allowing releases with high
> risk. But with the disclaimer and -incubating suffixes, the risk of many
> non-compliance issues are low, even CatX and binary inclusions.
>
> Whether the incubator needs to have a secondary vote is not required by
> the above. IPMC members could drop in on the podling vote thread.
> Podlings with 3 active mentors that vote on the podling's vote thread could
> be deemed sufficient.
>
> My 2 cents,
> -Alex
>
> On 6/30/19, 12:11 PM, "Davor Bonaci" <da...@apache.org> wrote:
>
> I do -not- have a problem where this is all tracking towards and
> believe it
> is right, but I do have a problem with how it is justified and
> explained.
>
> People say: "Incubator is a PMC/TLP", "Incubator takes on the resultant
> legal obligations associated w/ any PMC doing a release", "we can NOT
> allow
> any relaxation of the ASF release policy for a TLP", and then conclude
> that
> Incubator can do ~whatever it wants. This logic does not pass the
> consistency test.
>
> So... if you want that [new] people in the future don't trip on this,
> it is
> *necessary* to break this logic somehow.
>
> On Fri, Jun 28, 2019 at 8:31 PM Greg Stein <gs...@gmail.com> wrote:
>
> > On Fri, Jun 28, 2019 at 9:59 PM Justin Mclean <
> justin@classsoftware.com>
> > wrote:
> > >...
> >
> > > > It appears there is general consensus that "right to distribute
> > closed
> > > source" would be the main and potentially only blocker for
> podlings.
> > >
> > > That is not the case (re this is a blocker) I suggest you read
> that legal
> > > thread again. Also infra makes distribution policy.
> > >
> >
> > *distribution*
> >
> > Infra does not care about the contents. If a PMC says "we +1 the
> contents",
> > then Infra will not second-guess that. Leave out LICENSE, NOTICE, or
> do
> > those files wrong. Include jars, Cat X source. Whatever. We aren't
> going to
> > police that. Binaries in there? Knock yourself out. Legal might get
> on your
> > case, but that's Not Our Problem(tm).
> >
> > If the IPMC says "here is a podling tarball that we will allow",
> then it
> > can be put into distribution. Use whatever rules you want for the
> contents,
> > or lack of rules. Infra just wants it placed into our distribution
> system
> > in a specific way, to ensure correctness, auditing, and resilience.
> >
> > VP Infra has already stated the above. As an Officer of
> Infrastructure, I
> > concur and reiterate that position.
> >
> > Regards,
> > Greg Stein
> > InfraAdmin, ASF
> >
>
>
>
Re: Podlings, the Incubator, relationships and Apache
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jul 3, 2019, at 1:01 AM, Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
>> Jim said "Let's also recall that the origin genesis of the Incubator was NOT to provide legal oversight, but rather education and guidance into The Apache Way”
>
> If you look at the history threads I posted the other day one was about “legal oversight” way back in 2004.
>
There is history behind the Incubator from before 2004... Consider that the Incubator itself was created in late 2002 with:
"""
charged with
accepting new products into the Foundation, providing guidance
and support to help each new product engender their own
collaborative community, educating new developers in the
philosophy and guidelines for collaborative development as
defined by the members of the Foundation, and proposing to the
board the promotion of such products to independent PMC
status once their community has reached maturity.
"""
I am NOT discounting the importance of legal oversight. Far from it. Our legal protection is semi-worthless unless we take it seriously and ensure the correct checks. My position is rather that, IMO, most of the issues that podlings face, and even graduated TLPs, are not issues related to the legal matters but in understanding, groking and embracing The Apache Way, which was kind of the point at the very beginning.
If you consistently dilute a vaccine, after awhile, it will become useless.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Jim said "Let's also recall that the origin genesis of the Incubator was NOT to provide legal oversight, but rather education and guidance into The Apache Way”
If you look at the history threads I posted the other day one was about “legal oversight” way back in 2004.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Dave Fisher <da...@comcast.net>.
All we need is a simple pivot back. This is the closest, easiest path. Prioritize and ease the acceptance of the Apache Way.
Our current Disclaimer is enough. If governing in the way then the path to a PMC is eased.
We need to assure that the lessons from all versions of the Incubator are considered. I’ve attempted to resurrect the Clutch.
Warm Regards,
Dave
Sent from my iPhone
> On Jul 2, 2019, at 9:29 PM, Ross Gardler <rg...@outlook.com> wrote:
>
> Jim said "Let's also recall that the origin genesis of the Incubator was NOT to provide legal oversight, but rather education and guidance into The Apache Way"
>
> I say... HEAR! HEAR!
>
> Get Outlook for Android<https://aka.ms/ghei36>
>
> ________________________________
> From: Jim Jagielski <ji...@jaguNET.com>
> Sent: Tuesday, July 2, 2019 4:36:02 AM
> To: Incubator General
> Subject: Re: Podlings, the Incubator, relationships and Apache
>
>
>
>> On Jul 1, 2019, at 1:45 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> FWIW, I reconcile it as:
>>
>> Incubator is a PMC and must record a business decision to call something an ASF release in order to place that release under the legal protection of the ASF. ASF releases may have policy non-compliance issues. No TLP can decide on its own to never comply with policy. But the business decision of the costs of delaying a release to correct non-compliance vs risks of distributing a release with any non-compliance is up to the TLP. VP Legal will assert a risk profile for any non-compliance and VP Legal or any ASF Member or PMC Member should try to stop a release if a TLP decides to distribute something highly risky. But it is up to any TLP. Including the IPMC. And so the Incubator can do whatever it wants within limits. Any of us should protest if the IPMC starts allowing releases with high risk. But with the disclaimer and -incubating suffixes, the risk of many non-compliance issues are low, even CatX and binary inclusions.
>>
>> Whether the incubator needs to have a secondary vote is not required by the above. IPMC members could drop in on the podling vote thread. Podlings with 3 active mentors that vote on the podling's vote thread could be deemed sufficient.
>>
>
> Although not a "real" PMC, we do need to provide legal protection for each PPMC and distributing releases is the time that most legal considerations "kick in" as it were. So we need a clear "paper trail" of approvals for that PPMC to enjoy the legal protection the foundation exists to provide. The IPMC vote, since the IPMC is, in fact, a true PMC, provides that legal provenance such that, should anything untoward happen, we can clearly show to outside legal entities corporate provenance without having to try to explain the intricacies of podlings, and PPMCs and PMC and et.al. :-)
>
> Let's also recall that the origin genesis of the Incubator was NOT to provide legal oversight, but rather education and guidance into The Apache Way (TAW). Back then we had way too many projects that were TLP status that lacked even a basic awareness of TAW, and the board, rightfully, considered that a huge problem (this started with the mismanagement of the Jakarta project, which tried to create a sub-foundation within the ASF such that the Jakarta PMC was basically the "board" of that "foundation"... as these projects spun out, problems aplenty ensued). And so the Incubator was created to handle that problem.
> ---------------------------------------------------------------------
> 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: Podlings, the Incubator, relationships and Apache
Posted by Ross Gardler <rg...@outlook.com>.
Jim said "Let's also recall that the origin genesis of the Incubator was NOT to provide legal oversight, but rather education and guidance into The Apache Way"
I say... HEAR! HEAR!
Get Outlook for Android<https://aka.ms/ghei36>
________________________________
From: Jim Jagielski <ji...@jaguNET.com>
Sent: Tuesday, July 2, 2019 4:36:02 AM
To: Incubator General
Subject: Re: Podlings, the Incubator, relationships and Apache
> On Jul 1, 2019, at 1:45 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> FWIW, I reconcile it as:
>
> Incubator is a PMC and must record a business decision to call something an ASF release in order to place that release under the legal protection of the ASF. ASF releases may have policy non-compliance issues. No TLP can decide on its own to never comply with policy. But the business decision of the costs of delaying a release to correct non-compliance vs risks of distributing a release with any non-compliance is up to the TLP. VP Legal will assert a risk profile for any non-compliance and VP Legal or any ASF Member or PMC Member should try to stop a release if a TLP decides to distribute something highly risky. But it is up to any TLP. Including the IPMC. And so the Incubator can do whatever it wants within limits. Any of us should protest if the IPMC starts allowing releases with high risk. But with the disclaimer and -incubating suffixes, the risk of many non-compliance issues are low, even CatX and binary inclusions.
>
> Whether the incubator needs to have a secondary vote is not required by the above. IPMC members could drop in on the podling vote thread. Podlings with 3 active mentors that vote on the podling's vote thread could be deemed sufficient.
>
Although not a "real" PMC, we do need to provide legal protection for each PPMC and distributing releases is the time that most legal considerations "kick in" as it were. So we need a clear "paper trail" of approvals for that PPMC to enjoy the legal protection the foundation exists to provide. The IPMC vote, since the IPMC is, in fact, a true PMC, provides that legal provenance such that, should anything untoward happen, we can clearly show to outside legal entities corporate provenance without having to try to explain the intricacies of podlings, and PPMCs and PMC and et.al. :-)
Let's also recall that the origin genesis of the Incubator was NOT to provide legal oversight, but rather education and guidance into The Apache Way (TAW). Back then we had way too many projects that were TLP status that lacked even a basic awareness of TAW, and the board, rightfully, considered that a huge problem (this started with the mismanagement of the Jakarta project, which tried to create a sub-foundation within the ASF such that the Jakarta PMC was basically the "board" of that "foundation"... as these projects spun out, problems aplenty ensued). And so the Incubator was created to handle that problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Ted Dunning <te...@gmail.com>.
In the incubator, leadership is also very important.
On Wed, Jul 3, 2019 at 11:50 AM Daniel Shahaf <d....@daniel.shahaf.name>
wrote:
> Guys, aren't you forgetting something? The VP is to sign the Board
> report. Everything else that Justin is doing he's doing as a rank and
> file Incubator committer. If you disagree with Justin, that's one
> thing, but his being VP is orthogonal to your disagreement.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Podlings, the Incubator, relationships and Apache
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Guys, aren't you forgetting something? The VP is to sign the Board report.
And not even that. All I do is ensure the report is submitted on time, no signing is involved, and while I generally write the majority of the report anyone can contribute or help out in doing that.
> Everything else that Justin is doing he's doing as a rank and file Incubator committer.
In case it’s unclear anytime I do something (like vote on a release or email this list) it’s as an IPMC member and my view carries no more weight than other IPMC members.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Dave Fisher <da...@comcast.net>.
+1.
> On Jul 3, 2019, at 11:49 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>
> Guys, aren't you forgetting something? The VP is to sign the Board
> report. Everything else that Justin is doing he's doing as a rank and
> file Incubator committer. If you disagree with Justin, that's one
> thing, but his being VP is orthogonal to your disagreement.
>
> ---------------------------------------------------------------------
> 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: Podlings, the Incubator, relationships and Apache
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Guys, aren't you forgetting something? The VP is to sign the Board
report. Everything else that Justin is doing he's doing as a rank and
file Incubator committer. If you disagree with Justin, that's one
thing, but his being VP is orthogonal to your disagreement.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Ted Dunning <te...@gmail.com>.
Let me add my vote of full confidence in Justin as VP Incubator. He is
doing an excellent job.
On Wed, Jul 3, 2019 at 11:41 AM Roman Shaposhnik <ro...@shaposhnik.org>
wrote:
> On Wed, Jul 3, 2019 at 4:48 AM Greg Stein <gs...@gmail.com> wrote:
> > > > IMO, stop being pessimistic. Move forward with change to stop the
> gating,
> > > > and let podlings do their releases without all the IPMC burden.
> > >
> > > We want to be at “D” or “E” , we’re currently at “A” and there's a few
> > > steps that need to be taken. I don’t believe the IPMC can just say
> “make it
> > > so” and move from “A" to “E”. We also need consensus which I don’t
> believe
> > > we have yet, so we might end up at “F” or “G”. Also if we make this
> > > position “offical”, it will stop the same issue from reoccurring in the
> > > future. It has occurred every few years since the incubator has
> existed as
> > > far as I can tell. Well that’s the way I see it anyway, you and others
> may
> > > see it differently.
> > >
> >
> > I have zero confidence that you will move the pin here. You have shown
> zero
> > willingness. I'd like to see a new VP Incubator.
>
> And I would HATE to see a new VP Incubator (and I think a lot of podlings
> would
> agree with that). As a former VP Incubator I just wanted to acknowledge
> that
> Justin has probably done more than any other VP around here. He's pedantic
> at times and not of the "move fast and break things" mentality (like Greg)
> but
> he's the reason I'm still willing to be on the IPMC (I don't have any
> active podling
> to mentor).
>
> Greg, you've been very helpful on this thread -- but this email ain't so.
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Podlings, the Incubator, relationships and Apache
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Wed, Jul 3, 2019 at 4:48 AM Greg Stein <gs...@gmail.com> wrote:
> > > IMO, stop being pessimistic. Move forward with change to stop the gating,
> > > and let podlings do their releases without all the IPMC burden.
> >
> > We want to be at “D” or “E” , we’re currently at “A” and there's a few
> > steps that need to be taken. I don’t believe the IPMC can just say “make it
> > so” and move from “A" to “E”. We also need consensus which I don’t believe
> > we have yet, so we might end up at “F” or “G”. Also if we make this
> > position “offical”, it will stop the same issue from reoccurring in the
> > future. It has occurred every few years since the incubator has existed as
> > far as I can tell. Well that’s the way I see it anyway, you and others may
> > see it differently.
> >
>
> I have zero confidence that you will move the pin here. You have shown zero
> willingness. I'd like to see a new VP Incubator.
And I would HATE to see a new VP Incubator (and I think a lot of podlings would
agree with that). As a former VP Incubator I just wanted to acknowledge that
Justin has probably done more than any other VP around here. He's pedantic
at times and not of the "move fast and break things" mentality (like Greg) but
he's the reason I'm still willing to be on the IPMC (I don't have any
active podling
to mentor).
Greg, you've been very helpful on this thread -- but this email ain't so.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Jul 3, 2019 at 1:07 AM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > Or we *don't* provide legal protections. That *is* what the disclaimer is
> > there for.
>
> For that to happen I think the disclaimer text would need to change, I’m
> assuming you don’t think that. Even so a DISCLAIMER doesn’t remove legal
> obligations.
>
What the heck are you talking about? "legal obligations"? ... A tarball is
placed on a server. People download. Done.
As long as we don't include stolen source, then ... whatever.
Of course, the disclaimer changes. It should say "The Foundation doesn't
endorse this. It is an artifact produced by a third party, and we make no
guarantees on licensing, functionality, or security."
> I don't recall that advice. In fact, Roman seemed to indicate Legal would
> > be just fine with that.
>
> Only if the incubator is not considered a TLP but is a special construct
> within the Foundation. Several people have indicated they see the incubator
> as a TLP.
>
Blah blah blah. Wordsmithing crap. The Incubator is a PMC. Period. Fact. It
can operate however it needs to, to achieve the outcome assigned by the
Board.
The Board told it to onboard communities.
The Board did *NOT* tell it to follow standard release policy. That's just
an invalid assumption.
> > IMO, stop being pessimistic. Move forward with change to stop the gating,
> > and let podlings do their releases without all the IPMC burden.
>
> We want to be at “D” or “E” , we’re currently at “A” and there's a few
> steps that need to be taken. I don’t believe the IPMC can just say “make it
> so” and move from “A" to “E”. We also need consensus which I don’t believe
> we have yet, so we might end up at “F” or “G”. Also if we make this
> position “offical”, it will stop the same issue from reoccurring in the
> future. It has occurred every few years since the incubator has existed as
> far as I can tell. Well that’s the way I see it anyway, you and others may
> see it differently.
>
I have zero confidence that you will move the pin here. You have shown zero
willingness. I'd like to see a new VP Incubator.
-g
Re: Podlings, the Incubator, relationships and Apache
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Or we *don't* provide legal protections. That *is* what the disclaimer is
> there for.
For that to happen I think the disclaimer text would need to change, I’m assuming you don’t think that. Even so a DISCLAIMER doesn’t remove legal obligations.
> I don't recall that advice. In fact, Roman seemed to indicate Legal would
> be just fine with that.
Only if the incubator is not considered a TLP but is a special construct within the Foundation. Several people have indicated they see the incubator as a TLP.
> IMO, stop being pessimistic. Move forward with change to stop the gating,
> and let podlings do their releases without all the IPMC burden.
We want to be at “D” or “E” , we’re currently at “A” and there's a few steps that need to be taken. I don’t believe the IPMC can just say “make it so” and move from “A" to “E”. We also need consensus which I don’t believe we have yet, so we might end up at “F” or “G”. Also if we make this position “offical”, it will stop the same issue from reoccurring in the future. It has occurred every few years since the incubator has existed as far as I can tell. Well that’s the way I see it anyway, you and others may see it differently.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Justin Mclean <ju...@me.com>.
Hi,
> No. The other way around. What are the expectation of protections that
> a legal shield is offering to PPMC *today*.
>
> IOW, what do folks expect ASF to provide.
Given the IPMC makes the release, isn’t the question more what protection does it give the IPMC? (And those people with binding +1 votes?). My expectation is that they would be covered by the legal shield.
Does that change if we consider those releases to not be acts of the foundation?
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Dave Fisher <da...@comcast.net>.
Sent from my iPhone
> On Jul 3, 2019, at 2:53 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
>> On Wed, Jul 3, 2019 at 2:13 PM Jim Jagielski <ji...@jagunet.com> wrote:
>>
>>
>>
>>>> On Jul 3, 2019, at 5:06 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>>>>
>>>>
>>>> 1. Podlings, and PPMC members, to enjoy the legal protection of the foundation when they do a release
>>>
>>> Let's be pedantic and define those in this particular case, shall we?
>>> What exactly are the expectations for PPMC members?
>>
>> Do you mean what does the ASF expect from PPMC members (ie: "What will the PPMC members do for the ASF")? Or do you mean what do PPMC members expect by the ASF ("What will the ASF do for PPMC members")?
>
> No. The other way around. What are the expectation of protections that
> a legal shield is offering to PPMC *today*.
>
> IOW, what do folks expect ASF to provide.
That’s the incentive for the PPMC Members and Release Manager to have a release with no issues to Disclaim. As Daniel write elsethread it is that point during Incubation that goal was met.
Best,
Dave
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> 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: Podlings, the Incubator, relationships and Apache
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Wed, Jul 3, 2019 at 2:13 PM Jim Jagielski <ji...@jagunet.com> wrote:
>
>
>
> > On Jul 3, 2019, at 5:06 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> >
> >>
> >> 1. Podlings, and PPMC members, to enjoy the legal protection of the foundation when they do a release
> >
> > Let's be pedantic and define those in this particular case, shall we?
> > What exactly are the expectations for PPMC members?
>
> Do you mean what does the ASF expect from PPMC members (ie: "What will the PPMC members do for the ASF")? Or do you mean what do PPMC members expect by the ASF ("What will the ASF do for PPMC members")?
No. The other way around. What are the expectation of protections that
a legal shield is offering to PPMC *today*.
IOW, what do folks expect ASF to provide.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jul 3, 2019, at 5:06 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
>>
>> 1. Podlings, and PPMC members, to enjoy the legal protection of the foundation when they do a release
>
> Let's be pedantic and define those in this particular case, shall we?
> What exactly are the expectations for PPMC members?
Do you mean what does the ASF expect from PPMC members (ie: "What will the PPMC members do for the ASF")? Or do you mean what do PPMC members expect by the ASF ("What will the ASF do for PPMC members")?
Re: Podlings, the Incubator, relationships and Apache
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Wed, Jul 3, 2019 at 1:59 PM Jim Jagielski <ji...@jagunet.com> wrote:
> > On Jul 3, 2019, at 2:37 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> >
> >
> > This is correct. Provided we *do* explicitly acknowledge that special
> > status of the Incubator.
> >
> > This acknowledgement will basically put podling source code releases
> > at the same level we have convenience binary releases. Which is: they
> > are NOT acts of the foundation.
> >
>
> IMO, we want 2 things:
>
> 1. Podlings, and PPMC members, to enjoy the legal protection of the foundation when they do a release
Let's be pedantic and define those in this particular case, shall we?
What exactly are the expectations for PPMC members?
> 2. The outside world, and esp downstream end-users, to know that podling releases should be expected to not be fully compliant with the normal expectations associated w/ PMC releases.
>
> #1 requires them to be acts of the foundation; #2 requires easily visible and discoverable disclaimers.
>
> Anything else just seems excessive and somewhat unwarranted, I think. Let's make it as easy as possible, and as painless as possible, for podlings to learn; Heck, at the start of The Apache Group and the ASF, we didn't do everything right; we tried some things and some failed. It's in the nature of education and mentoring. Making mistakes is not a problem; not learning from them is.
>
> After we resolve this, I *really* would like to switch the convo around to a discussion as deep, and as involved, but related to the other (IMO, more important) side of the Incubator coin: education in the Apache Way. So much derives from that... even the legal considerations of releases ultimately can be found there, IMO. And I still maintain that we do a Not-So-Good job here.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Jim Jagielski wrote on Wed, 03 Jul 2019 16:59 -0400:
> IMO, we want 2 things:
>
> 1. Podlings, and PPMC members, to enjoy the legal protection of the
> foundation when they do a release
>
> 2. The outside world, and esp downstream end-users, to know that
> podling releases should be expected to not be fully compliant with the
> normal expectations associated w/ PMC releases.
Re #2, I'd be concerned about two kinds of fallout:
A. Podling Foo releases non-compliant artifact. Downstream users apply the same expectations to Podling Bar.
B. Podling Foo releases non-compliant artifact. Downstream users apply the same expectations to PMC Baz.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> After we resolve this, I *really* would like to switch the convo around to a discussion as deep, and as involved, but related to the other (IMO, more important) side of the Incubator coin: education in the Apache Way. So much derives from that... even the legal considerations of releases ultimately can be found there, IMO. And I still maintain that we do a Not-So-Good job here.
+1000 I expect this to a be a difficult conversation as well (as it has been in the past). Some of this is because there are many different interpretations of the Apache Way and that who know it well may not be the best teachers. I mean no offence by that statement but say it because that knowledge is instinctual / unconscious and that makes it hard to explain and pass on, experts in any given field are not always the best teachers. hopefully we have exceptions here.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by David Nalley <da...@gnsa.us>.
On Wed, Jul 3, 2019 at 4:59 PM Jim Jagielski <ji...@jagunet.com> wrote:
>
>
>
> > On Jul 3, 2019, at 2:37 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> >
> >
> > This is correct. Provided we *do* explicitly acknowledge that special
> > status of the Incubator.
> >
> > This acknowledgement will basically put podling source code releases
> > at the same level we have convenience binary releases. Which is: they
> > are NOT acts of the foundation.
> >
>
> IMO, we want 2 things:
>
> 1. Podlings, and PPMC members, to enjoy the legal protection of the foundation when they do a release
>
> 2. The outside world, and esp downstream end-users, to know that podling releases should be expected to not be fully compliant with the normal expectations associated w/ PMC releases.
>
> #1 requires them to be acts of the foundation; #2 requires easily visible and discoverable disclaimers.
>
> Anything else just seems excessive and somewhat unwarranted, I think. Let's make it as easy as possible, and as painless as possible, for podlings to learn; Heck, at the start of The Apache Group and the ASF, we didn't do everything right; we tried some things and some failed. It's in the nature of education and mentoring. Making mistakes is not a problem; not learning from them is.
>
> After we resolve this, I *really* would like to switch the convo around to a discussion as deep, and as involved, but related to the other (IMO, more important) side of the Incubator coin: education in the Apache Way. So much derives from that... even the legal considerations of releases ultimately can be found there, IMO. And I still maintain that we do a Not-So-Good job here.
Well said Jim.
Mistakes are inevitable as long as humans are involved. Regardless of
the process we apply we aren't going to solve that. The incubator can
make 'business' decisions around that risk. However, our legal process
is only side of the coin, and while it's important - we should care
much more about perpetuating and communicating our culture vis-a-vis
the Apache Way.
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jul 3, 2019, at 2:37 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
>
> This is correct. Provided we *do* explicitly acknowledge that special
> status of the Incubator.
>
> This acknowledgement will basically put podling source code releases
> at the same level we have convenience binary releases. Which is: they
> are NOT acts of the foundation.
>
IMO, we want 2 things:
1. Podlings, and PPMC members, to enjoy the legal protection of the foundation when they do a release
2. The outside world, and esp downstream end-users, to know that podling releases should be expected to not be fully compliant with the normal expectations associated w/ PMC releases.
#1 requires them to be acts of the foundation; #2 requires easily visible and discoverable disclaimers.
Anything else just seems excessive and somewhat unwarranted, I think. Let's make it as easy as possible, and as painless as possible, for podlings to learn; Heck, at the start of The Apache Group and the ASF, we didn't do everything right; we tried some things and some failed. It's in the nature of education and mentoring. Making mistakes is not a problem; not learning from them is.
After we resolve this, I *really* would like to switch the convo around to a discussion as deep, and as involved, but related to the other (IMO, more important) side of the Incubator coin: education in the Apache Way. So much derives from that... even the legal considerations of releases ultimately can be found there, IMO. And I still maintain that we do a Not-So-Good job here.
Re: Podlings, the Incubator, relationships and Apache
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
David Nalley wrote on Wed, 03 Jul 2019 16:21 -0400:
> On Wed, Jul 3, 2019 at 2:38 PM Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> >
> > On Tue, Jul 2, 2019 at 10:27 PM Greg Stein <gs...@gmail.com> wrote:
> > >
> > > On Wed, Jul 3, 2019 at 12:10 AM Justin Mclean <ju...@classsoftware.com>
> > > wrote:
> > > >...
> > >
> > > > Hi,
> > > >
> > > > > Although not a "real" PMC, we do need to provide legal protection for
> > > > each PPMC and distributing releases is the time that most legal
> > > > considerations "kick in" as it were. So we need a
> > >
> > >
> > > Or we *don't* provide legal protections. That *is* what the disclaimer is
> > > there for.
> >
> > That's exactly the direction I personally would like this to go into.
> >
>
> As VP Legal, I think that's well within your bailiwick to make such a decision.
> As a member, I find that it's counter to one of the stated purposes of
> the Foundation - which is to shield individuals[1] and find it
> concerning that we are wanting to shift that back to the individual.
2017 - Project Foo is a non-Apache project
2018 - Project Foo has joined the Incubator
2019 - Project Foo graduated to PMC
Releases in 2017 are not Apache releases. Releases in 2019 are Apache
releases. Starting from some point in 2018 the Foo podling releases
should enter the legal shield — but that point needn't coincide with the
start of Incubation. Thus, instead of expecting that *every* release
made while in Incubation be an Apache release, expect that *eventually*
every release will be an Apache release.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by David Nalley <da...@gnsa.us>.
On Wed, Jul 3, 2019 at 2:38 PM Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Tue, Jul 2, 2019 at 10:27 PM Greg Stein <gs...@gmail.com> wrote:
> >
> > On Wed, Jul 3, 2019 at 12:10 AM Justin Mclean <ju...@classsoftware.com>
> > wrote:
> > >...
> >
> > > Hi,
> > >
> > > > Although not a "real" PMC, we do need to provide legal protection for
> > > each PPMC and distributing releases is the time that most legal
> > > considerations "kick in" as it were. So we need a
> >
> >
> > Or we *don't* provide legal protections. That *is* what the disclaimer is
> > there for.
>
> That's exactly the direction I personally would like this to go into.
>
As VP Legal, I think that's well within your bailiwick to make such a decision.
As a member, I find that it's counter to one of the stated purposes of
the Foundation - which is to shield individuals[1] and find it
concerning that we are wanting to shift that back to the individual.
> > > Which while I don’t disagree with, again I ask how can a PMC (i.e the
> > > incubator) make releases that are not in line with policy? Current advice
> > > seems that the board would not grant a blanket exception like to the IPMC
> >
> >
> > I don't recall that advice. In fact, Roman seemed to indicate Legal would
> > be just fine with that.
>
> This is correct. Provided we *do* explicitly acknowledge that special
> status of the Incubator.
>
> This acknowledgement will basically put podling source code releases
> at the same level we have convenience binary releases. Which is: they
> are NOT acts of the foundation.
>
As I've said elsewhere, I don't think that argument holds water. We
celebrate downloads of binaries with press releases, we adorn binaries
with cryptographic signatures that identify the content as originating
from us, we've entered into contractual agreements with vendors to
explicitly distribute binaries on our behalf. Download of binaries
from us, our mirrors, and our vendors dwarfs all of the other traffic
to our web properties by a huge margin. As a result a substantial
function of our operations - e.g. what the ASF actually spends money
is facilitating the download of binaries. By taking these actions, or
perhaps by not policing the fact that these actions have been taken,
we are essentially telling the world its something we've done, and not
something an individual has done.
I can't imagine a court saying that the binary of Apache Foo which is:
*uploaded by a member of the Foo PMC, a position granted to him by the
consent of the board of directors of the Foundation,
*signed by the official Foundation code signing keys,
* placed on the Apache.org web properties,
* linked to from foo.apache.org,
* announced in an official Apache press release,
* and with an Apache press release highlighting that we have eclipsed
5 million downloads of those same binaries
is the work of an individual and not the calculated effort of the
Foundation. That just doesn't pass the smell test.
--David
[1] https://www.apache.org/foundation/faq.html#why
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Tue, Jul 2, 2019 at 10:27 PM Greg Stein <gs...@gmail.com> wrote:
>
> On Wed, Jul 3, 2019 at 12:10 AM Justin Mclean <ju...@classsoftware.com>
> wrote:
> >...
>
> > Hi,
> >
> > > Although not a "real" PMC, we do need to provide legal protection for
> > each PPMC and distributing releases is the time that most legal
> > considerations "kick in" as it were. So we need a
>
>
> Or we *don't* provide legal protections. That *is* what the disclaimer is
> there for.
That's exactly the direction I personally would like this to go into.
> > Which while I don’t disagree with, again I ask how can a PMC (i.e the
> > incubator) make releases that are not in line with policy? Current advice
> > seems that the board would not grant a blanket exception like to the IPMC
>
>
> I don't recall that advice. In fact, Roman seemed to indicate Legal would
> be just fine with that.
This is correct. Provided we *do* explicitly acknowledge that special
status of the Incubator.
This acknowledgement will basically put podling source code releases
at the same level we have convenience binary releases. Which is: they
are NOT acts of the foundation.
> IMO, stop being pessimistic. Move forward with change to stop the gating,
> and let podlings do their releases without all the IPMC burden.
>
> >...
>
> > > Let's also recall that the origin genesis of the Incubator was NOT to
> > provide legal oversight
> >
> > That may be the original thought, but historical threads bring up legal
> > oversight very very early on. (I posted one from 2004 the other day).
> > Hopefully someone can explain this history?
> >
>
> Who cares? Red herring. We are where we are. Move forward from here.
+1000!
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Jul 3, 2019 at 12:10 AM Justin Mclean <ju...@classsoftware.com>
wrote:
>...
> Hi,
>
> > Although not a "real" PMC, we do need to provide legal protection for
> each PPMC and distributing releases is the time that most legal
> considerations "kick in" as it were. So we need a
Or we *don't* provide legal protections. That *is* what the disclaimer is
there for.
>...
> Which while I don’t disagree with, again I ask how can a PMC (i.e the
> incubator) make releases that are not in line with policy? Current advice
> seems that the board would not grant a blanket exception like to the IPMC
I don't recall that advice. In fact, Roman seemed to indicate Legal would
be just fine with that.
IMO, stop being pessimistic. Move forward with change to stop the gating,
and let podlings do their releases without all the IPMC burden.
>...
> > Let's also recall that the origin genesis of the Incubator was NOT to
> provide legal oversight
>
> That may be the original thought, but historical threads bring up legal
> oversight very very early on. (I posted one from 2004 the other day).
> Hopefully someone can explain this history?
>
Who cares? Red herring. We are where we are. Move forward from here.
-g
Re: Podlings, the Incubator, relationships and Apache
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Of historical interest - “legal oversight” goes back to some to some the very first email about the incubator in 2003. Here's one [1] slightly later from Jim in 2005 who seemed to think back then legal aspects were important. Perhaps that's out of context, and you had to be there, it’s really hard to tell. ¯\_(ツ)_/¯ This by Jim is also an interesting read [2] (also 2005) as is this one [3] (2006) as is that entire thread.
Do we think that is a good idea to continue to have this position that the incubator is special undocumented or unratified?
Thanks,
Justin
1.https://lists.apache.org/thread.html/54c9cef4395a2e300de241c521fc2e4210d5f56c3a5980dd6e5b35e3@1125588769@%3Cgeneral.incubator.apache.org%3E
2. https://lists.apache.org/thread.html/296e0103bbc420b856c932c4e71a35723824f44aa8d7493622507fd5@1135360046@%3Cgeneral.incubator.apache.org%3E
3. https://lists.apache.org/thread.html/73d0d3e852b281c005750cffb91c88079257dd82d56fa1ab4d53dc2c@1166622769@%3Cgeneral.incubator.apache.org%3E
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Although not a "real" PMC, we do need to provide legal protection for each PPMC and distributing releases is the time that most legal considerations "kick in" as it were. So we need a clear "paper trail" of approvals for that PPMC to enjoy the legal protection the foundation exists to provide. The IPMC vote, since the IPMC is, in fact, a true PMC, provides that legal provenance such that, should anything untoward happen, we can clearly show to outside legal entities corporate provenance without having to try to explain the intricacies of podlings, and PPMCs and PMC and et.al. :-)
Which while I don’t disagree with, again I ask how can a PMC (i.e the incubator) make releases that are not in line with policy? Current advice seems that the board would not grant a blanket exception like to the IPMC and we couldn't get consensus on submitting such a request to the board last month. So is it just a mater of refining that board proposal or is it a matter of changing the remit of the IPMC to make it clearer or even changing that the IPMC it is a TLP?
> Let's also recall that the origin genesis of the Incubator was NOT to provide legal oversight
That may be the original thought, but historical threads bring up legal oversight very very early on. (I posted one from 2004 the other day). Hopefully someone can explain this history?
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jul 1, 2019, at 1:45 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> FWIW, I reconcile it as:
>
> Incubator is a PMC and must record a business decision to call something an ASF release in order to place that release under the legal protection of the ASF. ASF releases may have policy non-compliance issues. No TLP can decide on its own to never comply with policy. But the business decision of the costs of delaying a release to correct non-compliance vs risks of distributing a release with any non-compliance is up to the TLP. VP Legal will assert a risk profile for any non-compliance and VP Legal or any ASF Member or PMC Member should try to stop a release if a TLP decides to distribute something highly risky. But it is up to any TLP. Including the IPMC. And so the Incubator can do whatever it wants within limits. Any of us should protest if the IPMC starts allowing releases with high risk. But with the disclaimer and -incubating suffixes, the risk of many non-compliance issues are low, even CatX and binary inclusions.
>
> Whether the incubator needs to have a secondary vote is not required by the above. IPMC members could drop in on the podling vote thread. Podlings with 3 active mentors that vote on the podling's vote thread could be deemed sufficient.
>
Although not a "real" PMC, we do need to provide legal protection for each PPMC and distributing releases is the time that most legal considerations "kick in" as it were. So we need a clear "paper trail" of approvals for that PPMC to enjoy the legal protection the foundation exists to provide. The IPMC vote, since the IPMC is, in fact, a true PMC, provides that legal provenance such that, should anything untoward happen, we can clearly show to outside legal entities corporate provenance without having to try to explain the intricacies of podlings, and PPMCs and PMC and et.al. :-)
Let's also recall that the origin genesis of the Incubator was NOT to provide legal oversight, but rather education and guidance into The Apache Way (TAW). Back then we had way too many projects that were TLP status that lacked even a basic awareness of TAW, and the board, rightfully, considered that a huge problem (this started with the mismanagement of the Jakarta project, which tried to create a sub-foundation within the ASF such that the Jakarta PMC was basically the "board" of that "foundation"... as these projects spun out, problems aplenty ensued). And so the Incubator was created to handle that problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Justin Mclean <ju...@me.com>.
HI,
> But it is up to any TLP.
I wouldn't go that far for instance see [1] ("Projects MUST notify the Board…") and [2] ("Deviations from this policy may have an adverse effect …”) and [3] ("Every ASF release MUST comply with ASF licensing policy.”) As someone said in another thread a disclaimer doesn’t void legal rights or compliance.
The words "authorized business decision” were chosen very carefully again see [2]
> Whether the incubator needs to have a secondary vote is not required by the above.
Currently it requires that 3 IPMC members vote on it [4], most podlings can’t get 3 +1 IPMC votes on their list. Current incubator policy goes a little further [5]
> IPMC members could drop in on the podling vote thread.
IMO Currently the IPMC doesn’t have the bandwidth to do that, release candidates sometime struggle to get votes, having to vote on 2-5x as many RC is unlikely to be possible.
Thanks,
Justin
1. http://www.apache.org/legal/release-policy.html#administration
2. http://www.apache.org/legal/release-policy.html#why
3. http://www.apache.org/legal/release-policy.html#licensing
4. http://www.apache.org/legal/release-policy.html#release-approval
5. https://incubator.apache.org/policy/incubation.html#releases
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Alex Harui <ah...@adobe.com.INVALID>.
FWIW, I reconcile it as:
Incubator is a PMC and must record a business decision to call something an ASF release in order to place that release under the legal protection of the ASF. ASF releases may have policy non-compliance issues. No TLP can decide on its own to never comply with policy. But the business decision of the costs of delaying a release to correct non-compliance vs risks of distributing a release with any non-compliance is up to the TLP. VP Legal will assert a risk profile for any non-compliance and VP Legal or any ASF Member or PMC Member should try to stop a release if a TLP decides to distribute something highly risky. But it is up to any TLP. Including the IPMC. And so the Incubator can do whatever it wants within limits. Any of us should protest if the IPMC starts allowing releases with high risk. But with the disclaimer and -incubating suffixes, the risk of many non-compliance issues are low, even CatX and binary inclusions.
Whether the incubator needs to have a secondary vote is not required by the above. IPMC members could drop in on the podling vote thread. Podlings with 3 active mentors that vote on the podling's vote thread could be deemed sufficient.
My 2 cents,
-Alex
On 6/30/19, 12:11 PM, "Davor Bonaci" <da...@apache.org> wrote:
I do -not- have a problem where this is all tracking towards and believe it
is right, but I do have a problem with how it is justified and explained.
People say: "Incubator is a PMC/TLP", "Incubator takes on the resultant
legal obligations associated w/ any PMC doing a release", "we can NOT allow
any relaxation of the ASF release policy for a TLP", and then conclude that
Incubator can do ~whatever it wants. This logic does not pass the
consistency test.
So... if you want that [new] people in the future don't trip on this, it is
*necessary* to break this logic somehow.
On Fri, Jun 28, 2019 at 8:31 PM Greg Stein <gs...@gmail.com> wrote:
> On Fri, Jun 28, 2019 at 9:59 PM Justin Mclean <ju...@classsoftware.com>
> wrote:
> >...
>
> > > It appears there is general consensus that "right to distribute
> closed
> > source" would be the main and potentially only blocker for podlings.
> >
> > That is not the case (re this is a blocker) I suggest you read that legal
> > thread again. Also infra makes distribution policy.
> >
>
> *distribution*
>
> Infra does not care about the contents. If a PMC says "we +1 the contents",
> then Infra will not second-guess that. Leave out LICENSE, NOTICE, or do
> those files wrong. Include jars, Cat X source. Whatever. We aren't going to
> police that. Binaries in there? Knock yourself out. Legal might get on your
> case, but that's Not Our Problem(tm).
>
> If the IPMC says "here is a podling tarball that we will allow", then it
> can be put into distribution. Use whatever rules you want for the contents,
> or lack of rules. Infra just wants it placed into our distribution system
> in a specific way, to ensure correctness, auditing, and resilience.
>
> VP Infra has already stated the above. As an Officer of Infrastructure, I
> concur and reiterate that position.
>
> Regards,
> Greg Stein
> InfraAdmin, ASF
>
Re: Podlings, the Incubator, relationships and Apache
Posted by Davor Bonaci <da...@apache.org>.
I do -not- have a problem where this is all tracking towards and believe it
is right, but I do have a problem with how it is justified and explained.
People say: "Incubator is a PMC/TLP", "Incubator takes on the resultant
legal obligations associated w/ any PMC doing a release", "we can NOT allow
any relaxation of the ASF release policy for a TLP", and then conclude that
Incubator can do ~whatever it wants. This logic does not pass the
consistency test.
So... if you want that [new] people in the future don't trip on this, it is
*necessary* to break this logic somehow.
On Fri, Jun 28, 2019 at 8:31 PM Greg Stein <gs...@gmail.com> wrote:
> On Fri, Jun 28, 2019 at 9:59 PM Justin Mclean <ju...@classsoftware.com>
> wrote:
> >...
>
> > > It appears there is general consensus that "right to distribute
> closed
> > source" would be the main and potentially only blocker for podlings.
> >
> > That is not the case (re this is a blocker) I suggest you read that legal
> > thread again. Also infra makes distribution policy.
> >
>
> *distribution*
>
> Infra does not care about the contents. If a PMC says "we +1 the contents",
> then Infra will not second-guess that. Leave out LICENSE, NOTICE, or do
> those files wrong. Include jars, Cat X source. Whatever. We aren't going to
> police that. Binaries in there? Knock yourself out. Legal might get on your
> case, but that's Not Our Problem(tm).
>
> If the IPMC says "here is a podling tarball that we will allow", then it
> can be put into distribution. Use whatever rules you want for the contents,
> or lack of rules. Infra just wants it placed into our distribution system
> in a specific way, to ensure correctness, auditing, and resilience.
>
> VP Infra has already stated the above. As an Officer of Infrastructure, I
> concur and reiterate that position.
>
> Regards,
> Greg Stein
> InfraAdmin, ASF
>
Re: Podlings, the Incubator, relationships and Apache
Posted by Greg Stein <gs...@gmail.com>.
On Fri, Jun 28, 2019 at 9:59 PM Justin Mclean <ju...@classsoftware.com>
wrote:
>...
> > It appears there is general consensus that "right to distribute closed
> source" would be the main and potentially only blocker for podlings.
>
> That is not the case (re this is a blocker) I suggest you read that legal
> thread again. Also infra makes distribution policy.
>
*distribution*
Infra does not care about the contents. If a PMC says "we +1 the contents",
then Infra will not second-guess that. Leave out LICENSE, NOTICE, or do
those files wrong. Include jars, Cat X source. Whatever. We aren't going to
police that. Binaries in there? Knock yourself out. Legal might get on your
case, but that's Not Our Problem(tm).
If the IPMC says "here is a podling tarball that we will allow", then it
can be put into distribution. Use whatever rules you want for the contents,
or lack of rules. Infra just wants it placed into our distribution system
in a specific way, to ensure correctness, auditing, and resilience.
VP Infra has already stated the above. As an Officer of Infrastructure, I
concur and reiterate that position.
Regards,
Greg Stein
InfraAdmin, ASF
Re: Podlings, the Incubator, relationships and Apache
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> An "exception" would be a potentially permanent allowance of non-compliance.
Exceptions when given have been temporary and not permanent.
> It appears there is general consensus that "right to distribute closed source" would be the main and potentially only blocker for podlings.
That is not the case (re this is a blocker) I suggest you read that legal thread again. Also infra makes distribution policy.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 6/27/19, 10:57 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
But VP legal said as much the other day. "we can NOT allow any relaxation of the ASF release policy for a TLP.”
I interpret that to mean that a TLP must eventually get around to fixing non-compliance. A TLP cannot stop attempting to find non-compliance before shipping a release as well. An "exception" would be a potentially permanent allowance of non-compliance. And since I think VP Legal said that the legal committee mainly does risk profiling of non-compliance and the "business decision" is up to the PMC, I think that gives the IPMC the ability to be give podlings even more time to deal with non-compliance about most things. It appears there is general consensus that "right to distribute closed source" would be the main and potentially only blocker for podlings.
My 2 cents,
-Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> While you've been going through the history and other docs: Does it actually say somewhere that a true ASF release MUST NOT contain any non-compliance of policy?
Again I’m not sure why you’re talking about TLP policy on the incubator general list. But VP legal said as much the other day. "we can NOT allow any relaxation of the ASF release policy for a TLP.”
I would probably alter the above to say "known non-compliance without approval”. Exceptions have been made and mistakes will happen and things will be missed. IMO as long as the project is willing to correct a previously unknown issue before the next release all is generally fine.
Looking at the history the incubator, I didn’t see anything with explicitly those exact words, but that doesn’t mean it has not been stated in another form, as there a lot of conversions in that history. What I did see is that the incubator has been much stricter on policy in the past.
> Sebb just reported that something like 3 TLPs have releases that are not compliant with the NOTICE file policy.
Issues in TLP project NOTICE are reasonably common e.g. I saw this the other day [1]. Hadoop (and a couple of other TLPs) have had a long history of not being the best examples to copy from. Podlings often do and then are surprised when it’s not correct, in the last year I’ve contacted several TLP and asked (politely) for some NOTICE issues to be fixed as they are causing podling project issues, they usually have been fixed. This has been mentioned in the IPMC board report if you want more details.
Give the NOTICE is for informational purposes only, these are probably not serious issues. Even it’s not in line with ASF policy it would probably still tick all the legal boxes. (I’ve not looked at the details so that’s an assumption on my part.)
Thanks,
Justin
1. https://github.com/apache/hive/blob/master/NOTICE
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Alex Harui <ah...@adobe.com.INVALID>.
While you've been going through the history and other docs: Does it actually say somewhere that a true ASF release MUST NOT contain any non-compliance of policy? Or is it possible that the communities must fix some non-compliance issues right away and can fix others later? Then it isn't about relaxing policy or exceptions to policy, it is just acceptance that not all policy non-compliance issues are "must fix now".
Sebb just reported that something like 3 TLPs have releases that are not compliant with the NOTICE file policy. I don't think the legal shield has been damaged nor will the board shut down those projects. I imagine they will simply take note and fix it in their next release. They may not even have to drop everything there are currently working on and push out a release with the fix.
Again, the restaurant food handling codes allow the restaurant owners to fix some non-compliance issues over time.
HTH,
-Alex
On 6/27/19, 4:58 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
Hi,
> The Incubator itself is a PMC.
OK that's sorted.
> Now let's talk about podling releases... When the IPMC votes on accepting a podling release, and it passes, my opinion is that the Incubator takes on the resultant legal obligations associated w/ any PMC doing a release. Now the podling releases themselves are noted and described as "not GA" and "not official", et.al. but this is, again IMO, simply to make it clear to anyone who is downloading and using the software that the expectations normally associated with "regular" Apache releases do not apply, such that there could be some licensing issues, etc, that would be verboten in "official" releases, but may exist here. In other words: this is a podling release; expect issues and mistakes and churn.
Except it's not, as it seems the IPMC doesn’t need to abide by what other PMCs need to abide by when making releases :-) (Which is ironic given the IPMC is tasked with teaching and passing that knowledge on.) And that policy exception is not documented anywhere. :-) Nor has the board, to my knowledge, approved such an exception. Yay! So how is a voted on PMC release, an act which make it official, is not an official release? Do you see how this might be confusing or open to a board range of interpretations?
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Recall that with other PMCs, the PMCs themselves are directly responsible for the development of the code. Not so with the IPMC.
Where is this documented? Where has the board granted this? It’s not in the IPMC's policy or in it charter. IMO Until that happens it always going to be a cause of conflict in the IPMC.
> Incubation should be a... wait for it... 'safe space' (/me ducks) for podlings to learn the ropes, to fail doing the "normal" things that a PMC must do (including releases), because that is how people learn best. As long as the outworld world is aware that podlings can not, and should not, be expected to be "the same" as other PMCs, we are OK.
I don’t disagree that’s where we would like to be, but I fail to see how people outside the ASF would reach that conclusion. The DISCLAMER, for instance, says nothing about this.
Thanks,
Justin
Re: Podlings, the Incubator, relationships and Apache
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jun 27, 2019, at 7:57 PM, Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
>> The Incubator itself is a PMC.
>
> OK that's sorted.
>
>> Now let's talk about podling releases... When the IPMC votes on accepting a podling release, and it passes, my opinion is that the Incubator takes on the resultant legal obligations associated w/ any PMC doing a release. Now the podling releases themselves are noted and described as "not GA" and "not official", et.al. but this is, again IMO, simply to make it clear to anyone who is downloading and using the software that the expectations normally associated with "regular" Apache releases do not apply, such that there could be some licensing issues, etc, that would be verboten in "official" releases, but may exist here. In other words: this is a podling release; expect issues and mistakes and churn.
>
> Except it's not, as it seems the IPMC doesn’t need to abide by what other PMCs need to abide by when making releases :-) (Which is ironic given the IPMC is tasked with teaching and passing that knowledge on.) And that policy exception is not documented anywhere. :-) Nor has the board, to my knowledge, approved such an exception. Yay! So how is a voted on PMC release, an act which make it official, is not an official release? Do you see how this might be confusing or open to a board range of interpretations?
>
Yes, I see how it can be confusing and open to a range of opinions.
Recall that with other PMCs, the PMCs themselves are directly responsible for the development of the code. Not so with the IPMC. The expectation w/ other PMCs is that they know how to do releases, and that their releases will be correct and valid. With podlings, the expectation is the reverse. It is expected that podling releases will have issues... in fact, iirc, somewhere along the line *making* a podling do a release was added as a required step to graduation, to make sure that upon graduation, they knew how to do it.
Incubation should be a... wait for it... 'safe space' (/me ducks) for podlings to learn the ropes, to fail doing the "normal" things that a PMC must do (including releases), because that is how people learn best. As long as the outworld world is aware that podlings can not, and should not, be expected to be "the same" as other PMCs, we are OK.
Maybe we should think of the podlings more as "Apprenticeship PMCs" ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> The Incubator itself is a PMC.
OK that's sorted.
> Now let's talk about podling releases... When the IPMC votes on accepting a podling release, and it passes, my opinion is that the Incubator takes on the resultant legal obligations associated w/ any PMC doing a release. Now the podling releases themselves are noted and described as "not GA" and "not official", et.al. but this is, again IMO, simply to make it clear to anyone who is downloading and using the software that the expectations normally associated with "regular" Apache releases do not apply, such that there could be some licensing issues, etc, that would be verboten in "official" releases, but may exist here. In other words: this is a podling release; expect issues and mistakes and churn.
Except it's not, as it seems the IPMC doesn’t need to abide by what other PMCs need to abide by when making releases :-) (Which is ironic given the IPMC is tasked with teaching and passing that knowledge on.) And that policy exception is not documented anywhere. :-) Nor has the board, to my knowledge, approved such an exception. Yay! So how is a voted on PMC release, an act which make it official, is not an official release? Do you see how this might be confusing or open to a board range of interpretations?
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jun 25, 2019, at 9:49 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
>
>
> On 6/24/19, 9:12 AM, "Roman Shaposhnik" <ro...@shaposhnik.org> wrote:
>
>> What kinds of policy violations truly affect the legal shield if the non-compliance:
>
> You're asking the wrong question. You're still asking the TLP question.
>
> I'm asking the TLP question to understand how big the difference is between TLP and Podlings.
Please note that the only legal structure in this discussion is a PMC. The Bylaws have no concept of a podling nor a "top level project", although we tend to use the terms TLP and PMC interchangeably.
Now a podling is NOT a PMC because, again, the bylaws are clear on what constitutes a PMC and how one is created.
The Incubator itself is a PMC.
Now let's talk about podling releases... When the IPMC votes on accepting a podling release, and it passes, my opinion is that the Incubator takes on the resultant legal obligations associated w/ any PMC doing a release. Now the podling releases themselves are noted and described as "not GA" and "not official", et.al. but this is, again IMO, simply to make it clear to anyone who is downloading and using the software that the expectations normally associated with "regular" Apache releases do not apply, such that there could be some licensing issues, etc, that would be verboten in "official" releases, but may exist here. In other words: this is a podling release; expect issues and mistakes and churn.
The IPMC vote is not, and should not be, some sort of secondary QA test, some sort of verification of validity: it exists, IMO, simply so that the podling (and its contributors) can enjoy the legal protection under the Incubator "umbrella" when they do a release.
Cheers!
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 6/24/19, 9:12 AM, "Roman Shaposhnik" <ro...@shaposhnik.org> wrote:
> What kinds of policy violations truly affect the legal shield if the non-compliance:
You're asking the wrong question. You're still asking the TLP question.
I'm asking the TLP question to understand how big the difference is between TLP and Podlings. If we allow podlings the ability to make releases with certain kinds of issues until they eventually get one release right, the question still remains that once they graduate and add some new dependency and make some (what I consider minor) non-compliance, will they be required to consider all non-compliance a release-blocker? That would be a big cliff to jump off of and probably make for some unhappy newly-minted TLPs.
If you are saying that the TLPs get to make a "business decision" that sounds good to me. IMO, it would be nice to have some sort of risk profile assessment associated with each release policy to help TLPs make better business decisions.
My 2 cents,
-Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Sun, Jun 23, 2019 at 11:03 PM Alex Harui <ah...@adobe.com.invalid> wrote:
>
> But, IMO, the reason the question went to VP Legal is that it doesn't really matter what the IPMC thinks if their "business decision" will have an impact on the "Legal Shield" and the insurance premiums that go with it. So I think the question got lost on legal-discuss. The "space of options" should probably be constrained by the "Legal Shield".
Nope. That's not how any of the legal works. Legal never makes policy
-- legal always evaluates risk profiles of the policy that business
stakeholders make.
In fact, and thin may come as a shock, legal never *blocks* anything.
Legal doesn't have veto power simply because the business decision
always trupms legal.
You *may* get sued is a statement that is always true -- regardless of
what you do.
> What kinds of policy violations truly affect the legal shield if the non-compliance:
You're asking the wrong question. You're still asking the TLP question.
> 1) is actually released
> 2) released but noted in RELEASE_NOTES or DISCLAIMER
> 3) released but not corrected in the next release
>
> Ted, Roy, Hen, seem to say that only "no rights to distribute" and "CatX" should not be released by TLPs but "CatX" should be ok for podlings. My takeaway from Roman is that all policy non-compliance issues are release breakers and Incubator should either be granted special status or not. But I'd like to see the first question be answered so we can understand how special the Incubator status would have to be. How different would it be from TLP releases and what risks to the foundation would that pose and could a DISCLAIMER or other means mitigate that risk? Without knowing how the Legal Shield works, it is hard to know what the options truly are.
>
> HTH,
> -Alex
>
> On 6/23/19, 10:43 PM, "Davor Bonaci" <da...@apache.org> wrote:
>
> On Sun, Jun 23, 2019 at 10:04 PM Greg Stein <gs...@gmail.com> wrote:
>
> > I disagree. I see a number of people who think that podling releases are
> > TLP-level releases from the Incubator itself. I see people wanting
> > structure/policy/rules to ensure these TLP releases are done properly. And
> > that some want to "fix a few things" to make it easier for podlings to make
> > these releases.
> >
>
> Perhaps you are right, but it is not necessary to debate it. (The
> 'disagreement' is about what other people think; we can let them speak up
> and/or measure consensus or lack thereof in the usual ways.)
>
> The balls rolls forward by understanding the space of options, and then
> discussing it. (... the first part of which is happening on other threads.)
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> What kinds of policy violations truly affect the legal shield if the non-compliance:
> 1) is actually released
> 2) released but noted in RELEASE_NOTES or DISCLAIMER
> 3) released but not corrected in the next release
This question (in a slightly different form) was in the proposal to the board, it did not have consensus, so was removed. VP legal pointed out that that question in the proposal was too broad and the board would be unlikely to be able to answer it.
I suggest you ask this on legal discuss, however previous advice was been allso that they that not likely to be unable to answer broad general questions like that.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Alex Harui <ah...@adobe.com.INVALID>.
But, IMO, the reason the question went to VP Legal is that it doesn't really matter what the IPMC thinks if their "business decision" will have an impact on the "Legal Shield" and the insurance premiums that go with it. So I think the question got lost on legal-discuss. The "space of options" should probably be constrained by the "Legal Shield".
What kinds of policy violations truly affect the legal shield if the non-compliance:
1) is actually released
2) released but noted in RELEASE_NOTES or DISCLAIMER
3) released but not corrected in the next release
Ted, Roy, Hen, seem to say that only "no rights to distribute" and "CatX" should not be released by TLPs but "CatX" should be ok for podlings. My takeaway from Roman is that all policy non-compliance issues are release breakers and Incubator should either be granted special status or not. But I'd like to see the first question be answered so we can understand how special the Incubator status would have to be. How different would it be from TLP releases and what risks to the foundation would that pose and could a DISCLAIMER or other means mitigate that risk? Without knowing how the Legal Shield works, it is hard to know what the options truly are.
HTH,
-Alex
On 6/23/19, 10:43 PM, "Davor Bonaci" <da...@apache.org> wrote:
On Sun, Jun 23, 2019 at 10:04 PM Greg Stein <gs...@gmail.com> wrote:
> I disagree. I see a number of people who think that podling releases are
> TLP-level releases from the Incubator itself. I see people wanting
> structure/policy/rules to ensure these TLP releases are done properly. And
> that some want to "fix a few things" to make it easier for podlings to make
> these releases.
>
Perhaps you are right, but it is not necessary to debate it. (The
'disagreement' is about what other people think; we can let them speak up
and/or measure consensus or lack thereof in the usual ways.)
The balls rolls forward by understanding the space of options, and then
discussing it. (... the first part of which is happening on other threads.)
Re: Podlings, the Incubator, relationships and Apache
Posted by Davor Bonaci <da...@apache.org>.
On Sun, Jun 23, 2019 at 10:04 PM Greg Stein <gs...@gmail.com> wrote:
> I disagree. I see a number of people who think that podling releases are
> TLP-level releases from the Incubator itself. I see people wanting
> structure/policy/rules to ensure these TLP releases are done properly. And
> that some want to "fix a few things" to make it easier for podlings to make
> these releases.
>
Perhaps you are right, but it is not necessary to debate it. (The
'disagreement' is about what other people think; we can let them speak up
and/or measure consensus or lack thereof in the usual ways.)
The balls rolls forward by understanding the space of options, and then
discussing it. (... the first part of which is happening on other threads.)
Re: Podlings, the Incubator, relationships and Apache
Posted by Greg Stein <gs...@gmail.com>.
On Sun, Jun 23, 2019 at 11:55 PM Davor Bonaci <da...@apache.org> wrote:
> I wouldn't say that there are 2 camps. The IPMC seems to be overwhelmingly
> in the "2nd camp", with its desire to be lenient with the releases and
> rules.
>
I disagree. I see a number of people who think that podling releases are
TLP-level releases from the Incubator itself. I see people wanting
structure/policy/rules to ensure these TLP releases are done properly. And
that some want to "fix a few things" to make it easier for podlings to make
these releases.
There are some that disagree with that outlook (the 2nd campers), and would
like that "business decision" because the status quo is rough on podlings.
I believe we do not have consensus on this shift in outlook/operation.
Cheers,
-g
Re: Podlings, the Incubator, relationships and Apache
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Thanks to David for a very good summary of the historical situation and Davor for IMO correctly summing up peoples positions. I think both of those replies are worth a very careful read.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Davor Bonaci <da...@apache.org>.
I wouldn't say that there are 2 camps. The IPMC seems to be overwhelmingly
in the "2nd camp", with its desire to be lenient with the releases and
rules.
What I see is:
[1] David is saying (correctly) how Incubator is structured right now. He
hasn't expressed ~any opinions; it is just an interpretation of the facts
from past resolutions and decisions made. I don't think anything said there
is questionable as the current state of affairs.
[2] Most of IPMC agrees that the current state of affairs is [1], and
desires to relax it somewhat.
[3] Hence, Justin is asking for clarification regarding IPMC's authority to
depart from the current state of affairs described in [1].
The IPMC is capable of making the business decision; Justin is not asking
for the decision to be made, but instead to better understand the IPMC's
authority of possible decisions.
On Sun, Jun 23, 2019 at 8:53 PM Dave Fisher <da...@comcast.net> wrote:
> Thanks Roman!
>
> +1 to the 2nd camp!
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On Jun 23, 2019, at 8:25 PM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
> >
> >> On Sat, Jun 22, 2019 at 3:31 PM Rich Bowen <rb...@rcbowen.com> wrote:
> >>
> >> A couple of thoughts:
> >
> > And a couple of thoughts on top of that.
> >
> >> Podlings are not permitted to call themselves "Apache Foo" because they
> are
> >> not yet full Apache projects.
> >
> > Correct. The I way I see this thread is this: *when it comes to
> > releases*, there's
> > always been two camps in Incubator. One thinks that Incubator is a TLP
> just
> > like Apache Commons that happens to produce release artifacts that have
> > nothing in common (just like Apache Commons' JXPath has very little to
> do
> > with Compress and). A second camp thinks that Incubator is actually a
> special
> > construct within a foundation (after all, if it was just like Apache
> Commons why
> > would we make them put DISCLAIMER into release tarballs?).
> >
> > It seems that David is closer to the 1st camp, and Rich and I are
> > closer to the 2nd.
> >
> > Looking at the community benefits, I really think we should acknowledge
> that
> > Incubator is a special construct and optimize that special construct
> > for a particular
> > outcome: which is effectiveness of the graduation process.
> >
> >> While in the incubator we should expect podlibgs to fail at the rules.
> >> They're new to them and many of them feel arbitrary, even capricious, to
> >> those coming in from outside. We should make it safe to fail until they
> are
> >> ready to graduate. We should nurture them as long as they are moving
> >> towards that goal.
> >
> > Yup.
> >
> >> I cannot disagree with your reading of our resolutions. But I wonder if
> >> that reality is producing good citizen projects or a bunch of resentful
> >> people following rules they don't understand or embrace because they
> know
> >> they have to.
> >>
> >> Zipkin is only the latest project which clearly didn't get it and has
> left
> >> angry. I would rather a project realize that they don't fit and be able
> to
> >> leave with their dignity without having also to leave hating what we
> stand
> >> for.
> >>
> >> I want our new graduates to love and understand the ASF not merely
> tolerate
> >> it.
> >>
> >> I want the incubator to respond to failure with gentle correction rather
> >> than scoldings.
> >>
> >> Specifically I think podlings should be able to produce releases that
> are
> >> not asf complient and have them clearly labeled as such. Because they
> are
> >> not TLPs yet and so cannot be held to the same standard. This must be
> >> accompanied by a movement towards being a TLP, not some eternal
> incubation.
> >
> > With my IPMC member hat on -- huge +1 to the above.
> >
> > With my VP Legal hat on: I have no dog in this race. The IPMC needs to
> make
> > a *business* (well, community in this case) decision and then we can work
> > with a risk profile of that decision.
> >
> > Like I said -- the decision to make is: 1st vs. 2nd camp.
> >
> > Thanks,
> > Roman.
> >
> > ---------------------------------------------------------------------
> > 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: Podlings, the Incubator, relationships and Apache
Posted by Greg Stein <gs...@gmail.com>.
+1 to 2nd camp.
And even less requirements than have been suggested, I would offer. For
example: if the tarball is missing a LICENSE or NOTICE file? Who cares.
It's still a legal release. Just hard for downstream users to consume. But
they *can*. Nothing stopping somebody from trying out the tarball.
Cheers,
-g
On Sun, Jun 23, 2019 at 10:53 PM Dave Fisher <da...@comcast.net> wrote:
> Thanks Roman!
>
> +1 to the 2nd camp!
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On Jun 23, 2019, at 8:25 PM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
> >
> >> On Sat, Jun 22, 2019 at 3:31 PM Rich Bowen <rb...@rcbowen.com> wrote:
> >>
> >> A couple of thoughts:
> >
> > And a couple of thoughts on top of that.
> >
> >> Podlings are not permitted to call themselves "Apache Foo" because they
> are
> >> not yet full Apache projects.
> >
> > Correct. The I way I see this thread is this: *when it comes to
> > releases*, there's
> > always been two camps in Incubator. One thinks that Incubator is a TLP
> just
> > like Apache Commons that happens to produce release artifacts that have
> > nothing in common (just like Apache Commons' JXPath has very little to
> do
> > with Compress and). A second camp thinks that Incubator is actually a
> special
> > construct within a foundation (after all, if it was just like Apache
> Commons why
> > would we make them put DISCLAIMER into release tarballs?).
> >
> > It seems that David is closer to the 1st camp, and Rich and I are
> > closer to the 2nd.
> >
> > Looking at the community benefits, I really think we should acknowledge
> that
> > Incubator is a special construct and optimize that special construct
> > for a particular
> > outcome: which is effectiveness of the graduation process.
> >
> >> While in the incubator we should expect podlibgs to fail at the rules.
> >> They're new to them and many of them feel arbitrary, even capricious, to
> >> those coming in from outside. We should make it safe to fail until they
> are
> >> ready to graduate. We should nurture them as long as they are moving
> >> towards that goal.
> >
> > Yup.
> >
> >> I cannot disagree with your reading of our resolutions. But I wonder if
> >> that reality is producing good citizen projects or a bunch of resentful
> >> people following rules they don't understand or embrace because they
> know
> >> they have to.
> >>
> >> Zipkin is only the latest project which clearly didn't get it and has
> left
> >> angry. I would rather a project realize that they don't fit and be able
> to
> >> leave with their dignity without having also to leave hating what we
> stand
> >> for.
> >>
> >> I want our new graduates to love and understand the ASF not merely
> tolerate
> >> it.
> >>
> >> I want the incubator to respond to failure with gentle correction rather
> >> than scoldings.
> >>
> >> Specifically I think podlings should be able to produce releases that
> are
> >> not asf complient and have them clearly labeled as such. Because they
> are
> >> not TLPs yet and so cannot be held to the same standard. This must be
> >> accompanied by a movement towards being a TLP, not some eternal
> incubation.
> >
> > With my IPMC member hat on -- huge +1 to the above.
> >
> > With my VP Legal hat on: I have no dog in this race. The IPMC needs to
> make
> > a *business* (well, community in this case) decision and then we can work
> > with a risk profile of that decision.
> >
> > Like I said -- the decision to make is: 1st vs. 2nd camp.
> >
> > Thanks,
> > Roman.
> >
> > ---------------------------------------------------------------------
> > 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: Podlings, the Incubator, relationships and Apache
Posted by Dave Fisher <da...@comcast.net>.
Thanks Roman!
+1 to the 2nd camp!
Regards,
Dave
Sent from my iPhone
> On Jun 23, 2019, at 8:25 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
>> On Sat, Jun 22, 2019 at 3:31 PM Rich Bowen <rb...@rcbowen.com> wrote:
>>
>> A couple of thoughts:
>
> And a couple of thoughts on top of that.
>
>> Podlings are not permitted to call themselves "Apache Foo" because they are
>> not yet full Apache projects.
>
> Correct. The I way I see this thread is this: *when it comes to
> releases*, there's
> always been two camps in Incubator. One thinks that Incubator is a TLP just
> like Apache Commons that happens to produce release artifacts that have
> nothing in common (just like Apache Commons' JXPath has very little to do
> with Compress and). A second camp thinks that Incubator is actually a special
> construct within a foundation (after all, if it was just like Apache Commons why
> would we make them put DISCLAIMER into release tarballs?).
>
> It seems that David is closer to the 1st camp, and Rich and I are
> closer to the 2nd.
>
> Looking at the community benefits, I really think we should acknowledge that
> Incubator is a special construct and optimize that special construct
> for a particular
> outcome: which is effectiveness of the graduation process.
>
>> While in the incubator we should expect podlibgs to fail at the rules.
>> They're new to them and many of them feel arbitrary, even capricious, to
>> those coming in from outside. We should make it safe to fail until they are
>> ready to graduate. We should nurture them as long as they are moving
>> towards that goal.
>
> Yup.
>
>> I cannot disagree with your reading of our resolutions. But I wonder if
>> that reality is producing good citizen projects or a bunch of resentful
>> people following rules they don't understand or embrace because they know
>> they have to.
>>
>> Zipkin is only the latest project which clearly didn't get it and has left
>> angry. I would rather a project realize that they don't fit and be able to
>> leave with their dignity without having also to leave hating what we stand
>> for.
>>
>> I want our new graduates to love and understand the ASF not merely tolerate
>> it.
>>
>> I want the incubator to respond to failure with gentle correction rather
>> than scoldings.
>>
>> Specifically I think podlings should be able to produce releases that are
>> not asf complient and have them clearly labeled as such. Because they are
>> not TLPs yet and so cannot be held to the same standard. This must be
>> accompanied by a movement towards being a TLP, not some eternal incubation.
>
> With my IPMC member hat on -- huge +1 to the above.
>
> With my VP Legal hat on: I have no dog in this race. The IPMC needs to make
> a *business* (well, community in this case) decision and then we can work
> with a risk profile of that decision.
>
> Like I said -- the decision to make is: 1st vs. 2nd camp.
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> 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: Podlings, the Incubator, relationships and Apache
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Sat, Jun 22, 2019 at 3:31 PM Rich Bowen <rb...@rcbowen.com> wrote:
>
> A couple of thoughts:
And a couple of thoughts on top of that.
> Podlings are not permitted to call themselves "Apache Foo" because they are
> not yet full Apache projects.
Correct. The I way I see this thread is this: *when it comes to
releases*, there's
always been two camps in Incubator. One thinks that Incubator is a TLP just
like Apache Commons that happens to produce release artifacts that have
nothing in common (just like Apache Commons' JXPath has very little to do
with Compress and). A second camp thinks that Incubator is actually a special
construct within a foundation (after all, if it was just like Apache Commons why
would we make them put DISCLAIMER into release tarballs?).
It seems that David is closer to the 1st camp, and Rich and I are
closer to the 2nd.
Looking at the community benefits, I really think we should acknowledge that
Incubator is a special construct and optimize that special construct
for a particular
outcome: which is effectiveness of the graduation process.
> While in the incubator we should expect podlibgs to fail at the rules.
> They're new to them and many of them feel arbitrary, even capricious, to
> those coming in from outside. We should make it safe to fail until they are
> ready to graduate. We should nurture them as long as they are moving
> towards that goal.
Yup.
> I cannot disagree with your reading of our resolutions. But I wonder if
> that reality is producing good citizen projects or a bunch of resentful
> people following rules they don't understand or embrace because they know
> they have to.
>
> Zipkin is only the latest project which clearly didn't get it and has left
> angry. I would rather a project realize that they don't fit and be able to
> leave with their dignity without having also to leave hating what we stand
> for.
>
> I want our new graduates to love and understand the ASF not merely tolerate
> it.
>
> I want the incubator to respond to failure with gentle correction rather
> than scoldings.
>
> Specifically I think podlings should be able to produce releases that are
> not asf complient and have them clearly labeled as such. Because they are
> not TLPs yet and so cannot be held to the same standard. This must be
> accompanied by a movement towards being a TLP, not some eternal incubation.
With my IPMC member hat on -- huge +1 to the above.
With my VP Legal hat on: I have no dog in this race. The IPMC needs to make
a *business* (well, community in this case) decision and then we can work
with a risk profile of that decision.
Like I said -- the decision to make is: 1st vs. 2nd camp.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
Posted by Rich Bowen <rb...@rcbowen.com>.
A couple of thoughts:
Podlings are not permitted to call themselves "Apache Foo" because they are
not yet full Apache projects.
While in the incubator we should expect podlibgs to fail at the rules.
They're new to them and many of them feel arbitrary, even capricious, to
those coming in from outside. We should make it safe to fail until they are
ready to graduate. We should nurture them as long as they are moving
towards that goal.
I cannot disagree with your reading of our resolutions. But I wonder if
that reality is producing good citizen projects or a bunch of resentful
people following rules they don't understand or embrace because they know
they have to.
Zipkin is only the latest project which clearly didn't get it and has left
angry. I would rather a project realize that they don't fit and be able to
leave with their dignity without having also to leave hating what we stand
for.
I want our new graduates to love and understand the ASF not merely tolerate
it.
I want the incubator to respond to failure with gentle correction rather
than scoldings.
Specifically I think podlings should be able to produce releases that are
not asf complient and have them clearly labeled as such. Because they are
not TLPs yet and so cannot be held to the same standard. This must be
accompanied by a movement towards being a TLP, not some eternal incubation.
The incubator should be a mentor - an educator - not a jury.
On Fri, Jun 21, 2019, 01:04 David Nalley <da...@gnsa.us> wrote:
> There's been a lot of discussion in various threads about bureaucracy,
> whether podlings are part of the ASF, etc. As a result of that I've
> spent a good deal of time reading resolutions and older discussions
> and organizing those thoughts from a legal and community perspective.
> I've also read a number of conversations from the more august members
> of our body about this subject. Altogether it has somewhat changed
> some of my opinions and assumptions. I've also sensed that there is a
> community/business/legal disconnect in our conversations. We're using
> the same words to mean very different things in each of those
> contexts. That said I am but one member of the IPMC, but maybe this
> will be helpful to someone else - I've tried to avoid my assumptions
> in this.
>
> The IPMC's first 'job'[1] is "accepting new products into the
> Foundation" The second 'job' of the IPMC is to "provide guidance and
> support to ensure that the Incubator's sub-projects[2] develop
> products according to the Foundation's philosophy and guidelines". The
> final 'job' is evaluating the products and determining whether they
> should be abandoned, continue to receive guidance and support, or be
> promoted to "full project status".
>
> So there are several realizations I gained from this from the
> Incubator perspective.
> 1. Acceptance into the Incubator is acceptance of the product into the
> Foundation.
> 2. That product is then a sub-project of the Incubator.
> 3. The IPMC has the "primary responsibility for the management of
> those subprojects".
>
> From the Foundation's perspective there are a number of things that
> come to mind:
> 1. We aren't a github/sourceforge/google code type platform where
> random people can upload/post what they want.
> 2. We do not have DMCA Safe Harbor protection - e.g. we are
> responsible for everything that we publish or distribute. With the
> exception of wikis and bug trackers anyone who can put something up on
> an Apache property has some form of legal relationship with the
> Foundation. This could be as simple as an ICLAs where you've
> contractually said you won't contribute anything you don't have rights
> to.
> 3. Most of the project's who have come to us aren't entities in and of
> themselves. E.g. the 'project' doesn't truly exist from a legal entity
> perspective - and even those who do are at best an unincorporated
> association of individuals. From a legal perspective - projects can't
> make or distribute a release - they don't exist - only the ASF and the
> individual(s) doing the work. Given that one of the explicit reasons
> the Foundation was created was to[5]: "provide a means for individual
> volunteers to be sheltered from legal suits"; we want them to create
> and distribute releases as the Foundation.
> 4. Whether we like it or not - the Foundation is judged on the output
> from our projects and subprojects. We have a reputation of having
> clean IP, permissively licensed open source code, with clear
> provenance. Many people explicitly copy our standards, guidelines, and
> policies because they are the gold standard for good open source
> governance.
> 5. Disclaimers generally don't remove liability, and even if they did,
> our disclaimer talks about the maturity of our projects. - And it
> certainly doesn't remove the public's expectations from us - frankly -
> losing the publics trust is as scary as the potential legal liability.
> 6. The Board has delegated the responsibility of managing and ensuring
> adherence to policies and guidelines to the IPMC. I don't see this
> responsibility as boolean. It's not perfect compliance vs. failure.
> IMO, the IPMC has been delegated the decision making process, and may
> often find themselves making the business decision that an imperfect
> release is better than a community stalled for months or years. Don't
> let the perfect be the enemy of the good.
>
> From a podling's perspective:
> 1. Once you join the incubator you're a part of the ASF (Yay!?)
> 2. Your project is now a subproject of the IPMC.
> 3. There are rules, and you're entering a world of pain[4] In fact,
> you're likely to find that the ASF has more rules and structure that
> apply to projects than virtually any other home your project could
> choose. This is good and bad.
> 4. The incubator has a long, storied history of producing successful
> projects that flourish.
>
>
> [1]
> http://apache.org/foundation/records/minutes/2002/board_minutes_2002_10_16.txt
> [2] What we call Podlings, the initial resolution refers to as
> subprojects of the Incubator
> [3] It's worth noting that there were two resolutions proposed to
> create the Incubator - small differences, but interesting to read the
> differences.
> [4] https://youtu.be/3vB9U2hx6Qg
> [5] https://www.apache.org/foundation/faq.html#why
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Podlings, the Incubator, relationships and Apache
Posted by Davor Bonaci <da...@apache.org>.
I second every single sentence said here. Every. Single. Sentence.
On Thu, Jun 20, 2019 at 10:04 AM David Nalley <da...@gnsa.us> wrote:
> There's been a lot of discussion in various threads about bureaucracy,
> whether podlings are part of the ASF, etc. As a result of that I've
> spent a good deal of time reading resolutions and older discussions
> and organizing those thoughts from a legal and community perspective.
> I've also read a number of conversations from the more august members
> of our body about this subject. Altogether it has somewhat changed
> some of my opinions and assumptions. I've also sensed that there is a
> community/business/legal disconnect in our conversations. We're using
> the same words to mean very different things in each of those
> contexts. That said I am but one member of the IPMC, but maybe this
> will be helpful to someone else - I've tried to avoid my assumptions
> in this.
>
> The IPMC's first 'job'[1] is "accepting new products into the
> Foundation" The second 'job' of the IPMC is to "provide guidance and
> support to ensure that the Incubator's sub-projects[2] develop
> products according to the Foundation's philosophy and guidelines". The
> final 'job' is evaluating the products and determining whether they
> should be abandoned, continue to receive guidance and support, or be
> promoted to "full project status".
>
> So there are several realizations I gained from this from the
> Incubator perspective.
> 1. Acceptance into the Incubator is acceptance of the product into the
> Foundation.
> 2. That product is then a sub-project of the Incubator.
> 3. The IPMC has the "primary responsibility for the management of
> those subprojects".
>
> From the Foundation's perspective there are a number of things that
> come to mind:
> 1. We aren't a github/sourceforge/google code type platform where
> random people can upload/post what they want.
> 2. We do not have DMCA Safe Harbor protection - e.g. we are
> responsible for everything that we publish or distribute. With the
> exception of wikis and bug trackers anyone who can put something up on
> an Apache property has some form of legal relationship with the
> Foundation. This could be as simple as an ICLAs where you've
> contractually said you won't contribute anything you don't have rights
> to.
> 3. Most of the project's who have come to us aren't entities in and of
> themselves. E.g. the 'project' doesn't truly exist from a legal entity
> perspective - and even those who do are at best an unincorporated
> association of individuals. From a legal perspective - projects can't
> make or distribute a release - they don't exist - only the ASF and the
> individual(s) doing the work. Given that one of the explicit reasons
> the Foundation was created was to[5]: "provide a means for individual
> volunteers to be sheltered from legal suits"; we want them to create
> and distribute releases as the Foundation.
> 4. Whether we like it or not - the Foundation is judged on the output
> from our projects and subprojects. We have a reputation of having
> clean IP, permissively licensed open source code, with clear
> provenance. Many people explicitly copy our standards, guidelines, and
> policies because they are the gold standard for good open source
> governance.
> 5. Disclaimers generally don't remove liability, and even if they did,
> our disclaimer talks about the maturity of our projects. - And it
> certainly doesn't remove the public's expectations from us - frankly -
> losing the publics trust is as scary as the potential legal liability.
> 6. The Board has delegated the responsibility of managing and ensuring
> adherence to policies and guidelines to the IPMC. I don't see this
> responsibility as boolean. It's not perfect compliance vs. failure.
> IMO, the IPMC has been delegated the decision making process, and may
> often find themselves making the business decision that an imperfect
> release is better than a community stalled for months or years. Don't
> let the perfect be the enemy of the good.
>
> From a podling's perspective:
> 1. Once you join the incubator you're a part of the ASF (Yay!?)
> 2. Your project is now a subproject of the IPMC.
> 3. There are rules, and you're entering a world of pain[4] In fact,
> you're likely to find that the ASF has more rules and structure that
> apply to projects than virtually any other home your project could
> choose. This is good and bad.
> 4. The incubator has a long, storied history of producing successful
> projects that flourish.
>
>
> [1]
> http://apache.org/foundation/records/minutes/2002/board_minutes_2002_10_16.txt
> [2] What we call Podlings, the initial resolution refers to as
> subprojects of the Incubator
> [3] It's worth noting that there were two resolutions proposed to
> create the Incubator - small differences, but interesting to read the
> differences.
> [4] https://youtu.be/3vB9U2hx6Qg
> [5] https://www.apache.org/foundation/faq.html#why
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Podlings, the Incubator, relationships and Apache
Posted by ซ่อยค่อย ลืมเขาแน่ <09...@gmail.com>.
ในวันที่ ศ. 21 มิ.ย. 2019 23:22 Alex Harui <ah...@adobe.com.invalid>
เขียนว่า:
> It all makes sense to me. I think there are two key points that are
> driving all of this discussion:
>
> "5. Disclaimers generally don't remove liability"
>
> IANAL so I don't know if that's true or not. For sure there are lots of
> disclaimers in the world. I do not know the history of the current
> DISCLAIMER (and labeling of releases with -incubating). What was the
> DISCLAIMERs original purpose? Should it be modified to cover
> less-than-perfect podling releases, especially around CatX inclusions? Who
> gets to make that call?
>
> " It's not perfect compliance vs. failure.
> IMO, the IPMC has been delegated the decision making process, and may
> often find themselves making the business decision that an imperfect
> release is better than a community stalled for months or years. Don't
> let the perfect be the enemy of the good."
>
> I think several "prominent" ASF members are saying this same thing, but
> nobody really wants to make it official. The responsibility seems to have
> been passed around between IPMC, Board, and VP Legal. How can the ASF get
> closure on this topic?
>
> My 2 cents,
> -Alex
>
> On 6/20/19, 10:04 AM, "David Nalley" <da...@gnsa.us> wrote:
>
> There's been a lot of discussion in various threads about bureaucracy,
> whether podlings are part of the ASF, etc. As a result of that I've
> spent a good deal of time reading resolutions and older discussions
> and organizing those thoughts from a legal and community perspective.
> I've also read a number of conversations from the more august members
> of our body about this subject. Altogether it has somewhat changed
> some of my opinions and assumptions. I've also sensed that there is a
> community/business/legal disconnect in our conversations. We're using
> the same words to mean very different things in each of those
> contexts. That said I am but one member of the IPMC, but maybe this
> will be helpful to someone else - I've tried to avoid my assumptions
> in this.
>
> The IPMC's first 'job'[1] is "accepting new products into the
> Foundation" The second 'job' of the IPMC is to "provide guidance and
> support to ensure that the Incubator's sub-projects[2] develop
> products according to the Foundation's philosophy and guidelines". The
> final 'job' is evaluating the products and determining whether they
> should be abandoned, continue to receive guidance and support, or be
> promoted to "full project status".
>
> So there are several realizations I gained from this from the
> Incubator perspective.
> 1. Acceptance into the Incubator is acceptance of the product into the
> Foundation.
> 2. That product is then a sub-project of the Incubator.
> 3. The IPMC has the "primary responsibility for the management of
> those subprojects".
>
> From the Foundation's perspective there are a number of things that
> come to mind:
> 1. We aren't a github/sourceforge/google code type platform where
> random people can upload/post what they want.
> 2. We do not have DMCA Safe Harbor protection - e.g. we are
> responsible for everything that we publish or distribute. With the
> exception of wikis and bug trackers anyone who can put something up on
> an Apache property has some form of legal relationship with the
> Foundation. This could be as simple as an ICLAs where you've
> contractually said you won't contribute anything you don't have rights
> to.
> 3. Most of the project's who have come to us aren't entities in and of
> themselves. E.g. the 'project' doesn't truly exist from a legal entity
> perspective - and even those who do are at best an unincorporated
> association of individuals. From a legal perspective - projects can't
> make or distribute a release - they don't exist - only the ASF and the
> individual(s) doing the work. Given that one of the explicit reasons
> the Foundation was created was to[5]: "provide a means for individual
> volunteers to be sheltered from legal suits"; we want them to create
> and distribute releases as the Foundation.
> 4. Whether we like it or not - the Foundation is judged on the output
> from our projects and subprojects. We have a reputation of having
> clean IP, permissively licensed open source code, with clear
> provenance. Many people explicitly copy our standards, guidelines, and
> policies because they are the gold standard for good open source
> governance.
> 5. Disclaimers generally don't remove liability, and even if they did,
> our disclaimer talks about the maturity of our projects. - And it
> certainly doesn't remove the public's expectations from us - frankly -
> losing the publics trust is as scary as the potential legal liability.
> 6. The Board has delegated the responsibility of managing and ensuring
> adherence to policies and guidelines to the IPMC. I don't see this
> responsibility as boolean. It's not perfect compliance vs. failure.
> IMO, the IPMC has been delegated the decision making process, and may
> often find themselves making the business decision that an imperfect
> release is better than a community stalled for months or years. Don't
> let the perfect be the enemy of the good.
>
> From a podling's perspective:
> 1. Once you join the incubator you're a part of the ASF (Yay!?)
> 2. Your project is now a subproject of the IPMC.
> 3. There are rules, and you're entering a world of pain[4] In fact,
> you're likely to find that the ASF has more rules and structure that
> apply to projects than virtually any other home your project could
> choose. This is good and bad.
> 4. The incubator has a long, storied history of producing successful
> projects that flourish.
>
>
> [1]
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache.org%2Ffoundation%2Frecords%2Fminutes%2F2002%2Fboard_minutes_2002_10_16.txt&data=02%7C01%7Caharui%40adobe.com%7Cf7c5e39c364b4bf8fff008d6f5a159f7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636966470679352679&sdata=ohGIgOepkDRYbh%2Fd69YFASb%2BHe0BHOfHeWD1ArH1kn8%3D&reserved=0
> [2] What we call Podlings, the initial resolution refers to as
> subprojects of the Incubator
> [3] It's worth noting that there were two resolutions proposed to
> create the Incubator - small differences, but interesting to read the
> differences.
> [4]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyoutu.be%2F3vB9U2hx6Qg&data=02%7C01%7Caharui%40adobe.com%7Cf7c5e39c364b4bf8fff008d6f5a159f7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636966470679352679&sdata=qg%2FxPScn07i1mnnurxsS1d9TZW2myxfAJBWV4U3kj8U%3D&reserved=0
> [5]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apache.org%2Ffoundation%2Ffaq.html%23why&data=02%7C01%7Caharui%40adobe.com%7Cf7c5e39c364b4bf8fff008d6f5a159f7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636966470679352679&sdata=SbrEmxffhCoR5QXD3hpqXIcXMBs8I8tEoDsRrJSxqWY%3D&reserved=0
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
>
Re: Podlings, the Incubator, relationships and Apache
Posted by Alex Harui <ah...@adobe.com.INVALID>.
It all makes sense to me. I think there are two key points that are driving all of this discussion:
"5. Disclaimers generally don't remove liability"
IANAL so I don't know if that's true or not. For sure there are lots of disclaimers in the world. I do not know the history of the current DISCLAIMER (and labeling of releases with -incubating). What was the DISCLAIMERs original purpose? Should it be modified to cover less-than-perfect podling releases, especially around CatX inclusions? Who gets to make that call?
" It's not perfect compliance vs. failure.
IMO, the IPMC has been delegated the decision making process, and may
often find themselves making the business decision that an imperfect
release is better than a community stalled for months or years. Don't
let the perfect be the enemy of the good."
I think several "prominent" ASF members are saying this same thing, but nobody really wants to make it official. The responsibility seems to have been passed around between IPMC, Board, and VP Legal. How can the ASF get closure on this topic?
My 2 cents,
-Alex
On 6/20/19, 10:04 AM, "David Nalley" <da...@gnsa.us> wrote:
There's been a lot of discussion in various threads about bureaucracy,
whether podlings are part of the ASF, etc. As a result of that I've
spent a good deal of time reading resolutions and older discussions
and organizing those thoughts from a legal and community perspective.
I've also read a number of conversations from the more august members
of our body about this subject. Altogether it has somewhat changed
some of my opinions and assumptions. I've also sensed that there is a
community/business/legal disconnect in our conversations. We're using
the same words to mean very different things in each of those
contexts. That said I am but one member of the IPMC, but maybe this
will be helpful to someone else - I've tried to avoid my assumptions
in this.
The IPMC's first 'job'[1] is "accepting new products into the
Foundation" The second 'job' of the IPMC is to "provide guidance and
support to ensure that the Incubator's sub-projects[2] develop
products according to the Foundation's philosophy and guidelines". The
final 'job' is evaluating the products and determining whether they
should be abandoned, continue to receive guidance and support, or be
promoted to "full project status".
So there are several realizations I gained from this from the
Incubator perspective.
1. Acceptance into the Incubator is acceptance of the product into the
Foundation.
2. That product is then a sub-project of the Incubator.
3. The IPMC has the "primary responsibility for the management of
those subprojects".
From the Foundation's perspective there are a number of things that
come to mind:
1. We aren't a github/sourceforge/google code type platform where
random people can upload/post what they want.
2. We do not have DMCA Safe Harbor protection - e.g. we are
responsible for everything that we publish or distribute. With the
exception of wikis and bug trackers anyone who can put something up on
an Apache property has some form of legal relationship with the
Foundation. This could be as simple as an ICLAs where you've
contractually said you won't contribute anything you don't have rights
to.
3. Most of the project's who have come to us aren't entities in and of
themselves. E.g. the 'project' doesn't truly exist from a legal entity
perspective - and even those who do are at best an unincorporated
association of individuals. From a legal perspective - projects can't
make or distribute a release - they don't exist - only the ASF and the
individual(s) doing the work. Given that one of the explicit reasons
the Foundation was created was to[5]: "provide a means for individual
volunteers to be sheltered from legal suits"; we want them to create
and distribute releases as the Foundation.
4. Whether we like it or not - the Foundation is judged on the output
from our projects and subprojects. We have a reputation of having
clean IP, permissively licensed open source code, with clear
provenance. Many people explicitly copy our standards, guidelines, and
policies because they are the gold standard for good open source
governance.
5. Disclaimers generally don't remove liability, and even if they did,
our disclaimer talks about the maturity of our projects. - And it
certainly doesn't remove the public's expectations from us - frankly -
losing the publics trust is as scary as the potential legal liability.
6. The Board has delegated the responsibility of managing and ensuring
adherence to policies and guidelines to the IPMC. I don't see this
responsibility as boolean. It's not perfect compliance vs. failure.
IMO, the IPMC has been delegated the decision making process, and may
often find themselves making the business decision that an imperfect
release is better than a community stalled for months or years. Don't
let the perfect be the enemy of the good.
From a podling's perspective:
1. Once you join the incubator you're a part of the ASF (Yay!?)
2. Your project is now a subproject of the IPMC.
3. There are rules, and you're entering a world of pain[4] In fact,
you're likely to find that the ASF has more rules and structure that
apply to projects than virtually any other home your project could
choose. This is good and bad.
4. The incubator has a long, storied history of producing successful
projects that flourish.
[1] https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache.org%2Ffoundation%2Frecords%2Fminutes%2F2002%2Fboard_minutes_2002_10_16.txt&data=02%7C01%7Caharui%40adobe.com%7Cf7c5e39c364b4bf8fff008d6f5a159f7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636966470679352679&sdata=ohGIgOepkDRYbh%2Fd69YFASb%2BHe0BHOfHeWD1ArH1kn8%3D&reserved=0
[2] What we call Podlings, the initial resolution refers to as
subprojects of the Incubator
[3] It's worth noting that there were two resolutions proposed to
create the Incubator - small differences, but interesting to read the
differences.
[4] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyoutu.be%2F3vB9U2hx6Qg&data=02%7C01%7Caharui%40adobe.com%7Cf7c5e39c364b4bf8fff008d6f5a159f7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636966470679352679&sdata=qg%2FxPScn07i1mnnurxsS1d9TZW2myxfAJBWV4U3kj8U%3D&reserved=0
[5] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apache.org%2Ffoundation%2Ffaq.html%23why&data=02%7C01%7Caharui%40adobe.com%7Cf7c5e39c364b4bf8fff008d6f5a159f7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636966470679352679&sdata=SbrEmxffhCoR5QXD3hpqXIcXMBs8I8tEoDsRrJSxqWY%3D&reserved=0
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org