Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein]

On Sun, Nov 22, 2015 at 5:42 AM, Harbs  wrote:
>...

> If there is a disagreement, it seems to be part semantics, part version
> control technologies (i.e. SVN optimized workflow vs Git optimized
> workflow) and part an actual difference in how to handle certain
> situations. It seems to me that the actual disagreement is pretty small. ;-)
>

No, it isn't small. I believe RTC as a standard policy is actively harmful.
Proponents use excuses for it, but using RTC for trunk/master is (IMO)
always a mechanism for control, exclusion, and a lack of trust of your
peers/community.

Cheers,
-g

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein]

On Sat, Nov 21, 2015 at 10:10 PM, Niclas Hedhman  wrote:

> I have now, days later, Reviewed this Thread and Commit to a veto of the
>

RTC


> whole debate, Can't agree That it is Rewarding for anyone... ;-)
>

CTR

... I saw what you did there :-)

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein]

Trick question, as I'd never work under that model :-)

Apache Subversion is CTR, with a very low bar to get commit access to
portions of the tree or a branch (only PMC members get access to whole
tree, so we grant full access and PMC membership simultaneously). We don't
need a fancy label for "contributor who is a committer" because such a
concept is anathema to the Subversion community's peer respect model.

On Thu, Nov 19, 2015 at 6:38 PM, Ralph Goers <ralph.go...@dslextreme.com>
wrote:

> Greg, which of these do you use when the “contributor” is a committer?
> Remember the model here is that the author is never allowed to commit their
> own code.
>
> Ralph
>
> > On Nov 19, 2015, at 3:10 PM, Greg Stein <gst...@gmail.com> wrote:
> >
> > The Apache Subversion project does something similar:
> >
> >
> http://subversion.apache.org/docs/community-guide/conventions.html#crediting
> >
> > We have a tool ("contribulyzer") that analyzes them. It's pretty neat.
> > On Nov 19, 2015 1:57 PM, "Chris Nauroth" <cnaur...@hortonworks.com>
> wrote:
> >
> >> Some projects use the git Signed-off-by field in the commit log to
> >> differentiate the author from the reviewer.
> >>
> >> --Chris Nauroth
> >>
> >>
> >>
> >>
> >> On 11/19/15, 10:58 AM, "Ralph Goers" <ralph.go...@dslextreme.com>
> wrote:
> >>
> >>> And there is another problem I have. Maybe it isn¹t true of all
> projects,
> >>> but the one I am involved with says the author can¹t commit his own
> code.
> >>> So the commit logs will not reflect who actually authored the code but
> >>> who reviewed it.
> >>>
> >>> I could probably tolerate RTC if I had to have the commit somewhere it
> >>> could be reviewed, I had to wait for the review and fix any defects and
> >>> then could commit the code myself (ideally even if no one actually
> >>> reviewed it). That process isn¹t really much different than what I do
> for
> >>> my larger commits anyway. But just submitting something for review and
> >>> then hoping someone reviews it and then hoping someone commits it takes
> >>> all the joy out of it for me.
> >>>
> >>> Ralph
> >>>
> >>>> On Nov 19, 2015, at 10:10 AM, Todd Lipcon <t...@cloudera.com> wrote:
> >>>>
> >>>>
> >>>> Sure, that's a big problem with some RTC workflows. Using gerrit or
> >>>> github
> >>>> PRs makes the flow much easier -- for a trivial or small patch, the
> sort
> >>>> that a "drive-by" contributor typically contributes, there probably
> >>>> won't
> >>>> be any review comments. So, they just push the patch for review, and
> >>>> they
> >>>> can be out of the loop for the rest of it. If the patch requires small
> >>>> revisions (eg addressing a typo or something) I think it's fine for
> the
> >>>> reviewer to just make the change themselves and commit on behalf of
> the
> >>>> original author to avoid the issue you've raised. Most RTC workflows
> >>>> permit
> >>>> this kind of thing in my experience.
> >>>
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >>> For additional commands, e-mail: general-h...@incubator.apache.org
> >>>
> >>>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein]

The Apache Subversion project does something similar:

http://subversion.apache.org/docs/community-guide/conventions.html#crediting

We have a tool ("contribulyzer") that analyzes them. It's pretty neat.
On Nov 19, 2015 1:57 PM, "Chris Nauroth"  wrote:

> Some projects use the git Signed-off-by field in the commit log to
> differentiate the author from the reviewer.
>
> --Chris Nauroth
>
>
>
>
> On 11/19/15, 10:58 AM, "Ralph Goers"  wrote:
>
> >And there is another problem I have. Maybe it isn¹t true of all projects,
> >but the one I am involved with says the author can¹t commit his own code.
> >So the commit logs will not reflect who actually authored the code but
> >who reviewed it.
> >
> >I could probably tolerate RTC if I had to have the commit somewhere it
> >could be reviewed, I had to wait for the review and fix any defects and
> >then could commit the code myself (ideally even if no one actually
> >reviewed it). That process isn¹t really much different than what I do for
> >my larger commits anyway. But just submitting something for review and
> >then hoping someone reviews it and then hoping someone commits it takes
> >all the joy out of it for me.
> >
> >Ralph
> >
> >> On Nov 19, 2015, at 10:10 AM, Todd Lipcon  wrote:
> >>
> >>
> >> Sure, that's a big problem with some RTC workflows. Using gerrit or
> >>github
> >> PRs makes the flow much easier -- for a trivial or small patch, the sort
> >> that a "drive-by" contributor typically contributes, there probably
> >>won't
> >> be any review comments. So, they just push the patch for review, and
> >>they
> >> can be out of the loop for the rest of it. If the patch requires small
> >> revisions (eg addressing a typo or something) I think it's fine for the
> >> reviewer to just make the change themselves and commit on behalf of the
> >> original author to avoid the issue you've raised. Most RTC workflows
> >>permit
> >> this kind of thing in my experience.
> >
> >
> >
> >-
> >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein]

On Thu, Nov 19, 2015 at 8:10 PM, Ralph Goers 
wrote:
>...

> of people wanting to join. I am sure this is going to be a controversial
> statement, but I have noticed that the projects that I’ve seen do this
> often have a fair number of committers who are paid to work on the project
> by their employer and I have to admit that I have wondered if these
> projects do this actually want to limit participation.
>

Yeup. And this kind of monkey business is why the Board specifically
requires PMCs to document their additions. A static PMC membership may be a
sign of exclusion. This kind of behavior is why the Board has completely
emptied two PMCs in the Foundation's history, and made them regrow
themselves organically.

As I said at the start of this thread: RTC is a mechanism for control, not
for managing "complex projects".

Cheers,
-g

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein]

Todd: as Ross notes, your three points about code reviews in a CTR project
are quite valid, and match accepted engineering practices.

What I haven't seen is an explanation why a committer must be treated the
same as a drive-by. Both are subject to requiring "permission"[1] to make
even the simplest of changes under RTC. Even worse, from else-thread, it
sounds like under your control scheme, you don't even allow the committer
to apply their own change [after review]. A committer can give a binding +1
to somebody else's work. But they aren't trusted to give that to their own
work. Just like a drive-by contributor can't be trusted.

-g

[1] thanks to Upayavira for capturing the essence of RTC: it is a
"permission" mechanism for control.

On Wed, Nov 18, 2015 at 3:16 AM, Ross Gardler <ross.gard...@microsoft.com>
wrote:

> Interesting, Todd, can you identify which of your three arguments for CTR
> are not present in RTC.
>
> Ross
>
> -Original Message-
> From: Todd Lipcon [mailto:t...@cloudera.com]
> Sent: Tuesday, November 17, 2015 11:23 PM
> To: general@incubator.apache.org
> Subject: Re: RTC vs CTR (was: Concerning Sentry...)
>
> On Tue, Nov 17, 2015 at 11:12 PM, Greg Stein <gst...@gmail.com> wrote:
>
> > On Wed, Nov 18, 2015 at 1:07 AM, Todd Lipcon <t...@apache.org> wrote:
> > >...
> >
> > > I think it's a _plus_ that contributors and committers contribute
> > > code in the same way -- it's more of a level playing field for new
> > > people contributing to the project.
> > >
> >
> > "level playing field"?? seriously??
> >
> > I find no logical or valid reasoning to drag committers down to the
> > same level as drive-by contributors.
> >
>
> I gave the logical and valid reasoning in previous posts in this thread:
> 1) no matter how seasoned a committer you are, you might make mistakes
> which are easily caught in code review
> 2) no matter how good you are at coding, your code might not make sense to
> a second pair of eyes, who can ask you to improve comments or docs
> 3) no matter if your code is perfect, the act of another person reading
> your code builds shared ownership over the code, thus alleviating
> bus-factor issues and improving the general feeling of a cohesive community
> developing a single project instead of a loose coalition of people with
> their own fiefdoms.
>
> I believe this to be generally accepted in the software engineering
> community. I don't know practices at every company, but I know at least
> that most of the well-regarded technology companies I've met with have some
> form of pre-commit review, and certainly many highly adopted open source
> projects as well (especially in infrastructure software).
>
> Either a high percentage of the world does this for "no logical or valid
> reason" or this is just a matter of opinion, and like I said, we can agree
> to disagree.
>
> -Todd
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein]

On Thu, Nov 19, 2015 at 11:10 AM, Todd Lipcon  wrote:

> On Thu, Nov 19, 2015 at 8:16 AM, Ralph Goers 
> wrote:
>
> > None of your statements below are any different between RTC or CTR. The
> > only time it makes aa difference is if no one does reviews.  My feeling
> is
> > that a community that insists on RTC believes that code will not be
> > reviewed unless committers are forced to do it.
> >
>
> Yep, that's my assumption. It's much more fun to write code than review it,
> so "forcing" people to do it is a good idea. The other worry is that, in a
>

And there it is. Forcing behavior. I knew it, and said so at the beginning
of this thread:

"I have always found the "complex project" to merely be an excuse for
control/no-trust."


-g

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein]

On Wed, Nov 18, 2015 at 4:31 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> I believe the issue here is that with CTR it is very easy to miss the 72h
> lazy consensus voting (with an assumed +1 absence any votes cast) that most
> CTR projects operate under... and thus it can also be very easy to miss the
> fact that there are reviews going on (and I am being generous here, I
> suspect that a lot of CTR commits are only reviewed within the 72h by a
> blind man on a galloping horse)
>

There isn't lazy consensus going on. All that really exists is the ability
to veto. If you don't get a veto, then you've achieved consensus :-)

And 72h is not part of the process either ... any change can be vetoed any
time before it gets released. "-1 on releasing that change" can occur
months later as you're preparing a release. See: http://s.apache.org/j4

Cheers,
-g

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein]

On Tue, Nov 17, 2015 at 8:06 PM, Todd Lipcon  wrote:
>...

> Except that there seems to be great disagreement among the Members as to
> whether RTC is somehow anti-Apache-Way.
>

That seems rather melodramatic. Speaking for myself, I've said that I find
RTC a terrible basis for forming a healthy community. I never mentioned the
Apache Way.


> If you want to try to create an ASF-wide resolution that RTC doesn't follow
> the Apache Way, and get the board/membership to vote on it, go ahead, but
> it confuses podlings who are new to the ASF when people espouse personal
> opinions as if they are ASF rules.
>

And again with the drama: nobody has suggested imposing any particular
approach on Apache communities.

I responded in this thread (and others) to get my views "out there", so
that podlings and other Apache communities can review my reasoning, and
whether those thoughts could be applied within their community.

Cheers,
-g

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein]

Of course it is community-based! (never said otherwise)

And my points are attempting to inform people about the underlying
principles of trust in these two modes of community operation. And (IMO)
that RTC is a horrible underpinning, preventing an establishment of a true
trust relationship among the members of the community. RTC leads with "I
don't trust you". CTR leads with "I trust you."

Others may justify their use of RTC under the rubric of "complexity", but
as I stated else-thread that is merely an excuse. There is no
justification, other than control. "Greg: you cannot fix javadoc tags. We
don't trust you. Each fix must be reviewed first, and approved." Hah.

-g


On Tue, Nov 17, 2015 at 3:35 AM, Pierre Smits <pierre.sm...@gmail.com>
wrote:

> No... That is a resolution in play based on consensus by the community. You
> may question that. But it is better done there.
>
> Best regards,
>
>
>
> Pierre Smits
>
> *OFBiz Extensions Marketplace*
> http://oem.ofbizci.net/oci-2/
>
> On Tue, Nov 17, 2015 at 10:27 AM, Greg Stein <gst...@gmail.com> wrote:
>
> > Hunh? How do you get that? I trust my fellow committers. That's not
> > projection.
> >
> > If I joined Hadoop right now, RTC says I cannot commit without review.
> That
> > is called "lack of trust". That I am unable to determine what is safe to
> > commit, and what I feel I need help with to safely commit.
> >
> > -g
> >
> >
> > On Tue, Nov 17, 2015 at 3:23 AM, Pierre Smits <pierre.sm...@gmail.com>
> > wrote:
> >
> > > That is what I say: you're projecting.
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > *OFBiz Extensions Marketplace*
> > > http://oem.ofbizci.net/oci-2/
> > >
> > > On Tue, Nov 17, 2015 at 10:11 AM, Greg Stein <gst...@gmail.com> wrote:
> > >
> > > > On Tue, Nov 17, 2015 at 3:02 AM, Pierre Smits <
> pierre.sm...@gmail.com>
> > > > wrote:
> > > > >...
> > > >
> > > > > And by the way, this has little to do with trust. More with hope.
> As
> > > in:
> > > > we
> > > > > hope they won't abuse our trust. It seems you're projecting trust
> > > issues!
> > > > >
> > > >
> > > > It is ALL about trust. I've worked in the httpd, apr, and svn
> projects
> > > > here. I trust all of my fellow community members to commit
> > appropriately.
> > > > Hope doesn't come into play at all. I trust them.
> > > >
> > > > -g
> > > >
> > >
> >
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein]

On Tue, Nov 17, 2015 at 3:02 AM, Pierre Smits 
wrote:
>...

> And by the way, this has little to do with trust. More with hope. As in: we
> hope they won't abuse our trust. It seems you're projecting trust issues!
>

It is ALL about trust. I've worked in the httpd, apr, and svn projects
here. I trust all of my fellow community members to commit appropriately.
Hope doesn't come into play at all. I trust them.

-g

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein]

Hunh? How do you get that? I trust my fellow committers. That's not
projection.

If I joined Hadoop right now, RTC says I cannot commit without review. That
is called "lack of trust". That I am unable to determine what is safe to
commit, and what I feel I need help with to safely commit.

-g


On Tue, Nov 17, 2015 at 3:23 AM, Pierre Smits <pierre.sm...@gmail.com>
wrote:

> That is what I say: you're projecting.
>
> Best regards,
>
> Pierre Smits
>
> *OFBiz Extensions Marketplace*
> http://oem.ofbizci.net/oci-2/
>
> On Tue, Nov 17, 2015 at 10:11 AM, Greg Stein <gst...@gmail.com> wrote:
>
> > On Tue, Nov 17, 2015 at 3:02 AM, Pierre Smits <pierre.sm...@gmail.com>
> > wrote:
> > >...
> >
> > > And by the way, this has little to do with trust. More with hope. As
> in:
> > we
> > > hope they won't abuse our trust. It seems you're projecting trust
> issues!
> > >
> >
> > It is ALL about trust. I've worked in the httpd, apr, and svn projects
> > here. I trust all of my fellow community members to commit appropriately.
> > Hope doesn't come into play at all. I trust them.
> >
> > -g
> >
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein]

On Tue, Nov 17, 2015 at 1:53 AM, Bertrand Delacretaz  wrote:

> On Tue, Nov 17, 2015 at 5:25 AM, Ted Dunning 
> wrote:
> > ...RTC can be framed as "I don't trust you to do things right"...
>
> Or also "I don't trust myself 100% to do things right here and would
> like systematic reviews of my commits".
>

People should be trusted to ask for help/review when necessary. CTR trusts
people to commit changes they feel are right, but it also trusts them to
stop and ask for a preliminary review when they feel/know they're deep into
the tricky code.

RTC never trusts people with the easy changes. It believes all changes are
equal, assumes all changes are beyond the abilities of individuals, and all
committers are incapable of self-reflection. That each and every change
must be scrutinized by others for approval.

Ted's phrase "I trust you to help me make things better" is not unique to
RTC. Both CTR and RTC have that "R" in them for review, to ensure the code
can always be improved.

If I join a CTR community, then I know that I can go around improving
comments, docstrings, and minor code cleanups. That is a solid contribution
that every project would love to have. If I join an RTC community, I'm not
trusted to do any of that. There is no other explanation. None of that has
to do with "complexity". It is simply control and exclusion of my
desire/interest to contribute. To keep the mantle of development within a
select set of people who decided to exert this tactic over their codebase.

-g

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein]

In RTC, a contributor sending in a patch, a pull request, or a JIRA/patch
is handled exactly the same as any other committer. None are trusted to
apply their change, until they receive review and permission from others.
So you would think that "everybody" would get committer status on Day One.
Why not? No effective difference between contributor and committer. "Oh, he
gets a committer privilege bit to apply the change." ... That's it. A
committer bit. No other difference from John Doe contributor.

"Hey! We want to invite you to become a committer!" ... "oh. gee. yay. I'm
so enthused. what a difference. NOT."

On Wed, Nov 18, 2015 at 12:06 AM, Dave Fisher  wrote:

> I see the essence of what it means to be a committer. Being trusted to
> both do the correct action and be willing to listen objectively to
> criticism. In an CTR project it is clear to me that the point where a
> project grants Committership should be the point where the PMC wants to
> treat an individual's contribution as CTR rather than RTC. How does an RTC
> project make THAT important decision?
>
> Regards,
> Dave
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein]

On Wed, Nov 18, 2015 at 1:07 AM, Todd Lipcon  wrote:
>...

> I think it's a _plus_ that contributors and committers contribute code in
> the same way -- it's more of a level playing field for new people
> contributing to the project.
>

"level playing field"?? seriously??

I find no logical or valid reasoning to drag committers down to the same
level as drive-by contributors.

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein]

On Mon, Nov 16, 2015 at 11:53 AM, Todd Lipcon  wrote:
>...

> 1) You're right, I don't trust anybody to make code changes to a complex
> project with zero oversight. I currently work on a project that I
>

I have always found the "complex project" to merely be an excuse for
control/no-trust.

All software is hard. Your project is no more complex than others.

-g

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein]

On Mon, Nov 16, 2015 at 4:56 PM, Todd Lipcon <t...@cloudera.com> wrote:

> On Mon, Nov 16, 2015 at 2:50 PM, Greg Stein <gst...@gmail.com> wrote:
> > On Mon, Nov 16, 2015 at 11:53 AM, Todd Lipcon <t...@apache.org> wrote:
> > >...
> > > 1) You're right, I don't trust anybody to make code changes to a
> complex
> > > project with zero oversight. I currently work on a project that I
> >
> > I have always found the "complex project" to merely be an excuse for
> > control/no-trust.
> >
> > All software is hard. Your project is no more complex than others.
>
> Having worked on projects in pretty much every layer of the software stack,
> I think we'll just have to agree to disagree.
>

hahaha... and you prove my point.

Cheers,
-g

Re: [VOTE] Retire Corinthia

[Greg Stein]

+1 (binding)

On Sun, Nov 15, 2015 at 9:01 PM, Marvin Humphrey 
wrote:

> Greetings,
>
> The Corinthia community has voted to retire:
>
>   http://s.apache.org/odN
>
> This is a vote of the IPMC to confirm the decision to retire the podling.
>
> [ ] +1 to retire Corinthia from the Incubator
> [ ] -1 to keep Corinthia in the Incubator
>
> This vote will be held open for at least 72 hours.
>
> Should this vote pass, I have volunteered to assist Corinthia with
> retirement,
> as I am assisting Droids and Kalumet.
>
> Marvin Humphrey
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Greg Stein]

On Wed, Nov 11, 2015 at 6:27 AM, Steve Loughran 
wrote:

>
> > On 11 Nov 2015, at 09:38, Bertrand Delacretaz 
> wrote:
> >
> > Hi Steve,
> >
> > On Tue, Nov 10, 2015 at 9:31 PM, Steve Loughran 
> wrote:
> >> ...is JIRA-first development conducive to developing a community?...
> >
> > I don't think so, as you say this breaks the project into very small
> > buckets and it's very hard for someone new to get the overview of
> > what's going on and what the big ideas and visions are.
>

