Re: Lack of releases with Droids

[ant elder]

On Mon, Aug 18, 2014 at 9:40 PM, Marvin Humphrey  wrote:
> On Mon, Aug 18, 2014 at 12:42 PM, Richard Frovarp  wrote:
>
>> A lot of wind was taken out of the sails in the fights to get the IPMC votes
>> necessary to finish a release. We had two votes, but needed to request
>> several times for help getting that third vote. For those that did help us
>> out, thank you. However, the whole process wasn't fun or easy. With most
>> every other PMC, you're going to have enough interested parties to chip in
>> and help get that release out, without asking for votes for well over a
>> week.
>
> The release process reforms adopted in December 2013 greatly mitigate
> this problem. (All Droids releases pre-date the reforms.)
>
>   http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
>
> These days, I think we should have little sympathy for podlings who
> choose to wait passively for IPMC votes rather than seize the
> initiative.

Heh, well i at least still have sympathy for podlings struggling to
getting binding votes. The alternative release process hardly seems
like the holy grail to me and i still hope for something better one
day.

   ...ant

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

Re: [DISCUSS] Incubator exit criteria

[ant elder]

On Tue, Aug 12, 2014 at 8:08 AM, Roman Shaposhnik  wrote:

> On Mon, Aug 11, 2014 at 1:14 AM, Bertrand Delacretaz
>  wrote:
> > On Mon, Aug 11, 2014 at 2:22 AM, Roman Shaposhnik 
> wrote:
> >> ...Including the patch below...
> >
> > Sorry to come in late but I had a look at [1] and it's way too
> > complicated IMO, and I don't think the proposed patch helps with that.
> >
> > In general http://incubator.apache.org/ is way too verbose and hard to
> > maintain - removing everything that is not essential would help IMO.
> >
> > With this in mind, I would remove almost everything from the "What is
> > retirement" section and keep just
> >
> > 
> > A retired project is a project which has been closed down for various
> > reasons, instead of graduating as an Apache project. It is no longer
> > developed in the Apache Incubator and does not have any other duties.
> >
> > The project's code might stay available on Apache servers, if all the
> > required IP clearance requirements have been met.
> >
> > Retirement is a decision of the Incubator PMC, which usually delegates
> > it to the incubating project's mentors. The opinion of the incubating
> > project's community should of course be taken into account, but in the
> > end it's the Incubator PMC which makes the decision.
> > 
> >
> > And also keep the "steps to retirement" section.
>
> I totally agree with the section being overly complex to parse. I am,
> however,
> a little bit afraid of such a drastic edit ;-) Two points on that:
>* since I haven't seen much of complaining, can I please commit my
>  proposed stuff and then we can pile additional edits on top of that?
>* re-reading those sections made me realize that we are making a
>  distinction between two types of non-graduation: termination and
>  retirement. The way I read it, with termination there's no code left.
>  With retirement code is still available. Am I correct?
>
>
I also feel this is adding unnecessary complexity and would prefer the
edits simplify rather than add more things. If you're really insisting on
adding some of this text would you at least not add the following bit for
now:

" At this point the project is expected
to be put on a monthly reporting schedule and the next month's report
is expected to articulate the steps and expected time frame to get to
the release. In case of a clear lack of progress for straight three
months the [VOTE] thread on potential retirement is expected to be
started in IPMC."

   ...ant

Re: [DISCUSS] Incubator exit criteria

[ant elder]

On Wed, Jul 16, 2014 at 5:16 AM, Roman Shaposhnik 
wrote:

> On Sat, Jul 12, 2014 at 4:15 AM, Christian Grobmeier
>  wrote:
> > On 12 Jul 2014, at 8:05, Roman Shaposhnik wrote:
> >> That's actually the part of the thread that I have a lot of interest in.
> >> Is there any reason not to use attic for hibernated podlings?
> >
> > I am not sure if there is a real reason, but maybe its because the attic
> > currently contains only "real" ASF projects where all legal things were
> > sorted out.
> >
> > With a podling coming in this might not be the case. We would need to
> > check back with the Attic people if they can handle this.
> >
> > Otherwise I don't see a reason why we shouldn't use the attic, imho
> > its the reason why its there.
>
> Quick question: who's in charge of saying 'yay' or 'nay' to Incubator
> projects coming to the Attic?
>
> > Roman, would you mind to create an update patch and send it around
> > here for some kind of discussing/voting? Then we would see how people
> feel.
> > I think this thread is already to big to get the right attention.
>
> Will do shortly. Btw, I presume you're talking about the patch
> to the Incubator web pages documenting the policy, right?
>
> At least that's what I'm going to patch and send for a VOTE
>
>
>
What happpened to you agreeing to try it with a few of the old podlings
first?

   ...ant

Re: [DISCUSS] Incubator exit criteria

[ant elder]

This is quite a long thread now so its not that clear what the actual
proposal is now, could you maybe state what the current proposal is?

I think its something like "If a podling is over a year old and not
done a release then retire it". As i've said i don't think thats a
very good rule and doesn't seem like its really been thought through
properly. For example, its kept saying that the podling would go to
the ASF Attic but the Attic is only for TLPs so retired podlings don't
go there.

How about before adding a new rule to the policy page we just try it
with a few of the old podlings first to see what happens and from that
find what sort of rule might work?

   ...ant

On Wed, Jul 9, 2014 at 8:23 AM, Roman Shaposhnik  wrote:
> On Tue, Jul 1, 2014 at 11:01 PM, ant elder  wrote:
>> Right, and thats why i don't think a rule like that would be useful.
>
> I still don't quite follow. Are you saying that the rule wouldn't
> be useful, or that incubator -> attic migration wouldn't be?
>
>> If Droids was made to retire the code would be frozen in the attic or
>> forced out to github,
>
> That would be true. But what's the harm in that? The code
> still exists and can be checked out. What we're essentially
> signaling to the outside world is that ASF can no longer
> vouch for the viability of the community around it. Isn't it
> the truth of the matter?
>
>> forced to change its package name
>
> I don't really see any reason to do that for code
> that got moved to that attic. Am I missing something?
>
>> in the code and so probably lose existing users,
>
> Again, why would code lose users? Remember we're talking
> about a situation of no releases here. Presumably those
> users who are comfortable building from the repo would
> just keep doing so. And since there was no release,
> what else is out there for us to worry about?
>
>> and remove all references to apache in  the
>> project and doc and website etc etc. All tons of work which being a small
>> project they'd probably never get done so it would likely be the death of
>> the project.
>
> I see no reason to do any of that for the project that's
> in the attic.
>
>> And for what purpose? To quote one of them from their dev list a couple of
>> months ago: "Going to the attic would suck. It's a solid code base, it's
>> just one of those things that doesn't necessarily need to change much.".
>> The main people in Droids we know and trust, they are ASF members and PMC
>> chairs. We in the Incubator should be helping them graduate not looking for
>> ways to retire the project.
>
> The quote feels a little bit misinformed about the attic/ASF
> policies.
>
> 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

Re: [DISCUSS] Incubator exit criteria

[ant elder]

On Wed, Jul 2, 2014 at 3:35 AM, Joe Brockmeier  wrote:

> On Tue, Jul 1, 2014, at 04:23 AM, ant elder wrote:
> > On Tue, Jul 1, 2014 at 4:46 AM, Roman Shaposhnik  wrote:
> >
> > > Hi!
> > >
> > > Sorry for a belated reply -- at first I was following Doug's rule
> > > and then I got distracted ;-)
> > >
> > > That said -- I really would like to drive us to some kind
> > > consensus (even if we have to do the vote) because
> > > the current situation is simply sad (top 8 project):
> > >https://whimsy.apache.org/incubator/podlings/by-age
> > >
> > >
> > I had a quick look at a few of the top 8 podlings in that link.
> >
> > Droids should be helped to graduate not to retire, VXQuery is currently
> > voting to graduate, ODF toolkit should graduate (IMHO), S4 has just voted
> > to retire.
>
> Are you saying Droids is ready to graduate, or...?
>
> Looking at its mailing lists and last report, I'm not seeing many signs
> of activity. Why is it a target for graduation rather than retirement?
> Is there activity that I'm missing? Last release was in August 2012, at
> least according to its Web site. (0.2-incubating)
>
> Under the proposed rules, Droids would be a candidate for retirement,
> not graduation, unless I'm missing something.
>
>
>
Right, and thats why i don't think a rule like that would be useful.

If Droids was made to retire the code would be frozen in the attic or
forced out to github, forced to change its package name in the code and so
probably lose existing users, and remove all references to apache in  the
project and doc and website etc etc. All tons of work which being a small
project they'd probably never get done so it would likely be the death of
the project.

And for what purpose? To quote one of them from their dev list a couple of
months ago: "Going to the attic would suck. It's a solid code base, it's
just one of those things that doesn't necessarily need to change much.".
The main people in Droids we know and trust, they are ASF members and PMC
chairs. We in the Incubator should be helping them graduate not looking for
ways to retire the project.

   ...ant

Re: [DISCUSS] Incubator exit criteria

[ant elder]

On Tue, Jul 1, 2014 at 4:46 AM, Roman Shaposhnik  wrote:

> Hi!
>
> Sorry for a belated reply -- at first I was following Doug's rule
> and then I got distracted ;-)
>
> That said -- I really would like to drive us to some kind
> consensus (even if we have to do the vote) because
> the current situation is simply sad (top 8 project):
>https://whimsy.apache.org/incubator/podlings/by-age
>
>
I had a quick look at a few of the top 8 podlings in that link.

Droids should be helped to graduate not to retire, VXQuery is currently
voting to graduate, ODF toolkit should graduate (IMHO), S4 has just voted
to retire.

So from that i'm not really seeing the need for a new rule about retiring
podlings. I'm not sure where the current retirement policy is documented,
there best i can find is this email from Ross which i really like, its on
the private list (i thought that was going to be put up on the wiki, did
that ever happen?): http://s.apache.org/ZHh

   ...ant

Re: [DISCUSS] Incubator exit criteria

[ant elder]

On Wed, Jun 25, 2014 at 9:04 AM, Christian Grobmeier 
wrote:

> On 24 Jun 2014, at 21:27, Rob Weir wrote:
>
> > On Tue, Jun 24, 2014 at 9:57 AM, Upayavira  wrote:
> >>
> >>
> >> On Tue, Jun 24, 2014, at 12:02 PM, Christian Grobmeier wrote:
> >>> On 24 Jun 2014, at 7:24, Roman Shaposhnik wrote:
> >>> That said, reminding people of the "release often and early" thing is
> >>> good to do,
> >>> but also have in mind that incubator releases are very difficult to
> >>> make.
> >>
> >> Unlike Christian (another Wave mentor :-) ), I am generally in support
> >> of this proposal. If a project cannot get a release out, then it
> >> suggests insufficient weight behind it. Releasing software is what the
> >> ASF is about. It is acceptable that a mature ASF project, one that is
> >> code-complete, doesn't release regularly, but an incubator project would
> >> not fall into that camp, therefore being able to say "we can muster the
> >> resources to make a 'legally valid release' within a year seems
> >> eminently reasonable to me.
> >>
> >
> > https://blogs.apache.org/OOo/entry/an_apache_openoffice_timeline
> >
> > In total, from entering incubation to first release was 11 months and
> > a week.  So this confirms that a year, for most projects should be
> > sufficient.  But there could be exceptions, due to factors similar to
> > those I listed above.  But such exceptions should be rare.
>
> Indeed the OOo was an impressive amount of work.
>
> Reading comments from Upayavira and Rob, I am willing to support
> the "relaxed" proposal of Roman. I would prefer mine, but
> we can always do modifications as we see fit.
>
> As it seems i was the only sceptic, we can try to formulate a patch
> for our policies.
>
>
>
You aren't the only sceptic, i'm not enthusiastic about having such
specific policy about release time frames either. Some projects are just
slow, having a deadline like that could just make them get a release out of
low quality without much care just to tick the box.

Looking at clutch these are the current podlings and age which are older
than a year and have no release:

Aurora 267
BatchEE 265
DeviceMap 904
Kalumet 1009
Ripple 617
Samza 330
Streams 582
Usergrid 265
Wave 1299

Maybe their mentors should just go have a conversation with them about it?

   ...ant

Re: When to sign-off on Incubator reports?

[ant elder]

On Tue, Apr 8, 2014 at 12:29 PM, Upayavira  wrote:

> FWIW as far as I am concerned, you can 'conditionally' sign off on a
> report, that is, with comments, if there's things you need to say.
>
> Upayavira
>

+1 to that. And its still over a week till the baord meeting and lots of
mentors active in Stratos so its not like there are surprises.

   ...ant

Re: [VOTE] Release of Apache Olingo 1.1.0 incubating (RC03)

[ant elder]

Also, why doesn't Olingo go for graduation? I had a little look around the
project and don't see anything holding it up.

   ...ant


On Mon, Feb 10, 2014 at 9:35 AM, ant elder  wrote:

> +1
>
> Looks ok to me
>
>...ant
>
>
> On Mon, Feb 10, 2014 at 8:52 AM, Klevenz, Stephan  > wrote:
>
>> No progress on Olingo's release vote. Still one binding vote is missing.
>> What else can we do to get it done?
>>
>> Regards,
>> Stephan
>>
>> On 06.02.14 23:01, "Marvin Humphrey"  wrote:
>>
>> >On Thu, Feb 6, 2014 at 7:43 AM, Amend, Christian <
>> christian.am...@sap.com>
>> >wrote:
>> >> Hi IPMC members,
>> >>
>> >> Olingo is waiting to get a third vote for our current release
>> >>candidate. We
>> >> would really appreciate if someone could have a look at this.
>> >
>> >Is it time to enroll Olingo as in our release voting experiment?  Or if
>> >anyone
>> >is opposed, how about some votes?
>> >
>> >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: [VOTE] Release of Apache Olingo 1.1.0 incubating (RC03)

[ant elder]

+1

Looks ok to me

   ...ant


On Mon, Feb 10, 2014 at 8:52 AM, Klevenz, Stephan
wrote:

> No progress on Olingo's release vote. Still one binding vote is missing.
> What else can we do to get it done?
>
> Regards,
> Stephan
>
> On 06.02.14 23:01, "Marvin Humphrey"  wrote:
>
> >On Thu, Feb 6, 2014 at 7:43 AM, Amend, Christian  >
> >wrote:
> >> Hi IPMC members,
> >>
> >> Olingo is waiting to get a third vote for our current release
> >>candidate. We
> >> would really appreciate if someone could have a look at this.
> >
> >Is it time to enroll Olingo as in our release voting experiment?  Or if
> >anyone
> >is opposed, how about some votes?
> >
> >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: [VOTE] Enable Release Checklist Experiment

[ant elder]

Obviously +1 from me on doing experiments, and -1 for the silly policy
update stuff.

   ...ant


On Fri, Dec 13, 2013 at 8:59 PM, Marvin Humphrey wrote:

> Greetings,
>
> As the next step in our ongoing efforts to reform the release voting
> process,
> I propose that we run an experiment allowing the PPMC members of select
> podlings to earn binding votes under limited circumstances by completing a
> release checklist.
>
> For participating podlings, the Incubator's release management guide...
>
> http://incubator.apache.org/guides/releasemanagement.html
>
> ... would be supplanted by the following documents:
>
> http://incubator.apache.org/guides/release_manifest.txt
> http://incubator.apache.org/guides/release.html
>
> The scope of this VOTE is limited to approving the following patch to our
> policy page:
>
> https://paste.apache.org/k4vJ
>
> Here is the patch content minus markup:
>
> 2013 Alternate Release Voting Process
>
> Select podlings pre-cleared by a majority vote of the IPMC MAY
> participate in
> an alternate release voting process:
>
> Should a Podling decide it wishes to perform a release, the Podling
> SHALL
> hold a vote on the Podling's dev list and create a permanently archived
> Release Manifest as described in the Experimental Release Guide.  At
> least
> three +1 votes from PPMC members are required (see the Apache Voting
> Process page).  If the majority of PPMC votes is positive, then the
> Podling
> SHALL send a summary of that vote to the Incubator's general list and
> formally request the Incubator PMC approve such a release.
>
> Formal approval requires three binding +1 votes and more positive than
> negative votes.  Votes cast by members of the Incubator PMC are always
> binding.  For all releases after the first, votes cast by members
> of the PPMC
> are binding if a Mentor approves the Release Manifest.
>
> Please note that the proposed change is both incremental and reversible:
>
> *   It is incremental because podlings must be opted in by vote of the
> IPMC to
> participate.
> *   It is reversible because once the experiment has run its course the
> policy change can be reverted with zero impact through lazy consensus.
>
> Those who may have questions about the legitimacy of allowing binding votes
> from non-IPMC members should see this post from Roy Fielding:
>
> http://s.apache.org/v7
>
> Please vote:
>
> [ ] +1 Yes, apply the patch enabling the experiment.
> [ ] -1 No, do not apply the patch enabling the experiment.
>
> This majority VOTE will run for 7 days and will close at 13:00 PST on
> Friday,
> December 20, 2013.  Votes cast by members of the Incubator PMC are binding.
>
> Here is my own +1.
>
> Marvin Humphrey
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Release Verification Checklist

[ant elder]

The N word wasn't particularly helpful or constructive, sorry. I do think
the policy page should be kept simple and generic though, so isn't the
place to be describing this experiment.

   ...ant


On Fri, Dec 13, 2013 at 3:39 PM, ant elder  wrote:

> Well sorry but IMHO thats nonsense. The Maven decision was an isolated
> incident and didn't change the way all future Incubator policy should
> get decided. Insisting that this experiment is done via a change to
> the main policy just makes it contentious when it doesn't need to be.
> All the complexity in the language and approach, the three votes etc
> is exactly why people get the idea that the ASF is a ridiculous place
> with overbearing rules and process. Its just an experiment, use lazy
> majority consensus and go try it with a podling.
>
>...ant
>
> On Fri, Dec 13, 2013 at 3:27 PM, Marvin Humphrey 
> wrote:
> > On Fri, Dec 13, 2013 at 12:18 AM, ant elder  wrote:
> >> I'm also opposed to updating the policy document, so will be voting
> against
> >> this just for that.  Its just an experiment so you don't need to be
> making a
> >> permanent change to the policy page to try it, especially as its such a
> >> clunky convoluted change.
> >
> > An explicit policy change is required because otherwise there would be
> > ambiguity as to whether a release which passes under the modified regime
> is an
> > act of the Foundation and confers indemnity on the Release Manager.
> >
> > The language of the proposed change to the Policy page has been carefully
> > composed.  It is highly isolated from the rest of our policy and has no
> force
> > except on the the experiment.
> >
> > This proposal is structured as an incremental, reversible change.  It is
> > incremental because podlings must be opted in by vote of the IPMC to
> > participate.  It is reversible because once the experiment has run its
> course
> > the relevant section of the policy page can be removed with zero impact
> > through lazy consensus.
> >
> >> (And responding to another related comment in the thread - since when
> have
> >> policy updates not required consensus?)
> >
> > The 2008 proposal to allow distribution through Maven was enacted after a
> > contentious majority-rule vote passed 15 to 12.
> >
> > Marvin Humphrey
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>

Re: Release Verification Checklist

[ant elder]

Well sorry but IMHO thats nonsense. The Maven decision was an isolated
incident and didn't change the way all future Incubator policy should
get decided. Insisting that this experiment is done via a change to
the main policy just makes it contentious when it doesn't need to be.
All the complexity in the language and approach, the three votes etc
is exactly why people get the idea that the ASF is a ridiculous place
with overbearing rules and process. Its just an experiment, use lazy
majority consensus and go try it with a podling.

   ...ant

On Fri, Dec 13, 2013 at 3:27 PM, Marvin Humphrey  wrote:
> On Fri, Dec 13, 2013 at 12:18 AM, ant elder  wrote:
>> I'm also opposed to updating the policy document, so will be voting against
>> this just for that.  Its just an experiment so you don't need to be making a
>> permanent change to the policy page to try it, especially as its such a
>> clunky convoluted change.
>
> An explicit policy change is required because otherwise there would be
> ambiguity as to whether a release which passes under the modified regime is an
> act of the Foundation and confers indemnity on the Release Manager.
>
> The language of the proposed change to the Policy page has been carefully
> composed.  It is highly isolated from the rest of our policy and has no force
> except on the the experiment.
>
> This proposal is structured as an incremental, reversible change.  It is
> incremental because podlings must be opted in by vote of the IPMC to
> participate.  It is reversible because once the experiment has run its course
> the relevant section of the policy page can be removed with zero impact
> through lazy consensus.
>
>> (And responding to another related comment in the thread - since when have
>> policy updates not required consensus?)
>
> The 2008 proposal to allow distribution through Maven was enacted after a
> contentious majority-rule vote passed 15 to 12.
>
> 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: Release Verification Checklist

[ant elder]

On Fri, Dec 13, 2013 at 7:54 AM, Marvin Humphrey wrote:

> On Thu, Dec 12, 2013 at 8:56 PM, Dave Fisher 
> wrote:
>



> So...
>
> *   Ant likes the voting rule change, but is opposed to the checklist.
>

I'm also opposed to updating the policy document, so will be voting against
this just for that. Its just an experiment so you don't need to be making a
permanent change to the policy page to try it, especially as its such a
clunky convoluted change.

(And responding to another related comment in the thread - since when have
policy updates not required consensus?)

   ...ant

Re: IP Clearance before releasing

[ant elder]

On Thu, Dec 12, 2013 at 5:51 AM, Marvin Humphrey wrote:

 For a release tagged with the "incubating"
> label and disclaimer, filing bugs rather than blocking seems reasonable.
>
>
I may have edited away more than you like but yes - "filing bugs rather
than blocking" is the approach we should try using more, much more. All
that stuff about putting the foundation at risk seems vastly over stated -
are there any examples at all ever where the foundation has come to any
harm from a duff release? The release voting is to make the release a
collective action of the foundation to protect individuals not to protect
the foundation.

I'm curious what others think.  There's room for us to disagree, since
> release
> votes do not require consensus...
>
>
Podling release voting is one of the most problematic areas of the
Incubator and has been for years. Its the disagreement over whats required
that tosses podlings about with one person saying they must do one thing
and others something else, and it puts off mentors from voting in case
they're made to look like they don't know what they're doing. So I think we
should try to find some consensus on approach rather than agreeing to
disagree,

   ...ant

Re: IP Clearance before releasing

[ant elder]

On Tue, Dec 10, 2013 at 11:30 AM, Benson Margulies
 wrote:

>  If we deleted every
> release from the main Foundation distro area that had some divergence
> from some policy, no matter how tiny, my suspicion is that the distro
> area would become rather sparse.
>

Yes quite. And lets not forget how the "rules" keep changing eg not so
long ago people were insisting that all sorts of stuff absolutely must
be put in the NOTICE file where as now it absolutely must NOT be
there, who know what it will be like next year.