Agreed.

I also find it sad that work is *gated* by using Jira first. We should be
trusting our peers, let them commit changes necessary, and review their
work afterwards. Trust is the basis of a healthy community, and RTC (via
Jira or otherwise) just screams "we don't trust you. we must review all
commits first."

>...

> One of the troublespots is those "minor" patches which have traumatic
> consequences; you don't notice when the issue is created, don't watch it,
> and then, when its merged in, you discover that things now behave
> differently. Anything related to specific dependency updates are things to
> watch there (guava, jackson, jersey), but it could be something more subtle
> like a change in the concurrency model of some bit of code. It's only later
> that you find your code has stopped working and you are left trying to work
> out what happened and why.
>

I'm not sure what the above has to do with issues/Jira. Any commit can have
this effect, whether it was done directly or via an issue. It's just a
typical problem with development.

(and yeah, it leads into a whole separate conversation about testing and CI)

>...

> Noted, but we're going to try it in the slider dev group anyway, so we can
> do some more detailed code review of various complex things more
> interactively. I know it excludes people who can't be there, but its still
> more inclusive of
>

I see no problem doing code reviews this way, as other devs can still
comment/review whatever output gets committed. They're only "shut out" of
the first review, not ALL review.

Using them for initial code development or decisions? Not so much.

Using them to reach a consensus among a subset of the community? Sure, and
bring that result to the dev@ list to reach full community consensus. We
see this done all the time with hackathons: the group at the 'thon come up
with some idea they all like, and bring that to the dev@ list. 10 people
think it is the right approach and share it, then rope in the other 10.

>...

Cheers,
-g

Re: Releases during incubation?

[Greg Stein]

Yup. Subversion 1.6.9 was released while we were incubating.

Further: Subversion 1.6.x had patch releases for three years (given our
support rules), after we became Apache Subversion. 1.7.0 was our first
Apache release, occurring about 18 months after we became a TLP. We
distinguished them by name (Subversion vs Apache Subversion), and by
release channel/host (tigris.org vs apache.org). The same people happened
to work on both releases, but we made sure to distinguish non-Foundation
releases.

On Mon, Nov 9, 2015 at 7:22 PM, Joe Schaefer  wrote:

> Subversion cut a release while in incubation on their old system.
> Shouldn't pose a problem for others.
>
> On Mon, Nov 9, 2015 at 8:03 PM, Todd Lipcon  wrote:
>
> > Hey folks,
> >
> > Hopefully quick policy question here:
> >
> > Once a project is under proposal for incubation, what is the foundation
> > policy on that project making releases outside of Apache from its current
> > home?
> >
> > For example, suppose there's an open source project FooBar, with a public
> > release FooBar 1.0.0 in use by various people out in the world. FooBar is
> > then proposed to the incubator. During the discussion/voting timeframe,
> > someone discovers a bug in FooBar 1.0.0, and the team would like to
> release
> > FooBar 1.0.1 from the project's current home (eg github). Would this be
> an
> > issue?
> >
> > More controversial variant:
> >
> > How about early during the incubation period, while the project is still
> in
> > the process of transitioning the necessary infrastructure, etc, into the
> > ASF repositories? Assuming that the project is making good faith efforts
> > towards making a release compatible with ASF guidelines, would it be
> > allowed to make "external" releases during this initial period of
> > incubation, for the purposes of bug fixes?
> >
> > Thanks
> > Todd
> >
>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Greg Stein]

On Sat, Nov 7, 2015 at 1:07 PM, Dennis E. Hamilton 
wrote:
>...

> Huh?  The development of this document,
>
>  >
>
> was carried out on the dev community list over a significant period of
> time.  It even provides an account for


And that is the key part: written by the ComDev community. Not the
Foundation. I believe Brane shares my fear that the document will become a
de facto standard/requirement across the ASF.

Should mentors and podlines want to use it as a guide for things to
consider... great.

But some of us will push back, if it appears it is being used as a
yardstick, rather than a guide.

Cheers,
-g

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Greg Stein]

My belief is that committer != PMC is the ideal choice, based on my long
history of watching communities at the ASF. It allows for onboarding
committers rapidly and with a lower bar. That helps to draw them further
into the community, reduces the workload of others (who would otherwise
need to review/apply their work), and provides a mechanism to review
bringing them onto the PMC.

As Greg Reddin notes, separation of the two roles provides a mechanism for
distinguishing between "enable contributions" and "enable governance". As
an old-timer, I've observed (unfortunately) too many problems in
governance. An extra step is advisable (with a higher bar, while keeping
the low bar for contributions).

Cheers,
-g


On Fri, Nov 6, 2015 at 11:34 AM, Dennis E. Hamilton  wrote:

> I think there is a difference between what TLPs do and what the
> recommended approach for Podlings is.
>
> My impression, based on limited podling experience, is that the default
> tends to be PPMC == committer.
>
> Thanks for raising the notion of looking at why committers are *not* moved
> to the PMC of a TLP after some period of time, though.  My question, as a
> PMC member, would be whether or not we are holding the reins too tight at
> the expense of both community and sustainability.  An useful danger sign,
> that.
>
>  - Dennis
>
> > -Original Message-
> > From: Greg Reddin [mailto:gred...@gmail.com]
> > Sent: Friday, November 6, 2015 06:22
> > To: general@incubator.apache.org
> > Subject: Re: Concerning Sentry: A disagreement over the Apache Way and
> > graduation
> >
> > On Fri, Nov 6, 2015 at 7:58 AM, Rich Bowen  wrote:
> > > On 11/05/2015 12:02 AM, Joe Schaefer wrote:
> > >> Committership is the right to do work on the project. PMC membership
> > is the
> > >> right to participate in governance.  People left in the nebulous
> > state
> > >> between
> > >> committership and PMC membership for long periods of time more than
> > likely
> > >> will give up in frustration for not being trusted enough to govern
> > their
> > >> own work.
> > >
> > >
> > > Most of the older projects at the Foundation do not have PMC ==
> > > Committer. Notably, httpd. The notion that committers are
> > automatically
> > > PMC is a fairly new innovation. As it happens, it's an innovation that
> > I
> > > wholeheartedly support and recommend, but it's a minority of projects
> > > that have this policy. If you follow board reports, you'll notice that
> > > PMC additions and Committer additions are seldom coincident.
> >
> > In further support of Joe's point, for most of the projects I've been
> > involved with, the PMC promotion was almost automatic and occurred
> > within about 6 months of committership. The committer-only period was
> > just a probationary period to make sure a person was not going to
> > abuse his/her privileges. An invite to committership comes with an
> > unspoken assumption that we want you to help govern the project, but
> > let's start with giving you access. I don't know that I ever saw
> > anyone stay as committer-only for an extended period of time.
> >
> > Greg
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Greg Stein]

On Nov 4, 2015 10:03 AM, "Bertrand Delacretaz" 
wrote:
>
> Hi,
>
> On Wed, Nov 4, 2015 at 4:52 PM, Patrick Hunt  wrote:
> > ...If you read the graduation requirements it says nothing about adding
PPMC
> > as a strict requirement to graduation:
> >
http://incubator.apache.org/incubation/Incubation_Policy.html#Graduating+from+the+Incubator
> ...
>
> I agree but in the meantime we have
> https://community.apache.org/apache-way/apache-project-maturity-model.html

"we" don't have anything. ComDev has produced an interesting to way to look
at projects. Possibly a metric. ... But not an agreed-upon system for the
proper evaluation of a podling's health and community.

-g

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Greg Stein]

On Nov 4, 2015 2:47 AM, "Bertrand Delacretaz" 
wrote:
>
> On Tue, Nov 3, 2015 at 10:42 PM, Patrick Hunt  wrote:
> > ...what would the action item the community should take away from
> > this? As their mentor I'm not sure what advice i can give them. "add
more
> > ppmc members"? Sounds like that's in the pipeline. Seems artificial to
me
>
> If it's in the pipeline that's fine, what's important IMO is that the
> podling demonstrates that it can grow/renew its (p)PMC, during
> incubation.

And note the Board also wants to see PMC growth over the years (for TLPs).
This is why we mandate reporting requirements of "last date of PMC addition"

Cheers,
-g

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Greg Stein]

Jira issues are (IMO) a bit too passive to be focal points for community
interaction.

The *active* process of an email arriving in your inbox? Much better for
enabling community members to participate. And a uniform and easy way to do
so. Especially against the *transient* nature of Jira issues. If one gets
closed out quickly ("fixing them rapidly"), then discussion is effectively
shut down right then and there. That is not *inviting* discussion, but is
closing it down.

If you leave a Jira open for 72 hours, then it might be possible to argue
for inclusion. But the exact opposite seems to be occurring.

A mailing list allows any/all discussion to remain open. There is no
open/closed status associated with a particular topic.

Cheers,
-g


On Mon, Nov 2, 2015 at 5:59 AM, Joe Brockmeier  wrote:

> Hi all,
>
> I'm one of the mentors of Sentry, which has been in incubation for some
> time. The project has progressed in a number of ways, but my largest
> concern is that the podling is doing [in my opinion] too much
> development and discussion out-of-sight.
>
> I've raised issues about this, as has David Nalley. David had a
> conversation with members of Sentry at ApacheCon Big Data in September,
> and that discussion was brought back to the list. [1]
>
> Jiras are being filed, and swiftly acted on, in a way that strongly
> suggests that a lot of discussion and direction of the project are
> happening off-list and out-of-sight to the average participant. David
> and myself have suggested ways that the community can remedy this, but
> the most recent mail from Arvind indicates that he (and others in the
> podling) don't feel it is a "valid ask."
>
> At this point, I'm raising this to general@ because I'd like second (and
> third, etc.) opinions. Perhaps I'm deeply wrong, and others here feel
> Sentry is ready to graduate. My feeling is that the podling is not
> operating in "the Apache Way" and doesn't show a great deal of interest
> in doing so. [2] To quote Arvind:
>
> "I feel another issue being pointed out or which has been eluded to in
> the past is - who decides which Jiras should be fixed, what features to
> create etc, specially when they show up as Jira issues directly with
> patches that follow soon. It seems that in some ways the lack of using
> mailing lists directly for discussion is linked to this behavior of
> filing issues and fixing them rapidly, as if following a roadmap that
> the community does not have control over. Please pardon me if my
> interpretation/understanding of the issue is not right. But if it is
> right, then I do want to say that - that too is not an issue in my
> opinion at all. And here is why:
>
> When someone files a Jira, they are inviting the entire community to
> comment on it and provide feedback. If it is not in the interest of the
> project, I do believe that responsible members of the community will be
> quick to bring that out for discussion and even Veto it if necessary. If
> that is not happening, it is not an issue with lack of community
> participation, but rather it is an indicator of a project team that
> knows where the gaps are and understands how to go about filling them
> intuitively."
>
> The model that Sentry is pursing may work very well *for the existing
> members of the podling.* In my opinion, its process is entirely too
> opaque to allow for interested parties outside of the existing podling
> and companies interested in Sentry development to become involved.
>
> The podling is pressing to move to graduation, and I cannot in good
> conscience vote +1 or even +0 at this point. I'm strongly -1 as a mentor
> and don't feel the podling has any interest in working in "the Apache
> Way" as commonly understood. [3]
>
> However, I feel we've reached an impasse and there's little value in
> continuing to debate amongst the mentors / podling. They've stated their
> position(s) and I've stated mine. (I *think* David Nalley is in
> agreement with me, but I don't wish to speak for him.)
>
> I'm bringing this to the IPMC fully understanding that I might be
> totally wrong - maybe I'm holding to a too strict or outdated idea of
> how projects should operate. I'm happy to be told so if that's the case
> so I can improve as a mentor or decide to bow out from mentoring in the
> future, if it's the case that my idea of a project is out-of-line with
> the majority here.
>
> [1] http://s.apache.org/611
> [2] http://s.apache.org/bhQ
> [3] http://theapacheway.com/
>
> Best,
>
> jzb
> --
> Joe Brockmeier
> j...@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Short form IP clearance

[Greg Stein]

On Wed, Oct 28, 2015 at 10:35 AM, William A Rowe Jr 
wrote:
>...

> I'd noted that
> http://incubator.apache.org/ip-clearance/httpd-mod_h2-clearance.html
> never had a corresponding clearance/acceptance thread at general@i.a.o,
> so it appears that the current instructions no longer match the methodology
> documented in-practice by our VP Legal.  Jim, perhaps you can put together
> a change summary of what the actual incubator committee 'oversight'
> consists of, today? Current practice might already alleviate Greg's
> concerns.
>

I just believe that web page is incorrect -- that one PMC has no
jurisdiction over another. Thus, the page needs to be fixed. That's the one
thing I wanted, but it appears to be controversial.

If the Legal Affairs Committee(*) wants a "second set of eyes", then fine
... but please clarify that under www.a.o/legal/ with
instructions/clarification.

Thanks,
-g

(*) I've been remiss in earlier emails, in who to ask -- decisions are made
by the Board committee, who is chaired by VP Legal.

Re: Not just yet

[Greg Stein]

On Oct 23, 2015 1:01 AM, "Sam Ruby" <ru...@intertwingly.net> wrote:
>
> On Thu, Oct 22, 2015 at 10:17 PM, Greg Stein <gst...@gmail.com> wrote:
> > On Oct 22, 2015 9:57 AM, "Sam Ruby" <ru...@intertwingly.net> wrote:
> >>...
> >> I've also opened another issue that I would appreciate feedback on:
> >>
> >> https://issues.apache.org/jira/browse/WHIMSY-28
> >
> > Cross-check is nice.
> >
> > I'd suggest another possibility: a web tool to *add* a template-based
> > resolution in the first place.
>
> A.K.A.  A wizard or assistant[1].  Good idea, and easy peasy to
> implement.

Yup. With the agenda editing bits you've developed, I figured you could do
this with your morning coffee :-)

> I can start with these:
>
> https://svn.apache.org/repos/private/committers/board/templates/

Yes.

> The only thing that looks moderately challenging from a UI perspective
> is allowing the entry of a list of users.  I may just go with a
> textarea as people generally have a resolution that they have voted on
> prior to posting a board resolution.

Good point. But in that whimsy issue, you mentioned checking the list of
names/emails, so you've already got some processing for that textarea.

Cheers,
-g

Re: Short form IP clearance

[Greg Stein]

On Thu, Oct 22, 2015 at 6:45 AM, Jim Jagielski  wrote:

> First and foremost, I have not followed this thread almost at
> all. I've been at ATO2015 and then traveling.
>
> What I will say, whether it has been said or not, that
> as VP Legal, I will work w/ the Incubator on whatever issues
> or questions they may have. If it's time for a conversation
> between VP Legal and Incubator re: IP clearance, one that
> has not happened for at least a decade, iirc, then I am
> fine with that as well and am ready to do so.


Please read the thread: it contains my part of that conversation that I
think needs to happen.

Thx,
-g

Re: Short form IP clearance

[Greg Stein]

It certainly is not optional, and it would be very unfortunate if TLPs
thought so or are unaware. One of the reasons I'd prefer Legal to be the
clear owner. (But to be clear, that is separate from my original post)
On Oct 22, 2015 6:13 PM, "P. Taylor Goetz" <ptgo...@gmail.com> wrote:

> Again my apologies for polluting this thread with tangential thoughts.
>
> Maybe I should start a new thread: "Is IP Clearance Optional?"
>
> My point is that some projects seem to be diligent, while others do not --
> to the point that at times the IP Clearance process seems optional. I would
> expect the incubator ip clearance list to be a lot longer than it is, and
> have more entries especially from some big data projects that accept some
> very large "patches."
>
> I may be overly cautious, but it seems like there are some important legal
> concerns that are being overlooked.
>
> And I'm not trying to create more work for whatever ASF entity is charged
> with policing the process. ;)
>
> -Taylor
>
> > On Oct 22, 2015, at 12:29 AM, Greg Stein <gst...@gmail.com> wrote:
> >
> >> On Wed, Oct 21, 2015 at 11:10 PM, P. Taylor Goetz <ptgo...@gmail.com>
> wrote:
> >>
> >> Apologies for potentially coming out of left field on this…
> >
> > hehe... I did too :-)
> >
> >
> >> But I think that IP clearance is currently a difficult road to travel,
> and
> >> I worry that we are graduating podlings that don’t even know when or
> how to
> >> go down that road. It’s all too easy to merge a github pull request
> without
> >> considering IP clearance.
> >>
> >> I’ll admit that I’m unclear on the policy, and try to err on the
> cautious
> >> side.
> >
> > I expect anybody unclear to simply ask. That happens all the time. We
> have
> > press@ to help people with questions about marketing and outreach. We
> have
> > trademarks@ for branding questions. We have legal-internal@ and
> > legal-discuss@ to ask questions about IP clearance (and other legal-ish
> > matters).
> >
> > We have a system of Trust and Independence for our TLPs. The (filed)
> forms
> > are there for a TLP to follow, to check off steps, etc. There is a guide
> > and a description on how to fill out and file the form. And what is
> needed.
> >
> > All good.
> >
> > My concern is the injection of the IPMC into the process, and subjugating
> > one TLP to its will. IMO, that just is not *possible/allowed* by the
> > structure we have set up at the ASF. Thus, step 5 needs some modification
> > and 7/8 need removal to align with the actual structure of the ASF.
> >
> >
> >> I’ve seen commits to TLP projects that made me think “WTF… how did this
> >> evade IP clearance?”.
> >>
> >> I may be overreacting, but it seems to me IP clearance is REALLY
> >> important, and I worry that it may be taken for granted.
> >
> > You say it yourself: commits come from out of the blue. Nobody
> > second-guesses a TLP's series of commits. Nobody second-guesses (say) the
> > trust network they have set up in a KEYS file for their release
> artifacts.
> > The "IP Clearance" process is already *more* controlling than other
> > policies that TLPs must follow.
> >
> > I'm not asking to omit the process, but (IMO) the notion that the IPMC
> has
> > control over our other projects is simply incorrect, so the doc needs
> > updating.
> >
> > Cheers,
> > -g
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Not just yet

[Greg Stein]

On Oct 22, 2015 9:57 AM, "Sam Ruby"  wrote:
>...
> I've also opened another issue that I would appreciate feedback on:
>
> https://issues.apache.org/jira/browse/WHIMSY-28

Cross-check is nice.

I'd suggest another possibility: a web tool to *add* a template-based
resolution in the first place.

Cheers,
-g

Re: Short form IP clearance

[Greg Stein]

On Wed, Oct 21, 2015 at 11:10 PM, P. Taylor Goetz  wrote:

> Apologies for potentially coming out of left field on this…
>

hehe... I did too :-)


> But I think that IP clearance is currently a difficult road to travel, and
> I worry that we are graduating podlings that don’t even know when or how to
> go down that road. It’s all too easy to merge a github pull request without
> considering IP clearance.
>
> I’ll admit that I’m unclear on the policy, and try to err on the cautious
> side.
>

I expect anybody unclear to simply ask. That happens all the time. We have
press@ to help people with questions about marketing and outreach. We have
trademarks@ for branding questions. We have legal-internal@ and
legal-discuss@ to ask questions about IP clearance (and other legal-ish
matters).

We have a system of Trust and Independence for our TLPs. The (filed) forms
are there for a TLP to follow, to check off steps, etc. There is a guide
and a description on how to fill out and file the form. And what is needed.

All good.

My concern is the injection of the IPMC into the process, and subjugating
one TLP to its will. IMO, that just is not *possible/allowed* by the
structure we have set up at the ASF. Thus, step 5 needs some modification
and 7/8 need removal to align with the actual structure of the ASF.


> I’ve seen commits to TLP projects that made me think “WTF… how did this
> evade IP clearance?”.
>
> I may be overreacting, but it seems to me IP clearance is REALLY
> important, and I worry that it may be taken for granted.
>

You say it yourself: commits come from out of the blue. Nobody
second-guesses a TLP's series of commits. Nobody second-guesses (say) the
trust network they have set up in a KEYS file for their release artifacts.
The "IP Clearance" process is already *more* controlling than other
policies that TLPs must follow.

I'm not asking to omit the process, but (IMO) the notion that the IPMC has
control over our other projects is simply incorrect, so the doc needs
updating.

Cheers,
-g

Re: [RESULT] [VOTE] Accept Mynewt into the Apache Incubator

[Greg Stein]

Update: the mailing lists have been created, in case anybody is interested
in following along.


On Mon, Oct 19, 2015 at 12:10 PM, Sterling Hughes <sterl...@apache.org>
wrote:

> On Mon, Oct 12, 2015 at 9:04 AM, Sterling Hughes <sterl...@apache.org>
> wrote:
> > Hi All,
> >
> > As mentioned in the DISCUSS thread, all feedback has been positive on
> > the Mynewt proposal, so I'd like to call a VOTE to accept Mynewt as a
> > new ASF incubator project.
> >
> > The full text of the proposal is available on the incubator wiki at
> > the following URL:
> >
> > https://wiki.apache.org/incubator/MynewtProposal?action=recall=20
> >
> > I have also included the full text below.
> >
> > Vote is open until Thurs, 16th October 2015, 23:59:00 PST.
> >
> > [   ] +1 to accept Mynewt into the Apache Incubator
> > [   ] +0
> > [   ] -1 because...
> >
>
>
> This vote is now closed and passes with 4 binding +1 votes,
> 3 non-binding +1 votes and no 0 or -1 votes.
>
> Thanks to all who helped with the proposal and cast the vote!
>
> Here's a vote tally:
>
> Non-binding +1s:
>   Jim Jagielski
>   Marvin Humphrey
>   Bertrand Delacretaz
>
> Binding +1s:
>   P. Taylor Goetz
>   Justin Mclean
>   Greg Stein
>   Jean Baptiste Onofré
>
> No 0 or -1 votes.
>
> Thanks,
> Sterling
>
> PS: I didn't realize that I could also vote on the proposal until too
> late, but for the record, I'm also a +1 :-)
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Eagle incubator proposal

[Greg Stein]

On Thu, Oct 22, 2015 at 12:09 AM, Owen O'Malley  wrote:

> On Mon, Oct 19, 2015 at 9:00 AM, Ted Dunning 
> wrote:
>
> > I would suggest that Owen O'Malley has not had enough time to be a viable
> > mentor recently and should not be on the list of mentors.
> >
>
> I have been helping Kylin out and it is graduating, so I'm down to just
> Hawq. I'd like to help Eagle out.
>

No need to be on the official list of mentors ... just help out anyways ...
heck, then you don't have to be responsible for signing off reports ;-)

Re: [DISCUSS] Eagle incubator proposal

[Greg Stein]

On Wed, Oct 21, 2015 at 11:53 AM, Henry Saputra 
wrote:
>...

> To be fair, I will circle one more time to existing mentors for Eagle
> to confirm their commitment for active participation in the podling.
> Would that be acceptable solution?
>

Acceptable to whom? I bet you there are enough people who find the list of
mentors to be acceptable, despite Marvin's emails otherwise... :-)

To put it another way: it is unfair to pre-judge people. Even more,
*accepting* a podling should not be subject to a preapproved list of
mentors, since we have juggled mentors many times in the past. *Should* a
mentor be absent in the *future*, then they can be replaced. ... but I
believe it is better to be reactive, than to pre-judge.

Cheers,
-g

Short form IP clearance

[Greg Stein]

Hey all,

On the following page:
  http://incubator.apache.org/ip-clearance/ip-clearance-template.html

The process steps do not align with the intent described in the Preamble,
and some steps are not required. Specifically, steps 5, 7, and 8.

Step 5: the code will be imported *somewhere*; there is no reason for it to
be duplicated into the Incubator repository. The ASF simply requires
paperwork to acknowledge the propriety of that import, wherever it may be.
There isn't even a reason for a checksum.

Step 7: the Incubator has no prerogative over what the VP of an Apache
project does (or other Officers, for that matter). If a TLP wants some
code, then they can do so. And the representative of that TLP (the VP, an
Officer) is the one taking responsibility for their actions. The Incubator
has been a recording area, but that doesn't give it discretion over other
projects.
[ IMO, the recording should go somewhere identified by VP Legal Affairs,
and be entirely disconnected from the Incubator ]

Step 8: moot, once (7) is removed.

I'd like to modify the steps to reflect the above points.

Thoughts?

Cheers,
-g

Re: Short form IP clearance

[Greg Stein]

I believe a PMC is capable of performing IP clearance itself. They have a
VP that is an Officer and can take responsibility for the Foundation in
matters of that Project. The forms/recording are valid, so I haven't
suggested changing that (tho I'd like to see them move under /legal/, I'm
not fussed about their location).

I would hope that a PMC includes a note in their report to the Board, that
they filed a clearance form. That is just natural reporting. But that is
quite different from one TLP being subject to another TLP's vote (whether
lazy consensus or not).

There could certainly be an argument that a PMC needs to be double-checked
by $entity. But that kind of second-guessing means $entity needs to
double-check all commits and all release artifacts. We trust PMCs to get
their IP done correctly, as they work on their project and make releases.

Cheers,
-g

On Wed, Oct 21, 2015 at 8:28 PM, John D. Ament <johndam...@apache.org>
wrote:

> Greg,
>
> If I'm reading your email correctly, you're just saying that the Incubator
> is not responsible for processing IP Clearances in a lazy way.  Projects
> should instead direct their IP clearance emails to <>.
>
> That <> is TBD.
>
> John
>
> On Wed, Oct 21, 2015 at 9:17 PM Greg Stein <gst...@gmail.com> wrote:
>
> > [trimmed response right now; in favor of getting a couple other voices]
> >
> > On Wed, Oct 21, 2015 at 7:01 PM, Sam Ruby <ru...@intertwingly.net>
> wrote:
> > >...
> >
> > > What is this, randomly propose changes to the incubator month?
> > >
> >
> > Has nothing to do with the Incubator, but with how a PMC records its IP
> > clearance. And more importantly, to clarify that a PMC is not beholden to
> > the IPMC.
> >
> >
> > > Let me repeat what I just said.  I don't believe I was being obtuse,
> > > but then again, you don't appear to have read what I wrote.
> > >
> >
> > I certainly read it, you weren't being obtuse :-)
> >
> >
> > > 1) I hope we can agree that an Officer of the corporation should be
> > > subject to the direction of the Legal Affairs committee.
> > >
> >
> > Agreed.
> >
> > >...
> >
> > > > My point is to make the document reflect the reality of our
> > organization.
> > >
> > > Reality is what is reflected on this page:
> > > http://incubator.apache.org/ip-clearance/
> > >
> > > Click on any of the clearance documents.
> > >
> > > I don't know what you are smoking, but those documents are real.
> > >
> >
> > Of course. I didn't say "get rid of IP clearance". Please read my
> original
> > email, if you think otherwise. I just want to alter the published steps
> to
> > reflect that our TLPs are not beholden to the IPMC. We use the Incubator
> as
> > a location to record these things (which I find odd, but is a separate
> > discussion).
> >
> > >...
> >
> > Cheers,
> > -g
> >
>

Re: Short form IP clearance

[Greg Stein]

On Wed, Oct 21, 2015 at 8:45 PM, John D. Ament <johndam...@apache.org>
wrote:

> On Wed, Oct 21, 2015 at 9:40 PM Greg Stein <gst...@gmail.com> wrote:
>
> > I believe a PMC is capable of performing IP clearance itself. They have a
> > VP that is an Officer and can take responsibility for the Foundation in
> > matters of that Project. The forms/recording are valid, so I haven't
> > suggested changing that (tho I'd like to see them move under /legal/, I'm
> > not fussed about their location).
> >
> > I would hope that a PMC includes a note in their report to the Board,
> that
> > they filed a clearance form. That is just natural reporting. But that is
> > quite different from one TLP being subject to another TLP's vote (whether
> > lazy consensus or not).
> >
> > There could certainly be an argument that a PMC needs to be
> double-checked
> > by $entity. But that kind of second-guessing means $entity needs to
> > double-check all commits and all release artifacts. We trust PMCs to get
> > their IP done correctly, as they work on their project and make releases.
> >
>
> What you're saying makes a lot of sense.  I've always questioned the
> benefit of TLPs submitting IP Clearances to the incubator, but not
> questioned it because they're so few and far between it's irrelevant.
>

I get a bit crazy-headed when I perceive the ASF encroaches on the
independence of a TLP. This isn't really a case of the ASF imposing, but
similar. In my view, the Incubator cannot impede/affect the independence of
another TLP. Structurally. The Foundation creates each PMC as an
individual, independent group. Thus, I believe a few of these steps are
just incorrect. I'd like our documentation to reflect the reality of the
independence of our TLPs.

I would however pressure that podlings are not capable of completing this
> on their own, and that they should continue to follow the processes defined
> already.  They have knowledgeable mentors, but we should generally note
> that the IPMC as a whole is responsible for the podlings.
>

Absolutely! The referenced page (and the associated guide) explicitly state
it is for existing projects only. (the language could be clarified as "TLP,
not podling", but yeah: definitely not for podlings)

Cheers,
-g

Re: Short form IP clearance

[Greg Stein]

[trimmed response right now; in favor of getting a couple other voices]

On Wed, Oct 21, 2015 at 7:01 PM, Sam Ruby  wrote:
>...

> What is this, randomly propose changes to the incubator month?
>

Has nothing to do with the Incubator, but with how a PMC records its IP
clearance. And more importantly, to clarify that a PMC is not beholden to
the IPMC.


> Let me repeat what I just said.  I don't believe I was being obtuse,
> but then again, you don't appear to have read what I wrote.
>

I certainly read it, you weren't being obtuse :-)


> 1) I hope we can agree that an Officer of the corporation should be
> subject to the direction of the Legal Affairs committee.
>

Agreed.

>...

> > My point is to make the document reflect the reality of our organization.
>
> Reality is what is reflected on this page:
> http://incubator.apache.org/ip-clearance/
>
> Click on any of the clearance documents.
>
> I don't know what you are smoking, but those documents are real.
>

Of course. I didn't say "get rid of IP clearance". Please read my original
email, if you think otherwise. I just want to alter the published steps to
reflect that our TLPs are not beholden to the IPMC. We use the Incubator as
a location to record these things (which I find odd, but is a separate
discussion).

>...

Cheers,
-g

Re: Short form IP clearance

[Greg Stein]

On Wed, Oct 21, 2015 at 3:37 PM, Sam Ruby <ru...@intertwingly.net> wrote:

> On Wed, Oct 21, 2015 at 3:22 PM, Greg Stein <gst...@gmail.com> wrote:
> > Hey all,
> >
> > On the following page:
> >   http://incubator.apache.org/ip-clearance/ip-clearance-template.html
> >
> > The process steps do not align with the intent described in the Preamble,
> > and some steps are not required. Specifically, steps 5, 7, and 8.
> >
> > Step 5: the code will be imported *somewhere*; there is no reason for it
> to
> > be duplicated into the Incubator repository. The ASF simply requires
> > paperwork to acknowledge the propriety of that import, wherever it may
> be.
> > There isn't even a reason for a checksum.
> >
> > Step 7: the Incubator has no prerogative over what the VP of an Apache
> > project does (or other Officers, for that matter). If a TLP wants some
> > code, then they can do so. And the representative of that TLP (the VP, an
> > Officer) is the one taking responsibility for their actions. The
> Incubator
> > has been a recording area, but that doesn't give it discretion over other
> > projects.
> > [ IMO, the recording should go somewhere identified by VP Legal Affairs,
> > and be entirely disconnected from the Incubator ]
>
> Just some historical perspective (from the previous VP Legal Affairs,
> though this predates my having that role), IP clearance is something
> that is rarely done on a PMC level so it is something that most
> individual PMCs don't have much experience with; at a foundation level
> it is done frequently and primarily by the incubator.  Hence the VP of
> Legal Affairs (my predecessor and then unchanged by myself) designated
> that the Incubator have this role.
>
> > Step 8: moot, once (7) is removed.
> >
> > I'd like to modify the steps to reflect the above points.
> >
> > Thoughts?
>
> As far as I can tell, it has been working without issue, where lazy
> consensus is key to making it work smoothly.  So I'm -1 on fixing
> something that isn't broke.
>

It *is* broken. An Officer of the corporation should not be subject to the
will of the IPMC.

Gavin asked me how TLPs can import code, and I noted the IP clearance
process. I looked at it, and found it to be wrong. Whichever TLP he was
referring to should not be posting to general@. They should "file the
paperwork" and call it done.

I will even tell them to ignore those steps. If/when I ever do it with an
Officer hat on, I'll ignore those steps.

My point is to make the document reflect the reality of our organization.

Cheers,
-g

Re: Not just yet (was: [VOTE] Graduate Apache Brooklyn from incubator)

[Greg Stein]

Several things: the description of the project in para 1 and 3 do not
match. Second, the wording of the (current) last paragraph doesn't refer to
"podling" like other Incubator graduation resolutions. Third, the final
paragraph from the template, releasing the Incubator from responsibility.

See the Calcite resolution in this month's agenda.

Regarding 4 weeks: a new agenda should be posted within a 1-2 weeks, and
the revised resolution can immediately be placed there. The Board will vote
on it during its Nov 18 meeting. (technically, if you can finagle all 9
Directors to +1 the resolution before then, it passes on that 9th vote)

Cheers,
-g

On Wed, Oct 21, 2015 at 9:43 PM, John D. Ament 
wrote:

> Any reason you need 4 weeks to add the paragraph back?
> On Oct 21, 2015 21:09, "Hadrian Zbarcea"  wrote:
>
> > The resolution to graduate Apache Brooklyn out of the incubator was
> tabled
> > due to a procedural issue. This has nothing to do with the code or the
> > community.
> >
> > The reason was an editorial error on my side, I used the wrong template
> > and the last paragraph releasing the incubator from its responsibilities
> > was missing from the resolution. It is unfortunate that nobody caught
> that,
> > but the error is completely mine.
> >
> > We will resubmit in 4 weeks.
> >
> > Million apologies,
> > Hadrian
> >
> > On 10/01/2015 11:06 AM, Hadrian Zbarcea wrote:
> >
> >> Vote passes with:
> >>
> >> +1 - 6 binding (ke4qqq, jbonofre, jzb, johndament, olamy, hadrian)
> >> +1 - 2 non-binding
> >> -1 - 0
> >>
> >> We will submit the proposal below to the board for approval (including
> >> jbonofre and olamy in the PMC).
> >>
> >> Many thanks again to our mentors and the incubator in general for the
> >> guidance.
> >>
> >> Hadrian
> >>
> >>
> >> On 09/28/2015 10:06 AM, Hadrian Zbarcea wrote:
> >>
> >>> This is the Incubator vote to decide if Apache Brooklyn should graduate
> >>> from the Incubator. Please see the proposed resolution below.
> >>>
> >>> See also discuss thread [1]. Mentors were invited to join the future
> TLP
> >>> PMC on request. Invitation is open until this vote is closed.
> >>>
> >>> This vote is open for at least 72 hours.
> >>>
> >>> [ ] +1 Graduate Apache Brooklyn from the Incubator.
> >>> [ ] +0 Don't care.
> >>> [ ] -1 Don't graduate Apache Brooklyn from the Incubator because ...
> >>>
> >>> Thanks,
> >>> Hadrian
> >>>
> >>> [1]
> >>>
> >>>
> http://mail-archives.apache.org/mod_mbox/incubator-general/201509.mbox/%3C5604323C.1010207%40gmail.com%3E
> >>>
> >>>
> >>>
> >>>
> >>> 
> >>> X. Establish the Apache Brooklyn Project
> >>>
> >>>  WHEREAS, the Board of Directors deems it to be in the best
> >>>  interests of the Foundation and consistent with the
> >>>  Foundation's purpose to establish a Project Management
> >>>  Committee charged with the creation and maintenance of
> >>>  open-source software, for distribution at no charge to the
> >>>  public, related to tools that help automate various
> >>>  administrative tasks or information lookup activities.
> >>>
> >>>  NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> >>>  Committee (PMC), to be known as the "Apache Brooklyn Project",
> >>>  be and hereby is established pursuant to Bylaws of the
> >>>  Foundation; and be it further
> >>>
> >>>  RESOLVED, that the Apache Brooklyn Project be and hereby is
> >>>  responsible for the creation and maintenance of a software
> >>>  framework for modeling, monitoring, and managing cloud
> >>>  applications through autonomic blueprints; and be it further
> >>>
> >>>  RESOLVED, that the office of "Vice President, Apache Brooklyn"
> >>>  be and hereby is created, the person holding such office to
> >>>  serve at the direction of the Board of Directors as the chair
> >>>  of the Apache Brooklyn Project, and to have primary
> >>>  responsibility for management of the projects within the scope
> >>>  of responsibility of the Apache Brooklyn Project; and be it
> >>>  further
> >>>
> >>>  RESOLVED, that the persons listed immediately below be and
> >>>  hereby are appointed to serve as the initial members of the
> >>>  Apache Brooklyn Project Management Committee:
> >>>
> >>>  * Aled Sage 
> >>>  * Alex Heneveld 
> >>>  * Andrea Turli 
> >>>  * Andrew Kennedy 
> >>>  * Ciprian Ciubotariu 
> >>>  * Hadrian Zbarcea 
> >>>  * Richard Downer 
> >>>  * Sam Corbett 
> >>>  * Svetoslav Neykov 
> >>>
> >>>  NOW, THEREFORE, BE IT FURTHER RESOLVED, that 

Re: [DISCUSS] Eagle incubator proposal

[Greg Stein]

Hey there, Arun! ... I have no commentary on the proposal itself, as it
looks like a great proposal. I would suggest being a bit wary of the name,
as "Eagle" is a *very* popular PCB design program.

On Mon, Oct 19, 2015 at 10:33 AM, Manoharan, Arun 
wrote:

> Hello Everyone,
>
> My name is Arun Manoharan. Currently a product manager in the Analytics
> platform team at eBay Inc.
>
> I would like to start a discussion on Eagle and its joining the ASF as an
> incubation project.
>
> Eagle is a Monitoring solution for Hadoop to instantly identify access to
> sensitive data, recognize attacks, malicious activities and take actions in
> real time. Eagle supports a wide variety of policies on HDFS data and Hive.
> Eagle also provides machine learning models for detecting anomalous user
> behavior in Hadoop.
>
> The proposal is available on the wiki here:
> https://wiki.apache.org/incubator/EagleProposal
>
> The text of the proposal is also available at the end of this email.
>
> Thanks for your time and help.
>
> Thanks,
> Arun
>
> 
>
> Eagle
>
> Abstract
> Eagle is an Open Source Monitoring solution for Hadoop to instantly
> identify access to sensitive data, recognize attacks, malicious activities
> in hadoop and take actions.
>
> Proposal
> Eagle audits access to HDFS files, Hive and HBase tables in real time,
> enforces policies defined on sensitive data access and alerts or blocks
> user’s access to that sensitive data in real time. Eagle also creates user
> profiles based on the typical access behaviour for HDFS and Hive and sends
> alerts when anomalous behaviour is detected. Eagle can also import
> sensitive data information classified by external classification engines to
> help define its policies.
>
> Overview of Eagle
> Eagle has 3 main parts.
> 1.Data collection and storage - Eagle collects data from various hadoop
> logs in real time using Kafka/Yarn API and uses HDFS and HBase for storage.
> 2.Data processing and policy engine - Eagle allows users to create
> policies based on various metadata properties on HDFS, Hive and HBase data.
> 3.Eagle services - Eagle services include policy manager, query service
> and the visualization component. Eagle provides intuitive user interface to
> administer Eagle and an alert dashboard to respond to real time alerts.
>
> Data Collection and Storage:
> Eagle provides programming API for extending Eagle to integrate any data
> source into Eagle policy evaluation framework. For example, Eagle hdfs
> audit monitoring collects data from Kafka which is populated from namenode
> log4j appender or from logstash agent. Eagle hive monitoring collects hive
> query logs from running job through YARN API, which is designed to be
> scalable and fault-tolerant. Eagle uses HBase as storage for storing
> metadata and metrics data, and also supports relational database through
> configuration change.
>
> Data Processing and Policy Engine:
> Processing Engine: Eagle provides stream processing API which is an
> abstraction of Apache Storm. It can also be extended to other streaming
> engines. This abstraction allows developers to assemble data
> transformation, filtering, external data join etc. without physically bound
> to a specific streaming platform. Eagle streaming API allows developers to
> easily integrate business logic with Eagle policy engine and internally
> Eagle framework compiles business logic execution DAG into program
> primitives of underlying stream infrastructure e.g. Apache Storm. For
> example, Eagle HDFS monitoring transforms audit log from Namenode to object
> and joins sensitivity metadata, security zone metadata which are generated
> from external programs or configured by user. Eagle hive monitoring filters
> running jobs to get hive query string and parses query string into object
> and then joins sensitivity metadata.
> Alerting Framework: Eagle Alert Framework includes stream metadata API,
> scalable policy engine framework, extensible policy engine framework.
> Stream metadata API allows developers to declare event schema including
> what attributes constitute an event, what is the type for each attribute,
> and how to dynamically resolve attribute value in runtime when user
> configures policy. Scalable policy engine framework allows policies to be
> executed on different physical nodes in parallel. It is also used to define
> your own policy partitioner class. Policy engine framework together with
> streaming partitioning capability provided by all streaming platforms will
> make sure policies and events can be evaluated in a fully distributed way.
> Extensible policy engine framework allows developer to plugin a new policy
> engine with a few lines of codes. WSO2 Siddhi CEP engine is the policy
> engine which Eagle supports as first-class citizen.
> Machine Learning module: Eagle provides capabilities to define user
> activity patterns or user profiles for Hadoop users based on the user
> behaviour in the platform. These 