And the Incubator _is_ different and does have different policy and
rules, hence on occasion podlings being permitted to do releases which
include GPL dependencies while Incubating and just fixing those up as
a graduation requirement.

   ...ant

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

Re: Release Verification Checklist

[ant elder]

On Tue, Dec 10, 2013 at 5:45 AM, Marvin Humphrey  wrote:
> On Mon, Dec 9, 2013 at 2:34 AM, ant elder  wrote:
>> I know you're passionate about this Marvin but as it stands I'll be
>> voting against this proposal.
>
> I plan to propose this as an experiment

Well ok, earlier you said you'd planed it as a change to the Incubator
policy page but if its just an experiment then fine by me, i've
already said in the experiment discussions that i'd support anyone
doing some experiments.

>
>> 1) This proposal doesn't help podlings with the first release
>
> It helps by clarifying what we expect from podlings.  We're effectively
> replacing that absurd monstrosity, the Incubator's Release Management Guide...
>
> http://incubator.apache.org/guides/releasemanagement.html
>
> ... with a one page checklist:
>
> http://incubator.apache.org/guides/release_manifest.txt
>
> The first release will be easier because podlings will spend less time
> thrashing through docs trying to discover what is required.  Compliance isn't
> that much work in the grand scheme of things -- the big problem has been that
> the Incubator couldn't tell you the spec.
>
>> 3) The proposal adds new artificial process around doing a release
>> when we should be teaching podlings how TLPs do things
>
> I think podlings which have their act together ought to have the option of
> filling in a checklist rather than being forced to wait weeks hoping some
> random IPMC member wanders by.
>
>> Incubator releases are not official ASF releases so there is not and should
>> not be the same expectations around them.
>
> A lot of people seem to think this, but it's not true.  Incubator releases are
> official ASF releases.
>
>> If we could find a way to have Incubator PMC members accept a lower
>> bar for doing podling releases it would make a massive improvement to
>> everyones experience of the Incubator.
>
> We shouldn't be sticklers for inconsequential minutiae, but since the
> Incubator is a TLP like any other and its releases are subject to
> Foundation-wide policy, I don't believe we have much freedom to accept a lower
> bar.  Your request is impossible.
>

That doesn't seem to be true from past evidence. I could trawl back
through the archives and pull out numerous instances of podling
releases with known flaws being approved by the Incubator PMC, ASF
directors, and in some instances with the blessing of the ASF board.
Even the Incubator policy document says "No release made by a Podling
will be endorsed by the ASF. Unendorsed releases may be made by
Podlings ..."

The main purpose of the voting is to protect the folks who make
release decisions. So long as they're not just wildly throwing about
+1 votes with no thought then the ASF will be fine with having some
wiggle room on release quality for Incubating projects. We could go
ask the board for clarification, but not so long ago Roy told us:

"The Incubator is that PMC.  Make a decision and run with it. If it
doesn't work out, try another decision and run with that. The only
time the board should step in (with a hammer) is when no decisions are
being made."

Isn't that enough to at least try some experiments with easier releases?

   ...ant

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

Re: Release Verification Checklist

[ant elder]

On Mon, Dec 9, 2013 at 11:04 AM, Bertrand Delacretaz
 wrote:
> Hi,
>
> On Mon, Dec 9, 2013 at 11:34 AM, ant elder  wrote:
>> ...2) Podlings should normally graduate after the first release  (and we
>> should more proactively do that) not stay to do more...
>
> I wouldn't set this as a goal. It's nice when it happens, but as you
> say the goal is for a podling to be generally healthy and to have
> understood the Apache invariants before graduating. It's not the
> number of releases.
>

Yes sometimes podlings may need to stay longer, but think about it -
if a podling does all thats required including the first release, and
then graduates, from then on they get binding votes on everything
including their releases. If something means they can't graduate yet
why does that mean they shouldn't get binding votes on subsequent
releases? Surely that should only happen if they are staying because
their first release was a disaster. The other reasons to keep them
here are separate from the competence at doing releases so saying they
don't get the binding votes on subsequent releases is just punishment
that they haven't yet resolved the unrelated issue.



>> ...If we could find a way to have Incubator PMC members accept a lower
>> bar for doing podling releases it would make a massive improvement to
>> everyones experience of the Incubator
>
> Define "lower bar". Do you see any of the review items
> http://incubator.apache.org/guides/release_manifest.txt as optional?
>

Probably all of those could be optional or fixed next time. I've done
releases with invalid signatures in the past and there is some
automated thing in the ASF distribution area that sends you an email
about it and you just have to resign the artifact. If the podling
choose to do a release knowing some tests fail thats up to them, i can
think of a number of releases happened here missing the DISCLAIMER
file and they were told just fix it next time, etc for the rest of the
items on the list. We've even had Incubator releases including GPL
dependencies in the past. The point is i think that podlings learn
about the requirements but that doesn't mean we must block releases or
make people jump through hoops to do that learning.

   ...ant

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

Re: Release Verification Checklist

[ant elder]

I know you're passionate about this Marvin but as it stands I'll be
voting against this proposal.

1) This proposal doesn't help podlings with the first release
2) Podlings should normally graduate after the first release  (and we
should more proactively do that) not stay to do more
3) The proposal adds new artificial process around doing a release
when we should be teaching podlings how TLPs do things

IMHO the Incubator has lost the plot with this focus on release
artifacts, we should instead focus on teaching podlings about how to
build strong communities around their project.  It is not the primary
objective for the Incubator to protect the ASF from a rogue podling
release. Many many releases have been done in the ASF that have gone
out with problems but I have never heard of the ASF getting in to any
trouble from them, ever. Where as, many Incubator podlings and the
public perception of the ASF have been damaged by the problems around
doing an Incubator release. Incubator releases are not official ASF
releases so there is not and should not be the same expectations
around them.

If we could find a way to have Incubator PMC members accept a lower
bar for doing podling releases it would make a massive improvement to
everyones experience of the Incubator.

   ...ant


On Mon, Dec 9, 2013 at 4:49 AM, Marvin Humphrey  wrote:
> On Fri, Dec 6, 2013 at 1:55 AM, ant elder  wrote:
>
>> All the stuff required to be checked when voting on a release should be
>> documented in the ASF doc about releases. That its not in that doc suggests
>> its not required. If someone thinks something is required then they should
>> go get consensus around that with the wider ASF and get the ASF doc updated.
>
> OK, I've done the research and I've migrated the manifest proposal to a new
> documentation page with the links.  The ReleaseChecklist wiki page is now a
> home for optional checklist items.
>
> http://incubator.apache.org/guides/release.html
> https://wiki.apache.org/incubator/ReleaseChecklist
>
> Applying your criteria to the current checklist has resulted in the
> migration of two items to the optional list:
>
> *   Each expanded source archive matches the corresponding SCM tag.
>
> It turns out the only place matching the SCM tag was documented is the
> Incubator's Release Management guide.  Here's Leo Simons making the case
> against: <http://markmail.org/message/2ncepopzgnshtyd6>.
>
> *   Build instructions are provided, unless obvious
>
> I haven't found any documentation that this is required anywhere on
> www.apache.org/dev or www.apache.org/legal.  Bertrand, between me arguing
> that this won't come into play often enough and Ant and Olivier arguing
> that we should only include blockers documented elsewhere, I've made the
> judgment call that this should be moved to the optional list as well.
> Please let us know if you object.
>
>> Podling releases are not quite the same as TLP releases, thats why they
>> have the DISCLAIMER and "incubating" naming. I think we should be making it
>> easier for podlings to do releases, if its really necessary then make an
>> audit of the last release a requirement of graduation.
>
> I am passionately committed to making it easier for podlings to release, by
> granting limited self-governance to those who earn it.
>
> The proposal under consideration is a win for *both* streamlining the release
> voting process and improving release oversight.
>
> 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: Release Verification Checklist

[ant elder]

On Fri, Dec 6, 2013 at 1:40 AM, Marvin Humphrey wrote:

> On Thu, Dec 5, 2013 at 8:38 AM, sebb  wrote:
> > On 5 December 2013 10:37, Bertrand Delacretaz 
> wrote:
> >> On Tue, Dec 3, 2013 at 11:39 PM, Marvin Humphrey <
> mar...@rectangular.com> wrote:
>
> >>> ... Second, I'm amused that the "commits list" item was quietly
> dropped,
> >>> but new checklist items have been inserted regarding the dev and
> private
> >>> lists...
> >>
> >> Pure oversight on my part, sorry...but what would we do if no reviewer
> >> follows the commit lists? I don't think that's a reason to kill a
> release.
> >
> > Oversight of the commit list is vital; that is how we ensure that SCM
> > only contains material that is permitted.
> >
> > The source release is then checked against SCM to ensure we are only
> > published vetted material.
> >
> > If there is no review of the commit list, then the whole system breaks
> down.
>
> I certainly agree that following the commits list is essential (and sought
> to
> emphasize as much in the post at the top of the thread).  I'd barely even
> considered the possibility that *none* of the reviewers might be following
> the commits list.
>
> However, I think that Bertrand's "provenance" checklist item largely
> achieves
> what I'd been grasping for with the "commits list" item, and fits much
> better
> into the context of approving the release.  If nobody's following the
> commits
> list, that's an issue with serious implications for the project, but it's
> not
> a direct release blocker.  If provenance is unsettled, though, that clearly
> blocks the release.
>
> Personally, I wouldn't feel confident checking the "provenance" item if I
> wasn't watching the commits list.  It's true that the person making the
> commit
> affirms that they have the right to their contribution, but still, I feel
> like
> you need to at least be aware of what contributions have gone into the
> product.
>
> Maybe there ought to be a note to such effect on the explanations page.
>  But
> in any case, I'm OK with the "commits list" item disappearing, so long as
> the
> "provenance" item stays.
>
> As of revision 14 (removing the "dev list" and "private list" items) I'm
> now
> generally satisfied with the content of the checklist items and hope to
> move
> on to refining the workflow and surrounding documentation.
>
>
>
All the stuff required to be checked when voting on a release should be
documented in the ASF doc about releases. That its not in that doc suggests
its not required. If someone thinks something is required then they should
go get consensus around that with the wider ASF and get the ASF doc updated.

Podling releases are not quite the same as TLP releases, thats why they
have the DISCLAIMER and "incubating" naming. I think we should be making it
easier for podlings to do releases, if its really necessary then make an
audit of the last release a requirement of graduation.

   ...ant

Re: Release Verification Checklist

[ant elder]

Just fyi so I'm not accused of not saying anything - I'm not totally sure
what the intention is for this and I'm all for doing some experiments and
wouldn't get in the way if this is to be tried with a podling, however this
looks like its becoming a fairly complex and arduous process to me.

   ...ant

Re: Release vote thresholds

[ant elder]

Do these sort of experiments really need consensus? The Incubator PMC
is so big and diverse now it makes getting consensus on some things
all most impossible, after the change a little while back we don't
even need consensus for voting in new Incubator PMC members now.

   ...ant

On Sat, Nov 23, 2013 at 12:45 AM, Marvin Humphrey
 wrote:
> On Fri, Nov 22, 2013 at 4:20 PM, Dave Fisher  wrote:
>
>> I am not sure that this is a step in the correct direction.
>
> Dave, I'm sure you realize that your opposition is deeply disapointing to a
> number of us, when we seem so close.
>
> I will work with you to see if we can build what you are currently calling the
> "Incubator Committer" solution into something which can achieve consensus.
> It is not necessarily going to be easy to get that proposal as close as this
> one has come, but let's try.
>
> 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: [PROPOSAL] Experiment: VXQuery PPMC Release Voting

[ant elder]

I'm in favour of trying this. And its just experiment remember so not
a change for ever for all podlings so please people try to support it
or at least not try to block it.

   ...ant

On Fri, Nov 22, 2013 at 6:15 PM, Marvin Humphrey  wrote:
> The possibility of an experiment with making PPMC votes binding on incubating
> releases under some conditions has been discussed at length in recent threads
> on general@incubator.  I propose that we vote on the following language to run
> the experiment with VXQuery as a test podling:
>
> The following additional rules for voting on incubating releases shall
> apply to the VXQuery PPMC, whose membership is tracked on the VXQuery
> podling status page at
> .
>
> *   PPMC votes are binding for every release except the first.
> *   One IPMC vote is required for each release after the first.
>
> Note that VXQuery has already had its first incubating release approved by
> vote of the IPMC.
>
> It is my view that the position taken by ASF Board member Roy Fielding in a
> recent message to general@incubator[1] indicates that the Incubator PMC has
> the necessary authority to enact this proposal.
>
> Marvin Humphrey
>
> [1] http://s.apache.org/yPX
>
> -
> 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: Release vote thresholds

[ant elder]

On Thu, Nov 21, 2013 at 6:09 PM, Marvin Humphrey  wrote:
> On Thu, Nov 21, 2013 at 12:33 AM, ant elder  wrote:
>> On Thu, Nov 21, 2013 at 1:53 AM, Marvin Humphrey 
>> wrote:
>> I think this is getting too hung up on vetting releases is the be all and
>> end all of PMC membership when really there are other just as if not more
>> important things.
>
> Let's say we strike that bullet point from the proposal.  It seems like we're
> making good progress, because that moves us closer to *both* you and Dave
> Fisher.  The remaining question is whether we can arrive at an agreement in
> terms of how many IPMC votes it takes to get a release approved.
>
> Ant, you proposed a minimum of one IPMC vote for each release:
>
> http://s.apache.org/CHS
>
> How about simply changing the rules for Incubator releases so that they
> don't require at least three binding votes, but instead make it at least
> three votes only one of which must be binding. That would mean there would
> still be the element of oversight that a mentor vote gives but avoids all
> the problems with not having three mentors.
>
> Dave responded with this critique:
>
> http://s.apache.org/MSZ
>
> I don't think this is prudent, having only one binding vote is too low a
> check. We at the ASF have a responsibility to the public.  I want to be
> certain that no one steam rolls the process. Just the fact that there are
> edge cases means we need to be careful.
>
> This formulation was conceived to address both of your concerns:
>
> *   PPMC votes are binding for every release except the first.
> *   One IPMC vote is required for each release after the first.
>
> Ant, can you accept the elevated requirement for the first vote?  If we only
> have to muster that many IPMC members once per podling, I think it's much more
> doable.
>

Sure, its a step in the right direction. I do think we could still do
more but that would be a good start.

   ...ant

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

Re: Populating the initial PPMC

[ant elder]

On Thu, Nov 21, 2013 at 1:53 AM, Marvin Humphrey wrote:


> Still, this isn't the hill I want to die on.  I think that starting with an
> empty PPMC is good policy for a variety of reasons, but I'm willing to be
> flexible for the sake of building consensus on how to address the truly
> damaging dis-empowerment of PPMC members with regards to release votes.  If
> an empty initial PPMC is a deal breaker for you, does it's removal unblock
> your support for the rest of the proposal at ?
>
>

I think there are several problems with this approach.

One is that trying it for an already started podling _is_ disempowering.
You would have to go unsubscribe people from the private list and tell them
that they no longer have a voice in voting in new committers for their
project. That to me is just wrong.

Trying it for a new just starting up podling might work, which is why i
said previously try the experiment.  But i wouldn't like this to become a a
main stream approach. Remember what the main role of the PMC is - proposing
and voting for _and against_ new committers and PMC members. The point of
being able to veto PMC nominations is so you're not made to work with
someone you don't like or agree with. See the long post from Roy a while
ago about that.  Excluding podling participants from the PMC removes them
from those decisions.

This approach did happen a while ago to a podling, by accident not by
design when just them mentors ended up on the initial private list. They
voted in a new committer and announced it on the dev list, an argument
ensued where the others were surprised and angry about the choice, and the
result was everyone got added to the PPMC. Can't remember which, maybe
Cassandra if anyone wants to check the archives.

I think this is getting too hung up on vetting releases is the be all and
end all of PMC membership when really there are other just as if not more
important things. The way to teach new podling people about this is to
include them in the process while incubating, not exclude them.

   ...ant


I think this is getting to hung up on knowing how to make a release is the
be all and end all of PMC membership when thats jus

Re: Cultivating Outstanding IP Stewards

[ant elder]

Its not totally clear to me what that would look like. What would then
be the difference between an "IP Stewards" and what we currently call
"mentor", where would they discuss and vote on adding new "IP
Stewards"? I'm not saying it couldn't be made to work and i guess this
is the sort of thing an experiment would help sort out, but it does
seem like its starting to make things unnecessarily complicated. The
original pTLP approach where the PMC is all the PPMC + some others
providing oversight is easy and simple. If it looks like they're going
off course the ones providing the oversight step in, if necessary with
-1s, if those are ignored the pTLP gets sent back to the Incubator.

   ...ant

On Tue, Nov 19, 2013 at 10:51 AM, Joseph Schaefer
 wrote:
>
> Then lets disambiguate by not referring to the
> “IP Stewards” as being the PPMC.  Seems simple
> enough.
>
> On Nov 19, 2013, at 4:34 AM, ant elder  wrote:
>
> > The reason it might be dis-empowering is that currently one of the main
> > roles of the PPMC is voting in new committers so if the PPMC is initially
> > just the mentors then the other podling members wont be involved in that.
> > It might still be worth trying the approach as an experiment if a willing
> > podling can be found, but i doubt all new podlings would be very happy with
> > the approach.
> >
> >   ...ant
> >
> >
> >
> > On Mon, Nov 18, 2013 at 12:12 PM, Joseph Schaefer 
> > wrote:
> >
> >> I don’t see how the situation is any worse
> >> than it is now, where no one on the project
> >> currently has a binding vote on a release.
> >> Going from that to “a few” may seem unfair,
> >> but we have to start somewhere and we need
> >> to keep in mind that this is partly a training
> >> exercise, where we need to see people actually
> >> demonstrate good judgement on policy matters.
> >>
> >> Unfortunately this doesn’t solve the bootstrapping
> >> issue directly with the first release, unless we
> >> use it as a remedy for letting release votes stall.
> >>
> >>
> >> On Nov 18, 2013, at 6:41 AM, Andy Seaborne  wrote:
> >>
> >>> On 17/11/13 11:17, Upayavira wrote:
> >>>>
> >>>>
> >>>> On Sun, Nov 17, 2013, at 04:59 AM, Alex Harui wrote:
> >>>>>
> >>>>>
> >>>>> On 11/16/13 8:47 AM, "Upayavira"  wrote:
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Alex,
> >>>>>>
> >>>>>> I'm not sure I see the difference between a release auditor and an
> >> IPMC
> >>>>>> member. If someone is sufficiently clued up to audit a release, then
> >>>>>> they're surely ready to join the Incubator PMC. Am I missing
> >> something?
> >>>>> To me, there is more responsibility in being on the IPMC, like
> >> reviewing
> >>>>> proposals for new podlings and voting on their graduation and becoming
> >> a
> >>>>> mentor.  Personally, that's why I don't want to be on the IPMC, but I
> >>>>> might be willing to help IP audit a podling's release.  Just like some
> >>>>> projects don't have all committers on the PMC, a Release Auditor is
> >> just
> >>>>> someone who can do that specific task, and there is no need to vote
> >> them
> >>>>> in if they are already on some other TLP PMC because any member of a
> >> TLP
> >>>>> PMC supposedly knows how to do release auditing.
> >>>>>
> >>>>>>
> >>>>>> My interest is in a lesser level of involvement, where someone has
> >> shown
> >>>>>> merit within their own PPMC and can get a binding vote there, but
> >>>>>> no-where else. That feels to me like a very useful intermediate step
> >> to
> >>>>>> have.
> >>>>> I agree, except for the no-where else part.  If you know how to check a
> >>>>> RAT report and have an idea of what should be in the NOTICE files, you
> >>>>> should be able to help out any other podling by reviewing their release
> >>>>> and casting a binding vote so they can learn how to do that.  I'd say
> >>>>> that
> >>>>> 3 IPMC me

Re: Cultivating Outstanding IP Stewards

[ant elder]

The reason it might be dis-empowering is that currently one of the main
roles of the PPMC is voting in new committers so if the PPMC is initially
just the mentors then the other podling members wont be involved in that.
It might still be worth trying the approach as an experiment if a willing
podling can be found, but i doubt all new podlings would be very happy with
the approach.

   ...ant



On Mon, Nov 18, 2013 at 12:12 PM, Joseph Schaefer wrote:

> I don’t see how the situation is any worse
> than it is now, where no one on the project
> currently has a binding vote on a release.
> Going from that to “a few” may seem unfair,
> but we have to start somewhere and we need
> to keep in mind that this is partly a training
> exercise, where we need to see people actually
> demonstrate good judgement on policy matters.
>
> Unfortunately this doesn’t solve the bootstrapping
> issue directly with the first release, unless we
> use it as a remedy for letting release votes stall.
>
>
> On Nov 18, 2013, at 6:41 AM, Andy Seaborne  wrote:
>
> > On 17/11/13 11:17, Upayavira wrote:
> >>
> >>
> >> On Sun, Nov 17, 2013, at 04:59 AM, Alex Harui wrote:
> >>>
> >>>
> >>> On 11/16/13 8:47 AM, "Upayavira"  wrote:
> >>>
> 
> 
> 
>  Alex,
> 
>  I'm not sure I see the difference between a release auditor and an
> IPMC
>  member. If someone is sufficiently clued up to audit a release, then
>  they're surely ready to join the Incubator PMC. Am I missing
> something?
> >>> To me, there is more responsibility in being on the IPMC, like
> reviewing
> >>> proposals for new podlings and voting on their graduation and becoming
> a
> >>> mentor.  Personally, that's why I don't want to be on the IPMC, but I
> >>> might be willing to help IP audit a podling's release.  Just like some
> >>> projects don't have all committers on the PMC, a Release Auditor is
> just
> >>> someone who can do that specific task, and there is no need to vote
> them
> >>> in if they are already on some other TLP PMC because any member of a
> TLP
> >>> PMC supposedly knows how to do release auditing.
> >>>
> 
>  My interest is in a lesser level of involvement, where someone has
> shown
>  merit within their own PPMC and can get a binding vote there, but
>  no-where else. That feels to me like a very useful intermediate step
> to
>  have.
> >>> I agree, except for the no-where else part.  If you know how to check a
> >>> RAT report and have an idea of what should be in the NOTICE files, you
> >>> should be able to help out any other podling by reviewing their release
> >>> and casting a binding vote so they can learn how to do that.  I'd say
> >>> that
> >>> 3 IPMC members must vote to give a person Release Auditor status if
> they
> >>> are not already on a TLP PMC.  Consider this:  I am an the Flex PMC but
> >>> not the IPMC, but if I join the PPMC of some new podling, why
> shouldn't I
> >>> be able to cast a binding vote for that podling's releases?
> >>
> >> With a two tier model - with PPMC membership granting voting rights on
> >> podling releases, then a podling would start with just mentors on its
> >> PPMC. If you clearly knew what you were doing, you'd get voted onto the
> >> PPMC pretty quickly, and thus you'd be able to vote on your releases.
> >
> > I am concerned that it would be dis-empowering to the incoming community
> if at least the active and major developers of the podling were not on the
> PPMC at the start.
> >
> >   Andy
> >
> >>
> >> Upayavira
> >>
> >> -
> >> 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: Cultivating Outstanding IP Stewards