Re: [RESULT] [VOTE] Accept Mynewt into the Apache Incubator

[Greg Stein]

Yeah, they just didn't note that in their votes, so Sterling didn't count
them that way. *shrug* ... so it passes yet again :-)

On Tue, Oct 20, 2015 at 11:55 AM, Pierre Smits <pierre.sm...@gmail.com>
wrote:

> Sterling,
>
> As far as I can tell, both Bertrand Délacretaz and and Jim Jagielski are
> IPMC Members and as such their votes should be counted as binding.
>
> Best regards,
>
> Pierre Smits
>
> *OFBiz Extensions Marketplace*
> http://oem.ofbizci.net/oci-2/
>
> On Mon, Oct 19, 2015 at 7:10 PM, Sterling Hughes <sterl...@apache.org>
> wrote:
>
> > On Mon, Oct 12, 2015 at 9:04 AM, Sterling Hughes <sterl...@apache.org>
> > wrote:
> > > Hi All,
> > >
> > > As mentioned in the DISCUSS thread, all feedback has been positive on
> > > the Mynewt proposal, so I'd like to call a VOTE to accept Mynewt as a
> > > new ASF incubator project.
> > >
> > > The full text of the proposal is available on the incubator wiki at
> > > the following URL:
> > >
> > > https://wiki.apache.org/incubator/MynewtProposal?action=recall=20
> > >
> > > I have also included the full text below.
> > >
> > > Vote is open until Thurs, 16th October 2015, 23:59:00 PST.
> > >
> > > [   ] +1 to accept Mynewt into the Apache Incubator
> > > [   ] +0
> > > [   ] -1 because...
> > >
> >
> >
> > This vote is now closed and passes with 4 binding +1 votes,
> > 3 non-binding +1 votes and no 0 or -1 votes.
> >
> > Thanks to all who helped with the proposal and cast the vote!
> >
> > Here's a vote tally:
> >
> > Non-binding +1s:
> >   Jim Jagielski
> >   Marvin Humphrey
> >   Bertrand Delacretaz
> >
> > Binding +1s:
> >   P. Taylor Goetz
> >   Justin Mclean
> >   Greg Stein
> >   Jean Baptiste Onofré
> >
> > No 0 or -1 votes.
> >
> > Thanks,
> > Sterling
> >
> > PS: I didn't realize that I could also vote on the proposal until too
> > late, but for the record, I'm also a +1 :-)
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: Starting from the other end

[Greg Stein]

On Mon, Oct 19, 2015 at 5:38 PM, Roman Shaposhnik 
wrote:
>...

> Perhaps defining exact criteria that the board uses to evaluate such
> resolutions would be useful.
>

The Board evaluates them differently based on the path. I explained Direct
else-thread.

Historically, the Board has trusted the Incubator to only provide
resolutions for TLPs when the code/community is ready. A number of people
are claiming that trust is currently misplaced, which has spun up these
discussions over the past couple weeks. The two primary paths to
improve/demonstrate that trust (that I'm seeing) is to improve the
Incubation process(es), and to provide the Board with additional
information about the state of the community.

(if there are other paths people are looking at, then I've missed them)

Cheers,
-g

Re: Starting from the other end

[Greg Stein]

On Mon, Oct 19, 2015 at 6:25 PM, Roman Shaposhnik 
wrote:
>...

> Huge +1 to the above. Very well said and is exactly how I now start
> thing about the problem myself: Incubator is what's needed when
> there are gaps in straight to TLP. Lets identify what those gaps
>

There is one thing the Incubator cannot solve: ASF Members on the
direct-to-TLP PMC. That has been the primary metric the Board used for
those Resolutions (Zest and Serf). There are a few other direct-to-TLP
occurrences which was only about moving code/communities around within the
Foundation (STeVe, Whimsy, ORC, etc, lately, and when we blew up umbrellas
(eg. Jakarta, XML, Hadoop)).

So... I would not look at the Incubator as "get the podling community to
look like a candidate for direct-to-TLP", as it really can't do that.

The ultimate question, I believe, is: "does the code/community operate
according to Foundation principles?"

>...

Cheers,
-g

Re: Starting from the other end

[Greg Stein]

On Mon, Oct 19, 2015 at 11:22 PM, Marvin Humphrey 
wrote:
>...

> The Maturity Model defines evaluation criteria.  It is probably the most
> useful for the task we're focused on now, which is how to decide when a
> proposed TLP is ready, regardless of the path it took towards readiness.
>

As I've mentioned else-thread, that criteria has had no impact on the
Board's evaluation of incoming direct-to-TLP projects. Instead, the Board
took faith that *while a TLP* the community would reform itself to the
desired goal. There was no requirement for the TLP to be fully compatible
on Day One, but simply that the TLP knew *what* was needed, and *how* to
reach that goal.

I don't know about Apache Zest, but the (now) Apache Serf project always
operated itself very closely to an ASF community. But, as an example, we
did not use KEYS to sign releases. As a responsible TLP, we know the
various gaps, and are making the appropriate changes as we fit ourselves
into the ASF and produce our first ASF-branded release.

This is why I suggest to avoid comparing Incubation projects against
direct-to-TLP. By most measures that I can think of, they are quite
distinct.

Cheers,
-g

ps. it could be argued that a podling can become a TLP once it was
self-aware enough to know how to fix/mend the gaps, much like Serf is
doing. As Sam noted else-thread, this boils down to trust of those in the
PMC. Serf gets it via a 10 ASF Members on Day One; a podling has a very
high bar to reach comparative trust. [from the Board's perspective, IMO]



>
> The incubation checklist is what we use to track a podling's incremental
> progress through the Incubator.  You could see it as an Incubator-specific
> concrete realization of the Maturity Model, though as it is implemented
> today
> it only covers a fraction of the Model's bullet points.
>
> The Project Requirements document encompasses only policy, and thus only
> covers a subset of the curriculum.  However, because the Foundation's
> current
> policy documentation is unbounded, irregular, and bloated, mastering this
> part
> of the curriculum requires disproportionate effort.
>
> I believe that if we can streamline all aspects of the curriculum,
> incubation
> can take far less time and effort than it does today.  And if we can reduce
> the average time-to-incubate, many problems will simply solve themselves.
>
> Marvin Humphrey
>
> [0] The "curriculum" originally referred to the knowledge gained by a
> podling
> release manager while guiding a release candidate through the
> Incubator.
> [1] http://incubator.apache.org/projects/incubation-status-template.html
> [2]
> https://community.apache.org/apache-way/apache-project-maturity-model.html
> [3] http://www.apache.org/dev/project-requirements
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [graduation] Maturity model-based assessment of Groovy for its graduation

[Greg Stein]

I concur, and similarly pushed back just a few days ago on another
suggestion of such "policy".

Not really sure that an ASF-wide metric is appropriate (ie. all communities
are different, and freedom to set their own path is important), but there
is definitely value in some in the model. It can with provide
insight/review, and critical thinking about a community.

Cheers,
-g

On Thu, Oct 15, 2015 at 7:21 AM, Jim Jagielski  wrote:

> If we are to use the maturity model as the guideline regarding podling
> graduation, then certainly the model should be voted on and approved
> by the membership as *the* model for the ASF, right?
>
> Basically, it looks to me that the model is proposing and creating policy,
> and this is something that needs to be done 'correctly', if you get my
> meaning.
>
> > On Oct 15, 2015, at 5:46 AM, Bertrand Delacretaz 
> wrote:
> >
> > Hi Incubator PMC,
> >
> > FYI I have started an experiment at
> > https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc ,
> > using our maturity model to evaluate Groovy before its mentors suggest
> > its graduation (which should happen very soon).
> >
> > So far this has helped uncover a few issues that we (at least I)
> > hadn't noticed otherwise. Nothing major, but interesting, and I think
> > it can be useful for the IPMC and Board once they have to decide to
> > graduate the podling.
> >
> > -Bertrand
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [graduation] Maturity model-based assessment of Groovy for its graduation

[Greg Stein]

On Thu, Oct 15, 2015 at 9:28 AM, Filip Hanik  wrote:

> On Thursday, October 15, 2015, Emmanuel Lécharny 
> wrote:
> > Le 15/10/15 13:17, Rich Bowen a écrit :
>
>...

> > > Who
> > > evaluates the results?
> >
> > Either the board, or a group gathered for that purpose.
>
> the board? doesn't that become a bottleneck.
>

Not at all. "Bottleneck" implies motion that is slower than some desired
value. There's nothing saying "3 days" or "3 years".

But regardless, the Board reviews 70 reports *every* month. Every TLP
reports at least once per quarter. I don't think this would phase the Board
at all :-P ... it has more bandwidth than you'd expect.

Cheers,
-g
(with Director hat on)

Re: Require projects to have solid API docs

[Greg Stein]

On Sun, Oct 11, 2015 at 11:20 PM, Julian Hyde  wrote:

> On Sun, Oct 11, 2015 at 1:11 PM, Alan D. Cabrera 
> wrote:
> > Should != Must
>
> Yes, I know. But I didn't want to have everyone leap into yet another
> long-winded debate with no one even having mentioned that there is
> existing policy on this matter.
>

Euh... no. ComDev does *not* set/create policy for the ASF. The page you
cited is not Foundation policy.

Cheers,
-g

Re: [VOTE] Accept Mynewt into the Apache Incubator

[Greg Stein]

 commercial entities.
>
> == Documentation ==
>
> Documentation is available here: https://github.com/mynewt/documentation
>
> We are actively working on documentation and expect it to improve
> dramatically within the next couple of weeks.
>
> == Initial Source ==
>
> All source code is currently hosted by Runtime, Inc. on Github.
>
> The source code can be found here:
>
> https://github.com/mynewt/
>
> The "tadpole" repository contains the Core of the Operating System and
> file layout. The "larva" repository contains the Core OS and all packages
> developed around that core. The "newt" repository has the build and
> package management tool that is used to stitch together and build new OS
> projects.
>
> == External Dependencies ==
>
> No external dependencies currently exist in the core OS; all code has been
> written by Runtime.
>
> The board and microcontroller-specific support packages contain code from
> the various MCU vendors. This code has been ensured to be under either an
> Apache or BSD license.
>
> == Cryptography ==
>
> None
>
> == Required Resources ==
>
> === Mailing lists ===
>
>  * d...@mynewt.incubator.apache.org
>  * comm...@mynewt.incubator.apache.org
>  * notificati...@mynewt.incubator.apache.org
>
> === Git Directory ===
>
> We'd like to host the source code using Git.
>
> === Issue Tracking ===
>
>  * JIRA Project Mynewt (MYNEWT)
>
> == Initial Committers ==
>
>  * Sterling Hughes (sterling at apache.org)
>  * William San Filippo (will at runtime.io)
>  * Christopher Collins (chris at runtime.io)
>  * Aditi Hilbert (aditi at runtime.io)
>  * Marko Kiiskila (marko at runtime.io)
>  * Justin Mclean (jmclean at apache.org)
>  * Jan Iversen (jani at apache.org)
>
> == Affiliations ==
>
>  * Runtime: Sterling Hughes, William San Filippo, Christopher Collins,
> Aditi Hilbert, Marko Kiiskila.
>  * Class Software: Justin Mclean
>  * Unaffiliated: Jan Iversen
>
> == Sponsors ==
>
> === Champion ===
>
>  * Marvin Humphrey
>
> === Mentors ===
>
>  * Sterling Hughes
>  * Jim Jagielski
>  * Justin Mclean
>  * Greg Stein
>  * P. Taylor Goetz
>
> === Sponsoring Entity ===
>
>  * The Incubator PMC.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: A suggestion: podling post-mortems

[Greg Stein]

Pierre: by "time to graduate", Rich meant "ready to graduate". Not the
amount of time from entry until graduation.

On Mon, Oct 12, 2015 at 10:55 AM, Pierre Smits 
wrote:

> Since when is the incubation process a race that must be completed in the
> least amount of time? If it is, it would surely validate (for some) cutting
> corners and push-through actions (and associated tactics). Is that what the
> ASF wants or needs?
>
> Best regards,
>
> Pierre Smits
>
> *OFBiz Extensions Marketplace*
> http://oem.ofbizci.net/oci-2/
>
> On Mon, Oct 12, 2015 at 5:39 PM, Sam Ruby  wrote:
>
> > On Mon, Oct 12, 2015 at 11:14 AM, Bertrand Delacretaz
> >  wrote:
> > > On Mon, Oct 12, 2015 at 5:10 PM, Rich Bowen 
> wrote:
> > >> ...It would be very welcome to have this attached to a
> > graduation
> > >> resolution, so that we could have some background beyond just a
> > boilerplate
> > >> "time to graduate" message
> > >
> > > I agree, and IMO our maturity model [1] would provide a good framework
> > > for such a report.
> >
> > +1 to both of the above.
> >
> > > -Bertrand
> > >
> > > [1]
> >
> https://community.apache.org/apache-way/apache-project-maturity-model.html
> >
> > - Sam Ruby
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: Concerted Proposal

[Greg Stein]

Always!

On Mon, Oct 5, 2015 at 2:05 PM, Atri Sharma  wrote:

> If Incubator PMC sees fit, can I move this  thread to a discuss thread to
> discuss accepting of Concerted into ASF Incubator?
> On 5 Oct 2015 14:24,  wrote:
>
> > As a member of Concerted community, I believe that acceptance into ASF
> > Incubator is beneficial for Concerted especially in terms of community
> > support. Being an independent project on github really does not help when
> > we want to build a healthy community of people interested in Concerted
> and
> > aiming to take Concerted to ultimate goal we have i.e. being the primary
> in
> > memory support framework for big data engines. I really feel that
> > bootstrapping the existing code base and community into ASF will generate
> > much more interest, visibility and allow the community to be regulated
> in a
> > much better manner.
> >
> > Also, I agree with Atri on the fact that since our eventual goal is to be
> > supporting existing big data projects, working with them early on is a
> > great way to improve our roadmap and get contributions from those
> projects.
> >
> > As a person who has been revamping Concerted code base for a while now, I
> > believe that the existing code base is a great place to pick up the main
> > development of Concerted.
> >
> > Nupur
> >
> > On 05/10/2015 02:09 PM, Atri Sharma wrote:
> >
> >> While I do not disagree with the fact that the code base can evolve at
> >> github, the situation here is a bit different. Preliminary though it is,
> >> Concerted does have an existing code base. The bigger question is having
> >> the code base evolve at a higher frequency with a wider community.
> >>
> >> I think that if Concerted becomes a part of ASF Incubator, it has a much
> >> higher chance of evolving into a wider product with a much better
> >> alignment
> >> with the existing Apache big data ecosystem. Concerted provides the
> >> ability
> >> to DIY big data in memory support engines, with a high degree of custom
> >> building for each user project.
> >>
> >> The reason why Concerted is proposed to become part of ASF Incubator is
> >> that Concerted is a small project right now, with a roadmap and a set of
> >> developers. Getting into ASF allows the Concerted project to have much
> >> better visibility with existing big data projects, which will then allow
> >> Concerted to be developed with more goals in mind. Please note that
> >> eventual goal of Concerted is to be supporting existing big data engines
> >> with on demand custom in memory support. Since the primary target is
> >> Apache
> >> big data space, I think it makes sense to be bootstrapping into ASF
> early
> >> on.
> >>
> >> Second, ASF will allow Concerted to have better community support and
> >> management. As mentioned earlier, visibility and integration with other
> >> ASF
> >> projects will allow those projects to contribute to Concerted if they
> want
> >> to mold it. Also, being a part of ASF anyways helps build community and
> >> manage it in a much better manner.
> >>
> >> I think Roman put it aptly when he mentioned Apache Drill. I think
> Apache
> >> Drill came to ASF Incubator with a goal and a community, and Concerted
> >> comes with the same goal. We already have a small community of active
> >> people, and who are excited at prospect of joining the Incubator.
> >>
> >> Please also note that Concerted does not aim to become a large project
> >> like
> >> Apache Spark (although that might change with time). Community current
> >> aims
> >> are to become a lightweight in memory support engine building framework,
> >> with a small but well managed community and code base. So, the existing
> >> code base might actually be a great starting point for us to be
> >> bootstrapped into ASF Incubator, build community and build the existing
> >> framework into a much more mature project dedicated at supporting ASF
> big
> >> data projects.
> >>
> >> Thoughts?
> >>
> >> Regards,
> >>
> >> Atri
> >>
> >> On Mon, Oct 5, 2015 at 1:39 PM, Sergio Fernández 
> >> wrote:
> >>
> >> Well, I think what we should ask ourselves is if this is actually the
> role
> >>> of ASF incubation. FMPOV the project will evolve much easier at github,
> >>> and
> >>> once the code base becomes a reality we can help mentoring the project
> in
> >>> the Apache way. But this is just my personal opinion.
> >>>
> >>> On Mon, Oct 5, 2015 at 8:18 AM, Ted Dunning 
> >>> wrote:
> >>>
> >>> It looks like there is plenty of mentor-power left on the project. I
>  don't
>  see why one mentor dropping out from a good and large group is a
>  problem.
> 
>  On Sun, Oct 4, 2015 at 8:08 AM, Roman Shaposhnik 
>  wrote:
> 
>  > Hi!
>  >
>  > as some of you know, Atri and I have been
>  > discussing his Concerted Proposal lately:
>  >

Re: Concerted Proposal

[Greg Stein]

The Board created the Incubator as a mechanism to bring projects into the
ASF.

Whether that could be construed as "provide a space for a project to
bootstrap itself, into a new ASF project"  is arguable.

On Mon, Oct 5, 2015 at 3:09 AM, Sergio Fernández  wrote:

> Well, I think what we should ask ourselves is if this is actually the role
> of ASF incubation. FMPOV the project will evolve much easier at github, and
> once the code base becomes a reality we can help mentoring the project in
> the Apache way. But this is just my personal opinion.
>
> On Mon, Oct 5, 2015 at 8:18 AM, Ted Dunning  wrote:
>
> > It looks like there is plenty of mentor-power left on the project. I
> don't
> > see why one mentor dropping out from a good and large group is a problem.
> >
> > On Sun, Oct 4, 2015 at 8:08 AM, Roman Shaposhnik  wrote:
> >
> > > Hi!
> > >
> > > as some of you know, Atri and I have been
> > > discussing his Concerted Proposal lately:
> > >https://wiki.apache.org/incubator/ConcertedProposal
> > >
> > > At this point I can no longer offer my mentorship
> > > services (I ended up quite overloaded as it is)
> > > and I feel it is only fair to Atri if I ask for help here.
> > >
> > > Consider this thread a pre-DICUSS. Concerted isn't
> > > what most of the Incubator proposals are these days.
> > > It is much more about promise of technology rather
> > > than something that exists today. In this it reminds
> > > me of Drill a great deal when it just got proposed -- mostly
> > > and idea. Not much of an existing code base or product.
> > >
> > > So I guess what I'm asking is an IPMC opinion on
> > > how to proceed with this given the mentor situation
> > > and the state of technology.
> > >
> > > Please help by chiming in.
> > >
> > > Thanks,
> > > Roman.
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> > >
> >
>
>
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 6602747925
> e: sergio.fernan...@redlink.co
> w: http://redlink.co
>

Re: Permissive UI Libraries

[Greg Stein]

Ask the Apache Tcl project :-)
On Sep 9, 2015 4:30 PM, "Jochen Theodorou" <blackd...@gmx.org> wrote:

> Tk is a bit difficult to make not look like motif. It can be made look
> modern, no question, but it takes effort. And the lack of interest in the
> recent years made it a bit outdated with regards to accessibility and i18n.
> No question, you can fix all those. But is that a good base for an apache
> project with a few developer cycles?
>
> Am 08.09.2015 18:11, schrieb Dennis E. Hamilton:
>
>> And let us not forget Tk, <https://en.wikipedia.org/wiki/Tk_(software)>.
>>
>>   - [;<).
>>
>> -Original Message-
>> From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org]
>> Sent: Tuesday, September 8, 2015 08:12
>> To: general@incubator.apache.org
>> Subject: Permissive UI Libraries (was RE: [NOTICE] corinthia ...)
>>
>> [ ... ]
>>
>> -Original Message-
>> From: Greg Stein [mailto:gst...@gmail.com]
>> Sent: Monday, September 7, 2015 02:38
>> To: general@incubator.apache.org
>> Subject: Re: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg,
>> ianc, jani, louis, pmkelly
>>
>> [ ... ]
>> Given the UI landscape, and its licensing, I can see why Corinthia would
>> like to host elsewhere. One day, we'll see some permissive UI
>> libraries
>>
>> Cheers,
>> -g
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>
> --
> Jochen "blackdrag" Theodorou
> blog: http://blackdragsview.blogspot.com/
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, jani, louis, pmkelly

[Greg Stein]

On Sep 7, 2015 4:12 PM, "Jochen Theodorou"  wrote:
>...
> I am not sure that approach is realistic. I mean, if you say it must be
optional and not required, then there must be an existing alternative. And
that alternative must be not LGPL. If there is such a toolkit, then why not
go with that right away? The project has to manage its resources well.

Exactly. Without an alternative, then you have a pile of code that doesn't
meet any user expectations.

If it can be released as a library, for downstream users to produce an
editor, then okay. But an releasing an editor with no UI is kind of a
non-starter. :-(

Given the UI landscape, and its licensing, I can see why Corinthia would
like to host elsewhere. One day, we'll see some permissive UI libraries

Cheers,
-g

Re: ODF Toolkit may need help

[Greg Stein]

If the podling *has* cleared all IP, then I could see allowing it. But we
certainly don't want improper IP residing in the Attic. These aren't Apache
projects until graduation, so don't really belong. I can see releases
strengthening the argument for archival.

Henri should be able to clarify.

Cheers,
-g
On Sep 5, 2015 3:35 AM, "Dave Fisher" <dave2w...@comcast.net> wrote:

> I recollect seeing a retiring podling with releases go to the attic. If
> that is not correct or it was an exceptional case then thanks for the
> correction.
>
> What would be done with domain names? The podling came in with the domain
> name offtoolkit.org. What happens to that?
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On Sep 3, 2015, at 10:00 PM, Greg Stein <gst...@gmail.com> wrote:
> >
> > The Attic is for Apache projects. Podlings are simply retired/removed.
> >> On Sep 4, 2015 9:23 AM, "Dave Fisher" <dave2w...@comcast.net> wrote:
> >>
> >>
> >>
> >> Sent from my iPhone
> >>
> >>> On Sep 3, 2015, at 5:12 AM, John D. Ament <johndam...@apache.org>
> wrote:
> >>>
> >>> Hi Rob,
> >>>> On Thu, Sep 3, 2015 at 7:56 AM Rob Weir <r...@robweir.com> wrote:
> >>>>
> >>>> On Wed, Sep 2, 2015 at 6:25 AM, John D. Ament <johndam...@apache.org>
> >>>> wrote:
> >>>>> All,
> >>>>>
> >>>>> I'd like to bring to your attention the ODF Toolkit podling.
> >>>>>
> >>>>> This podling has been incubating for over 4 years now.  Last month
> they
> >>>>> filed a report without mentor sign off, without any feedback on the
> >>>> mailing
> >>>>> list.  They have remained partially active throughout the 4 years,
> but
> >>>> from
> >>>>> what I can tell suffering a bit in community growth.  I'd like to
> seek
> >>>>> input from the incubator on how to potentially resolve this and maybe
> >> get
> >>>>> help for this podling.
> >>>>>
> >>>>> John
> >>>>
> >>>>
> >>>> I am the mentor who did not sign off last month.  You may have noticed
> >>>> that the podling has been filing nearly identical reports for some
> >>>> time now.   I'd sum up accomplishments to date as:
> >>>>
> >>>> 1) We've done a few podling releases.
> >>>>
> >>>> 2) IP review is in good shape
> >>>>
> >>>> 3) Community gets along well, no significant frictions
> >>>>
> >>>> 4) Community has added new committers outside the original PPMC, but
> >>>> has also lost its original corporate-sponsored developers.
> >>>>
> >>>> 5) The code is being used, as seen by incoming traffic on users list
> >>>> and occasional patch submissions
> >>>
> >>> I have noticed that.  Has the podling been made aware that the report
> >>> shouldn't be a copy and paste, and that stagnating growth is probably
> >> not a
> >>> good sign?  It would help to explain why their report wasn't signed off
> >> on.
> >>>
> >>>
> >>>
> >>>
> >>>>
> >>>> These are all good steps towards graduation.  However, the community
> >>>> thinks, and I tend to agree, that the activity level is too low to
> >>>> sustain a TLP.   If we were able to attract another 2 or 3 active
> >>>> developers we would be in great shape.  As mentor I've given advice
> >>>> when asked, and when I thought needed.  But I'm not standing there
> >>>> with a whip and a megaphone telling them what to do.   I don't think
> >>>> that makes a sustainable community.
> >>>>
> >>>> I don't think shuffling the code around within Apache, to another
> >>>> project (or Podling) really solves anything.  The Attic is one option,
> >>>> but my guess is that would end the podling but not the (albeit small)
> >>>> community.  They would probably just set up on github and continue
> >>>> with the same pace of activity, with a lighterweight process, outside
> >>>> of Apache.  So, personally, I don't think the Attic would be the death
> >>>> of the ODF Toolkit.
> >>>
> >>> The attic should be considered only as a last stitch effort, all other
> >>> attempts at resolving the podling have been tried and failed.
> >>
> >> Nothing stops anyone from forking the podling to another location. The
> >> incubator would need to do something with the code. That would be to
> put it
> >> in the attic as an archive, as not maintained any longer.
> >>
> >> This is decision for the community such as it is to make.
> >>
> >> Regards,
> >> Dave
> >>
> >>
> >>>
> >>>
> >>>>
> >>>> Regards,
> >>>>
> >>>> -Rob
> >>>>
> >>>> -
> >>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >>>> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: ODF Toolkit may need help

[Greg Stein]

The Attic is for Apache projects. Podlings are simply retired/removed.
On Sep 4, 2015 9:23 AM, "Dave Fisher"  wrote:

>
>
> Sent from my iPhone
>
> > On Sep 3, 2015, at 5:12 AM, John D. Ament  wrote:
> >
> > Hi Rob,
> >> On Thu, Sep 3, 2015 at 7:56 AM Rob Weir  wrote:
> >>
> >> On Wed, Sep 2, 2015 at 6:25 AM, John D. Ament 
> >> wrote:
> >>> All,
> >>>
> >>> I'd like to bring to your attention the ODF Toolkit podling.
> >>>
> >>> This podling has been incubating for over 4 years now.  Last month they
> >>> filed a report without mentor sign off, without any feedback on the
> >> mailing
> >>> list.  They have remained partially active throughout the 4 years, but
> >> from
> >>> what I can tell suffering a bit in community growth.  I'd like to seek
> >>> input from the incubator on how to potentially resolve this and maybe
> get
> >>> help for this podling.
> >>>
> >>> John
> >>
> >>
> >> I am the mentor who did not sign off last month.  You may have noticed
> >> that the podling has been filing nearly identical reports for some
> >> time now.   I'd sum up accomplishments to date as:
> >>
> >> 1) We've done a few podling releases.
> >>
> >> 2) IP review is in good shape
> >>
> >> 3) Community gets along well, no significant frictions
> >>
> >> 4) Community has added new committers outside the original PPMC, but
> >> has also lost its original corporate-sponsored developers.
> >>
> >> 5) The code is being used, as seen by incoming traffic on users list
> >> and occasional patch submissions
> >
> > I have noticed that.  Has the podling been made aware that the report
> > shouldn't be a copy and paste, and that stagnating growth is probably
> not a
> > good sign?  It would help to explain why their report wasn't signed off
> on.
> >
> >
> >
> >
> >>
> >> These are all good steps towards graduation.  However, the community
> >> thinks, and I tend to agree, that the activity level is too low to
> >> sustain a TLP.   If we were able to attract another 2 or 3 active
> >> developers we would be in great shape.  As mentor I've given advice
> >> when asked, and when I thought needed.  But I'm not standing there
> >> with a whip and a megaphone telling them what to do.   I don't think
> >> that makes a sustainable community.
> >>
> >> I don't think shuffling the code around within Apache, to another
> >> project (or Podling) really solves anything.  The Attic is one option,
> >> but my guess is that would end the podling but not the (albeit small)
> >> community.  They would probably just set up on github and continue
> >> with the same pace of activity, with a lighterweight process, outside
> >> of Apache.  So, personally, I don't think the Attic would be the death
> >> of the ODF Toolkit.
> >
> > The attic should be considered only as a last stitch effort, all other
> > attempts at resolving the podling have been tried and failed.
>
> Nothing stops anyone from forking the podling to another location. The
> incubator would need to do something with the code. That would be to put it
> in the attic as an archive, as not maintained any longer.
>
> This is decision for the community such as it is to make.
>
> Regards,
> Dave
>
>
> >
> >
> >>
> >> Regards,
> >>
> >> -Rob
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: What is the legal basis for enforcing release policies at ASF?

[Greg Stein]

On Thu, Aug 20, 2015 at 9:37 PM, Ross Gardler ross.gard...@microsoft.com
wrote:
...

 So, in the strictest sense, distributions that make minor changes for
 their distribution should call it Bar powered by Apache Foo in order to
 differentiate it from an official release of the foundation. In the real
 world the question is, from a legal point of view, do we care?


This is why Debian has Iceweasel instead of Firefox.

...

Cheers,
-g

Re: third party tooling.

[Greg Stein]

On Thu, Aug 6, 2015 at 2:25 AM, Bertrand Delacretaz bdelacre...@apache.org
wrote:

 On Thu, Aug 6, 2015 at 1:57 AM, Roman Shaposhnik ro...@shaposhnik.org
 wrote:
  ...you can call yourself open source software all you want,
  but unless you get an exception from Fedora Packaging Committee
  you are not open enough for the distribution to consider your work...

 But that's doesn't make your project invalid or useless.


Right.

I don't know where you're coming from Roman, but the Foundation doesn't
require our projects to be built via bootsrappable [sic] from source using
*only* open source software binaries as the input. Never has, never will.
So to Jan's original question: totally fine, no issues with compiler
dependencies for certain platforms.

Our software is defined by ALv2 and the Category licenses for
dependencies.

We are Open Source by the OSI definition, and any reasonable person's
definition. If Fedora believes otherwise, then they better pony up a reason
why. I can't believe they think ASF software is not Open Source, so I don't
know where you're going with that.

-g

Re: [DISCUSSION] Graduate Ignite from the Apache Incubator

[Greg Stein]

On Jul 29, 2015 11:37 AM, Branko Čibej br...@apache.org wrote:

 On 29.07.2015 18:14, Joe Brockmeier wrote:
  On Thu, Jul 23, 2015, at 03:19 AM, Branko Čibej wrote:
  Personally I'm not too happy with how this community tracks issues, but
  hey, if it works for them, why fix it? It'll be a fine day when the
IPMC
  starts telling podlings how their development workflow should look
like.
  Does works for them translate into people not currently in the
  community can follow how the existing community tracks issues, so they
  can contribute and become part of the community? If so, then maybe it's
  OK. If it's not transparent to folks not currently part of that
  community, it's hard to see how the community will sustain itself with
  new members as other folks inevitably move on to other projects.

 Given that new contributors keep showing up on a regular basis, I have
 to assume that it's not so opaque as all that.

 Anyway, Ignite has been discussing and implementing a revised (and IMO
 better) set of policies for Jira use and git workflow since this
 discussion started; other than displaying an incomprehensible preference
 for RTC, it seems to be going well.

I always translate RTC as we don't trust you, so somebody else must
approve anything you do.

To me, that is a lousy basis for creating a community. Trust and peer
respect should be the basis, which implies CTR. I have seen many excuses
for RTC, but they all are just window dressing over mistrust.

-g

Re: [DISCUSSION] Graduate Ignite from the Apache Incubator

[Greg Stein]

On Jul 29, 2015 12:45 PM, Konstantin Boudnik c...@apache.org wrote:

 On Wed, Jul 29, 2015 at 12:25PM, Greg Stein wrote:
  On Jul 29, 2015 11:37 AM, Branko Čibej br...@apache.org wrote:
  
   On 29.07.2015 18:14, Joe Brockmeier wrote:
On Thu, Jul 23, 2015, at 03:19 AM, Branko Čibej wrote:
Personally I'm not too happy with how this community tracks
issues, but
hey, if it works for them, why fix it? It'll be a fine day when the
  IPMC
starts telling podlings how their development workflow should look
  like.
Does works for them translate into people not currently in the
community can follow how the existing community tracks issues, so
they
can contribute and become part of the community? If so, then maybe
it's
OK. If it's not transparent to folks not currently part of that
community, it's hard to see how the community will sustain itself
with
new members as other folks inevitably move on to other projects.
  
   Given that new contributors keep showing up on a regular basis, I have
   to assume that it's not so opaque as all that.
  
   Anyway, Ignite has been discussing and implementing a revised (and IMO
   better) set of policies for Jira use and git workflow since this
   discussion started; other than displaying an incomprehensible
preference
   for RTC, it seems to be going well.
 
  I always translate RTC as we don't trust you, so somebody else must
  approve anything you do.
 
  To me, that is a lousy basis for creating a community. Trust and peer
  respect should be the basis, which implies CTR. I have seen many excuses
  for RTC, but they all are just window dressing over mistrust.

 While I tend to agree with you, it worth noting that there's a whole
bunch of
 TLPs sticking to RTC.  So, this data point doesn't reflect on the podling
in
 question.

And POW!! There is one excuse on display already :-P

But others do it.

-g

Re: [ANNOUNCE] Aapche Lens 2.2.0-beta-incubating released

[Greg Stein]

Hello, Lens people!

In the future, please ensure that *all* release announcements include the
Incubating Disclaimer in them. Your download page should be updated
(asap) to include the same.

Thanks,
-g


On Thu, Jul 16, 2015 at 11:53 PM, Amareshwari Sriramdasu 
amareshw...@apache.org wrote:

 Hi all,

 The Apache Lens team is proud to announce the release of Apache Lens
 2.2.0-beta-incutaing.

 Apache Lens provides an Unified Analytics interface. Lens aims to cut the
 Data Analytics silos by providing a single view of data across multiple
 tiered data stores and optimal execution environment for the analytical
 query. It seamlessly integrates Hadoop with traditional data warehouses to
 appear like one.

 This release includes OLAP features like support for multiple expressions
 and union queries, many CLI Improvements, Descriptive error codes,
 integrates with Zeppelin and many more bug fixes and simple improvements.

 The release artifacts are downloadable from
 http://lens.incubator.apache.org/releases/download.html

 Maven jar artifacts have also been made available on

 https://repository.apache.org/content/repositories/releases/org/apache/lens/

 Release notes available at

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12329586projectId=12315923

 More details on Apache Lens can be found at
 http://lens.incubator.apache.org/

 Getting started available at
 http://lens.incubator.apache.org/lenshome/quick-start.html

 We would like to thank all the contributors who made this release possible.

 Thanks,
 The Apache Lens team

Re: Licensing Issue

[Greg Stein]

hahaha funny that the template at that site says the software is in the
public domain, but then goes on to state what can be done with it, and to
provide a disclaimer. If it is truly in the public domain, then no futher
discussion is needed.

And note that some jurisdictions (eg France) don't allow you to move things
into the public domain. You'll always be the owner.

Nice thought, but it needs some work.

On Sat, Jun 27, 2015 at 1:02 PM, Stefan Reich 
stefan.reich.maker.of@googlemail.com wrote:

 I will personally abolish copyright. Join the future.

 unlicense.org
 Am 27.06.2015 19:09 schrieb Ted Dunning ted.dunn...@gmail.com:

  Stefan,
 
  It is hard to understand what you meant since we don't have a common
 frame
  of reference.
 
  It sounds like you want to share with others.  That is great.
 
  But it also sounds like you want to disregard how the world works with
  respect to copyrights.  That won't work.  As I have just proved in this
  same discussion, it is very common that no matter what you know, there is
  more that you don't know.  Copyrights are complicated and won't go away.
 
  In your case, it sounds like you need to find ways to share that are as
  easy as possible.  That is what Apache licenses are for.
 
 
 
  On Sat, Jun 27, 2015 at 12:28 PM, Stefan Reich 
  stefan.reich.maker.of@googlemail.com wrote:
 
   What do you think I meant?
   Am 26.06.2015 08:51 schrieb Ted Dunning ted.dunn...@gmail.com:
  
Stefan,
   
In order to open source something, you have to define what you mean
  by
open source.  If you mean that anybody can do anything at all with
  the
code including claim it as their own, then you mean to put it into
 the
public
domain https://en.wikipedia.org/wiki/Public_domain.
   
If you mean anything else at all, then you have to specify what you
  mean.
Even if all you want to say is that people have to admit that you
 wrote
   the
code, you have to specify that.
   
The way that you specify what you want is to pick or write a license.
   
   
   
On Thu, Jun 25, 2015 at 1:29 PM, Stefan Reich 
stefan.reich.maker.of@googlemail.com wrote:
   
 Please - can we all stop using licenses and just open source
everything?
 Progress is waiting for us.

 BTW, I am now adding all (!) programming languages to the realm of
  AI.
 (Meaning they can then be programmed automatically.)
  tinybrain.blog.de

 Cheers
 Stefan
 Am 21.06.2015 00:51 schrieb Lewis John Mcgibbney 
 lewis.mcgibb...@gmail.com:

  Hi Folks,
  I am looking for some advice here.
  We are currently in conversation about potentially transitioning
  the
 Joshua
  project [0] to the foundation. Our current conversation is
 ongoing
  at
 [1].
  From one of the key developers of Joshua, the following question
  has
 arose;
  There is an issue with an LGPL'd library for handling language
  models
  (KenLM
  https://github.com/kpu/kenlm). There is an alternative
   (BerkeleyLM),
 but
  it is not actively maintained any more and is not quite as good
 as
KenLM
 in
  a few key respects. A quick glance at the incubator page suggests
   that
 this
  dependency would keep the project from becoming a full-fledged
 one.
   Can
 you
  comment on this?
  Thanks for any input folks
  Lewis
 
  [0] http://joshua-decoder.org/
  [1] https://github.com/joshua-decoder/joshua/issues/204
 
  --
  *Lewis*
 

   
  
 

Re: Blog policy for poddlings

[Greg Stein]

To clarify one step further: podlings are not official projects, so any
outreach via apache.org (and its name/recognition) needs appropriate
messaging. That is why we have press@ :-)

On Fri, May 29, 2015 at 10:36 PM, Ross Gardler (MS OPEN TECH) 
ross.gard...@microsoft.com wrote:

 It's not ComDev is press@

 Sent from my Windows Phone
 
 From: Roman Shaposhnikmailto:ro...@shaposhnik.org
 Sent: ‎5/‎29/‎2015 7:11 PM
 To: general@incubator.apache.orgmailto:general@incubator.apache.org
 Subject: Re: Blog policy for poddlings

 This is all very much confusing ;-) Is there any chance we can arrive
 at a more consistent policy or should I ask over at comdev@ ?

 Thanks,
 Roman.

 On Fri, May 29, 2015 at 11:46 AM, Henry Saputra henry.sapu...@gmail.com
 wrote:
  When Apache MetaModel still in incubator we were asking access to post
  blog at blogs.a.o and was told that it is preferable that podlings
  wait until graduation to post in it.
 
  - Henry
 
  On Fri, May 29, 2015 at 9:17 AM, David Nalley da...@gnsa.us wrote:
  I am unaware of a policy that would prohibit a podling from having a
  blog at blogs.a.o
 
  --David
 
  On Thu, May 28, 2015 at 9:36 PM, Roman Shaposhnik ro...@shaposhnik.org
 wrote:
  Hi!
 
  can someone please remind me what's the policy
  for letting poddlings use blogs.apache.org as a
  blogging platform?
 
  Thanks,
  Roman.
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Whimsy PMC