[ant elder]

Hi Benson,

On Sun, Nov 17, 2013 at 10:12 PM, Benson Margulies
 wrote:

> If the board were offering us another structural approach, this would
> be a different discussion. But, unless I've gotten lost in the torrent
> of email, the board isn't offering an alternative.

Yep you must have gotten lost. The board _is_ open alternatives and
trying some experiments. Roy said this here on general@, several
others have said that on board@. Our working assumption should be that
they'll ok us trying some things. Also, given the diverse and
disparate group that make up the Incubator PMC I hope everyone can try
to have an open mind about experiments and not try to block people
trying things just because its not what they personally think will
work or is the best experiment.

   ...ant

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

Re: Cultivating Outstanding IP Stewards

[ant elder]

On Fri, Nov 15, 2013 at 5:08 AM, Marvin Humphrey  wrote:
> On Thu, Nov 14, 2013 at 1:08 AM, ant elder  wrote:
>> What i'd like to try is more similar to the pTLP approach previously
>> talked about. So take some existing podling, eg Stratos and/or
>> VXQuery, and give the PPMC binding votes. They have experienced and
>> active mentors so there will be oversight and nothing to worry about.
>> They already have experienced participants so know what they're doing
>> anyway. Anyone on the Incubator PMC can join in or watch what happens
>> and intervene at any point to have the experiment shutdown in the
>> unlikely event that they go wild.
>
> I think there are some issues with that approach.
>
> *   Being listed in the initial committer list of a proposal is not
> sufficient justification for granting a binding vote.  Each individual
> needs to demonstrate merit in the context of incubation and there needs to
> be a VOTE.
> *   When it's already excruciatingly difficult to get IPMC members to
> review releases, making such reviews optional just means hardly anybody
> will get around to them -- even if they have the best of intentions.
> *   Under this model, a first incubating release could be approved with solely
> PPMC votes.  We need more accountability than that.
>

No no, thats not what i'm suggesting, this isn't for some new podling
thats never done a release or anything its for a more experienced
podling thats been here for a while and already done a release but is
still here for some reason. So they mostly know what they're doing,
and they'll have active mentors. Please don't just rule this out as
too scary, its just an experiment and even when successful would be
unlikly ever become the mainstream approach for most podlings.

   ...ant

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

Re: Cultivating Outstanding IP Stewards

[ant elder]

Those sound like fine experiments to try - having a release auditor,
and a new podling with the PPMC have binding votes and initially
seeded just with IPMC members - however they aren't the experiments i
was thinking of.

What i'd like to try is more similar to the pTLP approach previously
talked about. So take some existing podling, eg Stratos and/or
VXQuery, and give the PPMC binding votes. They have experienced and
active mentors so there will be oversight and nothing to worry about.
They already have experienced participants so know what they're doing
anyway. Anyone on the Incubator PMC can join in or watch what happens
and intervene at any point to have the experiment shutdown in the
unlikely event that they go wild.

Its just a small experimental trial. Even if successful this likely
wouldn't ever become the approach used for most podlings, but it could
be a useful step for some. Lets give it a try.

What do you say?

   ...ant

On Wed, Nov 13, 2013 at 7:05 PM, Suresh Marru  wrote:
> On Nov 13, 2013, at 1:14 PM, Marvin Humphrey  wrote:
>
>> On Tue, Nov 12, 2013 at 11:58 PM, ant elder  wrote:
>>> So, we _can_ let podlings have their own binding release votes and we
>>> could do our own "pTLP" type experiments without even needing to go to
>>> the board. We should try that. Not for every podling but just for
>>> select ones where the circumstances mean it will work better than the
>>> current approach. If there are no major objections to some experiments
>>> with this approach then i'd like to start trying one.
>>
>> +1 to run an experiment.  The position that Roy has taken changes the
>> equation.
>>
>> While a number of people have expressed a preference for the approach of
>> electing more podling contributors directly onto the IPMC, in practice it
>> remains uncertain whether the IPMC is capable of identifying, nominating and
>> voting in enough candidates -- as evidenced by some threads currently in
>> progress on private@incubator.
>>
>> I propose that the experiment take the following form:
>>
>> 1.  The initial PPMC shall be composed exclusively of IPMC members.
>> 2.  PPMC votes are binding for every release except the first.
>> 3.  One IPMC vote is required for each release after the first.
>>
>> I believe that this model provides sufficient oversight because the first
>> release must cross a high bar, and because it changes the dynamics of
>> electing PPMC members: even core contributors will now have to earn PPMC
>> membership, demonstrating to an initial PPMC composed of IPMC members that
>> they understand the Apache Way well enough to steward their project.
>
> + 1, I like this balance and caveats.
>
> In my personal view (which I am not generalizing), getting the first release 
> is very time consuming but educational and very much worth it. I do not look 
> at it as one month or so for a release is unreasonable, but rather think it 
> as, one month amortized over quality subsequent releases. Which ever approach 
> or policy changes we take, we still need patient incumbents and overly 
> patient mentors. The only way mentors scale is to teach the process and groom 
> new teachers. Ofcourse not many students will like the teachers until they 
> also become teachers. Atleast this happened to me, I appreciate my mentors 
> more now then when I was a student :)
>
> Suresh
>
>>
>> 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
>

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

Re: Cultivating Outstanding IP Stewards

[ant elder]

Thanks for that Roy.

So, we _can_ let podlings have their own binding release votes and we
could do our own "pTLP" type experiments without even needing to go to
the board. We should try that. Not for every podling but just for
select ones where the circumstances mean it will work better than the
current approach. If there are no major objections to some experiments
with this approach then i'd like to start trying one.

   ...ant

On Tue, Nov 12, 2013 at 11:12 AM, Roy T. Fielding  wrote:
> Release votes are expected to be a decision of the list of people
> empowered by the foundation to make that decision.  How that list
> of people is populated for podlings is up to the PMC.  Right now,
> the only list we have is the IPMC itself, as appointed by the board.
>
> If the Incubator wants to create separate subcommittees to mimic the
> operations of podling PMCs, with the subcommittee delegated the
> right to mint incubating releases and the subcommittee membership
> recorded in an appropriate place for Incubator committee records,
> that would meet my approval.
>
> The purpose of this requirement is to protect the folks who make
> release decisions (i.e., to provide a corporate record of their right
> to do an ASF release, since most of them have no other employment,
> contract, or officer role to back them up).
>
> Roy
>
> On Nov 10, 2013, at 7:34 AM, Joseph Schaefer wrote:
>
>> Unlikely to get at least Roy’s approval because release
>> votes are expected to be a decision of the full committee,
>> not any one member of it.
>>
>> On Nov 10, 2013, at 10:29 AM, Alan D. Cabrera  wrote:
>>
>>>
>>> On Nov 10, 2013, at 1:04 AM, ant elder  wrote:
>>>
>>>> How about simply changing the rules for Incubator releases so that
>>>> they don't require at least three binding votes, but instead make it
>>>> at least three votes only one of which must be binding. That would
>>>> mean there would still be the element of oversight that a mentor vote
>>>> gives but avoids all the problems with not having three mentors. I'm
>>>> sure the board would grant the Incubator authority to implement that
>>>> change.
>>>
>>> The board has charged us to vet the podlings and their releases.  What 
>>> process is used is up to us.
>>>
>>> I would prefer a variant of your proposal.  The first release needs three 
>>> mentor/IPMC votes.  Subsequent releases only require one mentor/IPMC vote.
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>>
>>> -
>>> 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

Fwd: Cultivating Outstanding IP Stewards

[ant elder]

Well ok but to help rule that one out lets see if we can hear this
from the horses mouth.

Hi Roy,

As usual over at the Incubator we're having discussion about how to
make things work better.

One problem is with the struggle that some podling releases have at
getting 3 binding votes from Incubator PMC members. One solution to
that could be to change the rules so that for podling releases only
one binding Incubator PMC vote is required as long as there are at
least 3 +1 votes on the release and more +1s than -1s.

Is this something that you would consider approving of?

Thanks for helping,

   ...ant



-- Forwarded message --
From: Joseph Schaefer 
Date: Sun, Nov 10, 2013 at 3:34 PM
Subject: Re: Cultivating Outstanding IP Stewards
To: general@incubator.apache.org


Unlikely to get at least Roy’s approval because release
votes are expected to be a decision of the full committee,
not any one member of it.

On Nov 10, 2013, at 10:29 AM, Alan D. Cabrera  wrote:

>
> On Nov 10, 2013, at 1:04 AM, ant elder  wrote:
>
>> How about simply changing the rules for Incubator releases so that
>> they don't require at least three binding votes, but instead make it
>> at least three votes only one of which must be binding. That would
>> mean there would still be the element of oversight that a mentor vote
>> gives but avoids all the problems with not having three mentors. I'm
>> sure the board would grant the Incubator authority to implement that
>> change.
>
> The board has charged us to vet the podlings and their releases.  What 
> process is used is up to us.
>
> I would prefer a variant of your proposal.  The first release needs three 
> mentor/IPMC votes.  Subsequent releases only require one mentor/IPMC vote.
>
>
> Regards,
> Alan
>
>
> -
> 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: Cultivating Outstanding IP Stewards

[ant elder]

How about simply changing the rules for Incubator releases so that
they don't require at least three binding votes, but instead make it
at least three votes only one of which must be binding. That would
mean there would still be the element of oversight that a mentor vote
gives but avoids all the problems with not having three mentors. I'm
sure the board would grant the Incubator authority to implement that
change.

   ...ant

On Sun, Nov 10, 2013 at 8:00 AM, Alex Harui  wrote:
> IMO, there are two problems:
>
> 1) We're trying to train folks to manage IP for their community but they
> have to seek approval from folks are aren't as vested in their community.
> My analogy is telling a new city council member: "Welcome to the city
> council.  For the next year all of your decisions will require
> ratification by 3 state senators".
>
> 2) Release voting takes a long time.  It would seem like tools should be
> able to reduce the time on several of the steps, except for this one from
> [1] "compile it as provided, and test the resulting executable on their
> own platform".
>
> Sometimes I think about trying to get on the IPMC and helping some podling
> get a release out but:
> A) Really, I just want to help check the legal aspects of a podling's
> release and don't have bandwidth to want to take on the other roles
> implied by being on the IPMC.
> B) I don't want to take the time to figure out how to build and test a
> release that I have no vested interest in.
>
> Now, incubating releases are not official releases, right? So why have
> such time- consuming requirements to get approval from the IPMC?  Let's
> assume that the podling folks tested the building and operation of the
> source package.  Could we build an ant script that any IPMC member or any
> PMC member from any TLP (to expand the pool of potential helpers to folks
> who supposedly know how) can run just to check:
>
> 1) source package has the name "incubating"
> 2) source package is signed
> 3) unzip source package
> 4) grab a tag from SVN/Git
> 5) Diff
> 6) Run Rat (without any fileset exclusions)
>
> Then some podling writes to general@ and says: "can we get legal approval
> to release? Please run the release checker ant script with the following
> inputs   "
>
> Then it could run while I read through all of the other ASF emails and
> eventually I get a report that contains mainly a list of non-Apache files
> in the RAT report that I review and comment on if needed.  To me, if
> you're reviewing a RAT report, you are a building inspector who has looked
> around inside.
>
> Can we make it that "simple"?
>
> For sure, if any podling member is qualified for IPMC before graduation
> they should be nominated and added, and I suppose we could also approve
> them to cast binding votes as a release checker which may be a lower bar
> and maybe less of a time commitment, but I think if it is possible to have
> a larger group of folks approve incubating releases mainly be reviewing
> RAT reports that might make it easier for a podling to get a release out
> the door and still assist in the training of the podling's future PMC
> members.
>
>
> [1] http://www.apache.org/dev/release.html#approving-a-release
>
> My two cents (probably more),
> -Alex
>
> On 11/9/13 9:38 PM, "Marvin Humphrey"  wrote:
>
>>On Sat, Nov 9, 2013 at 4:11 AM, Dave Brondsema  wrote:
>>> On 11/09/2013 02:23 AM, Jake Farrell wrote:
>>
 If mentors are not performing their duties to vote on a given releases
for
 a podling, then it is up to the IPMC as a whole to help that podling by
 doing the do diligence and casting a vote. We all asked to be apart of
the
 IPMC or where honored by a nomination and accepted the role. It is up
to us
 to show these podlings what the Apache was really means. These projects
 have all come to the ASF and we (the IPMC) have openly voted them into
 incubation, its up to us to help them succeed.
>>>
>>> While this is true in theory it's hard in practice to wrangle those
>>> votes together.
>>
>>That's not the only problem.  While IPMC volunteers who perform
>>"freelance"
>>release reviews keep the Incubator from grinding to a halt, our reliance
>>on
>>them undermines the Incubator's effectiveness as an IP clearinghouse.  I
>>wish
>>that we would redirect those volunteer energies elsewhere.
>>
>>IPMC members who vote +1 on an initial incubating release are endorsing
>>the
>>the code import and IP clearance process[1], as well as any work done
>>in-house
>>since incubation started.  Votes on subsequent incubating releases are
>>less
>>weighty because they chiefly endorse work done in-house since the last
>>release.
>>
>>Non-Mentors who swoop in at the last minute to vote +1 on a codebase
>>they've
>>never looked at produced by a community they've never interacted with are
>>not
>>in a position to make such endorsements, particularly for the first
>>incubating
>>release.
>>
>>They are like building inspectors who never go insid

Re: [RESULT][VOTE] Release Apache VXQuery Incubating 0.2 (RC4)

[ant elder]

Woohoo.

And i'll point out that LEGAL-182 has just been closed too saying its
fine, so everyone should be able to be happy.

Sorry it all took so long.

   ...ant

On Sun, Nov 10, 2013 at 7:38 AM, Till Westmann  wrote:
> Hi,
>
> the vote to release RC4 as Apache VXQuery Incubating 0.2 passes after more 
> than 72 hours with 3 +1 votes of IPMC members (Jochen Wiedmann, Ant Elder, 
> Marvin Humphrey) and no 0 or -1 votes.
>
> The vote thread on vxquery-dev can be found here:
> http://mail-archives.apache.org/mod_mbox/incubator-vxquery-dev/201310.mbox/%3C511917E5-9FC9-4B6C-9DE3-CF07EB4B69AB%40westmann.org%3E
>
> Thanks for voting,
> Till
>
> On Nov 9, 2013, at 9:08 PM, Marvin Humphrey  wrote:
>
>> On Mon, Oct 7, 2013 at 8:59 AM, Till  wrote:
>>
>>> [ ] +1 release this package as apache-vxquery-0.2-incubating
>>> [ ] -1 do not release this package because ...
>>
>> `LICENSE` looks good.  Appropriate pointer to ODC-BY.
>>
>> `NOTICE` looks good.  Copyright up to date.  Appropriate ASF citation.
>> Copyright for Black Titan software looks appropriate (though of course I did
>> not witness the commit which moved it there).
>>
>> RAT report is clean.  (Thanks for providing it!)
>>
>> The only archive file is `dblp.xml.gz`.  Though this is a binary file, it's
>> just compressed XML so it's still essentially "source".  No objection from me
>> with regards to the ODC-BY 1.0 licensing -- see LEGAL-182.
>>
>> The `KEYS` file should be removed from the source tree.  Not a blocker.
>>
>> `DISCLAIMER` is present.  It notes that the sponsor is the XMLBeans PMC, 
>> which
>> is interesting because XMLBeans is headed to the Attic[1].  Not something 
>> that
>> has to be resolved for the release, though IMO.
>>
>> Except for the file `DEPENDENCIES`, the archive contents matches the release
>> tag[2].
>>
>> All dependencies have compatible licensing.
>>
>> Sums and sigs look good[3].
>>
>> +1 (binding)
>>
>> Cheers,
>>
>> Marvin Humphrey
>>
>> [1] 
>> http://www.apache.org/foundation/records/minutes/2013/board_minutes_2013_07_17.txt
>>
>> [2] marvin@knut:~/Desktop/vxquery $ diff -ur
>> apache-vxquery-0.2-incubating export_from_svn_tag/
>>Only in apache-vxquery-0.2-incubating: DEPENDENCIES
>>marvin@knut:~/Desktop/vxquery $
>>
>> [3] marvin@knut:~/Desktop/vxquery $ gpg --verify
>> apache-vxquery-0.2-incubating-source-release.zip.asc
>>gpg: Signature made Thu Oct  3 10:19:23 2013 PDT using RSA key ID BAED10BC
>>gpg: Good signature from "Till Westmann (CODE SIGNING KEY)
>> "
>>gpg: WARNING: This key is not certified with a trusted signature!
>>gpg:  There is no indication that the signature belongs to
>> the owner.
>>Primary key fingerprint: 9BDA F9FB A128 CAD5 0B90  33FF 2501 E46B BAED 
>> 10BC
>>marvin@knut:~/Desktop/vxquery $ shasum
>> apache-vxquery-0.2-incubating-source-release.zip
>>f07fe151ddea24457c6497a1abd48528f9c02462
>> apache-vxquery-0.2-incubating-source-release.zip
>>marvin@knut:~/Desktop/vxquery $ cat
>> apache-vxquery-0.2-incubating-source-release.zip.sha1
>>f07fe151ddea24457c6497a1abd48528f9c02462marvin@knut:~/Desktop/vxquery $ 
>> md5
>>marvin@knut:~/Desktop/vxquery $ md5
>> apache-vxquery-0.2-incubating-source-release.zip
>>MD5 (apache-vxquery-0.2-incubating-source-release.zip) =
>> 381c212e2573b467855aa682a5e3ab22
>>marvin@knut:~/Desktop/vxquery $ cat
>> apache-vxquery-0.2-incubating-source-release.zip.md5
>>381c212e2573b467855aa682a5e3ab22marvin@knut:~/Desktop/vxquery $
>>
>> -
>> 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: [IMO] There are no Incubator issues

[ant elder]

Ha ha ha ha. Does the same also apply to maintaining the records, for
clutch, the vote monitoring and other tools, signing reports, writing
reports for that matter, and all the other aspects of the incubator -
all of that might get done eventually one day if people can ever find
the time, don't make a fuss, as frustrating as it is just keep asking
politely or do it yourself etc?

What it means if mentors aren't voting on things like releases after
weeks is that the mentors aren't doing any mentoring, in which case
whats the point in the podling being here?

   ...ant


On Fri, Nov 8, 2013 at 7:00 AM, David Crossley  wrote:
> Martijn Dashorst wrote:
>>  ...
>
> Well said. Hooray for common-sense and taking ownership.
>
> We must remember that we are all individuals. The ASF
> enables us to do what we want. We each need to take the
> initiative.
>
> -David
>
> -
> 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: Cultivating Outstanding IP Stewards

[ant elder]

On Thu, Nov 7, 2013 at 7:31 PM, Jim Jagielski  wrote:
>
> On Nov 7, 2013, at 2:13 PM, Marvin Humphrey  wrote:
>
>>
>> The Incubator has a fundamental structural flaw: it lacks a mechanism to
>> reward merit earned by individual podling contributors.
>
> Idea: Allow for podlings to nominate, and elect, Podling "chairs"
> which can cast Mentor-like votes.
>

Ok, but how about we also allow there to be a Podling "co-chair" as
well? That would make it possible for a podling with at least one
active mentor to get the three binding votes needed to do a release.

   ...ant

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

Re: [VOTE] Release Apache VXQuery Incubating 0.2 (RC4)

[ant elder]

Dave, (or any other Incubator PMC member), LEGAL-182 is almost closed now
saying this license use by VXQuery is ok, so would anyone give this the one
more +1 vote it needs to get the release out?

Many thanks,

   ...ant


On Fri, Oct 11, 2013 at 2:08 PM, Dave Fisher  wrote:

> HI Ant,
>
> On Oct 11, 2013, at 2:03 AM, ant elder wrote:
>
> > Dave/Vinayak,
> >
> > My understanding is that the ODC-BY license only needs to be run by ASF
> > legal if there is a concern about it, I've read the license when voting
> on
> > this and AFAICT its fine (and the package is not being modified so it
> could
> > be cat A or B), and its not listed as an excluded license at:
> > http://www.apache.org/legal/resolved.html#category-x. Are there any
> > particular clauses in the license that you have a concern about?
>
> IANAL - it is not on any list. I am not going to be an effective judge. If
> it is Class A then we are OK. If it is class B then it should not be in the
> source release, but should be pulled in from another location.
>
> This clause:
>
> > 2.4 Relationship to Contents in the Database. The individual items of
> the Contents contained in this Database may be covered by other rights,
> including copyright, patent, data protection, privacy, or personality
> rights, and this License does not cover any rights (other than Database
> Rights or in contract) in individual Contents contained in the Database.
> For example, if used on a Database of images (the Contents), this License
> would not apply to copyright over individual images, which could have their
> own separate licenses, or one single license covering all of the rights
> over the images. - See more at:
> http://opendatacommons.org/licenses/by/1.0/#sthash.z2xdvHcd.dpuf
>
> Further investigation into the contents may be required.
>
> >
> > Vinayak, the release does not need to be redone yet. If it really looks
> > like this will hold up getting another vote raise a ASF legal JIRA  (
> > https://issues.apache.org/jira/browse/LEGAL) asking to confirm that
> ODC-BY
> > is ok.
>
> It holds me up.
>
> Regards,
> Dave
>
> >
> >   ...ant
> >
> >
> >
> > On Fri, Oct 11, 2013 at 6:39 AM, Vinayak Borkar 
> wrote:
> >
> >> Hi Dave,
> >>
> >>
> >>
> >> Before I can VOTE I have questions.
> >>>
> >>> (1) What is the following file?
> >>>
> >>>   A apache-vxquery-0.2-incubating/**vxquery-core/src/test/**
> >>> resources/documents/dblp.xml.**gz
> >>>
> >>> Am I correct that this shows up in your LICENSE as:
> >>>
> >>>==**==**
> >>> ===
> >>>
> >>>The DBLP (http://dblp.uni-trier.de/db/) database in
> >>>
> >>>vxquery-core/src/test/**resources/documents/dblp.xml.**gz
> >>>
> >>>can be used under the terms and conditions of the Open Data Commons
> >>>Attribution License (ODC-BY 1.0). The full ODC-BY 1.0 license text
> >>>is avaialable at
> >>>
> >>>http://opendatacommons.org/**licenses/by/1.0/<
> http://opendatacommons.org/licenses/by/1.0/>
> >>>
> >>> I don't see this license on http://www.apache.org/legal/**3party.html<
> http://www.apache.org/legal/3party.html>
> >>>
> >>> Can you show me a reference from the Legal Discuss list:
> >>>
> http://www.apache.org/**foundation/mailinglists.html#**foundation-legal<
> http://www.apache.org/foundation/mailinglists.html#foundation-legal>that
> puts this in Class A? I think that this is required otherwise the
> >>> project will need to find a better way of packaging this source
> dependency.
> >>>
> >>
> >>
> >> The file is a standard XML file that is used for unit testing the
> parsing
> >> capabilities of the software. It is not critical to the release itself.
> >>
> >> Just to confirm, if there is no such mention on the mailing lists, do we
> >> have to create a new release without this dependency?
> >>
> >> Thanks,
> >> Vinayak
> >>
> >>
> >>
> >>
> >>
> >>
> >>> (2) Does the podling intend in this VOTE to authorize the release of
> the
> >>> convenience binary artifacts that are also in the directory? I see from
> >>> discussions on the project that this is NOT intended. At least that is
> how
> >>> I view

Re: [VOTE] Release Apache VXQuery Incubating 0.2 (RC4)

[ant elder]

ache-vxquery-0.2-incubating-source-release.zip.md5>
>>> https://repository.apache.org/**content/repositories/**
>>> orgapachevxquery-128/org/**apache/vxquery/apache-vxquery/**
>>> 0.2-incubating/apache-vxquery-**0.2-incubating-source-release.**zip.sha1<https://repository.apache.org/content/repositories/orgapachevxquery-128/org/apache/vxquery/apache-vxquery/0.2-incubating/apache-vxquery-0.2-incubating-source-release.zip.sha1>
>>>
>>> MD5:  381c212e2573b467855aa682a5e3ab**22
>>> SHA1: f07fe151ddea24457c6497a1abd485**28f9c02462
>>>
>>> The RAT report is at:
>>>
>>> http://people.apache.org/~**tillw/apache-vxquery-0.2-**
>>> incubating/rat-report.txt<http://people.apache.org/~tillw/apache-vxquery-0.2-incubating/rat-report.txt>
>>>
>>> and the KEYS file containing the PGP keys used to sign the release can
>>> currently
>>> be found at
>>>
>>> https://dist.apache.org/repos/**dist/release/incubator/**vxquery/KEYS<https://dist.apache.org/repos/dist/release/incubator/vxquery/KEYS>
>>>
>>> The vote on vxquery-dev passed [1] with
>>>
>>> +1 (binding)
>>> Vinayak Borkar
>>> Cezar Andrei
>>> Jochen Wiedmann (IPMC)
>>> Ant Elder (IPMC)
>>>
>>> -1
>>> none
>>>
>>> Please vote
>>> [ ] +1 release this package as apache-vxquery-0.2-incubating
>>> [ ] -1 do not release this package because ...
>>>
>>> Thanks,
>>> Till
>>>
>>>
>>> [1] http://mail-archives.apache.**org/mod_mbox/incubator-**
>>> vxquery-dev/201310.mbox/%**3C511917E5-9FC9-4B6C-9DE3-**
>>> CF07EB4B69AB%40westmann.org%3E<http://mail-archives.apache.org/mod_mbox/incubator-vxquery-dev/201310.mbox/%3C511917E5-9FC9-4B6C-9DE3-CF07EB4B69AB%40westmann.org%3E>
>>>
>>> --**--**
>>> -
>>> To unsubscribe, e-mail: 
>>> general-unsubscribe@incubator.**apache.org
>>> For additional commands, e-mail: 
>>> general-help@incubator.apache.**org
>>>
>>>
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> general-unsubscribe@incubator.**apache.org
>> For additional commands, e-mail: 
>> general-help@incubator.apache.**org
>>
>>
>>
>
> --**--**-
> To unsubscribe, e-mail: 
> general-unsubscribe@incubator.**apache.org
> For additional commands, e-mail: 
> general-help@incubator.apache.**org
>
>

Re: VXQuery needs some mentoring

[ant elder]

Hi Vinayak, I offered to help mentor if necessary when VXQuery came up a
few weeks ago so i can help with this. I'll go have a look at whats going
on and help.

   ...ant


On Wed, Sep 25, 2013 at 5:34 PM, Vinayak Borkar  wrote:

> Dear Incubator,
>
> The VXQuery podling is currently stalled at being able to add a new
> committer who has undergone a vote with all existing committers in favor
> and the individual has accepted to join the community. However, we are
> currently stuck at being able to make progress on the administrative part
> of making this person a full committer. Any help from anybody volunteering
> to perform the duties of a mentor will be appreciated. We are also working
> on getting a release done and would need some help there too. Please help.
>
>
> Thanks,
> Vinayak
>
> --**--**-
> To unsubscribe, e-mail: 
> general-unsubscribe@incubator.**apache.org
> For additional commands, e-mail: 
> general-help@incubator.apache.**org
>
>

Re: binary release artifacts

[ant elder]

I closed LEGAL-178 with the resolution "Not A Problem", which is quite
different to a resolution of "Fixed" or "Resolved" or "Answered".

>From my investigation, things like the text of the AL and various posts in
the mailing lists over the years answered the question to my satisfaction.
I doubt everyone agrees yet but the answers for me are:
- there is no need to vote on the convenience binary artifacts
- in fact voting on them is a bit pointless as you can't easily verify the
contents anyway, and the ASF only does source releases.
- its ok to have unvoted on convenience binaries in the ASF distribution
areas
- there is no requirement to have LICENSE/NOTICE files in the root
directory of a convenience binary

However i think it would take a fair bit of work to build enough consensus
around any documentation update. So just closing LEGAL-178 as Not A Problem
seemed much easier now that it seems like no one is insisting any historic
artifacts be removed.

Happy to continue discussing this as it does seem an interesting topic, but
if we do could it be in a new thread not so tied to Chukwa.

   ...ant


On Mon, Sep 23, 2013 at 11:42 PM, Luciano Resende wrote:

> On Mon, Sep 23, 2013 at 2:23 PM, Marvin Humphrey  >wrote:
>
> > On Mon, Sep 23, 2013 at 1:45 PM, Luciano Resende 
> > wrote:
> >
> > > Thanks for the summary Marvin,  how about we take the chance to update
> > our
> > > policy/documentation to clarify the social norm regarding placement of
> > > LICENSE/NOTICE in the top level of a distribution but also clarify
> that,
> > > any artifact being release by an Apache Project should be reviewed and
> > > voted, as there were some suggestions on this thread that this was not
> > the
> > > case. If we can't clarify that on ASF level, at least we can clarify
> that
> > > on the IPMC level.
> >
> > I understand the motivation, but I'm actually in favor of keeping the
> > status
> > quo.
> >
> > As Joe Schaefer pointed out, the VOTE only applies to the canonical
> source
> > release.  Binary artifacts cannot be official releases of the ASF, and
> the
> > IPMC cannot override that policy.
> >
> >
> Is there any written policy that states that ? I have never heard that the
> ASF can't have binary artifacts as official releases ?
>
> Also, from Joe's message, I think he was mentioning what is done in the
> context of HTTPD, not necessarily stating a policy or the social norm here
> at Apache.
>
>
> > Additionally, we still have a lot of work to do to squash licensing
> > documentation bugs in our canonical source releases.  When we can't even
> > get
> > our official releases right, I don't think it makes sense to dilute our
> > already thin quality control resources.
> >
> > Marvin Humphrey
> >
> >
> The issue I see, particularly when evaluating maven based java source
> releases (no binaries at all), is that the a lot of the dependencies for a
> project might be transient making much harder and much more work to
> evaluate a source only release. While reviewing a binary release, you have
> listed all the binary dependencies and all it's associated license, making
> the review process much simpler, allowing the reviewer to concentrate on
> making sure the dependencies are allowed, no specific jars got unaccounted
> on the license/notice, etc...
>
>
> [1]
>
> http://mail-archives.apache.org/mod_mbox/incubator-general/201309.mbox/%3CBF8E0313-15C2-4375-8470-FE0A1DA917C5%40yahoo.com%3E
>
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>

Re: [VOTE] Apache Chukwa graduation

[ant elder]

+1

   ...ant


On Fri, Sep 20, 2013 at 6:52 PM, Eric Yang  wrote:

> The Apache Chukwa project entered incubator in July of 2010. Since then
> it has grown the community in users, committers and PPMC members,
> made significant improvements to the project codebase and completed
> many releases following ASF policies and guidelines.
>
> The Apache Chukwa community has voted to proceed with graduation [1]
> and the result can be found at [2]. Discussion about the proposed
> resolution
> is also available at [3].
>
> Please cast your votes:
>
> [  ] +1 Graduate Chukwa podling from Incubator
> [  ] +0 Indifferent to graduation status of Chukwa
> [  ] -1 Reject graduation of Chukwa podling from Incubator because ...
>
> Please find the proposed board resolution below.
>
> [1] http://s.apache.org/chukwa-graduation-vote
> [2] http://s.apache.org/chukwa-graduation-result
> [3] http://s.apache.org/chukwa-graduation-Resolution
>
>
> Resolution:
>
> X.Establish the Apache Chukwa 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 data streaming and
>   visualization for Hadoop services.
>
>   NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>   Committee (PMC), to be known as the "Apache Chukwa Project",
>   be and hereby is established pursuant to Bylaws of the
>   Foundation; and be it further
>
>   RESOLVED, that the Apache Chukwa Project be and hereby is
>   responsible for the creation and maintenance of a software
>   project related to data streaming, monitoring and visualization
>   for Hadoop services; and be it further
>
>   RESOLVED, that the office of "Vice President, Apache Chukwa" 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
>   Chukwa Project, and to have primary responsibility for
>   management of the projects within the scope of responsibility of
>   the Apache Chukwa 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 Chukwa Project:
>
> * Ahmed Fathalla (afathalla)
> * Alan D. Cabrera (adc)
> * Ant Elder (antelder)
> * Ariel Rabkin (asrabkin)
> * Bill Graham (billgraham)
> * Eric Yang (eyang)
> * Grace Huang (grace.huang)
> * Ivy Tang (ivytang)
> * Jerome Boulon (jboulon)
> * Jiaqi Tan (tanjiaqi)
> * Shreyas Subramanya (shreyas)
> * Sourygna Luangsay (sluangsay)
>
>   NOW, THEREFORE, BE IT FURTHER RESOLVED, that Eric Yang,
>   be appointed to the office of Vice President, Apache Chukwa,
>   to serve in accordance with and subject to
>   the direction of the Board of Directors and the Bylaws of the
>   Foundation until death, resignation, retirement, removal or
>   disqualification, or until a successor is appointed; and be it
>   further
>
>   RESOLVED, that the initial Apache Chukwa Project PMC be hereby is
>   tasked with the creation of a set of bylaws intended to
>   encourage open development and increased participation in the
>   Apache Chukwa Project; and be it further
>
>   RESOLVED, that the initial Apache Chukwa Project be and hereby
>   is tasked with the migration and rationalization of the Apache
>   Incubator Chukwa podling; and be it further
>
>   RESOLVED, that all responsibility pertaining to the Apache
>   Incubator Chukwa podling encumbered upon the Apache Incubator
>   PMC are hereafter discharged.
>
>
> Regards
> Eric
>

Re: binary release artifacts

[ant elder]

On Thu, Sep 19, 2013 at 2:18 AM, Marvin Humphrey wrote:


> As Tim and Luciano have already stated, artifacts which were not voted on
> by
> the IPMC cannot continue to be distributed though our channels.
>


Is that actually the case? AIUI the ASF only releases open source code. We
vote on the source packages and call the positive results a release, and
the binary artifacts are just for convenience. Go take a look at the HTTPD
project (which should know what they're doing right?), their release votes
on the dev list only mention the source, but there are binary artifacts
mentioned up on their download page.

   ...ant

Re: binary release artifacts

[ant elder]

Perhaps, but AFAICT the existing documentation is either incorrect,
lacking, or ambiguous so i've raised LEGAL-178 to clarify.

   ...ant

On Mon, Sep 16, 2013 at 12:56 AM, sebb  wrote:
> On 15 September 2013 14:16, Tim Williams  wrote:
>> On Sun, Sep 15, 2013 at 5:19 AM, ant elder  wrote:
>>> Tim, one of the things we're trying to teach podlings is how to handle
>>> disputes and resolve problems in a happy respectful manner. You've out
>>> of the blue come on to their dev list without introducing yourself
>>> demanding that something that happened nearly two years ago be undone.
>>
>> My mail on their list wasn't intended to be 'demanding' or rude - my
>> apologies if it came across that way.  I honestly went in thinking it
>> was a mistake - a simple misunderstanding.
>>
>>> Its a testament to Chukwa that they've engaged in discussing the
>>> matter with you promptly and politely, never the less in under 48
>>> hours of starting the discussion you've escalated this to general@
>>> with a fairly negative email.
>>
>> I agree, Eric was prompt and polite.  I "escalated" this for two reasons:
>>
>> 1) It became apparent that it wasn't a misunderstanding - it's a
>> question of policy and it doesn't seem fair to hash that out on their
>> dev list.  It wasn't so much "escalation" as taking policy discussions
>> to the right audience - if there were a mentor@ list, I would have
>> aimed there.
>>
>> 2) This PMC has a release artifact published that was never voted
>> upon.  That was news to me and, I felt, worthy of sunlight -
>> especially after the [prompt/polite] defensive reaction received.
>>
>> Sorry for the negativity, it was borne of frustration.  It's
>> frustrating to ask podlings to work hard dotting I's and crossing T's
>> only to look around and see other podling's  lackadaisical approach.
>>
>>> Lets take your LICENSE/NOTICE file issue, you initially said the
>>> binary artifact didn't have any, it was then pointed out that in fact
>>> it did have them just not where you were looking, you then asserted
>>> that is not acceptable and they must only be right at the top
>>> directory, it was then pointed out other types of binary distributions
>>> like jars also don't have them at the top either, but you have ignored
>>> that and instead come here to general@.
>>
>> I guess I viewed that as a frustrating rationalization.  Their distro
>> is a standard tarball - where those files are well expected to be in
>> the standard place by both policy and social norm - not some other
>> artifact type where an difference is obvious.  Anyway, moving it here
>> was less about that and more about the fact that they released an
>> artifact without voting.
>>
>> Though, since you bring it up I'd appreciate that if there's going to
>> be no accountability for podlings to locate those source files in the
>> right place[1], then yeah, I think we should change the policy to
>> state that anywhere in the artifact is acceptable.
>
> I think the only proper places are at the top level for tarballs with
> the option of the META-INF directory for jars.
>
>> --tim
>>
>> [1] - http://apache.org/legal/src-headers.html#notice
>>
>>> I have no doubt that Chukwa will be happy to help resolve this in
>>> whatever way is necessary to satisfy all the ASF policy's, but we
>>> don't need a big general@ flame thread to do that.
>>>
>>>...ant
>>>
>>> On Sun, Sep 15, 2013 at 3:46 AM, Tim Williams  wrote:
>>>> Moving this[1] to general@
>>>>
>>>> On Sat, Sep 14, 2013 at 2:55 AM, ant elder  wrote:
>>>>> On Saturday, September 14, 2013, Tim Williams  
>>>>> wrote:
>>>>>> Hi Eric,
>>>>>> I've included references inline for your convenience.  I'll once again
>>>>>> [strongly] suggest you guys remove that artifact.
>>>>>>
>>>>>> Thanks,
>>>>>> --tim
>>>>>>
>>>>>> On Fri, Sep 13, 2013 at 6:53 PM, Eric Yang  wrote:
>>>>>>> Hi Tim,
>>>>>>>
>>>>>>> There is LICENSE.txt and NOTICES.txt in both source and binary package.
>>>>>  In
>>>>>>> the binary package, the files are located in $PREFIX/share/doc/chukwa to
>>>>>>> match what sta

Re: binary release artifacts

[ant elder]

Tim, one of the things we're trying to teach podlings is how to handle
disputes and resolve problems in a happy respectful manner. You've out
of the blue come on to their dev list without introducing yourself
demanding that something that happened nearly two years ago be undone.
Its a testament to Chukwa that they've engaged in discussing the
matter with you promptly and politely, never the less in under 48
hours of starting the discussion you've escalated this to general@
with a fairly negative email.

Lets take your LICENSE/NOTICE file issue, you initially said the
binary artifact didn't have any, it was then pointed out that in fact
it did have them just not where you were looking, you then asserted
that is not acceptable and they must only be right at the top
directory, it was then pointed out other types of binary distributions
like jars also don't have them at the top either, but you have ignored
that and instead come here to general@.

I have no doubt that Chukwa will be happy to help resolve this in
whatever way is necessary to satisfy all the ASF policy's, but we
don't need a big general@ flame thread to do that.

   ...ant

On Sun, Sep 15, 2013 at 3:46 AM, Tim Williams  wrote:
> Moving this[1] to general@
>
> On Sat, Sep 14, 2013 at 2:55 AM, ant elder  wrote:
>> On Saturday, September 14, 2013, Tim Williams  wrote:
>>> Hi Eric,
>>> I've included references inline for your convenience.  I'll once again
>>> [strongly] suggest you guys remove that artifact.
>>>
>>> Thanks,
>>> --tim
>>>
>>> On Fri, Sep 13, 2013 at 6:53 PM, Eric Yang  wrote:
>>>> Hi Tim,
>>>>
>>>> There is LICENSE.txt and NOTICES.txt in both source and binary package.
>>  In
>>>> the binary package, the files are located in $PREFIX/share/doc/chukwa to
>>>> match what standard Linux file system layout.  We voted for source
>> release
>>>> and there is no Apache restriction that a source release, can not
>> procedure
>>>> a binary package.
>>>
>>> "Votes on whether a package is ready to be released use majority
>>> approval -- i.e., at least three PMC members must vote affirmatively
>>> for release, and there must be more positive than negative votes."
>>>
>>> Each vote is on signed, hashed artifacts, so yes, if you say it's a
>>> "source vote" then no binary should accompany it.
>>>
>>> http://www.apache.org/dev/release.html#approving-a-release
>>>
>>>> There is also no restriction that binary release must
>>>> have LICENSE.txt and NOTICES.txt in the top level directory.
>>>
>>> How do you reach that understanding from the sentence below?
>>>
>>> "Every Apache distribution should include a NOTICE file in the top
>>> directory, along with the standard LICENSE file."
>>>
>>
>> Plenty of other release artifacts from other projects have these files
>> somewhere other than the top directory, eg most jar releases have them in
>> the meta-inf directory.
>>
>> There is also ambiguity around convenience binary releases in the ASF docs
>> and the historical mailing list discussions around those, so a little
>> flexibility is warranted. I recall there was once a some bugs in the maven
>> plugin for building jars which meant several projects distributing jar
>> artifacts with missing or completely incorrect license/notice files, and
>> those artifacts weren't pulled . I also recall on one project where an
>> artifact was discovered distributed without a release vote and the solution
>> was just to have a posthumous vote. The important thing here in my opinion
>> is to get a common understanding of how convenience binary artifacts will
>> be handled in the future that everyone is happy with.
>
> No offense, but this is ridiculous. If our job as mentors is to help
> podlings rationalize violations of most basic policies (e.g. release
> artifacts require a vote, NOTICE/LICENSE files), to play the
> well-they-got-away-with-it game, then this process is really a joke
> and we should close up shop. If such basic things as this are really
> up for debate by seemingly clueful folk, then the incubator isn't
> serving a useful purpose and should be dissolved as it means we're
> actively graduating podlings that are somewhere between just not
> getting it and putting the foundation at risk. (alarmingly, discussion
> of Chukwa's graduation was recently had!).  I dunno, that podlings are
> defending the idea of releasing unvoted on artifacts only to have
> their mentor follow su

Re: Followup to VXQuery July 2013 report

[ant elder]

I don't see the need or point in being so draconian with the poddling
especially given its history, so if you really do want to initiate
retirement discussions if they've not released by their next report
(which is just a few weeks away right?) I'll be voting against it and
will volunteer to be a mentor to help try to keep them alive if they
want to keep trying.

   ...ant


On Thu, Sep 5, 2013 at 3:18 PM, Marvin Humphrey  wrote:
>
> On Thu, Sep 5, 2013 at 2:01 AM, ant elder  wrote:
> > To me VXQuery looks like an example of a project being let down by the
> > Incubator PMC.
>
> Regardless, they will have to overcome their challenges themselves.
>
> > Similarly with the no releases in 4 years - they've attempted to
> > release twice and both times it stalled getting the votes, what they need
> > are mentors who can show them whats necessary to push releases and voting
> > through the Incubator.
>
> VXQuery received guidance on pushing releases back in July[1].  It seems to
> have had no effect[2].
>
> The Incubator is not a hosting service.  If VXQuery wants to be part of
> Apache, they must release.
>
> Marvin Humphrey
>
> [1] http://s.apache.org/9Sg
> [2] http://s.apache.org/rkn
>
> -
> 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: Followup to VXQuery July 2013 report

[ant elder]

Dropping the vxquery mailing list...

To me VXQuery looks like an example of a project being let down by the
Incubator PMC. This labeling issue was just an honest attempt at trying to
be helpful not some underhanded attempt to try to circumvent the ASF
release policy, if they were getting adequate mentoring it would have just
been an opportunity to teach them more about the ASF release policies and
processes. Similarly with the no releases in 4 years - they've attempted to
release twice and both times it stalled getting the votes, what they need
are mentors who can show them whats necessary to push releases and voting
through the Incubator. In the past they've asked us for more mentors to
help and got nothing. Its a small project but its managed to survive for 4
years here and still have some active committers and as they've just shown
now when a problem is reported they fixed it in less than a day, so all
credit to them for keeping on trying.



On Thu, Sep 5, 2013 at 9:46 AM, ant elder  wrote:

> Thanks for doing that so promptly Till.
>
>...ant
>
>
> On Thu, Sep 5, 2013 at 4:00 AM, Till Westmann  wrote:
>
>> Just for the record: The website is updated (from the branch that will
>> hopefully be released soon).
>>
>> Till
>>
>> On Sep 4, 2013, at 12:11 AM, Marvin Humphrey 
>> wrote:
>>
>> > On Tue, Sep 3, 2013 at 11:42 PM, David Crossley 
>> wrote:
>> >> ant elder wrote:
>> >>> Hi Marvin, I had a look, that README being pointed to is just build
>> >>> instructions on how to build the svn trunk isn't it, so not to some
>> >>> released artifacts. Thats allowed isn't it, i'm pretty sure other
>> projects
>> >>> and podlings have done something similar anyway. Is it that the
>> website
>> >>> describes it as user installation instructions rather than developer
>> build
>> >>> instructions thats the issue?
>> >>>
>> >>>   ...ant
>> >>
>> >> I reckon so. To clearly refer developers to developer resources
>> >> is fine, but users no. They need to be referred to user instructions.
>> >
>> > In VXQuery's case, there's nothing to refer users to because in four
>> years,
>> > VXQuery has never made an incubating release.
>> >
>> > If developer instructions for accessing version control are added to the
>> > website in accordance with ASF guidelines, of course that's fine -- so
>> > long as all "user installation" instructions are removed.
>> >
>> > Here's more background from the legal-discuss list regarding the
>> current policy,
>> > this time from a different Board member, Doug Cutting:
>> >
>> >http://markmail.org/message/pelvob23vrzuzws5
>> >
>> >Each PMC should attempt to ensure that every commit is in accord with
>> >Apache's intellectual property policies. Releases are a double-check
>> of
>> >this. We hope that source code repositories are not legally
>> considered
>> >publications, but we don't know that courts will in fact always
>> treat them
>> >that way, so it's best to guard against that too. Note that the extra
>> >scrutiny around releases both serves to double-check (belt and
>> suspenders)
>> >as well as to provide evidence that we do not consider the source
>> code
>> >repository as a publication. But again, we cannot depend on others to
>> >agree with that, and must guard against other interpretations as
>> best we
>> >can.
>> >
>> > If VXQuery finds it uncomfortable not to have anything they can show
>> users,
>> > they can solve that by making a release.
>> >
>> > 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: Followup to VXQuery July 2013 report

[ant elder]

Thanks for doing that so promptly Till.

   ...ant


On Thu, Sep 5, 2013 at 4:00 AM, Till Westmann  wrote:

> Just for the record: The website is updated (from the branch that will
> hopefully be released soon).
>
> Till
>
> On Sep 4, 2013, at 12:11 AM, Marvin Humphrey 
> wrote:
>
> > On Tue, Sep 3, 2013 at 11:42 PM, David Crossley 
> wrote:
> >> ant elder wrote:
> >>> Hi Marvin, I had a look, that README being pointed to is just build
> >>> instructions on how to build the svn trunk isn't it, so not to some
> >>> released artifacts. Thats allowed isn't it, i'm pretty sure other
> projects
> >>> and podlings have done something similar anyway. Is it that the website
> >>> describes it as user installation instructions rather than developer
> build
> >>> instructions thats the issue?
> >>>
> >>>   ...ant
> >>
> >> I reckon so. To clearly refer developers to developer resources
> >> is fine, but users no. They need to be referred to user instructions.
> >
> > In VXQuery's case, there's nothing to refer users to because in four
> years,
> > VXQuery has never made an incubating release.
> >
> > If developer instructions for accessing version control are added to the
> > website in accordance with ASF guidelines, of course that's fine -- so
> > long as all "user installation" instructions are removed.
> >
> > Here's more background from the legal-discuss list regarding the current
> policy,
> > this time from a different Board member, Doug Cutting:
> >
> >http://markmail.org/message/pelvob23vrzuzws5
> >
> >Each PMC should attempt to ensure that every commit is in accord with
> >Apache's intellectual property policies. Releases are a double-check
> of
> >this. We hope that source code repositories are not legally considered
> >publications, but we don't know that courts will in fact always treat
> them
> >that way, so it's best to guard against that too. Note that the extra
> >scrutiny around releases both serves to double-check (belt and
> suspenders)
> >as well as to provide evidence that we do not consider the source code
> >repository as a publication. But again, we cannot depend on others to
> >agree with that, and must guard against other interpretations as best
> we
> >can.
> >
> > If VXQuery finds it uncomfortable not to have anything they can show
> users,
> > they can solve that by making a release.
> >
> > 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: Followup to VXQuery July 2013 report

[ant elder]

Hi Marvin, I had a look, that README being pointed to is just build
instructions on how to build the svn trunk isn't it, so not to some
released artifacts. Thats allowed isn't it, i'm pretty sure other projects
and podlings have done something similar anyway. Is it that the website
describes it as user installation instructions rather than developer build
instructions thats the issue?

   ...ant


On Wed, Sep 4, 2013 at 12:30 AM, Marvin Humphrey wrote:

> On Thu, Aug 22, 2013 at 9:52 AM, Till  wrote:
> >> Marvin Humphrey  hat am 22. August 2013 um
> 18:21
> >> geschrieben:
>
> >> Let me be blunt: VXQuery needs to make an incubating release.
> >>
> >> Personally, I think it's important that we see one before your next
> >> quarterly report.
> >
> > Yes, I agree. And probably "important" is an understatement.
>
> Today, I was wondering how VXQuery could have made it through four
> years in the Incubator without making a release, and I took a look at the
> website.
>
> I note that in the navigation bar on the left hand side there is a "For
> Users"
> section which includes an "Installation" link.  The page at the link
> points to
> the README file in svn.
>
> http://incubator.apache.org/vxquery/user_installation.html
>
> Install instructions can be found in the README file.
>
> We must not distribute to users from our source repositories:
>
> http://www.apache.org/dev/release.html#what
>
> During the process of developing software and preparing a release,
> various
> packages are made available to the developer community for testing
> purposes. Do not include any links on the project website that might
> encourage non-developers to download and use nightly builds, snapshots,
> release candidates, or any other similar package. The only people who
> are
> supposed to know about such packages are the people following the dev
> list
> (or searching its archives) and thus aware of the conditions placed on
> the
> package. If you find that the general public are downloading such test
> packages, then remove them.
>
> Under no circumstances are unapproved builds a substitute for
> releases. If
> this policy seems inconvenient, then release more often. Proper release
> management is a key aspect of Apache software development.
>
> Here's some background about the policy in a message from Roy Fielding to
> the
> legal-discuss list.
>
> http://markmail.org/message/njray5dbazwcdcts
>
> The release process is critical because it is the point at which the
> ASF
> as an organization approves a release to the public. It is the point at
> which the ASF's liability and goodwill comes into play. The checkpoints
> are necessary to ensure that we don't release a product that isn't open
> source or that hasn't been reviewed by the peers, since either one
> would
> seriously damage the foundation. The consistency is necessary because
> it
> establishes a well-worn set of procedures that distinguish ASF projects
> from those at Sourceforge or Google code.
>
> Speaking as the Incubator PMC Chair:
>
> Please remove the user installation links immediately.  VXQuery is not
> allowed
> to distribute code which has not passed an IPMC vote to the general public.
>
> Speaking as a member of the Incubator PMC:
>
> If VXQuery has not released by the next report, I expect to initiate a
> discussion on retiring the podling.
>
> Marvin Humphrey
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Graduate Apache Curator as an Apache Top Level Project

[ant elder]

+1

   ...ant

On Wed, Aug 28, 2013 at 6:44 PM, Jordan Zimmerman
 wrote:
> This message is opening a VOTE to graduate the Apache Curator podling from 
> the Apache Incubator as an Apache Top Level Project.
>
> Apache Curator entered the Incubator in April of 2013. We have made 
> significant progress with the project since moving to Apache. We currently 
> have 4 committers listed on our status page [1] including 2 who were accepted 
> after the podling was formed.  A VOTE was held on the curator-dev group with 
> 8 binding +1 and 2 non-binding +1 votes for graduation [2]. A VOTE was also 
> held to adopt the graduation resolution (below) with 7 +1 votes for 
> acceptance [3]. According to Ohloh, Curator has a "large, active development 
> team" [4].
>
> During incubation, Curator:
> * Produced 4 releases
> * Added 2 new Committer/PPMC members and showed constant community activities
> * Cleared IP on code
> * Developed roadmap(s) for major and minor releases in a community process [5]
> * Established that Apache Curator is a suitable name [6]
> * Showed that its community is active, healthy, and growing and has 
> demonstrated the ability to self-govern using accepted Apache practices
>
> Please cast your vote:
> [ ] +1 Graduate the Apache Curator podling from Apache Incubator as a TLP
> [ ] +0 Indifferent to the graduation status of Apache Curator podling
> [ ] -1 Reject graduation of Apache Curator podling from Apache Incubator 
> because ...
>
> We'll run the vote for at least 72 hours.
>
> [1] http://curator.incubator.apache.org/team-list.html#Contributors
> [2] 
> http://mail-archives.apache.org/mod_mbox/incubator-curator-dev/201308.mbox/%3C44CD80F8-10B1-4FBA-A9D9-6DDEA7280FA5%40jordanzimmerman.com%3E
> [3] 
> http://mail-archives.apache.org/mod_mbox/incubator-curator-dev/201308.mbox/%3C3859DF43-460C-406E-B816-DD9F4049B4DC%40jordanzimmerman.com%3E
> [4] http://www.ohloh.net/p/apache-curator/factoids#FactoidTeamSizeLarge
> [5] 
> https://issues.apache.org/jira/browse/CURATOR#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel
> [6] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-28
>
> Sincerely,
>
> The Apache Curator Team
>
> Resolution:
>
> X. Establish the Apache Curator 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 a library and tools for working with
>Apache ZooKeeper.
>
>NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>Committee (PMC), to be known as the "Apache Curator Project",
>be and hereby is established pursuant to Bylaws of the
>Foundation; and be it further
>
>RESOLVED, that the Apache Curator Project be and hereby is
>responsible for the creation and maintenance of software
>related to a library and tools for working with Apache ZooKeeper;
>and be it further
>
>RESOLVED, that the office of "Vice President, Apache Curator" 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 Curator Project, and to have primary responsibility
>for management of the projects within the scope of
>responsibility of the Apache Curator 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 Curator Project:
>
>  * Jordan Zimmerman (randgalt)
>  * Jay Zarfoss (zarfide)
>  * Eric Tschetter (cheddar)
>  * Ioannis Canellos (iocanel)
>  * Patrick Hunt (phunt)
>  * Mahadev Konar (mahadev)
>  * Luciano Resende (lresende)
>  * Enis Söztutar (enis)
>
>NOW, THEREFORE, BE IT FURTHER RESOLVED, that Jordan Zimmerman
>be appointed to the office of Vice President, Apache Curator, to
>serve in accordance with and subject to the direction of the
>Board of Directors and the Bylaws of the Foundation until
>death, resignation, retirement, removal or disqualification,
>or until a successor is appointed; and be it further
>
>RESOLVED, that the initial Apache Curator PMC be and hereby is
>tasked with the creation of a set of bylaws intended to
>encourage open development and increased participation in the
>Apache Curator Project; and be it further
>
>RESOLVED, that the Apache Curator Project be and hereby
>is tasked with the migration and rationalization of the Apache
>Incubator Curator podling; and be it further
>
>RESOLVED, that all responsibilities pertaining to the Apache
>In

Re: Podling new committer votes

[ant elder]

On Wed, Aug 7, 2013 at 1:57 AM, Marvin Humphrey  wrote:
>
> On Tue, Aug 6, 2013 at 1:04 AM, ant elder  wrote:
> > On Wed, Jul 31, 2013 at 5:43 PM, Marvin Humphrey  
> > wrote:
> >>
> >> On Tue, Jul 30, 2013 at 6:24 AM, ant elder  wrote:
> >> > I've been away so a little slow in finishing this but i have just now 
> >> > made
> >> > an update to the guide, see
> >> > http://svn.apache.org/viewvc?view=revision&revision=1508433
> >>
> >> I guess preserving the 2010 status quo was too much too much to ask for. :)
> >
> > Not sure what to make of that comment or the smiley at the end, i've
> > tried to do this change as gently as possible, can you live with the
> > current text or do you want an update?
>
> Personally, I believe that removing the IPMC notification requirement when
> adding podling committers is a positive change.  The new language is expansive
> for my tastes -- the quarterly reporting requirement in particular seems out
> of place -- but I can live with it.
>
> It wasn't clear to me that there was a pressing need to change the policy,
> hence my pining for the previous hard-won consensus from 2010.  But the die is
> cast...
>

I guess one of the things i'm looking at with this is finding ways to
try to minimize the points at which the Incubator PMC needs to
participate in day to day podling activities because its those that
can lead to the ISSUE03 type flair ups. The pTLP approach is an
interesting idea but an alternative might be to try to have most
podling contact be just via mentors, minimize the time incubating, and
have the Incubator PMC operate with the more hands off approach that
the board uses.

Agree about the sentence about reporting being out of place, i'd only
included that to try to placate anyone who may have been unhappy about
the notification removal. Lets remove the sentence here and move it up
the page to the section on Podling Status Reports, and while doing
that also look at your earlier suggestion of harmonizing the Incubator
podling reporting with the Board's guidelines for TLPs.

   ...ant

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

Re: Podling new committer votes

[ant elder]

On Wed, Jul 31, 2013 at 5:43 PM, Marvin Humphrey  wrote:
>
> On Tue, Jul 30, 2013 at 6:24 AM, ant elder  wrote:
> > I've been away so a little slow in finishing this but i have just now made
> > an update to the guide, see
> > http://svn.apache.org/viewvc?view=revision&revision=1508433
>
> I guess preserving the 2010 status quo was too much too much to ask for. :)
>

Not sure what to make of that comment or the smiley at the end, i've
tried to do this change as gently as possible, can you live with the
current text or do you want an update?

>
> > This does not include anything yet for the request from Bertrand to still
> > require at least one mentor vote but instead goes more towards the
> > suggestion that we don't even need to document a standard for
> > committerpromotions- projects and podlings alike are free to experiment with
> > whatever process they deem appropriate.
>
> Regarding Bertrand's request, I note that while the process for adding
> committers has been relaxed, Mentor participation and IPMC notification are
> still required for PPMC membership.  In my opinion, this is a fine scheme, as
> it is consistent with how the Board requires notification for PMC membership
> but not committership.
>

I was tempted to update that too while editing the new committer text
but as we hadn't discussed it just left it and had planned a new
thread to discuss changing it. I can see the logic in having it work
the same way as the board notifications of new PMC members, but that
also feels a little unnecessary as the PPMC doesn't have any real
standing or binding votes on much at all so i can also appreciate the
Incubator PMC just leaving them to it and staying out of their way.

   ...ant

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

Re: Podling new committer votes

[ant elder]

I've been away so a little slow in finishing this but i have just now made
an update to the guide, see
http://svn.apache.org/viewvc?view=revision&revision=1508433

This does not include anything yet for the request from Bertrand to still
require at least one mentor vote but instead goes more towards the
suggestion that we don't even need to document a standard for
committerpromotions- projects and podlings alike are free to
experiment with
whatever process they deem appropriate. The change does update the podling
report template with a section to note any committers added since the last
report so that we are aware of what is happening.

   ...ant

Re: Podling new committer votes

[ant elder]

Going once, going twice...

   ...ant

On Wed, Jul 10, 2013 at 8:10 PM, Joe Schaefer wrote:

> It doesn't.  People were just being pedantic
> and untrusting of podling participants.  Committers
> have accounts, not formal standing in the org.  There
> is absolutely no reason for the IPMC to inject itself
> in a podling election of a new committer, so let's just
> leave oversight over the voting process to the mentors.
> As a matter of fact, we don't even need to document a
> standard for committer promotions- projects and podlings
> alike are free to experiment with whatever process they
> deem appropriate. Case in point is the Subversion process,
> which essentially promotes new committers through lazy
> consensus alone.
>
> IOW +1 to roll back to pre-May 1, 2007.
>
>
> - Original Message -
> > From: ant elder 
> > To: general@incubator.apache.org
> > Cc:
> > Sent: Wednesday, July 10, 2013 3:04 PM
> > Subject: Re: Podling new committer votes
> >
> > Ok seems everyone so far is ok with changing this, so how far can this
> go...
> >
> > In the "experiment" Joe commented "...basically rolling back the
> > clock
> > to May 1, 2007 on guides/ppmc.html" which is this change
> >
> http://svn.apache.org/viewvc/incubator/public/trunk/content/guides/ppmc.xml?r1=517024&r2=542806
> > which added "Only votes cast by Incubator PMC members are binding".
> > Before then podlings did their own committer votes and the Incubator
> > PMC weren't involved.
> >
> > Good we go back to that? Why does the Incubator PMC need to be notified?
> >
> >...ant
> >
> > -
> > 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: Podling new committer votes

[ant elder]

Ok seems everyone so far is ok with changing this, so how far can this go...

In the "experiment" Joe commented "...basically rolling back the clock
to May 1, 2007 on guides/ppmc.html" which is this change
http://svn.apache.org/viewvc/incubator/public/trunk/content/guides/ppmc.xml?r1=517024&r2=542806
which added "Only votes cast by Incubator PMC members are binding".
Before then podlings did their own committer votes and the Incubator
PMC weren't involved.

Good we go back to that? Why does the Incubator PMC need to be notified?

   ...ant

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

Podling new committer votes

[ant elder]

Looking at the "Voting in a new committer" section at
http://incubator.apache.org/guides/ppmc.html i see that its been
updated since i last looked and now says the Incubator PMC should be
notified twice when a podling is voting in a new committer, once at
the start of the vote and again with the result. Is this really
necessary? The last big discussion about this that i recall was
http://apache.markmail.org/message/v5gwhbpbifqcafqu which resulted in
a single notification, before that in the "experiment" that Joe
started with podlings doing their own committer votes there wasn't any
requirement to notify the Incubator PMC at all -
http://apache.markmail.org/message/mihzgp7jfclj2dcv. So I'd like to
remove this dual notification suggestion from that ppmc guide page
again. Comments?

   ...ant

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

Re: [VOTE] recommend Apache JSPWiki for graduating out of the incubator

[ant elder]

+1

   ...ant

On Sat, Jul 6, 2013 at 11:33 PM, Juan Pablo Santos Rodríguez <
juanpa...@apache.org> wrote:

> Hi all,
>
> The Apache JSPWiki podling is a project which holds a feature-rich and
> extensible WikiWiki engine, built around the standard Java EE components
> Java, Servlets, and Java Server Pages.
>
> We've been incubating for a very long time (almost 6 years); we feel we are
> ready for graduation. Since Jan 2012, we've shipped 2 releases, added 1
> committer, adhered to the Apache Way in deciding technical and
> non-technical issues and revamped our website. We've already done an
> internal VOTE on the proposal which passed with a big majority [#1], and we
> consider the podling namesearch task as completed [#2].
>
> Thus I'd like to ask the IPMC to VOTE on recommending the attached
> graduation proposal to the board.
>
> [+1] yes, go forward
> [+0] don't care
> [-1] nope, because [blocker_reason]
>
>
> The VOTE is open for at least 72h
>
>
> thanks & br,
> juan pablo
>
>
> [#1] http://s.apache.org/654 (an additional vote was received off-list,
> cfr. with http://s.apache.org/tC7)
> [#2] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-33
>
> -
> Proposed Board Resolution Report
> X. Establish the Apache JSPWiki 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 related to JSPWiki, a feature-rich and
>extensible Wiki engine built around the standard
>Java EE components Java, Servlets, and Java Server Pages,
>for distribution at no charge to the public.
>
>NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>Committee (PMC), to be known as the "Apache JSPWiki Project",
>be and hereby is established pursuant to Bylaws of the
>Foundation; and be it further
>
>RESOLVED, that the Apache JSPWiki Project be and hereby is
>responsible for the creation and maintenance of software
>related to JSPWiki, a feature-rich and
>extensible Wiki engine built around the standard
>Java EE components Java, Servlets, and Java Server Pages;
>and be it further
>
>RESOLVED, that the office of "Vice President, Apache JSPWiki" 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 JSPWiki Project, and to have primary responsibility
>for management of the projects within the scope of
>responsibility of the Apache JSPWiki 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 JSPWiki Project:
>
>  * Murray Altheim  
>  * Dirk Frederickx  
>  * Florian Holeczek
>  * Andrew Jaquith  
>  * Glen Mazza   
>  * Harry Metske 
>  * Craig L Russell  
>  * Juan Pablo Santos 
>  * Christoph Sauer 
>
>NOW, THEREFORE, BE IT FURTHER RESOLVED, that Juan Pablo Santos
>be appointed to the office of Vice President, Apache JSPWiki, to
>serve in accordance with and subject to the direction of the
>Board of Directors and the Bylaws of the Foundation until
>death, resignation, retirement, removal or disqualification,
>or until a successor is appointed; and be it further
>
>RESOLVED, that the Apache JSPWiki Project be and hereby
>is tasked with the migration and rationalization of the Apache
>Incubator JSPWiki podling; and be it further
>
>RESOLVED, that all responsibilities pertaining to the Apache
>Incubator JSPWiki podling encumbered upon the Apache Incubator
>Project are hereafter discharged.
>

Re: community graduation vote at jspwiki-dev

[ant elder]

Yay, well done!

Almost 6 years, must be well incubated by now.

   ...ant

On Wed, Jul 3, 2013 at 7:33 PM, Juan Pablo Santos Rodríguez <
juanpablo.san...@gmail.com> wrote:

> Hi all,
>
> a quick email to inform that we've just started the community graduation
> vote at jspwiki-dev :-)
>
>
> br,
> juan pablo
>

Re: Stratos proposal: is it possible to add another initial committer?

[ant elder]

On Wed, Jun 19, 2013 at 12:06 AM, Joe Schaefer wrote:

> He said majority, not everybody ant. Try a little harder to
> understand the written words instead of needing to interject
> your dissonant 2 cents and things will improve around here.
>
>
Don't be so abrasive Joe, I'm a mentor for this podling so I'm at least as
entitled as everyone else to express my view. If you must be pedantic he
said majority of IPMC which we certainly haven't had in this thread, and a
quick tally of comments in this thread so far actually shows most are
saying its fine to do this (unless i've counted wrong?).

   ...ant

Re: Stratos proposal: is it possible to add another initial committer?

[ant elder]

On Tue, Jun 18, 2013 at 11:49 PM, Ross Gardler
wrote:

> It seems clear that the majority of IPMC members believe this change
> on a vote in progress is not acceptable.
>
>
Don't assume its that clear, i think at least some agree with you that this
is just ISSUE3 and kept quiet, thats what i did.

I think its fine, its nothing like changing a release artifact during a
release, IMHO the way to judge it is if the champion for the proposal being
voted on doesn't object to the addition, if the champion is ok then just
carry on.

   ...ant

Re: [VOTE] Accept Stratos proposal as an incubating project

[ant elder]

+1

   ...ant

On Fri, Jun 14, 2013 at 10:49 PM, Ross Gardler
wrote:

> I would like to invite the IPMC vote to accept the Stratos proposal [1].
>
> I want to clarify that this vote is for the Stratos project to enter
> the incubator as a standard podling under the existing incubation
> policy. The acceptance or otherwise of the probationary TLP idea is a
> separate issue that will be explored during the first month of
> incubation, potentially resulting in a further IPMC vote.
>
> This vote is *only* for accepting the Stratos project as a podling.
>
> [ ] +1 Accept the Stratos project as an incubating project
> [ ] +0
> [ ] -1 Do not accept the Stratos project as an incubating project
> because... (provide reason)
>
> It's late on Friday evening here in the UK. I'll let this vote run
> well into next week to allow for the weekend.
>
> Thank you for your votes.
> Ross
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Accept Stratos as an Apache Incubation Project

[ant elder]

I'm also +1 (and excited!) on trying out this as a "probationary TLPs", and
with doing that using the approaches outlined by Ross and others in other
emails on this thread (which is basically having a vote now to accept this
as a podling so we can get started and then working up a probationary TLP
proposal for it to submit to the board meeting). I also commit that as
mentor i'll help try to make that work well while at the same time provide
oversight so that any issue that might arise do get reported.

   ...ant

On Thu, Jun 13, 2013 at 3:12 AM, Ross Gardler wrote:

> So here's a thought...
>
> There have been many discussions about different ways to incubate
> projects. One of the most radical ideas is to dismantle the incubator
> and replace the podling concept with "probationary TLPs" reporting to
> the board. As readers of this list will know I do not support the idea
> of dismantling the IPMC. I believe it does a great job that is not
> easily replaced by a board of nine directors. However, I have always
> acknowledged that the idea has merit under a certain set of
> circumstances.
>
> For me those circumstances are present in the Apache Stratos proposal.
> That is there are sufficient mentors and initial committers who are
> ASF Members that we can be reasonably certain that this project will
> succeed here at the ASF.
>
> I would therefore like to propose that we use Apache Stratos as a test
> case for the "probationary TLP" idea. I've already talked to Chris
> (who is driving the deconstruct the IPMC case) and Ant (who is less
> keen on dismantling the IPMC but wants to see how a probationary TLP
> model will play out). Both have agreed to help with this experiment if
> the IPMC and the Board wish it to proceed. I have not, however,
> discussed it with all the initial comitters or even mentors - I'm
> expecting them to speak up now.
>
> For my part my intention is to get the project set-up and then
> dissolve into the background. I do not intend to monitor the project
> on a day-to-day basis. However, I do promise to help pick up the
> pieces if the experiment should go horribly wrong.
>
> Of course running a single experiment will only allow us to define the
> incubation process for probationary TLPs, It is not going to solve all
> the problems Chris sees in the IPMC. However it will give us an
> opportunity to define the process, ask the board to approve this
> process and thus lay the foundations for other projects wishing to
> follow this path.
>
> So, what do you think?
>
> Ross
>
>
> On 11 June 2013 10:10, Ross Gardler  wrote:
> > It's with great pleasure that I invite the IPMC to review a new
> > proposal [1] for the Apache Incubator. Please let us know if you have
> > any questions or comments - as you will see there are plenty of people
> > on the initial commit list ready and willing to answer your questions.
> >
> > I copy the full text of the proposal for your convenience:
> >
> > = Stratos - A PaaS Framework =
> > == Abstract ==
> > Stratos will be a polyglot
> > [[http://www.gartner.com/it-glossary/platform-as-a-service-paas|PaaS]]
> > framework, providing developers a cloud-based environment for
> > developing, testing, and running scalable applications, and IT
> > providers high utilization rates, automated resource management, and
> > platform-wide insight including monitoring and billing.
> > == Proposal ==
> > The Stratos PaaS framework will encompass four layers:
> >  1. An [[
> http://www.gartner.com/it-glossary/infrastructure-as-a-service-iaas/|IaaS]]-agnostic
> > layer that can interface with a wide variety of IaaS systems to
> > provide elastic resources, and for multiple IaaS infrastructures to be
> > automated at one time (hybrid clouds.)
> >  2. A PaaS Controller with a cloud controller that automates and
> > monitors IaaS runtime interactions, distributes artifacts to the
> > underlying runtimes, deploys workloads, directs runtime traffic to the
> > right runtimes using a tenant-aware elastic load balancer, and
> > provides a portal for monitoring and provisioning of tenants on the
> > system.
> >  3. Foundational Services including security, logging, messaging,
> > registry, storage (relational, file, and noSQL), task management, and
> > billing.  Foundational services will be loosely-coupled to allow
> > swapping in alternate foundational services.
> >  4. A Cartridge Architecture allowing frameworks, servers, and other
> > runtimes to participate in the advantages of the system.  The
> > Cartridge Architecture must support multi-tenant workloads, and
> > provide for various levels of tenant isolation and policy-based
> > control over provisioning.
> >
> > Together these layers offer a foundational layer upon which
> > applications and middleware frameworks can be deployed to speed
> > time-to-market and simplify the development of scalable applications,
> > as well as provide a high level of resource sharing and centralized
> > management that can deliver lowest resou

Re: [DISCUSS] [VOTE] Accept Apache HotdoG into the Incubator

[ant elder]

On Wed, Jun 5, 2013 at 3:54 PM, Mattmann, Chris A (398J)
 wrote:
> Hey Alan,
>
> Great question if there is an "official" policy here. My read is
> that no it's based on tribal knowledge and informal assumption.
>

There is an official policy which is documented on the Incubator
policy page. That says "A Podling has one or more Mentors, one of
which MUST be an Apache Member. " -
http://incubator.apache.org/incubation/Incubation_Policy.html#Mentor

I think its fine to carry on without three, mentors come and go and
can easily be added if more are required.

   ...ant

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

Re: svn commit: r1488735 - in /incubator/public/trunk/tools: NOTICE.txt requirements.txt setup.py src/asf/utils/ src/asf/utils/__init__.py src/asf/utils/config.py src/asf/utils/file.py tests/test_conf

[ant elder]

On Tue, Jun 4, 2013 at 1:46 PM, Greg Stein  wrote:
> On Jun 4, 2013 4:22 AM, "ant elder"  wrote:
>>
>> On Tue, Jun 4, 2013 at 1:45 AM, Greg Stein  wrote:
>>
>> >
>> > Simple as that.
>> >
>>
>> If only.
>>
>> This is the old "what goes in the NOTICE file" debate that has
>> probably caused more emails and confusion than any other topic here.
>>
>> My understanding of the current thinking on this is to only include
>> something in the NOTICE file when there is a clear legal requirement,
>> and that probably means some explicit documentation at ASF Legal for
>> the specific case (i.e raise a Legal JIRA asking). If any attribution
>> is required or wanted then its probably done by including the license
>> / copyright in the LICENSE file or the attribution should be added to
>> the README or to a separate CREDITS type file. There are numerous
>> discussions on this list about that and JIRA's like LEGAL-62 (wasn't
>> there a post from Roy once saying he'd have artifacts removed from the
>> distribution area if people had added random stuff to the NOTICE?).
>>
>> This "when in doubt leave it out" approach has gone a long way at
>> smoothing podling release reviews compared to the olden days.
>
> Seriously? The inserted code uses our own license! Go look at 4(d) and tell
> me we should not insert a notice. It is both Right, and what is demanded by
> our own license.
>
> And this isn't some podling trying to figure shit out. This is some
> Incubator tooling that has explicitly incorporated third party code. We
> absolutely know third party code is there. We should provide notice.
>
> You guys are insane. This is dead simple, or it should be if you all would
> stop being bureaucratic, obstinate meddlers.
>
> -g

Alan asked the question "Would this suffice:" so we're just trying to
help, the hostility isn't necessary.

We're expected to review podling releases and help educate them about
what needs to go into the NOTICE file so we need to understand what
the requirements are. After numerous threads about this, questions to
Legal etc, over some years, AIUI the consensus is that few things
require an entry in the NOTICE file and you should not put things in
there unless explicitly required to. I'm totally happy to be told
thats wrong, its good if we all get a common understanding so podlings
know what to expect. If uou're now suggesting that 3rd party code
under AL2 then section 4(d) requires us to add an entry in our NOTICE
then we should clarify that because most podlings don't do that now,
if there is any question then we should just raise a Legal JIRA to
clarify.

   ...ant

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

Re: svn commit: r1488735 - in /incubator/public/trunk/tools: NOTICE.txt requirements.txt setup.py src/asf/utils/ src/asf/utils/__init__.py src/asf/utils/config.py src/asf/utils/file.py tests/test_conf

[ant elder]

On Tue, Jun 4, 2013 at 1:45 AM, Greg Stein  wrote:

>
> Simple as that.
>

If only.

This is the old "what goes in the NOTICE file" debate that has
probably caused more emails and confusion than any other topic here.

My understanding of the current thinking on this is to only include
something in the NOTICE file when there is a clear legal requirement,
and that probably means some explicit documentation at ASF Legal for
the specific case (i.e raise a Legal JIRA asking). If any attribution
is required or wanted then its probably done by including the license
/ copyright in the LICENSE file or the attribution should be added to
the README or to a separate CREDITS type file. There are numerous
discussions on this list about that and JIRA's like LEGAL-62 (wasn't
there a post from Roy once saying he'd have artifacts removed from the
distribution area if people had added random stuff to the NOTICE?).

This "when in doubt leave it out" approach has gone a long way at
smoothing podling release reviews compared to the olden days.

   ...ant

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

[jira] [Commented] (PODLINGNAMESEARCH-33) Establish whether "Apache JSPWiki" is a suitable name

[ant elder (JIRA)]

[ 
https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13672933#comment-13672933
 ] 

ant elder commented on PODLINGNAMESEARCH-33:


The Incubator podling naming guide which outlines the process and steps is here 
(if you didn't already know) -  http://incubator.apache.org/guides/names.html 

Form that it says:

"Once the information is collected and collated, then ask the trademark team to 
help interpret and analyse these results on the private lists, copying in the 
PPMC. Finally discuss the results of your investigation on the private PPMC 
list. "

> Establish whether "Apache JSPWiki" is a suitable name 
> --
>
> Key: PODLINGNAMESEARCH-33
> URL: 
> https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-33
> Project: Podling Suitable Names Search
>  Issue Type: Suitable Name Search
>Reporter: Juan Pablo Santos Rodríguez
>
> We have to do some investigations to ensure that "Apache JSPWiki" is a 
> suitable name for a TLP. Here are some resources related to this issue:
> http://incubator.apache.org/guides/names.html
> http://www.apache.org/foundation/marks/
> Apache JSPWiki is a Java-based WikiWiki engine, feature-rich and built around 
> standard J2EE components (Java, servlets, JSP). 
> A similar search was perfomed 4 years ago, so this issue is mostly an update 
> on that JIRA. cfr with: https://issues.apache.org/jira/browse/JSPWIKI-547

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: Podling not Poddling

[ant elder]

I think a lot of the "poddling" occurrences might be down to me and my
atrocious spelling and getting it wrong so often i don't even notice it
looks wrong now. I'll try to proofread more closely.

   ...ant

On Thu, May 30, 2013 at 4:32 PM, sebb  wrote:

> I keep seeing the word Poddling being used in mail and now the Wiki
> [1]; however I thought the original and correct name was Podling?
>
> I think we should stick to Podling for all the documentation.
> Anyone mind if I rename the Wiki page?
>
> [1] https://wiki.apache.org/incubator/OlderPoddlingsWithARelease
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: What's the difference between dormant and retired?

[ant elder]

Looking in poddling.xml there are 3 poddlings marked "dormant" and nearly
30 marked "retired". The 3 dormant ones are from ages ago and looking back
in the archives its from when there wasn't a documented retirement process
and people didn't really know what to call it. IMHO the simplest thing to
avoid this confusion would be to just change the status of Juice,
SocialSite, and TripleSoup in podling.xml from dormant to retired. If it
maters at all, AFAICT the main thing back then was some status that stopped
the poddling getting included in the reporting schedule, and either status
does that.

   ...ant

On Thu, May 30, 2013 at 6:30 AM, Christian Grobmeier wrote:

> On Wed, May 29, 2013 at 9:36 PM, ant elder  wrote:
> > I agree with Mark and John, the terms mean different things, and the term
> > "retired" is reasonably well understood now and mentioned in various
> places
> > in the Incubator documentation so wouldn't it be better to keep it as is?
>
> Question comes up from time to time, I don't see it's well understood.
>
> > Are there really any dormant poddlings? If so probably they are really
> > retired now and they should just be changed to that.
>
> Were there ever dormant podlings?
>
> Maybe there is a difference in the terms itself, but when ever we saw
> a podling became inactive we would discuss to retire them. Not sure
> anybody ever said "oh we have no committers, but I have heard next
> month comes a bunch of them". Or if there is just little activity,
> would you really go to a project and tell them they are dormant now
> and will retire in a few months? This all is just more overhead with
> no benefit for me.
>
> Cheers
> Christian
>
> >
> >...ant
> >
> > On Wed, May 29, 2013 at 6:47 PM, Alan Cabrera 
> wrote:
> >
> >> If no one minds I will change them all to dormant, since all are welcome
> >> back to the fold, should they so desire.
> >>
> >>
> >> Regards,
> >> Alan
> >>
> >> On May 27, 2013, at 12:58 PM, Christian Grobmeier 
> >> wrote:
> >>
> >> > On Mon, May 27, 2013 at 9:17 PM, John D. Ament <
> john.d.am...@gmail.com>
> >> wrote:
> >> >> I think the terms mean different things, from the incubator
> perspective.
> >> >>
> >> >> Dormant - we're not active enough right now for a full community, but
> >> >> believe later on we can build it back up.
> >> >> Retired - we've given up all hope of becoming a TLP, instead we think
> >> it's
> >> >> best to archive the code/move it to github/move it to bitbucket and
> >> allow
> >> >> others who want to work on it to just grab it and go.
> >> >
> >> > The difference is one goes to github and one does not?
> >> >
> >> > After this interpretation I would expect dormant projects to retire.
> >> > Retired projects
> >> > can be revived too. It does not matter if there was something on
> GitHub
> >> or not.
> >> >
> >> > Not enough for me to maintain two terms.
> >> >
> >> >>
> >> >> Just my 2 cents..
> >> >>
> >> >>
> >> >> On Mon, May 27, 2013 at 2:10 PM, Christian Grobmeier <
> >> grobme...@gmail.com>wrote:
> >> >>
> >> >>> On Mon, May 27, 2013 at 7:40 PM, Alan Cabrera  >
> >> >>> wrote:
> >> >>>> Yeah, I like the word dormant as well.  Should we rename them all
> to
> >> >>> dormant?
> >> >>>
> >> >>> +1 from me. So far I don't see any difference in the end.
> >> >>>
> >> >>>
> >> >>>
> >> >>>>
> >> >>>> Regards,
> >> >>>> Alan
> >> >>>>
> >> >>>> On May 27, 2013, at 10:32 AM, Upayavira  wrote:
> >> >>>>
> >> >>>>> I think it was just a question of 'retiring' sounding too final.
> >> Using
> >> >>>>> the word 'dormant' was less threatening, and made it more feasible
> >> for
> >> >>>>> the podlings to go, well, dormant.
> >> >>>>>
> >> >>>>> Upayavira
> >> >>>>>
> >> >>>>> On Mon, May 27, 2013, at 05:39 PM, Alan Cabrera 

Re: What's the difference between dormant and retired?

[ant elder]

I agree with Mark and John, the terms mean different things, and the term
"retired" is reasonably well understood now and mentioned in various places
in the Incubator documentation so wouldn't it be better to keep it as is?
Are there really any dormant poddlings? If so probably they are really
retired now and they should just be changed to that.

   ...ant

On Wed, May 29, 2013 at 6:47 PM, Alan Cabrera  wrote:

> If no one minds I will change them all to dormant, since all are welcome
> back to the fold, should they so desire.
>
>
> Regards,
> Alan
>
> On May 27, 2013, at 12:58 PM, Christian Grobmeier 
> wrote:
>
> > On Mon, May 27, 2013 at 9:17 PM, John D. Ament 
> wrote:
> >> I think the terms mean different things, from the incubator perspective.
> >>
> >> Dormant - we're not active enough right now for a full community, but
> >> believe later on we can build it back up.
> >> Retired - we've given up all hope of becoming a TLP, instead we think
> it's
> >> best to archive the code/move it to github/move it to bitbucket and
> allow
> >> others who want to work on it to just grab it and go.
> >
> > The difference is one goes to github and one does not?
> >
> > After this interpretation I would expect dormant projects to retire.
> > Retired projects
> > can be revived too. It does not matter if there was something on GitHub
> or not.
> >
> > Not enough for me to maintain two terms.
> >
> >>
> >> Just my 2 cents..
> >>
> >>
> >> On Mon, May 27, 2013 at 2:10 PM, Christian Grobmeier <
> grobme...@gmail.com>wrote:
> >>
> >>> On Mon, May 27, 2013 at 7:40 PM, Alan Cabrera 
> >>> wrote:
>  Yeah, I like the word dormant as well.  Should we rename them all to
> >>> dormant?
> >>>
> >>> +1 from me. So far I don't see any difference in the end.
> >>>
> >>>
> >>>
> 
>  Regards,
>  Alan
> 
>  On May 27, 2013, at 10:32 AM, Upayavira  wrote:
> 
> > I think it was just a question of 'retiring' sounding too final.
> Using
> > the word 'dormant' was less threatening, and made it more feasible
> for
> > the podlings to go, well, dormant.
> >
> > Upayavira
> >
> > On Mon, May 27, 2013, at 05:39 PM, Alan Cabrera wrote:
> >> They kinda sound the same.  Why didn't podlings want to retire?
>  Does
> >> anyone know?
> >>
> >>
> >> Regards,
> >> Alan
> >>
> >> On May 27, 2013, at 9:14 AM, Christian Grobmeier <
> grobme...@gmail.com>
> >> wrote:
> >>
> >>> I asked the same question in july 2011, and got a response from
> Henri
> >>> Yandell which I repost here:
> >>>
> >>> "Given the PPMC is closed down, I think it has to be retired.
> >>>
> >>> Dormant implies a PPMC is taking some time off.
> >>>
> >>> Basically this is a larger version of "don't be afraid to delete a
> >>> line of code; it's in version control".
> >>>
> >>> Hen"
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Mon, May 27, 2013 at 5:38 PM, Alan Cabrera  >
> >>> wrote:
>  Looking at the podlings.xml and it's not clear to me what the
> >>> difference is.  I'm sure I neglected to read some documentation bit.
> 
> 
>  Regards,
>  Alan
> 
> 
> 
> -
>  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>  For additional commands, e-mail:
> general-h...@incubator.apache.org
> 
> >>>
> >>>
> >>>
> >>> --
> >>> http://www.grobmeier.de
> >>> https://www.timeandbill.de
> >>>
> >>>
> -
> >>> 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
> 
> >>>
> >>>
> >>>
> >>> --
> >>> http://www.grobmeier.de
> >>> https://www.timeandbill.de
> >>>
> >>> -
> >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >>> For additional commands, e-mail: general-h...@incubator.apache.org
> >>>
> >>>
> >
> >
> >
> > --
> > http://www.grobmeier.de
> > https://www.t

Re: [PROPOSAL] MetaModel for the Apache Incubator

[ant elder]

>From the subject line I thought this was going to be another attempt to
sort out the incubator  :-/

   ...ant

On Tue, May 28, 2013 at 7:20 PM, Henry Saputra wrote:

> Dear ASF members,
>
> We would like to propose MetaModel for the incubator.
>
> Matt Franklin will be the Champion for this project and the proposal draft
> is available at:
>
> https://wiki.apache.org/incubator/MetaModelProposal
>
> Looking forward to all of your suggestions and feedback.
>
> Thanks,
>
> Henry Saputra
>
>
>
> -
>
> = MetaModel – uniform data access across datastores =
>
> Proposal for Apache Incubator
>
> == Abstract ==
>
> MetaModel is a data access framework, providing a common interface for
> exploration and querying of different types of datastores.
>
> == Proposal ==
>
> MetaModel provides a uniform meta-model for exploring and querying the
> structure of datastores, covering but not limited to relational databases,
> various data file formats, NoSQL databases, Salesforce.com, SugarCRM and
> more. The scope of the project is to stay domain-agnostic, so the
> meta-model will be concerned with schemas, tables, columns, rows,
> relationships etc.
>
> On top of this meta-model a rich querying API is provided which resembles
> SQL, but built using compiler-checked Java language constructs. For
> datastores that do not have a native SQL-compatible query engine, the
> MetaModel project also includes an abstract Java-based query engine
> implementation which individual datastore-modules can adapt to fit the
> concrete datastore.
>
> === Background ===
>
> The MetaModel project was initially developed by eobject.dk to service the
> DataCleaner application (http://datacleaner.org). The main requirement was
> to perform data querying and modification operations on a wide range of
> quite different datastores. Furthermore a programmatic query model was
> needed in order to allow different components to influence the query plan.
>
> In 2009, Human Inference acquired the eobjects projects including
> MetaModel. Since then MetaModel has been put to extensive use in the Human
> Inference products. The open source nature of the project was reinforced,
> leading to a significant growth in the community.
>
> MetaModel has successfully been used in a number of other open source
> projects as well as mission critical commercial software from Human
> Inference. Currently MetaModel is hosted at http://metamodel.eobjects.org.
>
> === Rationale ===
>
> Different types of datastores have different characteristics, which always
> lead to the interfaces for these being different from one another.
> Standards like JDBC and the SQL language attempt to standardize data
> access, but for some datastore types like flat files, spreadsheets, NoSQL
> databases and more, such standards are not even implementable.
>
> Specialization in interfaces obviously has merit for optimized usage, but
> for integration tools, batch applications and or generic data modification
> tools, this myriad of specialized interfaces is a big pain. Furthermore,
> being able to query every datastore with a basic set of SQL-like features
> can be a great productivity boost for a wide range of applications.
>
> === Initial goals ===
>
> MetaModel is already a stable project, so initial goals are more oriented
> towards an adaption to the Apache ecosystem than about functional changes.
>
> We are constantly adding more datastore types to the portfolio, but the
> core modules have not had drastic changes for some time.
>
> Our focus will be on making ties with other Apache projects (such as POI,
> Gora, HBase and CouchDB) and potentially renaming the ‘MetaModel’ project
> to something more rememberable.
> This includes comply with Apache Software Foundation license for third
> party dependencies.
>
> == Current status ==
>
> === Meritocracy ===
>
> We intend to do everything we can to encourage a meritocracy in the
> development of MetaModel. Currently most important development and design
> decisions have been made at Human Inference, but with an open window for
> anyone to participate on mailing lists and discussion forums. We believe
> that the approach going forward should be more encouraging by sharing all
> the design ideas and discussions in the open, not only just the topics that
> have been “dragged” into the open by third parties.  We believe that
> meritocracy will be further stimulated by granting the control of the
> project to an independent committee.
>
> === Community ===
>
> The community around MetaModel already exists, but we believe it will grow
> substantially by becoming an Apache project. With MetaModel used in a wide
> range of both open and closed source application, both at Human Inference
> (HIquality MDM), it’s open source projects DataCleaner, SassyReader and
> AnalyzerBeans and by other parties (such as the Quipo data warehouse
> automation project), we believe that the critical mass to sustain a
> commu

Re: [VOTE] Accept Apache BeanShell in the Incubator

[ant elder]

Its good that we can help keep BeanShell going by bring it to the ASF, but
my vote here is -1.

There was some discussion on this proposal back in April and one of the
last emails there was this one saying:

"If the intention is to have Beanshell become a part of Apache Commons then
the IPMC feels that Apache Commons should do the work there."

http://mail-archives.apache.org/mod_mbox/incubator-general/201304.mbox/%3ccaaqlglpwaqgtje3pwievcphtgub7gwc5lnazkdruxpnwsgn...@mail.gmail.com%3E

There was no further discussion that i can see after that until this vote
now.

It seems pointless to me to incubate this. Half the committers are ASF
members so they know what they're doing already, we're not going to teach
Sebb anything new about doing releases, and the intention is to become a
sub project of the commons PMC so that PMC is going to be able to provide
any additional oversight that may be needed.

All thats needed is a software grant and IP clearance (which from the
previous discuss thread has already been done?) and start up right away in
Commons.

What is it that we're going to do here at the Incubator with this? What
value are we going to add?

   ...ant

Re: [ANNOUNCE] Apache JSPWiki 2.9.1-incubating released

[ant elder]

On Fri, May 17, 2013 at 5:46 AM, Martin Cooper  wrote:
> I'll be the first to admit that I haven't been following along with the
> progress of this project at all, but I happened to notice that, according
> to the incubator projects page, this project has been in incubation for
> almost 6 years. That's an awfully long time in the incubator. What are the
> prospects of JSPWiki ever making it out of incubation?
>

The prospects are good, its happening right now.

   ...ant

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

Re: [META DISCUSS] talking about the overall state of this PMC

[ant elder]

On Sat, May 11, 2013 at 7:56 PM, Benson Margulies  wrote:
>>
>> If you think it's clear in either direction, call a VOTE. I think that's
>> the only demonstrable way to suggest what's clear and what's not.
>
> Please see several emails from Greg and others on the board@ list
> recently pointing out the inappropriateness of overuse of votes.
>
> If even *one* person strongly objects, there is no consensus. There is
> a strong handful of people who strongly object. So there's no
> consensus. This isn't a majority issue.
>
> I don't uniquely own the role of testing consensus. If you want to
> send a message that tests consensus on your proposal, or more
> accurately tests consensus on the idea of asking the board for
> permission to do a trial run of your proposal, go right ahead. I feel
> confident that it will attract enough firm -1 votes to demonstrate a
> lack of consensus in favor of the idea.
>

I'm with Benson on that particular point, if there is a vote to be
called it should be called by the ones in favour, but i don't think
any vote is needed here.

I do think some small experiments would be better and easier more
gentle and less divisive approach than trying to push through global
Incubator changes. You don't need to be king to go write some tooling,
you don't need Incubator consensus to nominate some poddling people to
the PMC. We could pick a handful of poddlings and ask their champions
to report monthly and see if that makes a difference, and we could
pick another handful and strip away their champion and shepards and
instead just give them two active mentors and see what difference that
makes.

I'm not suggesting a 'direct-to-PMC' trial, i'm suggesting trying
whats been label as "board managed poddlings" or "probationary TLPs"
seeded from existing poddlings. That seems to me a more direct way to
get to Joe's "instill self-governance as early as is feasible" than
electing the poddling people to the Incubator PMC, and it helps avoid
Ross's concern about poddlings "likely to run into problems according
to our collective experience". But for that we do need the question
put to the board first. Even if they if the board replied that
probationary TLPs are batshit insane that would be terrific because
then we could stop having this branch of the discussion keep coming
up.

   ...ant

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

Re: [META DISCUSS] talking about the overall state of this PMC

[ant elder]

Actually I wasn't thinking it would be you Benson who talked to the
board. There are several directors here including a couple on this
thread who've said they support trying this so i thought they could
bring it up informally at the upcoming meeting just to get us an idea
if this is something the board would entertain at all.

I agree with you that there are a lot of details that would need to be
worked out, but right now it doesn't look like anyone is doing that
work so getting some feedback from the board, even if its just "maybe
but we need more details", could help motivate getting that work done
and coming up with a complete proposal. If the board sounded
interested i'd help getting to that and it sounds like there are a few
others here who would too.

I also agree that there isn't consensus in the Incubator PMC to do
this, but I'm not sure we need it. If we come up with a process and
proposal that the board is happy with and poddlings to be guinea pigs
then we don't really need a unanimous Incubator PMC vote to go ahead.
And its just an experiment, so its a much more gentle approach than
the other big bang changes being proposed.

So what does anyone else think, is this worth trying? Greg
specifically, you were keen we try this earlier on in the thread so is
this something you could get us some feedback from the board about?

   ...ant

On Sat, May 11, 2013 at 1:40 PM, Benson Margulies  wrote:
>
> I'm not going to ask the May board meeting anything. There's no
> consensus of this community on 'probationary projects', and, more to
> the point, there are a host of details required to make that a viable
> proposal and no one has filled them in. As I wrote in the report, I
> plan to have a discussion with the board in June if we aren't making
> progress.
>
> A real experiment with 'probationary projects' would have to model the
> entire process of a new project launching with  _no IPMC_ to
> participate in any way. Taking a proposal that has been groomed and
> vetted at the IPMC and then launching the resulting project to the
> board is purely an experiment in board supervision. I'm not going to
> bring the board a proposal to increase their workload based on my
> personal judgement, and there's no consensus here, today, that it's a
> good idea, since there are several people who are eloquently opposed.
>
> My personal thought is this: new project creation is not a 'project',
> it's a function of the Foundation. If the committee currently
> constituted by the board to handle this isn't working well enough, and
> can't agree on what to do, it is an issue for the board to consider.
> The board could decide to keep what we are, arguments and all. It
> could constitute a small (and thus consensus-prone) committee to
> survey the terrain and make a recommendation. It could tell the whiney
> VP to JFDI -- make some decisions and get on with it. (Consensus is
> desirable, but read one of the board resolutions that installs a VP.)
>
>
> On Sat, May 11, 2013 at 2:39 AM, ant elder  wrote:
> > On Fri, May 10, 2013 at 5:33 PM, Eric Johnson  wrote:
> >> If this was a software project, and the appropriate answer was unknown, 
> >> they
> >> you might apply a "lean startup" approach, and figure out how to run tests
> >> to see which way works best.
> >>
> >> Given the number of incubating projects, should be easy to run some
> >> experiments. Then you just need to build up some consensus on how to run 
> >> the
> >> experiments. And how to evaluate the results. Essential to establish some
> >> metrics that will correlate with success. Then run the experiments for a
> >> while (three months, six months?). At the end, you'll have actual data that
> >> will inform a decision.
> >>
> >> Eric.
> >>
> >
> > +1 for experimenting with some new approaches.
> >
> > Several people have been in support of the board managed poddlings or
> > probationary TLPs, lets try that. Ask at the board meeting next week
> > if the board would support the experiment and if so just pick half a
> > dozen existing poddlings to try it.
> >
> >...ant
> >
> > -
> > 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: [META DISCUSS] talking about the overall state of this PMC

[ant elder]

On Fri, May 10, 2013 at 5:33 PM, Eric Johnson  wrote:
> If this was a software project, and the appropriate answer was unknown, they
> you might apply a "lean startup" approach, and figure out how to run tests
> to see which way works best.
>
> Given the number of incubating projects, should be easy to run some
> experiments. Then you just need to build up some consensus on how to run the
> experiments. And how to evaluate the results. Essential to establish some
> metrics that will correlate with success. Then run the experiments for a
> while (three months, six months?). At the end, you'll have actual data that
> will inform a decision.
>
> Eric.
>

+1 for experimenting with some new approaches.

Several people have been in support of the board managed poddlings or
probationary TLPs, lets try that. Ask at the board meeting next week
if the board would support the experiment and if so just pick half a
dozen existing poddlings to try it.

   ...ant

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

Re: [META DISCUSS] talking about the overall state of this PMC

[ant elder]

On Tue, May 7, 2013 at 10:51 AM, ant elder  wrote:
> On Mon, May 6, 2013 at 2:56 AM, Benson Margulies  
> wrote:
>>
>> Discussions on Ross' and Chris' proposals ground to a halt.
>>
>> In my view, there are real issues that drove those discussions, even if
>> those discussions drove some of us to distraction.
>>
>> A bit before the wiki crashed, I wrote:
>>
>> http://wiki.apache.org/incubator/BensonApril2013ProcessProposals
>>
>
> All the rest of this aside, in your wiki page at 2.2 it says - "When a
> podling reports, it is absolutely required to provide a list of
> releases." -  could something like the following change to the report
> template generation script be enough for that (do you need a list or
> is just the last release enough?):
>
> Index: clutch2report.py
> ===
> --- clutch2report.py(revision 1479828)
> +++ clutch2report.py(working copy)
> @@ -80,6 +80,8 @@
>
>  How has the project developed since the last report?
>
> +Date of last release:
> +
>  Please check this [ ] when you have filled in the report for $name.
>
>  Signed-off-by:
>
>...ant

This seems harmless and useful so I'll commit it unless anyone
objects. Benson, let me know if its enough for you. That will at least
give 25% of the things you've suggested in the proposal.

   ...ant

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

Re: [META DISCUSS] talking about the overall state of this PMC

[ant elder]

On Mon, May 6, 2013 at 2:56 AM, Benson Margulies  wrote:
>
> Discussions on Ross' and Chris' proposals ground to a halt.
>
> In my view, there are real issues that drove those discussions, even if
> those discussions drove some of us to distraction.
>
> A bit before the wiki crashed, I wrote:
>
> http://wiki.apache.org/incubator/BensonApril2013ProcessProposals
>

All the rest of this aside, in your wiki page at 2.2 it says - "When a
podling reports, it is absolutely required to provide a list of
releases." -  could something like the following change to the report
template generation script be enough for that (do you need a list or
is just the last release enough?):

Index: clutch2report.py
===
--- clutch2report.py(revision 1479828)
+++ clutch2report.py(working copy)
@@ -80,6 +80,8 @@

 How has the project developed since the last report?

+Date of last release:
+
 Please check this [ ] when you have filled in the report for $name.

 Signed-off-by:

   ...ant

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

Re: [VOTE] Release Apache Marmotta 3.0.0-incubating (RC8)

[ant elder]

Come back after being away its a bit hard to tell where this vote is but i
think its still open and you're wondering what to do.

+1 on the release from me.

I see the issues being discussed about the legal docs and i see on you're
addressing them as much as you can workout and nothing looks like a
blocking issue to me.

Whether a release must be redone or just fixed later comes up quite a lot,
there was some discussion around this a little while ago, see here  -

http://mail-archives.apache.org/mod_mbox/incubator-general/201208.mbox/%3CCABD8fLWD5UHFn8Y7S6qChQcoWkgKrx23oFVaEgb0cg26vKx3pQ%40mail.gmail.com%3E

- where the conclusion was there is some wriggle room for incubation
releases and some imperfections can be left to be resolved in later
releases.

   ...ant


On Mon, Apr 15, 2013 at 2:40 PM, Sebastian Schaffert
wrote:

> Dear all,
>
> Apache Marmotta is an implementation of the Linked Data Platform and
> accompanying services. In the last months, we have migrated our old source
> code to the Apache infrastructure and tried to adapt the Apache policies in
> all parts of the project. In particular, we have fixed all remaining
> licensing issues and spent much time on developing the appropriate NOTICE
> and LICENSE files.
>
> We have executed 8 voting cycles on release candidates throughout the last
> weeks and we think we are now (finally) ready to really do the release.
>
> The vote on release candidate RC8 has been open for more than 72 hours on
> the developer mailinglist [1]. After closing the vote, we have the
> following voting results:
> - 2 binding votes (from the mentors Andy Seaborne and Nandana
> Mihindukulasooriya)
> - 6 non-binding votes (the remaining developers)
>
> I'd therefore like to ask now the general incubator to check our release
> candidate. Since this is our first release, please check thoroughly, I'd
> like to be sure we did not miss anything. The release notes (fixed issues)
> are available at the Jira Issue Tracker [2].
>
>
> [1]
>
> http://markmail.org/message/uncutapltb3mopgy?q=list:org%2Eapache%2Emarmotta%2Edev
> [2]
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314321&version=12323952
>
>
> Please find attached below the concrete details on the release and on the
> vote.
>
> Greetings,
>
> Sebastian
>
>
> ===
> A candidate for the Marmotta 3.0.0-incubating release is available at:
>
> https://dist.apache.org/repos/dist/dev/incubator/marmotta/3.0.0-incubating/
>
> The release candidate is based on the sources tagged with 3.0.0-incubating
> in:
>
> https://git-wip-us.apache.org/repos/asf/incubator-marmotta.git
>
> The release candidate consists of the following source distribution
> archives:
> - apache-marmotta-3.0.0-incubating-src.[zip|tar.gz]
>   SHA1 of ZIP: ac0cc9aa641a37fea96adaf128e44b0d6a06cc8f
>   SHA1 of TGZ: e176b0b7816e5c334a3d8dccb960cda0b64d4b4c
>
> In addition, the following supplementary binary distributions are provided:
> - apache-marmotta-3.0.0-incubating-installer.[zip|tar.gz]
>   SHA1 of ZIP: 4e5bf3e5c59e04bea3776d76c37990fa1efd6995
>   SHA1 of TGZ: a8736dd1700c7993762dea0446a23c2d314e03ec
> - apache-marmotta-3.0.0-incubating-ldpath.[zip|tar.gz]
>   SHA1 of ZIP: 3dab792c935bf0380c98fb2767ea75653df3b9b1
>   SHA1 of TGZ: 237040387801aa6538fd07e3c75265b06e3d4ce3
> - apache-marmotta-3.0.0-incubating-webapp.[zip|tar.gz]
>   SHA1 of ZIP: 7784ee71b665782f1011a8d1333524c825b90c6d
>   SHA1 of TGZ: 217e17709e6e84ffe755841ac69f850538e867f7
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/content/repositories/orgapachemarmotta-093/
>
> Please vote on releasing this package as Apache Marmotta 3.0.0-incubating.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Marmotta PMC votes are cast.
>
> [ ] +1 Release this package as Apache Marmotta 3.0.0-incubating
> [ ]  0 I don't feel strongly about it, but I'm okay with the release
> [ ] -1 Do not release this package because...
>

Re: Incubator structure (was Re: Vote on personal matters: majority vote vs consensus)

[ant elder]

On Thu, Apr 4, 2013 at 2:08 PM, Ross Gardler wrote:


> Having said that, here's an idea that builds on your proposal. There is
> already the opportunity to name the board as the sponsoring organisation.
> Why not say "where the board is willing to sponsor the project it can go
> straight to TLP" (e.g. exactly as Apache Steve did). This would allow a
> larger scale experiment around Chris' proposal but provides the opportunity
> for the board to control how much of the oversight role is pushed towards
> it and how much remains with the IPMC.
>
> Ross
>

If the board are ok with that experiment then i think it sounds like an
fine thing to try.

   ...ant

Re: Incubator structure (was Re: Vote on personal matters: majority vote vs consensus)

[ant elder]

On Thu, Apr 4, 2013 at 9:42 AM, Upayavira  wrote:

> Just a thought.
>
> Chris' solution says 'make mentors the initial PMC'. They vote in other
> project team members as appropriate to be peers. This creates a positive
> egalitarian setup which mirrors that of a PMC, which is a good thing.
>
>
There was a poddling a while ago that had this approach of having the
initial PPMC be just the mentors. It ended in an argument when the
PPMC/mentors voted in a new committer that the other committers weren't so
keen on, and it ended with the PPMC rebooted to add in all the initial
committers. That approach also goes against the change we made so that
poddlings could vote in their own committers without needing binding votes
from Incubator PMC members.

   ...ant

Re: Incubator structure (was Re: Vote on personal matters: majority vote vs consensus)

[ant elder]

On Wed, Apr 3, 2013 at 3:25 PM, Ross Gardler wrote:

> On 3 April 2013 14:41, ant elder  wrote:
>
> > On Wed, Apr 3, 2013 at 2:12 PM, Noah Slater  wrote:
> >
> > > Thanks for the clarification, Ant. Is the documentation ignored?
> > Whenever I
> > > look through it, it seems like the problem is that it is incomplete and
> > > confusing. It's hardly a wonder people disagree. ;) (This is just a bit
> > of
> > > rhetoric. I hardly mean to imply the documentation is responsible for
> the
> > > whole problem...)
> > >
> > >
> > Yep I don't know that "ignored" is the best word, and i agree the doc can
> > be incomplete and confusing. For another example take the minimum
> > graduation requirements documented on the policy page:
> >
> > "The project is not highly dependent on any single contributor (there are
> > at least 3 legally independent committers and there is no single company
> or
> > entity that is vital to the success of the project)"
> > - http://incubator.apache
> > .org/incubation/Incubation_Policy.html#Graduating+from+the+Incubator
> >
>
> Great example - it's reasonably clear but incorrect (as well as being
> imprecise as you illustrate). We don't require a minimum of 3 independent
> committers. We require a community that doesn't exclude anyone.
>
> I don't have the time to look it up but there was quite some discussion
> about this point some time ago. I seem to remember the IPMC agreeing the
> docs need to be updated.
>
> Ross
>
>
That would be further evidence that the doc is often "ignored" right?

(Would be interested in a link if you/anyone can find it, to see if a
decision was clearly made about this)

   ...ant

Re: Incubator structure (was Re: Vote on personal matters: majority vote vs consensus)

[ant elder]

On Wed, Apr 3, 2013 at 2:12 PM, Noah Slater  wrote:

> Thanks for the clarification, Ant. Is the documentation ignored? Whenever I
> look through it, it seems like the problem is that it is incomplete and
> confusing. It's hardly a wonder people disagree. ;) (This is just a bit of
> rhetoric. I hardly mean to imply the documentation is responsible for the
> whole problem...)
>
>
Yep I don't know that "ignored" is the best word, and i agree the doc can
be incomplete and confusing. For another example take the minimum
graduation requirements documented on the policy page:

"The project is not highly dependent on any single contributor (there are
at least 3 legally independent committers and there is no single company or
entity that is vital to the success of the project)"
- http://incubator.apache
.org/incubation/Incubation_Policy.html#Graduating+from+the+Incubator

That seems reasonably clear. Based on that policy we have people saying a
poddling can't graduate yet because they don't have three independent
committers. Or maybe they do have three committers listed but some haven't
been active for ages. How long is ages though? Or what is active - actually
committing something or is the odd email enough? Or what about if we think
they would vote in a new person if someone came along in the future, maybe
thats enough? Or how about if some of the mentors agree to stick around on
the new PMC to make up the numbers? All of those things get debated. Not so
long ago we had a "what to do with small slow poddlings" debate and a
couple of small poddlings were allowed to graduate anyway despite not quite
meeting that minimum requirement, then just a little while later Chuwka in
a very similar state was nearly retired.

   ...ant

Re: Incubator structure (was Re: Vote on personal matters: majority vote vs consensus)

[ant elder]

On Tue, Apr 2, 2013 at 5:26 PM, Noah Slater  wrote:

> As far as I understand your comment, Ant, you mean to say that he problem
> is that there is too much variation in opinion and approach. (Primarily, I
> understand, in relation to releases.)
>
>
Hi Noah, i suggested that one of the problems was the variation in opinion
and in who happens to decide to be active at particular moment means it can
be hard to tell what the reaction will be to any particular action, and
once there is a disagreement the diversity of opinion means it can be hard
to find any consensus.

I didn't offer any solutions yet, just getting some agreement on what the
issues are first would be good. But I'm not convinced more doc is going to
help this much, and moving the doc to be under the control of comdev would
IMHO just make the doc even more ignored than it is today.

   ...ant

Re: Incubator structure (was Re: Vote on personal matters: majority vote vs consensus)

[ant elder]

On Tue, Apr 2, 2013 at 10:17 AM, Upayavira  wrote:

> Chris,
>
> What I was trying to do with this particular thread is to identify the
> problems the incubator has before deciding on solutions. If we can get a
> common agreement on that, specific solutions will be much easier for us
> all to accept.
>
> So, my question to you is are you able/willing to articulate the
> problems do you see the incubator as having, that need to be solved?
> That is, without (yet) suggesting how it should be fixed?
>
> I'd be very curious to hear how you see it.
>
> Upayavira
>
>
This is what i think is a big part of the problem:

The PMC is so big and diverse, and made up of people who just join by
choice not by being invited, and sometimes they don't even care about the
PMC they just join to mentor their poddling, so there isn't so much sense
of respect or working together. Those people all have different points of
view and expectations on how things should happen, some are liberal while
some are more conservative, and the set of people who are active varies
over time.

So what that means is it can be hard to tell what the reaction will be to
any particular action, and when something unexpected happens its
understandable that sometimes someone is going to get surprised or upset.

Take voting on a release as an example, sometimes that will get three quick
+1s with minimal review, sometimes it will take weeks of pleading for
votes, sometimes a problem will be pointed out but people will still vote
+1 anyway, sometimes it will be +1'd with a request to fix the issue later,
other times it will be demanded that a respin is done to fix the issue.
Theres no way of knowing really, it just depends who happens to be around
and active at the time.

And the same thing happens for just about every situation where there is
some rule or policy or guideline documented.

There are things I think we could do to fix some of that, but i agree with
Upayavira, we would need some common understanding and agreement on what
the issues are first.

   ...ant

Re: Vote on personal matters: majority vote vs consensus

[ant elder]

On Fri, Mar 29, 2013 at 8:47 AM, Matthias Friedrich  wrote:

>
> As someone who is relatively new to the ASF and who's first behind the
> scenes contact with Apache was the incubation process, I can tell that
> this is absolutely true. Podlings find themselves in a kafkaesque
> world where many rules are undocumented or can only be found in
> old mailing list discussions.
>
> Apache and this list especially can feel like a really hostile place
> for newbies.
>
> Regards,
>   Matthias
>

Unfortunately it can feel quite hostile to even not so newbies too.
Once out of the Incubator its a much more friendly place though.

   ...ant

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

Re: Vote on personal matters: majority vote vs consensus

[ant elder]

On Thu, Mar 28, 2013 at 5:01 PM, Joe Schaefer  wrote:

>
> As Doug points out, votes are structured away
> from the status quo- we don't ever vote to
> continue on with previously agreed to issues
> just to circumvent the voting process.
>

Ok thanks Joe and Doug. So to be absolutely clear, the wording of
votes is important and votes need to be structured the right way. You
can tell how to do it by looking at if the resulting action changes
the status quo. Using the previous example if Joe wants to send an
email to me to saying I'm now not a mentor, or remove me from a status
file, etc then thats changing the status quo so now requires a 75%
vote. Right?

   ...ant

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

Re: Vote on personal matters: majority vote vs consensus

[ant elder]

On Thu, Mar 28, 2013 at 2:17 PM, Joseph Schaefer  wrote:
> No more so than they already had.
>

It does Joe, let me give you a more clear example.

Lets imagine i've done something that you deem shows i'm a terrible
incubator mentor, and its not the first time.

There's a big debate within the PMC, no clear consensus, so in the end
you say enough is enough and call a vote to remove me so i don't do
any more damage - a vote on removing ant.

With this new supermajority approach you'd need 75% or more of voters
to agree with you to get me gone.

Alternatively, you could say enough is enough and to end the debate
you're going to call a vote to demonstrate i've the PMCs support - a
vote on letting ant stay on. That sounds like you're being nice, but
in fact you're being clever, because now you only need 25% of voters
to vote -1 and i'm gone.

25% is much easier to get than the 75% in the previous vote example.

The problem here i think is that the policy is being rushed through
and people are only thinking of the voting people to the PMC case
whereas the policy is going to apply much more widely that  - to all
votes on personal matters - so lots of scope for wording bias.

Isn't this the case? Apologies in advance for the noise if my logic is
screwed up somewhere.

   ...ant

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

Re: Vote on personal matters: majority vote vs consensus

[ant elder]

No what it means Joe is that who chooses the wording of the vote gets
a lot of control the outcome.

   ...ant

On Thu, Mar 28, 2013 at 1:25 PM, Joseph Schaefer  wrote:
> Waah.  Look this just DEFINES consensus as 75% instead
> of the old 100%.  It doesn't throw consensus out the window.
> Please stop with all of these exaggerations and try to
> self-moderate- half of the volume in these debates is all
> you talking to yourself.
>
>
> On Mar 28, 2013, at 9:18 AM, ant elder  wrote:
>
>> On Thu, Mar 28, 2013 at 12:44 PM, Benson Margulies
>>  wrote:
>>> It appears to me that we have a consensus here on using a majority system
>>> with a 3/4 supermajority. I'd like to establish the existence of this
>>> consensus with a minimum of fuss, and begin to stop wasting everyone's
>>> time. Our goal here is to achieve consensus, not to hold votes. So, I'm
>>> going to treat this as a lazy consensus issues. I'm going to watch this
>>> thread for an additional 72 hours. If anyone objects to this consensus,
>>> send along a brief summary of your objection with a -1. If there are, in
>>> fact, substantive objections, I'll organize a separate vote process to
>>> resolve this. Please do not debate objections here, we'll do that later if
>>> we have to. Everyone's had a fair opportunity to state their opinion, so
>>> the only thing we're doing now is ensuring that no one is harboring a
>>> serious objection that I have somehow overlooked. Acquiescing in this
>>> process does not prejudice the discussion of changing the PMC.
>>>
>>
>> I'd prefer we stick with consensus but not enough to vote against this.
>>
>> However as no one has mentioned this I do think its worth pointing out
>> that when using supermajority instead of consensus or simple majority
>> then the phrasing of the vote becomes important.
>>
>> Eg. Say 16 people participate in a vote then:
>> "Throw the guy out" needs 5 -1s to stop it happening
>> "Let the guy stay" needs 12 +1s to make it happen.
>>
>>   ...ant
>>
>> -
>> 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: Vote on personal matters: majority vote vs consensus

[ant elder]

On Thu, Mar 28, 2013 at 12:44 PM, Benson Margulies
 wrote:
> It appears to me that we have a consensus here on using a majority system
> with a 3/4 supermajority. I'd like to establish the existence of this
> consensus with a minimum of fuss, and begin to stop wasting everyone's
> time. Our goal here is to achieve consensus, not to hold votes. So, I'm
> going to treat this as a lazy consensus issues. I'm going to watch this
> thread for an additional 72 hours. If anyone objects to this consensus,
> send along a brief summary of your objection with a -1. If there are, in
> fact, substantive objections, I'll organize a separate vote process to
> resolve this. Please do not debate objections here, we'll do that later if
> we have to. Everyone's had a fair opportunity to state their opinion, so
> the only thing we're doing now is ensuring that no one is harboring a
> serious objection that I have somehow overlooked. Acquiescing in this
> process does not prejudice the discussion of changing the PMC.
>

I'd prefer we stick with consensus but not enough to vote against this.

However as no one has mentioned this I do think its worth pointing out
that when using supermajority instead of consensus or simple majority
then the phrasing of the vote becomes important.

Eg. Say 16 people participate in a vote then:
"Throw the guy out" needs 5 -1s to stop it happening
"Let the guy stay" needs 12 +1s to make it happen.

   ...ant

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

Re: Vote on personal matters: majority vote vs consensus

[ant elder]

On Wed, Mar 27, 2013 at 4:23 PM, Ross Gardler
 wrote:
> On 27 March 2013 15:54, ant elder  wrote:
>
>> On Wed, Mar 27, 2013 at 11:55 AM, Benson Margulies
>>  wrote:
>> Ok, i propose we have an "experiment" [1] where we try having a mentor
>> or two who are not PMC members. Have some other experienced mentors
>> helping to make sure nothing unfixable can go wrong, and just see how
>> it goes for a while, reporting each month with the status.
>>
>
> In general I'm all for more mentors, but if they are not IPMC members where
> will the binding votes for releases come from?
>

>From PMC members on general@ which is what happens for lots of
poddlings now anyway as most don't get three mentors voting on their
releases and have to come to general@. I'm not suggesting that we
start off the experiment with a poddling having all non-PMC mentors so
there would be other mentors with binding votes being active in the
poddling.

   ...ant

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

Re: Vote on personal matters: majority vote vs consensus

[ant elder]

On Wed, Mar 27, 2013 at 11:55 AM, Benson Margulies
 wrote:

>
> Or it might 'work', but some might feel that this large,
> diffuse, group, operating by majority rules is either inconsistent with
> Apache policy or a bad example for the podlings.

Thats more how i see it. Using consensus instead of majority votes is
one of the main things that makes the ASF special, so we should avoid
changing from that if we can, for both those reasons you suggest. And
there is nothing that needs this changed presently so IMHO its not
necessary to change anything.

> I'd like to see us find more
> incremental changes that help further

Ok, i propose we have an "experiment" [1] where we try having a mentor
or two who are not PMC members. Have some other experienced mentors
helping to make sure nothing unfixable can go wrong, and just see how
it goes for a while, reporting each month with the status.

Maybe it will fail and we'll know not to try that again, but i think
and hope it should work ok. If it does work ok then changing to make
this more common would avoid a lot of the times were we need to make
new not well known people PMC members or have these debates,  which
solves part of the problem here.

If that works then there are some further small incremental changes we
can make which will also help with reasons for people needing to join
the PMC, and those will help with the PMC size and disparity issues.

Wouldn't a small experiment like this be worth trying before we drop
something as fundamental as using consensus?

   ...ant

[1] We tried a similar "experiment" with the change back to allow
poddlings to vote for their own committers again which was similarly
controversial before it was tried -
http://mail-archives.apache.org/mod_mbox/incubator-general/201008.mbox/%3C974721.3581.qm%40web54401.mail.re2.yahoo.com%3E

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

Re: Vote on personal matters: majority vote vs consensus

[ant elder]

On Mon, Mar 25, 2013 at 7:52 AM, ant elder  wrote:

> Your second suggestion sounds like the thing to do to me - separating
> IPMC-ship and Mentor-ship - that would solve several of the problems
> we've being having including this one, it would open up a much bigger
> pool of potential mentors, and IPMC'ers would get much more visibility
> of people as they work here which should make the PMC voting easier.

Ok some people sound like they like this suggestion, and some others
have expressed concern about the lack of a binding vote. I'd like to
try this, perhaps as a sort of experiment like we've done for other
changes in the past. I'll post a more articulate proposal in a new
thread but doesn't anyone else have any feelings about this either
way?

   ...ant

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

Re: Vote on personal matters: majority vote vs consensus

[ant elder]

On Mon, Mar 25, 2013 at 8:36 AM, Upayavira  wrote:

>
> Now, you might argue that mentoring is a lot more than voting, but we
> could create another bottleneck in getting release votes through,
> requiring votes from incubator PMC members who are not particularly
> focused on the podling.
>

Thats exactly what i would argue, mentoring is a lot more than voting
on releases. Many (most?) poddlings don't get three mentor votes on
releases anyway and have to come to general@ so changing to have
non-PMC mentors isn't going to make that worse than it already is.

   ...ant

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

Re: Identifying and removing inactive mentors

[ant elder]

On Mon, Mar 25, 2013 at 7:21 AM, Matthias Friedrich  wrote:
> On Monday, 2013-03-25, Alex Karasulu wrote:
>> On Sun, Mar 24, 2013 at 10:43 PM, Bertrand Delacretaz <
>> bdelacre...@apache.org> wrote:
> [...]
>>> IMO it's the podlings who need to make sure they have enough mentor
>>> energy available - they are best placed to judge that, and delegating
>>> that to them scales much better than burdening the incubator PMC.
>
>> In total agreement. No one knows better than the podling.
>
> I was never sure how much mentoring our podling was supposed to get.
> And I certainly wouldn't have reported an inactive mentor because
> I had no idea what kind of discussions that would have started.
>

And thats going to be the problem with most poddlings i would guess.
They don't really know what to expect, and, they would be put off by
worry of causing trouble.

I was on an Incubating poddling once which had a couple of not
terribly active mentors, i'm not sure that they read the dev list
regularly. However they were both experienced ASF oldtimers and if you
pinged them for help they jumped in and helped out which on several
occasions proved invaluable (it was a bit of a troubled poddling).

The problem with making some new rule, eg must sign reports, is that
some people will then just make sure they do that without changing the
activeness of their mentoring.

   ...ant

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

Re: Vote on personal matters: majority vote vs consensus

[ant elder]

On Sat, Mar 23, 2013 at 8:02 PM, Christian Grobmeier
 wrote:
> Hi,
>
> following a thread on private@, I would like to bring the discussion
> on how we vote on nominated IPMC members.
>
> We had the case were one person was nominated and received three +1.
> Another voter had concerns an voted -1. The vote has been marked as
> failed, because no consensus could be found.
>
> Now this was my understanding and I was surprised that the vote failed:
>
> "Votes on procedural issues follow the common format of majority rule
> unless otherwise stated."
> http://www.apache.org/foundation/voting.html
>
> Joe brought this up before around 14 months:
> http://s.apache.org/majorityinipmc
>
> We have not found a consens, but one might highlight Roy Fieldings e-mail:
> http://s.apache.org/royCommitterVeto
>
> I still think like Joe and feel that consensus should not apply in the
> IPMC. We are way to different to normal PMCs. As IPMC members we have
> no code which we can veto. Its all about accepting podlings,
> discussing rules and mentoring.
>
> We also have 172 IPMC members to date (according committer index).
> Most of the people are not seen often; we have many awol mentors.
> Currently becoming an IPMC member is necessary to become a Mentor. It
> always felt wrong to me. I think one should be able to become a Mentor
> and finally be able to join the IPMC and discuss rules, when he has
> shown merit.
>
> With an IPMC of that size it becomes more and more easy to get a -1.
>
> Personally I would like to see the IPMC separating IPMC-ship and
> Mentor-ship. I have proposed this already, but it seems nobody else
> except me wants that. So I am proposing now to reconsider Joes
> original proposal and change our community voting to a majority voting
> unless we restructure the IPMC.
>
> I am sorry to bring this lengthy discussion up again, but from the
> original thread I have learned a couple of other IPMC members are
> thinking similar on majority / consensus.
>
> I would also like to suggest that this time we finish the discussion
> with a vote.
>
> Cheers
> Christian
>

A concern with changing to majority votes instead of consensus is that
it will get misunderstood and at some point someone will think its ok
to do that in other projects too.

Your second suggestion sounds like the thing to do to me - separating
IPMC-ship and Mentor-ship - that would solve several of the problems
we've being having including this one, it would open up a much bigger
pool of potential mentors, and IPMC'ers would get much more visibility
of people as they work here which should make the PMC voting easier.

   ...ant

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

Re: [INVALID][RESULT][VOTE] Accept MRQL into the Incubator

[ant elder]

Please find that the MRQL mailing lists have been created and are
ready to be used for further discussion:

  d...@mrql.incubator.apache.org
  u...@mrql.incubator.apache.org
  priv...@mrql.incubator.apache.org

Would everyone named on the proposal please go subscribe to them, and
happy MRQL'ing.

   ...ant

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

Re: [RESULT][VOTE] Accept MRQL into the Incubator

[ant elder]

On Mon, Mar 18, 2013 at 10:31 AM, Bertrand Delacretaz
 wrote:
> On Sun, Mar 17, 2013 at 4:01 PM, Mohammad Nour El-Din
>  wrote:
>> On Sun, Mar 17, 2013 at 11:49 AM, Alex Karasulu wrote:
>>> We're also missing Ant Elder from the Nominated Mentors list no?
>> Fixed...
>
> I have pasted the current version of the proposal below, so that this
> list has it correctly archived.
>

Actually, I believe the following is is the current version following
the vote and discussion. If there are any further personnel changes
can we please have the discussion on private@ to make sure there is
consensus before posting here.

= Abstract =

MRQL is a query processing and optimization system for large-scale,
distributed data analysis, built on top of Apache Hadoop and Hama.

= Proposal =

MRQL (pronounced ''miracle'') is a query processing and optimization
system for large-scale, distributed data analysis. MRQL (the
!MapReduce Query Language) is an SQL-like query language for
large-scale data analysis on a cluster of computers. The MRQL query
processing system can evaluate MRQL queries in two modes: in
!MapReduce mode on top of [[http://hama.apache.org/|Apache Hadoop]] or
in Bulk Synchronous Parallel (BSP) mode on top of
[[http://hama.apache.org/|Apache Hama]]. The MRQL query language is
powerful enough to express most common data analysis tasks over many
forms of raw ''in-situ'' data, such as XML and JSON documents, binary
files, and CSV documents. MRQL is more powerful than other current
high-level !MapReduce languages, such as Hive and !PigLatin, since it
can operate on more complex data and supports more powerful query
constructs, thus eliminating the need for using explicit !MapReduce
code. With MRQL, users will be able to express complex data analysis
tasks, such as !PageRank, k-means clustering, matrix factorization,
etc, using SQL-like queries exclusively, while the MRQL query
processing system will be able to compile these queries to efficient
Java code.

= Background =

The initial code was developed at the University of Texas of Arlington
(UTA) by a research team, led by Leonidas Fegaras. The software was
first released in May 2011. The original goal of this project was to
build a query processing system that translates SQL-like data analysis
queries to efficient workflows of !MapReduce jobs. A design goal was
to use HDFS as the physical storage layer, without any indexing, data
partitioning, or data normalization, and to use Hadoop (without
extensions) as the run-time engine. The motivation behind this work
was to build a platform to test new ideas on query processing and
optimization techniques applicable to the !MapReduce framework.

A year ago, MRQL was extended to run on Hama. The motivation for this
extension was that Hadoop !MapReduce jobs were required to read their
input and write their output on HDFS. This simplifies reliability and
fault tolerance but it imposes a high overhead to complex !MapReduce
workflows and graph algorithms, such as !PageRank, which require
repetitive jobs. In addition, Hadoop does not preserve data in memory
across consecutive !MapReduce jobs. This restriction requires to read
data at every step, even when the data is constant. BSP, on the other
hand, does not suffer from this restriction, and, under certain
circumstances, allows complex repetitive algorithms to run entirely in
the collective memory of a cluster. Thus, the goal was to be able to
run the same MRQL queries in both modes, !MapReduce and BSP, without
modifying the queries: If there are enough resources available, and
low latency and speed are more important than resilience, queries may
run in BSP mode; otherwise, the same queries may run in !MapReduce
mode. BSP evaluation was found to be a good choice when fault
tolerance is not critical, data (both input and intermediate) can fit
in the cluster memory, and data processing requires complex/repetitive
steps.

The research results of this ongoing work have already been published
in conferences (WebDB'11, EDBT'12, and !DataCloud'12) and the authors
have already received positive feedback from researchers in academia
and industry who were attending these conferences.

= Rationale =

 * MRQL will be the first general-purpose, SQL-like query language for
data analysis based on BSP.
 . Currently, many programmers prefer to code their !MapReduce
applications in a higher-level query language, rather than an
algorithmic language. For instance, Pig is used for 60% of Yahoo!
!MapReduce jobs, while Hive is used for 90% of Facebook !MapReduce
jobs. This, we believe, will also be the trend for BSP applications,
because, even though, in principle, the BSP model is very simple to
understand, it is hard to develop, optimize, and maintain non-trivial
BSP applications coded in a general-purpose programming language.
Currently, there is no widely acceptable declarative BSP query
language,

Re: [RESULT][VOTE] Accept MRQL into the Incubator

[ant elder]

On Sat, Mar 16, 2013 at 11:07 PM, Edward J. Yoon wrote:

> The required action has been taken, so let me close this thread again.
> I apologize again for my mistake.
>
> The Sponsors are changed as following:
>
>  == Champion ==
>
>   * Alex Karasulu 
>
>   == Nominated Mentors ==
>
>* Alex Karasulu 
>* Mohammad Nour 
>* Alan Cabrera 
>
> The following IPMCers voted in favor:
>
>  * Mohammed Nour El-Din
>  * Alex Karasulu
>  * Tommaso Teofili
>  * Chris Mattmann
>  * Christian Grobmeier
>  * Niall Pemberton
>
> Thanks.
>
>
Actually Edward we've discussed this within the Incubator PMC and the plan
is to respect the original vote and leave you on as champion and mentor,
the only change being the additional mentors. You're an Officer of the ASF
which is close enough and there are now a lot of mentors who can provide
any additional help should it be needed. Sorry from the Incubator that this
got into such a mess.

   ...ant

Re: [INVALID][RESULT][VOTE] Accept MRQL into the Incubator

[ant elder]

On Fri, Mar 15, 2013 at 1:28 PM, Alex Karasulu  wrote:

> On Fri, Mar 15, 2013 at 3:01 PM, ant elder  wrote:
>
> > On Fri, Mar 15, 2013 at 12:16 PM, Alex Karasulu  > >wrote:
> >
> > > On Fri, Mar 15, 2013 at 10:21 AM, Edward J. Yoon <
> edwardy...@apache.org
> > > >wrote:
> > >
> > > > > could you please close the "Create MRQL" tasks in the Infra Jira
> > until
> > > > > the situation has been cleared up. Whenever this all has been
> sorted
> > > > > out you can reopen the issues.
> > > >
> > > > Sure.
> > > >
> > > > Since this might not be fixed soon, proposal can be changed
> > > > (especially corporation volunteers). And, thank you for your
> > > > suggestion, but I'm already in initial committers list.
> > > >
> > > > To IPMC, I would request you to focus more on reviewing Proposal in
> > > > the future. The opportunity of MRQL should not be faded by my
> mistake.
> > > >
> > > >
> > > Bravo! There was no malice in the vote, just a simple mistake. If need
> > be I
> > > or Mo can take on the Champion role.
> > >
> > > Are there others from the IPMC that would be interested in mentoring
> > MRQL?
> > >
> > > --
> > > Best Regards,
> > > -- Alex
> > >
> >
> > The champion role is really just to help the proposal through any
> > discussion prior to being accepted as a poddling so thats been done and
> it
> > makes little difference now.
>
>
> True. I'm totally down with your reasoning.
>
> But don't you think it might be a formality we need to comply with, even if
> it does not make sense at this stage?
>
>
There has been a vote, which passed with enough binding votes, no one has
-1'd, and no one has retracted their vote. Lets wait till Monday and if the
majority vote still passes just carry on with the additional mentors. I
hope no one does -1, theres several experienced mentors now so nothing
really to be gained from forcing some new vote.

   ...ant

Re: [INVALID][RESULT][VOTE] Accept MRQL into the Incubator

[ant elder]

On Fri, Mar 15, 2013 at 12:16 PM, Alex Karasulu wrote:

> On Fri, Mar 15, 2013 at 10:21 AM, Edward J. Yoon  >wrote:
>
> > > could you please close the "Create MRQL" tasks in the Infra Jira until
> > > the situation has been cleared up. Whenever this all has been sorted
> > > out you can reopen the issues.
> >
> > Sure.
> >
> > Since this might not be fixed soon, proposal can be changed
> > (especially corporation volunteers). And, thank you for your
> > suggestion, but I'm already in initial committers list.
> >
> > To IPMC, I would request you to focus more on reviewing Proposal in
> > the future. The opportunity of MRQL should not be faded by my mistake.
> >
> >
> Bravo! There was no malice in the vote, just a simple mistake. If need be I
> or Mo can take on the Champion role.
>
> Are there others from the IPMC that would be interested in mentoring MRQL?
>
> --
> Best Regards,
> -- Alex
>

The champion role is really just to help the proposal through any
discussion prior to being accepted as a poddling so thats been done and it
makes little difference now. Mohammed had volunteered to be a mentor so
lets continue as that and I'll add myself as mentor too just to help if
anymore is needed. So that gives plenty of mentors, we don't need more
voting for that as the Incubator PMC can update mentors as it sees fit. So
lets just continue on with that and the poddling accepted.

   ...ant

Re: [VOTE] Graduation of EasyAnt into Ant

[ant elder]

+1

   ...ant

On Tue, Mar 12, 2013 at 3:06 PM, Nicolas Lalevée  wrote:

> Hi,
>
> The EasyAnt community would like to graduate as an subproject of Ant.
>
> The Ant PMC has just accepted:
>
> http://mail-archives.apache.org/mod_mbox/ant-dev/201303.mbox/%3CBD5DB6B8-13BC-421F-800C-CE6CB21D7BF4%40hibnet.org%3E
>
> The goal is to make EasyAnt a subproject of Ant, just like Ivy and IvyDE
> are.
> - EasyAnt code will be brought into Ant's svn tree.
> - EasyAnt committers will become Ant committers but not part of the PMC
> (on 5 committers, 3
> are already Ant ones, and 2 are part of Ant's PMC)
> - The Ant PMC will be responsible for the code, the community, the next
> releases of EasyAnt.
>
> Easyant has been incubating since 31/01/2011.
> A release has been done the 27/02/2013.
>
> Some usefull links:
> - the EasyAnt project incubator page:
> http://incubator.apache.org/projects/easyant.html
> - the archive of the mailing lists
> http://mail-archives.apache.org/mod_mbox/incubator-easyant-commits/
> http://mail-archives.apache.org/mod_mbox/incubator-easyant-dev/
> - the release
> http://www.apache.org/dist/incubator/easyant
>
> Please cast your votes over the graduation of Easyant as a subproject of
> Ant.
>
> cheers,
> Nicolas
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>