[Greg Stein]

On Tue, Apr 28, 2015 at 11:57 AM, Roman Shaposhnik ro...@shaposhnik.org
wrote:
...

 In case you're curious -- I'd ask the same question, for example,
 about a community
 that decided to produce software that is be only applicable as an add-on
 for a small market share commercial offering.


The Foundation does not care about a project's market size. If a
*community* wants to be part of the ASF, then they are welcome. The
maturity of their codebase, the size of it, the language, whether 1 person
uses it, or 1 million use it. We are interested in supporting communities,
not cherry-picking successful projects (by whatever definition you may
care to use to define success).

Cheers,
-g

Re: [DISCUSS] Whimsy PMC

[Greg Stein]

On Mon, Apr 27, 2015 at 8:51 PM, Ross Gardler (MS OPEN TECH) 
ross.gard...@microsoft.com wrote:

 It's a tough one. We could be setting a precedence here that we absolutely
 do not want to set. On the other hand, it's problematic (not to mention
 simply ridiculous) if the foundation not being able to use Apache software
 because we don't pay for development and might want to submit a patch
 upstream.

 As long as all committers are equal and earn their merit in the
 traditional way I don't see a problem from the projects side. IN this
 instance the ASF is just another contributor to the project.

 This means the foundation never pays for development to something like
 the foundation never pays for development except where the modification is
 made as part of our normal infrastructure operations. On these rare
 occasions the foundation is just another employer and the contributor is
 just another community member. Changes are contributed upstream through the
 normal contribution process. There is no special role for ASF infra
 contractors.


The ASF pays for Infra contractors. Their job/role is to maintain our
systems. Sometimes their duty *may* be to contribute software to $Project
(wherever that may be).

That is *very* distinct from paying a person to contribute directly to
$ASFProject.

Cheers,
-g

Re: [DISCUSS] Whimsy PMC

[Greg Stein]

On Thu, Apr 23, 2015 at 8:36 PM, Sam Ruby ru...@intertwingly.net wrote:

 On Thu, Apr 23, 2015 at 8:58 PM, Greg Stein gst...@gmail.com wrote:
  I'd suggest striking the user@ mailing list. Keep the community (such
 as it
  is) on dev@ until traffic gets too heavy. I've seen early splitting of
 the
  user/dev keep a new project from reaching a good critical mass.

 FWIW, I copied from Steve.

 Struck.


Yeah :-( ... before sending my email, I realized Steve actually has a user@
mailing list. Bleh. Missed that when we set up, and now I see there have
been a few messages there. Mostly just pending. The community is over/only
on dev@.

Cheers,
-g

Re: [DISCUSS] Whimsy PMC

[Greg Stein]

On Fri, Apr 24, 2015 at 7:47 AM, Shane Curcuru a...@shanecurcuru.org wrote:
...

 our own project operations, which we'll do in any case.  The presumed
 pTLP would be to develop the code; I could easily imagine some of the
 code being useful as examples outside of the ASF.  Being a pTLP would
 also make development easier for newcomers, since code/mailinglists/etc.
 would all be normalized with other projects.


The pTLP concept is on hiatus. We don't have any (lately, Orc and Zest hit
TLP directly), and Whimsy is not suggested to operate under that idea. ...
it would become a standard TLP.

Cheers,
-g

Re: [DISCUSS] Whimsy PMC

[Greg Stein]

I'd suggest striking the user@ mailing list. Keep the community (such as it
is) on dev@ until traffic gets too heavy. I've seen early splitting of the
user/dev keep a new project from reaching a good critical mass.

On Thu, Apr 23, 2015 at 1:46 PM, Sam Ruby ru...@intertwingly.net wrote:

 Initial sketch placed on the wiki:

 https://wiki.apache.org/incubator/WhimsyProposal

 Anyone who is so inclined is welcome to edit the proposal directly.

 No urgency or timeframe in mind (other than preferably starting sometime
 in 2015ish).  My current thinking is to follow in Steve's footprints and go
 directly to TLP, but I'm starting a discussion here (in Incubator) to see
 if there are any other thoughts on the matter.

 - Sam Ruby

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: Soliciting feedback for a detailed pTLP policy document

[Greg Stein]

On Mon, Mar 2, 2015 at 8:56 PM, John D. Ament johndam...@apache.org wrote:

 Roman,

 I don't think much is missing.  One of my concerns with all of these
 proposals, especially for participants like myself, is the difference in
 how the IPMC operates vs how these PMCs must operate.  For someone like me,
 I wouldn't be able to help these pTLP's the way I can on the IPMC.


John: you can help a pTLP just as much as any other podling. Is your point
that you don't have a binding vote? That your help is tied into such a
forceful voice? ... I believe that your wisdom will be helpful, regardless
of whether your vote is binding or not.

From a document's standpoint, I'm concerned with heavy reliance on three
 existing Apache members.  Specifically, if the pTLP gets into a situation
 where only 2 of its 3 members are active, they can't even add an additional
 member.  While having three active participants is crucial (from the tone
 of the document), as soon as one of those three starts failing, they cannot
 ever recover without that 3rd person rejoining.


This is not a concern, and is one of the reasons that myself and others are
championing the pTLP process. The above is not quite correct, and having
ASF Members and direct interaction with the Board will help communities to
understand what/how the Foundation truly operates.

Yes, we require (3) +1 votes for a *release*.

No, that requirement does not apply whatsoever to adding new PMC members,
and certainly not towards new committers (and other aspects of turning
community members into active contributors). The VP can unilaterally add
new PMC members and committers. We don't like to see that, but you're
already proposing a community in crisis; in that case, I *EXPECT* the VP to
act unilaterally to reboot the active participation. And recall: the Board
has the direct oversight and helpful aid for that project. If the VP is the
one to disappear, then the Board will notice and will ask for a
recommendation to replace.

In short, a TLP or pTLP can always recover from stasis. Unlike a podling
subject to another group for its well-being, a (p)TLP has the complete
ability to rebuild itself. The VP of the (p)TLP is an Office and is
directed towards ensuring the success and well-being of the project. That
allows for a *very* wide-ranging set of actions.

This approach seems to favor cases where the pTLP is proposed and managed
 by an existing member.  I can see this approach not helping foster external
 groups from joining the ASF, especially trying to find three members openly
 willing to help foster that community.


As Ross noted elsewhere, this is a new/experimental process for moving
projects into the Foundation. The Incubator shall remain, and can continue
to address your concern for projects without ASF Members to advance the
pTLP style process.

...

Cheers,
-g

Re: pTLP process amendments

[Greg Stein]

On Mon, Mar 2, 2015 at 3:24 AM, Bertrand Delacretaz bdelacre...@apache.org
wrote:

 On Mon, Mar 2, 2015 at 4:33 AM, Ross Gardler (MS OPEN TECH)
 ross.gard...@microsoft.com wrote:
  ...either this pTLP idea is independent of the IPMC. Or it is not

 I think it is actually in between ;-)

 While the pTLP itself, once created by the board, is independent of
 the Incubator PMC, the steps that lead to the board voting on the pTLP
 creation resolution are IMO best handled by the Incubator PMC, as they
 are fairly similar to the creation of a podling.


Please explain why that resolution cannot come from the community itself.

If a community says, we'd like to be a pTLP, then why/how does the
Incubator PMC need to be involved in that?

-g

Re: pTLP process amendments

[Greg Stein]

On Mon, Mar 2, 2015 at 3:44 AM, Bertrand Delacretaz bdelacre...@apache.org
wrote:

 On Mon, Mar 2, 2015 at 10:35 AM, Greg Stein gst...@gmail.com wrote:
  On Mon, Mar 2, 2015 at 3:24 AM, Bertrand Delacretaz 
 bdelacre...@apache.org
  wrote:
  ...the steps that lead to the board voting on the pTLP
  creation resolution are IMO best handled by the Incubator PMC, as they
  are fairly similar to the creation of a podling...
 
  Please explain why that resolution cannot come from the community itself.

 It can, but I'd like it to be at least exposed for public review, in
 the same way as podling proposals are.

 The goals are to make people aware that a new project is about to be
 created, and to provide a space (this list) for public review.

 Other steps that are similar to podling creation are the name checks,
 recruiting mentors, fine tuning the initial project charter, etc. -
 this list is an excellent place to do all this, even though for some
 pTLPs the work might be minimal. The Incubator PMC might not have a
 formal say in pTLP creation, but there's significant work that happens
 before that, collaboratively and in public.


That isn't the IPMC. You're simply talking about discussion on a mailing
list.

-g

Re: pTLP process amendments

[Greg Stein]

On Mon, Mar 2, 2015 at 4:11 AM, Bertrand Delacretaz bdelacre...@apache.org
wrote:

 On Mon, Mar 2, 2015 at 10:49 AM, Greg Stein gst...@gmail.com wrote:
  On Mon, Mar 2, 2015 at 3:44 AM, Bertrand Delacretaz 
 bdelacre...@apache.org
 ...The Incubator PMC might not have a
  formal say in pTLP creation, but there's significant work that happens
  before that, collaboratively and in public.
 
  That isn't the IPMC. You're simply talking about discussion on a mailing
  list

 Not a mailing list, this mailing list. There's no reason for the
 preparation of a pTLP to happen in a different place than where
 podlings are prepared, which is on this list.


Fine. My primary point was: IPMC has *nothing* to do with the discussion.
That happens on a mailing list, and sure: general@i.a.o is just fine.

Maybe one day, it will be new-proje...@apache.org.

But I want to reinforce what Ross noted: pTLP should not be conflated with
Incubator bits. It has no place, and that's why I'm being vocal right now.
You said, the steps that lead to the board voting on the pTLP creation
resolution are IMO best handled by the Incubator PMC, and I believe that
is totally wrong.

Cheers,
-g

Re: pTLP process amendments

[Greg Stein]

On Wed, Feb 25, 2015 at 7:08 AM, Marvin Humphrey mar...@rectangular.com
wrote:

 On Wed, Feb 25, 2015 at 4:35 AM, Niclas Hedhman nic...@hedhman.org
 wrote:
  On Wed, Feb 25, 2015 at 8:27 PM, jan i j...@apache.org wrote:
  The proposal only refer to new projects entering Apache, would it be
 worth
  while to consider a way for projects that entered  Incubator recently
 and
  has enough (whatever that is) asf members as committers ?
 
  That is a discussion for perhaps the Incubator, but more specifically the
  podlings that you might be referring to.

 I don't see why the Incubator wouldn't just let them go.


Haha well, the reality is that the Incubator wouldn't have a choice. If
the Board passes a pTLP resolution, then there isn't much the IPMC could do
about it :-P

Now, I'm not suggesting the Board would be eager to just rip podlings out
of the Incubator with *some* modicum of discussion with the IPMC. I'm just
pedantically pointing out the reality of the situation... hehe...

Cheers,
-g

Re: Practical next steps for pTLP experiment

[Greg Stein]

if we accept ... take a position, Ross.

The two problems *are* orthogonal. The IPMC can do whatever it likes. A
pTLP is a proposal to the Board.

Bertrand would like to see discussion on general@incubator, but that is
merely a handy location. It actually has zero to do with the Incubator.

Ross: if you believe that a pTLP is somehow tied to the Incubator, then
state that. Otherwise, please STOP throwing uncertainty into the waters.

-g


On Mon, Feb 23, 2015 at 7:29 PM, Ross Gardler (MS OPEN TECH) 
ross.gard...@microsoft.com wrote:

 Fair enough. I don't think I ever agreed they are orthogonal. In fact the
 only concern I have consistently stated, and is reflected on the summary
 below, is that it, potentially, moves the problem rather than solves it.

 That being said, if we accept its orthogonal then your point is a good one.

 Sent from my Windows Phone
 
 From: Roman Shaposhnikmailto:ro...@shaposhnik.org
 Sent: 2/23/2015 4:49 PM
 To: general@incubator.apache.orgmailto:general@incubator.apache.org
 Subject: Re: Practical next steps for pTLP experiment

 On Mon, Feb 23, 2015 at 4:11 PM, Ross Gardler (MS OPEN TECH)
 ross.gard...@microsoft.com wrote:
  It's not unfair. I deliberately tried to say i don't want to distract
 from the handover process.

 I though we all agreed that whatever pTLP is -- it is absolutely 100%
 orthogonal to
 the process that Incubator is in business of managing. There will be
 some overlap
 of people involved in both, but we don't need to wait on Incubator to
 proceed with
 pTLP any more than we'd need to wait on Incubator to do something in
 Hadoop land
 (although quite a few Hadoop folks are on IPMC).

  I don't think its productive to make someone's support or otherwise of
 an experiment
  to distract from getting the right chair to replace you.

 That would be a fair point if we didn't try as hard as we can to
 decouple the two.

 If what you're saying is: currently there's no way for Incubator NOT
 to be involved
 in pTLP AND if that's the opinion shared by the majority on the board,
 I'd have to
 re-evaluate things on my end.

 I thought Greg convinced you all that it must be de-coupled. That's what I
 based
 my calculations on.

 Thanks,
 Roman.

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: Practical next steps for pTLP experiment

[Greg Stein]

On Mon, Feb 23, 2015 at 6:31 PM, Mattmann, Chris A (3980) 
chris.a.mattm...@jpl.nasa.gov wrote:

 Hi Niclas,

 I'm in favor of the overall pTLP process. I don't
 agree with others that it hasn't been well specified yet. I


There is (yet) a singular page that defines the process. Roman has been
working on one. Your wiki page is coupled with other process/organizational
changes.


 think it's easy to invent things that haven't been
 done and to overlook what has been done (more than
 1 wiki page, in Incubator-ville; an in ComDev now,
 thanks to Roman; 100s-1000s of emails over many years
 on the subject, etc.).


While agreed, and several Directors have been party to those discussions ...
the internal discussion on board@ has shown a lack of recognition/review of
all of that. This is not unexpected: that discussion occurred *here*. I
thought it was reasonable to assume our fellow Directors to be caught up on
that discussion, but that was presumptuous. ... The past years of discussion
must be distilled, rather than oh, look in the archives.



 Continuing to play the bring me a rock game will
 lead to no progress.


Yeah :-(



 I don't have a ton of confidence for pTLP in the
 current board. I also fully invite the membership of
 the ASF to use this as a measuring stick for future
 board members. Ask your board member candidates during
 the next ASF member election to answer this question
 before you cast you VOTE and use it to help decide.


Agreed. Experimentation, rather than status quo.

Cheers,
-g

Re: pTLP process amendments

[Greg Stein]

This is fantastic. Thanks you, Niclas!

On Mon, Feb 23, 2015 at 8:15 PM, Niclas Hedhman nic...@hedhman.org wrote:

 Roman,

 See comments below to
 https://cwiki.apache.org/confluence/display/COMDEV/Provisional+TLP


 2.1  -- I suggest to change the word probationary to provisional. I
 also suggest that a text is added such as; 'It is required that the
 provisional concept is explained in detail to the users, for instance by
 linking to page http://' where  is another page on ComDev
 explaining pTLP from the user's perspective.

 After the two bullet points, the following text At the same time those
 folks are beholden to the project not an external entity (like IPMC). By
 creating a PMC that understands what is needed, then a pTLP can groom new
 PMC members, and use the standard process for adding them to the PMC. The
 Board doesn't care about committership, so the pTLP can do whatever it
 wants in that regard. sounds to me a bit harsh, and I would like to
 suggest the following instead;
 The initial PMC should therefor, at least in theory, have a stronger base
 for grooming new committers and PMC members, than the regular podling
 graduate.


 I think that 3.7. to 3.9. are really not necessary. I would like to suggest
 to change that to;

 3.
 7. The first business for the initial PMC is to complete the pTLP
 checklist of tasks, primarily in coordinating with infrastructure, end
 ensure compliance with branding and legal policies. See http://x/;
 8.  The pTLP day-to-day operation is identical to a regular TLP. It is
 recommended that the PMC members are extra careful, to avoid confrontation
 and seek consensus to the greatest extent possible, and to explicitly
 explain all activities in greater detail to community members, as part of
 the learning process.


 Below is the beginning of tasks that should be listed, and I think a
 separate page for this, order not totally thought through. These tasks
 could exist as a set of one Jira tasks with a subtask for each, which can
 be cloned for each new project.

 Setting up a Provisional Top Level Project

 * Complete Name Search in accordance with Branding policy at
 http://www.apache.org/dev/project-names
 * Check PMC Chair is recorded in LDAP.
 * Request Jira from INFRA
 * Request Mailing lists from INFRA
 * Add project to Reporting Schedule
 * Request source control (svn or git) from INFRA
 * Submission of ICLAs from existing committers.
 * Submission of CCLAs from affected companies
 * IP Clearance as described on http://incubator.apache.org/ip-clearance/
 * Filing of Software Grant, if applicable.
 * Change to Apache License v2.0, if applicable.
 * Update Apache Navigation to include project
 * Request User Accounts from INFRA
 * Request CMS from INFRA
 * Migrate existing documentation to Apache.
 * Ensure Provisional markings are adhered to, and link to http://
 * Enable Notifications from Jira to Mailing list
 * Migrate existing codebase to Apache
 * Ensure dependency licensing compatibility, see
 http://www.apache.org/legal/resolved.html
 * Review legal compliance on all dependencies, in particular NOTICE file.
 * Ensure compliance with Branding policy
 * Establish self-assessed Apache Maturity Model declaration.

 There might more that I can't think of this morning.
 --
 Niclas Hedhman, Software Developer
 http://www.qi4j.org - New Energy for Java

Re: Practical next steps for pTLP experiment

[Greg Stein]

Stop talking about Incubator changes. You begin with pTLP, but devolve into
other proposals about changes to the Incubator.

Niclas restarted this thread about pTLP. That is all.


On Tue, Feb 24, 2015 at 3:06 AM, Ross Gardler (MS OPEN TECH) 
ross.gard...@microsoft.com wrote:

 Ok let me try again.

 I am in support of pTLP where it is clear it will work for a given
 project. Sam makes a good point that if we are sure it will work why
 bother. Just make it a TLP and be done with it. This version of orthogonal
 to the IPMC. I agree and I think its a great idea.

 My own concern is not projects that can become a pTLP or even a TLP. Such
 projects are not a problem for the Incubator.. They graduate and don't have
 growing pains once graduated (or at least no more than if they were to go
 straight to TLP). This is because they have, by definition, active people
 in their community that will ensure the project will graduate

 My concern, which is an IPMC concern, is the few projects that don't have
 that starting point. The pTLP doesn't solve that problem. It moves it. I've
 been consistent with that feedback throughout.

 I'm not sure how Roman interpreted my repeat of that, and a desire to try
 something else, as me saying pTLP had to happen in the incubator. I didn't
 say that, at least not intentionally. And in the summary of my position at
 the start of this thread, a summary I didn't write (that is other people
 seen to understand my point).

 So there you have it, I am taking a position.

 PTLP is fine. Go do it (actually I'm with Sam, drop the p and thus drop
 the confusion)

 PTLP doesn't solve the problems identified in the wiki. So whilst it can
 reduce unnecessary work in the IPMC it wont since the problem.

 Am I being clear?

 One more point of clarity. If anyone wants to claim pTLP is all we need,
 and the IPMC can be dissolved then I have a problem with that. And if
 someone does claim this then the two things are not orthogonal.

 Ross

 Sent from my Windows Phone
 
 From: Greg Steinmailto:gst...@gmail.com
 Sent: 2/24/2015 12:32 AM
 To: general@incubator.apache.orgmailto:general@incubator.apache.org
 Subject: Re: Practical next steps for pTLP experiment

 if we accept ... take a position, Ross.

 The two problems *are* orthogonal. The IPMC can do whatever it likes. A
 pTLP is a proposal to the Board.

 Bertrand would like to see discussion on general@incubator, but that is
 merely a handy location. It actually has zero to do with the Incubator.

 Ross: if you believe that a pTLP is somehow tied to the Incubator, then
 state that. Otherwise, please STOP throwing uncertainty into the waters.

 -g


 On Mon, Feb 23, 2015 at 7:29 PM, Ross Gardler (MS OPEN TECH) 
 ross.gard...@microsoft.com wrote:

  Fair enough. I don't think I ever agreed they are orthogonal. In fact the
  only concern I have consistently stated, and is reflected on the summary
  below, is that it, potentially, moves the problem rather than solves it.
 
  That being said, if we accept its orthogonal then your point is a good
 one.
 
  Sent from my Windows Phone
  
  From: Roman Shaposhnikmailto:ro...@shaposhnik.org
  Sent: 2/23/2015 4:49 PM
  To: general@incubator.apache.orgmailto:general@incubator.apache.org
  Subject: Re: Practical next steps for pTLP experiment
 
  On Mon, Feb 23, 2015 at 4:11 PM, Ross Gardler (MS OPEN TECH)
  ross.gard...@microsoft.com wrote:
   It's not unfair. I deliberately tried to say i don't want to distract
  from the handover process.
 
  I though we all agreed that whatever pTLP is -- it is absolutely 100%
  orthogonal to
  the process that Incubator is in business of managing. There will be
  some overlap
  of people involved in both, but we don't need to wait on Incubator to
  proceed with
  pTLP any more than we'd need to wait on Incubator to do something in
  Hadoop land
  (although quite a few Hadoop folks are on IPMC).
 
   I don't think its productive to make someone's support or otherwise of
  an experiment
   to distract from getting the right chair to replace you.
 
  That would be a fair point if we didn't try as hard as we can to
  decouple the two.
 
  If what you're saying is: currently there's no way for Incubator NOT
  to be involved
  in pTLP AND if that's the opinion shared by the majority on the board,
  I'd have to
  re-evaluate things on my end.
 
  I thought Greg convinced you all that it must be de-coupled. That's what
 I
  based
  my calculations on.
 
  Thanks,
  Roman.
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 

Re: Practical next steps for pTLP experiment

[Greg Stein]

On Mon, Feb 23, 2015 at 2:12 AM, Niclas Hedhman nic...@hedhman.org wrote:
...

 Sam -- Think there is no need for a new concept, and have no problem with
 incoming projects backed by ASF veterans to bypass the Incubator.


I believe Sam gave this based on a singular, concrete proposal. He would
likely respond differently over time, and over different proposals.


 Bertrand  -- Doesn't want a new concept for the Board to deal with.
 Suggests to run pTLP under the Incubator supervision.


He has responded else-thread.



 , but warn
 possible burden on Board if something goes wrong.


This is a concern for the pTLP community, not the Board. As we all know,
the Board has a very large hammer. If you are doing something wrong, then
you get shut down. There are a couple solutions just short of that, but
they all hurt. Badly. ... Yet the real point is: the Board doesn't have any
extra work that it doesn't already provided to TLPs here. And the Board
even reviews podlings, via the Incubator report. ... so we're not really
talking about any real, additional burden upon the Board.

...

Cheers,
-g

Re: Practical next steps for pTLP experiment

[Greg Stein]

On Tue, Feb 10, 2015 at 4:01 PM, Sam Ruby ru...@intertwingly.net wrote:

 On Tue, Feb 10, 2015 at 3:35 PM, Greg Stein gst...@gmail.com wrote:
 
  Who ever said the Incubator has the exclusive Right to be the only way to
  become part of the Apache Software Foundation? New approaches can be
  discussed anywhere. At the end of the day, it will be the Board who votes
  on a pTLP resolution.

 Resolution R2, paragraph 3:


 http://apache.org/foundation/records/minutes/2002/board_minutes_2002_10_16.txt


Well aware, Sam. I voted on that. ... and again: it doesn't assign
*exclusive* management of incoming projects. It is flat out impossible for
such. The Board can write a resolution saying that one day, and then accept
a contravening resolution the next.

*shrug*

... what you're missing is that pTLP is not part of the Incubator. Nothing
against it, but it has zero bearing upon these proposals. All of that is
left to the Board.

...

Cheers,
-g

Re: Practical next steps for pTLP experiment

[Greg Stein]

On Mon, Feb 2, 2015 at 4:38 AM, Bertrand Delacretaz bdelacre...@apache.org
wrote:

 Hi,

 I missed a few important points in this thread last week, with which I
 disagree:

 On Tue, Jan 27, 2015 at 7:28 PM, Greg Stein gst...@gmail.com wrote:
  ...1) Draft a template resolution. Starting in the wiki is fine, but
 you'll
  want to involve board@ when you have your first draft done

 IMO board members have more important things to do than work on draft
 resolutions for new projects,


Read it again, Bertrand: TEMPLATE RESOLUTION.

The Board doesn't let arbitrary resolutions just drop on our desk. We
expect them to be in a form that we agree with. Thus, any pTLP resolution
must fit our expectations. That means how does this look, Board? what
needs to change?

Part of that has already occurred, when I provided some feedback on the
(concrete) Zest resolution. A template still needs to be created from that.


 and it's also important for drafts of
 new projects to be discussed in public. If only to allow new people
 and mentors to jump in.


Resolutions don't need to be discussed, since they are fill in the blank
from a template. What needs to be discussed with the Board, is that
template.


 I strongly suggest discussing such draft resolutions on this list.
 Even if the Incubator PMC is not formally involved in managing those
 pTLPs, this list is where the know-how about creating new projects
 resides, I see no reason to move that work elsewhere.


Already agreed to. No need to beat that dead horse.



  ...2) Create a ComDev page discussing what it means to be a provisional
 TLP

 I don't understand why people want these things to move to comdev -
 did you even ask the comdev PMC about this? It sounds like people want
 to send a bunch of tasks their way, without even asking.


It was brought up on dev@ just like it should, Bertrand. Stop assuming the
worst.



 I see no reason for the pTLP process definition to happen outside of
 the Incubator, which is the PMC tasked with bringing new projects to
 the ASF.


Who ever said the Incubator has the exclusive Right to be the only way to
become part of the Apache Software Foundation? New approaches can be
discussed anywhere. At the end of the day, it will be the Board who votes
on a pTLP resolution.

-g

Re: [ANNOUNCE] Apache Slider 0.60.0-incubating

[Greg Stein]

Excellent. Thanks!

On Tue, Feb 3, 2015 at 8:07 PM, Josh Elser josh.el...@gmail.com wrote:

 No worries :). I'm glad you said something -- I didn't realize it.

 I'll update our releasing page to make sure it includes the required
 disclaimer text so the next person who copy-pastes it doesn't forget it
 like I did.


 Greg Stein wrote:

 Heh. Just saw how old this release was... :-P


 On Tue, Feb 3, 2015 at 4:00 PM, Greg Steingst...@gmail.com  wrote:

  This release announcement does not contain the required DISCLAIMER
 necessary for all incubating projects.

 Please see:
http://incubator.apache.org/guides/branding.html

 On Mon, Nov 24, 2014 at 3:53 PM, Josh Elserels...@apache.org  wrote:

  The Apache Slider team is proud to announce Apache Slider incubation
 release version 0.60.0-incubating.

 Apache Slider (incubating) is a YARN application which deploys existing
 distributed applications on YARN, monitors them, and makes them larger
 or
 smaller as desired - even while the application is running.

 The release artifacts are available at:
 http://www.apache.org/dyn/closer.cgi/incubator/slider/0.
 60.0-incubating/src/

 The full change set is available at: http://s.apache.org/07

 To use these artifacts, please use the following documentation:
 http://slider.incubator.apache.org/docs/getting_started.html

 We would like to thank all the contributors that made the release
 possible.


 Regards,
 The Slider Team
 http://slider.incubator.apache.org/




 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: [ANNOUNCE] Apache Streams 0.1-incubating release

[Greg Stein]

This release announcement does not contain the required DISCLAIMER
necessary for all incubating projects.

Please see:
  http://incubator.apache.org/guides/branding.html

On Tue, Feb 3, 2015 at 12:27 PM, Steve Blackmon sblack...@apache.org
wrote:

 I'm pleased to announce immediate availability of streams 0.1-incubating.

 Download links to the source code zip, md5, and asc are available from
 http://streams.incubator.apache.org.

 Steve Blackmon
 sblack...@apache.org

Re: [ANNOUNCE] Apache Slider 0.60.0-incubating

[Greg Stein]

This release announcement does not contain the required DISCLAIMER
necessary for all incubating projects.

Please see:
  http://incubator.apache.org/guides/branding.html

On Mon, Nov 24, 2014 at 3:53 PM, Josh Elser els...@apache.org wrote:

 The Apache Slider team is proud to announce Apache Slider incubation
 release version 0.60.0-incubating.

 Apache Slider (incubating) is a YARN application which deploys existing
 distributed applications on YARN, monitors them, and makes them larger or
 smaller as desired - even while the application is running.

 The release artifacts are available at:
 http://www.apache.org/dyn/closer.cgi/incubator/slider/0.
 60.0-incubating/src/

 The full change set is available at: http://s.apache.org/07

 To use these artifacts, please use the following documentation:
 http://slider.incubator.apache.org/docs/getting_started.html

 We would like to thank all the contributors that made the release possible.


 Regards,
 The Slider Team
 http://slider.incubator.apache.org/

Re: [ANNOUNCE] Apache Slider 0.60.0-incubating

[Greg Stein]

Heh. Just saw how old this release was... :-P


On Tue, Feb 3, 2015 at 4:00 PM, Greg Stein gst...@gmail.com wrote:

 This release announcement does not contain the required DISCLAIMER
 necessary for all incubating projects.

 Please see:
   http://incubator.apache.org/guides/branding.html

 On Mon, Nov 24, 2014 at 3:53 PM, Josh Elser els...@apache.org wrote:

 The Apache Slider team is proud to announce Apache Slider incubation
 release version 0.60.0-incubating.

 Apache Slider (incubating) is a YARN application which deploys existing
 distributed applications on YARN, monitors them, and makes them larger or
 smaller as desired - even while the application is running.

 The release artifacts are available at:
 http://www.apache.org/dyn/closer.cgi/incubator/slider/0.
 60.0-incubating/src/

 The full change set is available at: http://s.apache.org/07

 To use these artifacts, please use the following documentation:
 http://slider.incubator.apache.org/docs/getting_started.html

 We would like to thank all the contributors that made the release
 possible.


 Regards,
 The Slider Team
 http://slider.incubator.apache.org/

Re: Practical next steps for pTLP experiment

[Greg Stein]

On Tue, Jan 27, 2015 at 12:38 PM, Roman Shaposhnik ro...@shaposhnik.org
wrote:
...

 Totally agreed! Who can help me learning the ropes on how ComDev
 documentation is maintained, etc?


Maybe ask on dev@community rather than general@ ?? :-P

Re: Practical next steps for pTLP experiment

[Greg Stein]

There are a few things that I would suggest for next steps:

1) Draft a template resolution. Starting in the wiki is fine, but you'll
want to involve board@ when you have your first draft done. This will also
start the discussion among the Directors (recall: the Board hasn't even
agreed to try this!), and may produce some refinements.

2) Create a ComDev page discussing what it means to be a provisional TLP.
The disclaimers/warnings/release-naming should likely mirror what we do for
incubating podlings.

3) Note that I use provisional, since probationary implies you got in
trouble.

I wouldn't really worry about time frames. This will be a very subjective
process, and every project is different. It will be hard to make a solid
determination on day X in the future. If I were to put my thumb in the air,
I'd say 6 and 12 months, rather than your 3/6.

Cheers,
-g

On Tue, Jan 27, 2015 at 11:28 AM, Roman Shaposhnik r...@apache.org wrote:

 Hi!

 as I mentioned in a different thread, I feel really
 passionate about championing the pTLP experiment.
 To that end, here's what's going to happen shortly:
   #1 a couple of new projects that feel equally enthusiastic
about trying a pTLP route (and have a level of support
from a few board members) will submit a pTLP proposal
to the board.
   #2 based on how #1 goes we will try to establish a path
for existing (willing!) podlings to be converted to pTLP.
A solicitation and details of what to expect will be posted
on general@ with the expectations of having a couple
existing podlings as part of the experiment

 In about 3 months time frame, if #1 and #2 are moving in the
 right direction, I'd like to start offering pTLP *option* for new
 communities seeking to join ASF. By that time I hope to have
 some amount of documentation detailing the process and pros/cons
 compared to the existing IPMC led model.

 In about 6 months time frame I would like to have enough details
 in place to submit to IPMC and start a discussion on whether
 pTLP is a viable model that needs to be encouraged and what
 does it mean for IPMC and ASF Incubation process.

 For all practical purposes, consider me a self-appointed pTLP
 champion and please, please help along as much as you can!

 Thanks,
 Roman.

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: my pTLP view

[Greg Stein]

Go to the FIRST POST of this thread (titled: my pTLP view!!). THAT is
what we're talking about. Not the Strawman.

On Sun, Jan 25, 2015 at 1:56 PM, Andrew Purtell apurt...@apache.org wrote:

 Oh, my mistake! (smile) I confused pTLP with the Strawman proposal there
 for a minute. In the pTLP proposal, there are no new-to-the-Foundation
 project members on the pTLP PMC.

 All proposals for new ASF projects must include an initial PMC chair and
 an initial set of PMC members. These people must be acceptable to the
 board. It is the responsibility of the Incubator Committee to vett these
 people. All of them must have experience on existing PMCs


 Newcomers to Apache *might* get committership depending how the
 only-members-as-PMC decide. They don't get even non-binding stakeholdership
 in decisionmaking on new commiters, releases, and so on.


 On Sun, Jan 25, 2015 at 11:49 AM, Andrew Purtell apurt...@apache.org
 wrote:

   This is *exactly* the way things work in a TLP.
 
  Yes, everyone new to the Foundation on the PPMC has a sense of equal
  ownership in the process. The PPMC makes a decision together as equals,
  then the decision is reviewed as a whole. But this is not how things
  would work in a pTLP, right? Individuals there would effectively cast
  votes +1 (binding), or -1 (binding), +1 (non-binding), or -1
  (non-binding), etc., depending if they are a Member or not. Maybe in
  practice the pTLP PMC wouldn't write down their votes like that, but
  somehow the distinction must be presented in the tallies to be
 meaningful.
 
 
 
  On Sun, Jan 25, 2015 at 11:11 AM, Branko Čibej br...@apache.org wrote:
 
  On 25.01.2015 19:51, Andrew Purtell wrote:
   That hardly ever happens (it's most likely when there are problems
 with
   ​ ​
   a podling's first few releases), which is why you get the impression
   ​ ​
   that the PPMC can make binding decisions.
  
   ​Close. The PPMC membership feels they have made a decision that
 matters
   with equal input.
   Certainly on PPMCs I've been on,
   ​there is awareness that everything is
   provisional
   ​. Still, a
process takes place on PPMC mailing lists leading to a tallied
 outcome.
   The input that leads to this output is the consensus or voting of *a
  group
   of equal peers*.
   ​ This output is handed to the IPMC in aggregate. ​
   When casting votes on the PPMC lists there are no +1 (binding) or +1
   (non-binding) distinctions made. PPMC sends the outcome over to the
 IPMC
   feeling some level of ownership having just participated in a decision
   making process as equal
   ​s​
   . (Or at least so I think, in some perhaps quaint notion.) Of course
 in
   IPMC voting it is different, but the IPMC is where supervision
 happens,
  or
   doesn't, as some argue.
 
  This is *exactly* the way things work in a TLP. Any committer can
  propose a release. The PMC must (!) start a (public) vote. Anyone can
  vote, with PMC votes being binding. /Any/ -1 vote, either from PMC
  member or plain committer, should block the release and trigger a
  discussion to find a solution; and in this discussion (which purpose is
  to reach consensus on a solution), PMC members have no more voice than
  any other community member.
 
  If the PMC decides to ignore a -1 on a release vote, they'd better have
  really good reasons for that, or I'd expect the Board to come down like
  a ton of bricks on that PMC.
 
  The situation is slightly different with new committer/PMC member
  nominations and votes, which are private; you have a point there.
 
  -- Brane
 
   On Sun, Jan 25, 2015 at 10:35 AM, Branko Čibej br...@apache.org
  wrote:
  
   On 25.01.2015 19:16, Andrew Purtell wrote:
   With a PPMC we invite newcomers to make votes we call binding on
  matters
   of
   their own project.
   As other people have said, PPMC members (that are not also IPMC
  members)
   do not have binding votes, neither for releases nor for inviting new
   committers/PPMC members. The binding bit lies with the IPMC, which
  can
   revoke any formal decision made by the PPMC.
  
   That hardly ever happens (it's most likely when there are problems
 with
   a podling's first few releases), which is why you get the impression
   that the PPMC can make binding decisions. In this respect, there's no
   practical difference between the current IPMC model and the proposed
   pTLP model.
  
   Of course, when it comes to /technical/ decisions, there's no such
  thing
   as a vote, so the term binding does not apply. Consensus, of one
 form
   or another, always rules: and the IPMC or mentors can't meddle in
 this
   case.
  
   -- Brane
  
  
   -
   To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
   For additional commands, e-mail: general-h...@incubator.apache.org
  
  
  
 
 
  -
  To unsubscribe, e-mail: 

Re: my pTLP view

[Greg Stein]

Apache Subversion uses discussion/consensus for all of those. We throw out
+1 and similar as shorthand for our preference, but we never tally, as it
isn't a formal vote.

On Sun, Jan 25, 2015 at 1:58 PM, Andrew Purtell apurt...@apache.org wrote:

 In all of the projects I have been PMC or PPMC on, we vote on releases, new
 committers, and elevating committers to PMC.


 On Sun, Jan 25, 2015 at 11:56 AM, Greg Stein gst...@gmail.com wrote:

  On Sun, Jan 25, 2015 at 1:49 PM, Andrew Purtell apurt...@apache.org
  wrote:
 
This is *exactly* the way things work in a TLP.
  
   Yes, everyone new to the Foundation on the PPMC has a sense of equal
   ownership in the process. The PPMC makes a decision together as equals,
   then the decision is reviewed as a whole. But this is not how things
  would
   work in a pTLP, right? Individuals there would effectively cast votes
 +1
   (binding), or -1 (binding), +1 (non-binding), or -1 (non-binding),
 etc.,
   depending if they are a Member or not. Maybe in practice the pTLP PMC
   wouldn't write down their votes like that, but somehow the distinction
  must
   be presented in the tallies to be meaningful.
  
 
  Nah. First: votes should be rare in the first place. Go for consensus
  instead. Apache Subversion has had maybe 3 votes in its 15 year history.
 
  And if you *do* end up voting? People already know who is binding or not.
  This isn't some star chamber PMC. Everybody knows each other already. If
  the PMC is voting differently from the others, then you have a problem,
  regardless of not/binding.
 
  Anyways... we'll run the experiment, and see how it works. We may have a
  candidate already.
 
  Cheers,
  -g
 



 --
 Best regards,

- Andy

 Problems worthy of attack prove their worth by hitting back. - Piet Hein
 (via Tom White)

Re: my pTLP view

[Greg Stein]

They are reporting to the Board. We know what inactivity looks like. So we
ask the PMC to fix it, or we shut them down. Just this week, you messaged a
PMC asking if they had enough actives. There is ample precedent for us
detecting and working through inactivity.
On Jan 23, 2015 9:46 AM, Bertrand Delacretaz bdelacre...@apache.org
wrote:

 Hi,

 On Fri, Jan 23, 2015 at 2:42 PM, Greg Stein gst...@gmail.com wrote:
  ...1. probationary text is prominent,...

  ...2. the initial PMC is comprised of only ASF Members...

 I like that proposal, it's simple and looks actionable.

 The only worry is what happens if the ASF Members on the PMC become
 inactive - those folks will need to be serious about their job, to
 make sure they elect the appropriate people to the PMC before leaving.
 Doesn't sound impossible though.

 -Bertrand

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: my pTLP view

[Greg Stein]

On Jan 23, 2015 8:53 AM, jan i j...@apache.org wrote:

 On 23 January 2015 at 14:42, Greg Stein gst...@gmail.com wrote:
 ...

 I agree with everything else you write, but the demand for only ASF
 Members seems very hard. If I come to ASF with a community and a project,
 I really would feel unhappy being cut out of the loop (PMC cares about the
 community, not the committers following our role definition).

 Would it not be possible to write The initial PMC must be comprised of
 more than 50% ASF Members, or something similar.

It would be a Resolution put before the Board. So the initial mix can be
whatever you can get away with. :-)

As a Director, I'd look for 100%. But with some rationale, one or two
others could be fine.

 If this came to vote, I would give it a -1, because we cannot and should
 not overrule an existing community, but merely guide them.

The community is who agreed on the approach and placed it before the Board,
for pTLP status. And only the Board would be voting on that Resolution.

Cheers,
-g

Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)

[Greg Stein]

On Fri, Jan 23, 2015 at 12:57 PM, Marvin Humphrey mar...@rectangular.com
wrote:
...

 Time is on the side of those who think shepherd institution should die.  It
 would be better if it died quickly, vacating the report review mindspace
 and
 making way for Mentor commentary supplemented by reactive IPMC report
 feedback.  Mentors on the ground *are* the Incubator's analogue to Board
 shepherds -- the extra layer is unnecessary and costs too much.  It is
 harmful
 that shepherd reviews are the way it's done.


I believe the Incubator shepherds exist to help the IPMC with its duties.
The shepherds delegate/divide the work needed of the IPMC to review the
podling reports, before passing its report up to the Board.

The IPMC is an active entity with responsibilities. It has a job to do, and
the shepherds provide a way to do that. Rather than waving a hand and
saying the IPMC will review (and nothing happening cuz everybody thinks
everybody else will do it) ... or requiring the VP to do it every month..
the shepherds provide a way for volunteers to assist with the process.

There is nothing stopping the IPMC from designating certain Mentors as
shepherds for their podlings. Look at the Board: since I am the VP of
Subversion, a shepherd is never assigned to that report. I'm the implied
shepherd. Anything that the Board needs to convey to the PMC, I'm
responsible for that legwork (just like we delegate working with PMCs to
shepherds).

So if a Mentor is active enough, then put your name on the list to be the
shepherd for your podling (and be an IPMC member, of course). That activity
wasn't happening in the past, so the shepherds were filling in. Especially
when a Mentor is temporarily away.

Cheers,
-g

Re: my pTLP view

[Greg Stein]

On Fri, Jan 23, 2015 at 6:18 PM, jan i j...@apache.org wrote:

 On Saturday, January 24, 2015, Ross Gardler (MS OPEN TECH) 
 ross.gard...@microsoft.com
 javascript:_e(%7B%7D,'cvml','ross.gard...@microsoft.com'); wrote:

  No, the PMC is *not* the driving force. The project community is, even
  where the PMC is a subset of the committers. Since it is the set of
 active
  *contributors* that are important, they are the ones doing the work.

 I totally agree, but pTLC calls for a PMC that can be 0% subset of the
 community, how can the PMC in this situation reflect the community?


Because the Board chose to put people onto the PMC that understand: *guide*
the community. Not *rule* the community.

Even better is when the ASF/PMC members are *part* of the community, rather
than just being present to assist with that guidance.

In the current Incubator model, a Champion is chosen. That is usually a
person who has some self-interest in the project, and becomes *part* of the
community. So you already have some overlap there.



 Remember we talk rules here, and rules should be made so the reflect what
 we want, and I believe it is important that the community is represented in
 the PMC, not 100% but also not 0%.


No. We DON'T talk about rules here. I said create a PMC with a couple
requirements. Then the project does what works best for their community,
within the overall view of what the ASF believes makes a great project.

Rules exist to provide guidance when consensus does not exist. That is all
a rule is good for. A project with a strong consensus model doesn't need
rules.

  I don't understand your argument about releases. Nothing changes under
  under the pTLP proposal with respect to how a release is made. In any
ASF
  project the full community votes for a release if they want to. Only the
  PMC have binding votes, but they should listen to the community in
casting
  those votes (same is true for podlings where the podling community
votes on
  a release but it needs to be formalized by the IPMC via its mentors).

 I read the rules instead of believing in should. If a PMC does not like
a
 technical direction, they can block it totally within the rules, even if
 all non-PMC prefers it.

Sure... they *could*. How long do you honestly believe the Board would
allow that to continue? Seriously.

You propose a situation that just won't ever happen.

 I think my problem is that I agree with both you and Roman, The PMC should
 leave technical matters including releases to the total community. But
 alone by talking about binding and non-binding votes creates two
 levels, and if the PMC does not include the incoming community the
 disconnect gets bigger.

There *are* two different levels. That is how it works. Always has. Always
will. Accept that.

But that doesn't mean those with binding votes should (or WOULD!!) ignore
those without. I don't see that happen. Do you? I would guess not. So it
isn't something to worry about.

I also specifically said ASF Members because I believe *they* know how to
run a community. Not to use the ASF legal structure against it, but to help
the community work *within* the structure. As Ross said: to empower the
community.

 With pTLC I fear that the incoming community will feel empowered,  the
[ I'm assuming you meant: not feel empowered ]
 community does not (according to the rules) need to vote, just let the ASF
 members do the work. With PPMC the podling must make a vote otherwise a
 release will never happen.

That won't happen. The community will do the work. If not, then there
wasn't a community.

You are looking at an extreme failure mode according to what is possible
in the rules. I am telling you: that won't happen. We don't allow our
communities to do that, and we won't create a PMC that allows that to
happen. And the Board will be reviewing the project to *ensure* it doesn't
happen.

 Again please remember I read the suggested rules and see what could go
 wrong, in a perfect world we would not have wars and every project would
 function perfect.

Your pessimism is unwarranted.

-g

Re: my pTLP view

[Greg Stein]

On Fri, Jan 23, 2015 at 4:33 PM, Alex Harui aha...@adobe.com wrote:

 On 1/23/15, 1:34 PM, Ross Gardler (MS OPEN TECH)
 ross.gard...@microsoft.com wrote:

 A good mentor is a guide, not a manager.
 
 The proposals might seem top down, but when executed correctly, they are
 not.

 OK, I'll accept that, but if executed correctly, the current Incubator
 probably doesn't need changing either.


Yup. So it keeps doing its thing. The existence of pTLPs at the ASF does
not preclude or replace the Incubator.



 IMO, it is hard to find a lot of really dedicated volunteers.  So your
 choices are to work the really good ones really hard, try to manage
 other volunteers, or try to find a way to work without really dedicated
 volunteers.

 In my experience, the more you try to control and check on these other
 volunteers, the faster they will go away.


Sure. And the pTLP allows the community to work at its best, with the
peanut gallery (read: general@incubator and the IPMC) getting in their
face. There are *way* fewer controls/checks in the pTLP approach. It relies
on the ASF members to share their knowledge and to provide the needed
guidance. No extra controls or checks, beyond those of a normal TLP. (well,
except for that probationary or provisional warning)



 Apache has a really great system of accepting code from volunteers with
 limited time.   You don't have to make a time commitment, just occasional
 code commitment.  Can the ASF find a way to teach culture via volunteers
 with limited time?  Probably.  That's why I mentioned the notion of having
 more ASF people involved in a project, but not as the initial PMC.  Real
 communities teach their culture by hanging out around the newcomers, but
 no one person is signed up to do the teaching.  They do it by having lots
 of villagers watching the newbies checking on what the newbies are doing
 and saying when they can.  That's hard to do on email, but if certain
 newbie efforts require a shout out outside their list, then it is easier
 for this larger band of villagers to hear that something important is
 going on.


That is certainly a possibility, and has always been possible here in the
Incubator. Hasn't happened. And when you *do* add a whole bunch of people?
Guess what happens? ... John thinks Joe is paying attention. Joe thinks
John is paying attention. Nobody does. The podling goes pear-shaped.

Regardless, nothing about the pTLP proposal interferes with your ability to
test your theory. The pTLP proposal is not exclusionary. You are welcome to
set up a new podling with 20 Mentors.

My proposal is for communities who want to try a different path. It isn't
and won't be the only path.

Based on my personal experience when Apache Subversion went through
incubation... the pTLP approach would have worked much better. We had a
half-dozen ASF Members that could have formed the initial PMC. They would
have added the next 20 right off the bat. And after some IP clearance,
would have been done, and asked for removal of the provisional flag. The
community was designed as an Apache community from the start. But the
Incubator attempted to apply checklist items that didn't make sense. Those
checklists were for communities that had no understanding of Apache. The
Incubator model works very well for some, not so well for others.

Mentors are important, yes. And we don't have enough. Mandating they fall
into a single mentoring approach? Or that their available time must be
allocated in a certain way? Nah... Let them follow what interests them, and
to follow their thoughts on shaping a community into a fantastic Apache
community.

Cheers,
-g

Re: my pTLP view

[Greg Stein]

On Fri, Jan 23, 2015 at 8:08 PM, Andrew Purtell apurt...@apache.org wrote:
...

 project, they become a PPMC, a podling. Sure, the IPMC provides oversight,
 and the board again, but the PPMC can make binding votes on committers,
 releases, everything that matters - provisionally, of course, which is
 completely acceptable.


provisionally, of course .. that is exactly Roman's point. TODAY, the
PPMC has no ownership. It is completely subjugated to the whims of the IPMC.

The pTLP concept replaces the IPMC with a group of a few ASF Members that
are dedicated/interested in that specific community. The community doesn't
end up with 100+ random IPMC members who care less about the community.
Instead, it gets some volunteers who are responsible to listen, to guide,
and to assist the community with becoming part of the Foundation.

That community can still create consensus. And the PMC will/should obey
that consensus. If it does NOT, then the Board axes them. Every PMC works
this way. Always has.

The PMC may be all powerful (or more specifically: the VP singularly),
but when the Board hears that a VP or a PMC is working against the
community? Shit gets real, and heads start to roll. The Board doesn't take
kindly to that.

This all changes if the PMC does not include any
 members of the incoming community. There isn't even a provisional ownership
 stake in the endeavor. When Apache grants the incoming community a
 provisional binding stake in the process, this establishes trust.


The incoming community has NEVER had a stake in the outcome. That's what
Roman has been trying to say.

You seem to be under the impression that the PMC will work against the
community. That is a baseless opinion. Name a precedent.

I've been here for 16+ years. I haven't seen that yet. As a Director for
almost 14 years, I have reviewed *thousands* of project reports. Read
umpteen mailing lists. Reviewed archives. Investigated JIRA conflicts. Not
once have I seen a PMC actively work against its community, as you describe.

Have you? Would love a pointer, if you have one.


 I don't agree that the chances ASF PMC members of pTLP will start actively
 overriding votes is slim to none.  I've been around here for a while and
 spent some time in Hadoop land. The process is not infallable. The
 membership is not infallable. To ensure the probability of better outcomes
 no matter what happens during an incubation, the incoming community should
 be treated more like partners in a common endeavor with a full stake in the
 process than what is proposed here.


Again, you believe the PMC won't act as partners. I call bullshit.

Cheers,
-g

Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)

[Greg Stein]

On Fri, Jan 23, 2015 at 9:49 PM, Marvin Humphrey mar...@rectangular.com
wrote:

 Hi Greg,

 On Fri, Jan 23, 2015 at 1:33 PM, Greg Stein gst...@gmail.com wrote:

  There is nothing stopping the IPMC from designating certain Mentors as
  shepherds for their podlings.

 Having volunteers step forward as dedicated shepherds for individual
 podlings would be helpful.  On its own, though, it is not sufficient,
 because Incubator shepherds are not as reliable as Board members.  What
 happens when the dedicated shepherd goes missing?  Podlings will start
 falling through the cracks again.


Agreed. I was thinking on a month-to-month basis. I'll shepherd ACME this
month. (in addition to more general shepherds of gimme 3 podlings that
haven't been allocated already)



 An additional mechanism needs to be in place to ensure that no report goes
 unreviewed.  For instance:

 1.  The Incubator doesn't file its report until each and every podling
 report has been reviewed by either a shepherd or a freelance IPMC
 member filling in.


Ah. I like the term freelance (better than my general above) ... note
that the IPMC must file a report. It can't wait forever. I think what
you're really looking for is fully-explained in your point below. (ie. not
sure how the above is different than below)

2.  Podling reports which have not been reviewed by a shepherd are omitted
 from the aggregate report and the podling is required to report again
 next month.


yes, the above would work just fine. Get the podling report reviewed, or
we strip it from the report to the Board.

Of course, the corollary is that the Board will get a bit cranky if it
keeps receiving empty Incubator reports :-P


 Starting this month, the Incubator has instituted something similar to the
 second option: podling reports where not a single Mentor has signed
 off get rejected and the podling is required to report again next
 month[1].  There was criticism that this mechanism punishes a podling for
 the sins of its Mentors, but the intended result was achieved: every
 podling report got signed off.  (Besides, in many cases the podling is at
 fault for filing at the last minute and leaving too small a window for
 Mentor signoff.)


*nod* ... It means get it in on time, and if your Mentors aren't helping,
then find new ones. Unfortunately, we *have* had a case or three in the
past where a podling has been unable to locate new Mentors. There isn't a
good solution for that, under any plan :-(



 With signoff required, Mentors assume the essential functionality of
 shepherds, and the value added by the titular shepherds is limited to
 cross-cutting feedback.  I maintain that there are better ways to provide
 such feedback.


Fair enough.



  That activity
  wasn't happening in the past, so the shepherds were filling in.

 Shepherd participation has fallen too low to keep podlings from getting
 lost -- it's now below 50%.  What has kept distressed podlings like
 NPanday from falling off the IPMC's radar screen, for the last year and a
 half, has been the Report Manager putting podlings who don't file reports
 into monthly reporting.  It's not perfect, but it's *way* less work and
 more reliable than shepherds.


It's an imperfect system, given volunteers, varying time, and changing
interests. Maybe a call for new shepherds? Maybe a slight change in Mentors
and their signoff? and as you note: maybe another way to create
cross-cutting feedback outside of the Mentor/shepherd roles. (general@ is
already a good mechanism for much of that)



 Maybe the Incubator should strike that task from the Report Manager's
 runbook and start losing track of podlings again?  Because I feel like we
 designed a better system and nobody noticed.

 Marvin Humphrey

 [1] This is related but not linked to the list of not-signing-off Mentors
 which the Board has chosen to remove from this month's report.  I've
 remained silent about that up till now out of deference to those IPMC
 members who are working hard to address issues of Mentor
 accountability, but I support the Board's decision.


I believe the list of no-sign-off Mentors is very useful, and the Incubator
should have that data. With the right context, it makes sense and is
helpful. It can help identify where a Mentor is slipping and needs
encouragement, replacement, or more Mentors for a podling.

However, the Board minutes do not provide the context. He was on vacation
doesn't appear, so it is easy to misconstrue what that list means. And it
is a bit too fine-grained for the Board. Replacing that list with something
like we had 30 active Mentors, and are reaching out to 4 that appear to
have moved on would be something the Board would be interested in. That is
about the *health* of the mentoring program, rather than calling out names.
(in fact, we asked a PMC or two to remove individual names from reports
over the past couple months; longer discussion on why)

Cheers,
-g

Re: Running an experiment with pTLP

[Greg Stein]

And another +1 from myself, as a Director voting on that
proposal/resolution.

On Mon, Dec 29, 2014 at 11:01 PM, Mattmann, Chris A (3980) 
chris.a.mattm...@jpl.nasa.gov wrote:

 The structure would still be there - my hypothesis is that the
 mentors + the board will both uplift structure, and help to identify
 (more quickly) situations like no report, lack of mentors, etc.

 Anyhoo this experiment (the 2 that have volunteered so far) would
 have my board VOTE - prepare a resolution and send it to the
 board agenda and let's see what happens..

 Cheers,
 Chris

 ++
 Chris Mattmann, Ph.D.
 Chief Architect
 Instrument Software and Science Data Systems Section (398)
 NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
 Office: 168-519, Mailstop: 168-527
 Email: chris.a.mattm...@nasa.gov
 WWW:  http://sunset.usc.edu/~mattmann/
 ++
 Adjunct Associate Professor, Computer Science Department
 University of Southern California, Los Angeles, CA 90089 USA
 ++






 -Original Message-
 From: Marvin Humphrey mar...@rectangular.com
 Reply-To: general@incubator.apache.org general@incubator.apache.org
 Date: Monday, December 29, 2014 at 8:36 PM
 To: general@incubator.apache.org general@incubator.apache.org
 Subject: Re: Running an experiment with pTLP

 On Mon, Dec 29, 2014 at 3:14 PM, Roman Shaposhnik r...@apache.org wrote:
  Might be seen as
  grossly unfair by the project that remain in the old regime
 
 There's no structure like no structure!
 
 Marvin Humphrey
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 


 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator report sign-off

[Greg Stein]

On Tue, Dec 30, 2014 at 4:04 AM, jan i j...@apache.org wrote:

 On Tuesday, December 30, 2014, Bertrand Delacretaz bdelacre...@apache.org
 
 wrote:

  On Mon, Dec 29, 2014 at 9:32 PM, Andrew Purtell
  andrew.purt...@gmail.com javascript:; wrote:
   ...Certainly some projects have a de facto lead that coincide with
 Chair
  and I'm pretty sure
   in some cases that is an honorary arrangement agreed to by the
  community
 
  *loud red alarms going off all over my brain*
 
  If that's the case, such projects should make sure they implement a
  regular PMC chair rotation. Or be prepared to go down in flames once
  that leader changes their mind and no one has a clue how their project
  runs.

 big +1actually the chair rotation is something we should consider
 having as a rule (and allow deviations for good reasins).


I cannot see the Board ever mandating chair rotations. That is up to the
community. As long as the chair/VP remains administrative, then there isn't
a problem. We have *many* chairs across the Foundation (myself included)
that have been in their position for many years. It works well because we
*support* the project, rather than any attempt to direct, steer, or lead
based upon that position. The VP is the link between a project's needs and
the Foundation's support for that project, along with bidirectional
communication.

For projects that don't understand the difference between supportive and
lead: yeah, they could use a dose of trout-slapping and a chair rotation
or three.

Cheers,
-g

Re: How do reporting groups get assigned?

[Greg Stein]

Leveling. Which group has the fewest? Boom.

On Sat, Nov 22, 2014 at 7:06 PM, John D. Ament john.d.am...@gmail.com
wrote:

 I always assumed that it was based on the month the podling joins.  Since
 there are 3 reporting groups, the decision on who to report is on the mod
 of the current month number against 3, so I figured M % 3 = reporting
 group, except 3 replaces 0.

 But that's only my guess as none of the guides describe how to choose it.
 But this makes it so that the podling has to present 4 straight reports
 after entering incubation.

 John

 On Sat, Nov 22, 2014 at 7:54 PM, Alan D. Cabrera l...@toolazydogs.com
 wrote:

  How do reporting groups get assigned to podlings?
 
 
  Regards,
  Alan
 
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 

Re: Committer Voting and Vetos

[Greg Stein]

On Fri, Sep 26, 2014 at 10:21 AM, Noah Slater nsla...@apache.org wrote:
...

 Specifically, we (CouchDB) see voting as the failure mode of a
 discussion (a useful one non-the-less), or as a last-step requirement
 to officiate a particular set of project-level decisions (that are
 fully enumerated in the bylaws).


I very much agree with this sentiment, as does the Apache Subversion
project. In the project's 14 year history, we have held (maybe) about FOUR
actual votes. EVER. And I'm talking both technical and community-issue
votes. I'm really kind of guessing here. I can recall only two, but there
must have been a few others. If a community cannot reach consensus, and
needs a vote instead, then something is wrong (IMO).

To the concrete question, the Subversion project never calls a strict
[VOTE] for new committers or PMC members. We discuss first, and that sets
the direction. People throw out +1 messages, but that is sure, make it so
rather than a true vote. Whenever somebody says wait a minute, then we
do. We don't have formal rules around this stuff, since a general goal of
consensus is so ingrained into the community.

Cheers,
-g

Re: Committer Voting and Vetos

[Greg Stein]

On Tue, Sep 30, 2014 at 10:28 AM, Ted Dunning ted.dunn...@gmail.com wrote:

 On Tue, Sep 30, 2014 at 3:46 AM, Greg Stein gst...@gmail.com wrote:

  To the concrete question, the Subversion project never calls a strict
  [VOTE] for new committers or PMC members. We discuss first, and that sets
  the direction. People throw out +1 messages, but that is sure, make it
 so
  rather than a true vote. Whenever somebody says wait a minute, then we
  do. We don't have formal rules around this stuff, since a general goal of
  consensus is so ingrained into the community.
 

 The nice thing about the vote is that there is a [RESULT] message to link
 to.  What does the Subversion project link to in the account request?


We don't provide a link. There is no reason for Infrastructure to
second-guess account requests from Officers or ASF Members, so that link is
optional. *Should* a question ever arise, then it is easy enough to provide
background information.

Cheers,
-g