Re: A smaller IPMC

[William A Rowe Jr]

Just to point out the obvious...

On Thu, Mar 7, 2019 at 5:33 PM Justin Mclean 
wrote:

>
> Some suggestions:
> 1. Ask all inactive IPMC if they want to continue being on the IPMC and
> see who steps down. Being inactive they are probably not following this
> list so we need to identify and send each one email them personally.
>

A good number of us have served multiple stints on the IPMC and as our
focus changed, we've asked to be furloughed emeritus, and then sent asks to
rejoin to actively mentor another incubation proposal. Often to be met by
"Oh, you had left? We hadn't recorded that, so you are already still-here."

I'm not sure I'd trust the current roster, and a refresh of "please express
interest if you are still following the Incubator project" isn't a bad idea
on a very infrequent basis. Resolving how to deal with those who don't
respond at all (neither "please move me to emeritus" nor "I'm still here!"
come across) is an exercise left to the IPMC who are paying attention, it
doesn't need to be transacted on general@ (and would be a bit of an
exercise in shaming if they tried.)

2. There were some questions around merit raised, remove all IPMC members
> who were not on the initial proposal and who were voted in. Those left on
> the IPMC vote back in those who are currently active.
>

So, those from the original IPMC formation are recalled in an inactive and
largely unaware state, as the "impartial observers", to do what, exactly?
Solve problems they haven't been following and can't offer solid
prescriptions for?

A more focused approach might be to suspend non-members from the IPMC for a
reaffirmation vote if that group has caused significant issues, but I doubt
that is a useful exercise (see comments that follow...)

3. Get rid of all IPMC members, and vote (with ASF members vote being
> binding - not sure how else it could be done?) currently active ones back
> in.
>

All members have generally been welcomed as volunteer participants at the
Incubator. If you want something at this scale, I'd suggest you need to
scale it similarly to the board of directors. Fixed number of seats,
membership-wide voting under STV. Or ad-hoc number of participants, up/down
votes on individuals, which are effectively assured to all be accepted,
rendering the entire activity useless.

In respect to non-Member nominees, I'd suggest anyone participating at the
IPMC level, not an ASF member, and not nominated now for ASF membership
should receive very close scrutiny. One of two mistakes has occurred in
those cases, and either mistake is a cause for concern and reflects poorly
on the IPMC.


> 4. Do nothing as this is not actually a problem but instead address other
> underlying issues. e.g. lack of mentor engagement.
>

IPMC membership has nothing to do with mentor engagement.

If you are trying to diagnose mentorship, then you need to start over with
a mentorship discussion. If mentors participating at the IPMC don't
correlate to their mentor engagement with their podlings, that's something
to address. Changing the IPMC composition has no impact on such a problem.

Re: Using GPLv3 in the build?

[William A Rowe Jr]

Yup. This seems concordant with most of the GPL exception clauses on
generated output. That is fine, we don't prohibit through use of GPL for
target architecture buildable tarballs of sources, so long as the consumers
of those source tarballs are not imposed restrictions beyond the AL 2.0.

Many projects generate tarballs from AutoMake/AutoConf, and this seems to
sort in that category, but to be sure, present this as a legal-discuss@a.o
inquiry with a corresponding Jira to have a binding conclusion.

On Wed, Jan 9, 2019, 10:04 Christofer Dutz  Ok ... so that was quick,
>
> I looked up the guy doing most of the commits and asked him. Here his
> reply:
>
> "As with majority of the compilers (gcc, clang, etc), Kaitai Struct
> compiler does not make any special takes on the output. If you own the
> input, you totally own the output, and free to specify your own
> conditions on its licensing.
>
> If you use something from our formats repo — http://formats.kaitai.io/
> — it's generally safe to assume that output license equals to KSY
> input file license (of course, I'm not a lawyer, I can't provide legal
> advice, blah, blah, etc, the regular disclaimer you've probably seen
> tons of times already). As most of formats in that repo are
> CC0-licensed, basically it's public domain, you can do whatever you
> want with them."
>
> So if we input a definition which we write as part of the PLC4X project
> and which is naturally Apache 2.0, so the output would be Apache 2.0 too
> ... so that sounds good.
>
> Unfortunately he also told me that even if the parsing code was already
> good, the serialization code is in very early stages and would probably not
> be up to our expectations :-(
>
> So we probably shouldn't base our project on that ... but thanks for the
> fast response Richard :-)
>
> Chris
>
>
>
> Am 09.01.19, 16:26 schrieb "Richard Eckart de Castilho" :
>
> Hi Chris,
>
> This seems to be a similar situation as for tools such as automake
> (which I believe is used by several Apache projects).
>
> To the best of my knowledge (I am not a lawyer), the the copyleft
> clause of the GPLv3 does not impose and restrictions on the output of tools
> under the license. E.g. if you have a text editor published under GPLv3,
> the copyleft doesn't affect to the texts you have written with it.
>
> In the case of a code generator (like a compiler or like automake)
> you'd best check if the generated output contains anything that is licensed
> under the problematic license. For example, the compiler might generate a
> boot loader block into every application and this boot loader block might
> be under a copyleft license - that could be a problem. For this reason,
> e.g. automake has special exceptions to the GPLv3:
> https://www.gnu.org/licenses/exceptions.en.html
>
> If the compiler you want to use does not mention any such exceptions
> as part of their FAQ/license description, maybe best enter into contact
> with the developers and ask them.
>
> Cheers,
>
> -- Richard
>
> > On 9. Jan 2019, at 15:53, Christofer Dutz 
> wrote:
> >
> > Hi all,
> >
> > I just double checked the text on the GPLv3 compatibility.
> > Stupid thing is the problem I’m having isn’t really covered by that
> [1].
> >
> > The case I’m currently having is that there is a toolset called
> Kaitai [2], which sounds interesting for the Apache PLC4X project.
> > In general you define a data-format and have it generate model,
> serializer and parser in multiple languages (Similar to Thrift or Protobuf,
> but with a focus on the transport data-format and not the model).
> >
> > This consists of a compiler and a runtime.
> >
> > The compiler generates code from sources which use the runtime
> libraries.
> > The runtime libraries are Apache 2.0 and MIT licensed, so this would
> be ok
> > The compiler however is GPLv3 …
> >
> > Now we would not be bunding the compiler and the users wouldn’t need
> to use it when using PLC4X as it’s only needed in the code-generation phase
> of the build.
> >
> > So before I throw the idea over board, I just wanted to double-check
> this special case.
> >
> > Chris
> >
> >
> >
> > [1] https://www.apache.org/licenses/GPL-compatibility.html
> > [2] https://kaitai.io/
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
>
>

Re: [DISCUSS] IP Clearance

[William A Rowe Jr]

Would it be helpful if incubator submissions came with a [IP Review]
subject line? All accepted incubator and already-evaluated TLP records
would still be presented, with a [IP Recorded] or [IP Reviewed] subject
line.

I suspect it is helpful to show all incoming projects the conclusion of
other TLP's ongoing evaluations, but that evaluation for incubating efforts
must happen on this list.


On Tue, Jun 5, 2018, 15:05 Dave Fisher  wrote:

> Hi -
>
> Thanks to everyone for participating so far. I see that many feel that the
> IP Clearance being part of the Incubator for public recording purposes is
> in the interests of the Foundation.
>
> The records at http://incubator.apache.org/ip-clearance/index.html are
> important.
>
> - The direction about new project’s in the box is inconsistent and does
> not get to the proper place.
> - If the process is not for podlings then why are there (incubating)
> projects in the table?
> - There is no instruction about where to add the entry and I see additions
> to both the top and the bottom of the table.
>
> The lefthand navigation has some dead links and the IP Clearance process
> could be made more prominent.
>
> A concern about having IP Clearance from a podling is if the podling is
> retired.
>
> If a podling has a new contribution after the contributions that are
> documented in the Podling Proposal then do they go through this process
> like a TLP or do they just record it?
>
> If a podling is asking for IP Clearance then I think that should NOT be by
> LAZY CONSENSUS.
>
> Regards,
> Dave
>
> On Jun 5, 2018, at 9:53 AM, Craig Russell  wrote:
>
> Hi Dave,
>
> On Jun 4, 2018, at 10:46 AM, Dave Fisher  wrote:
>
> Hi -
>
> I think that the IP Clearance process has become very much a bureaucratic
> process where the IPMC is contributing little of value. Very seldom is
> there any feedback provided.
>
>
> It is intended to be a bureaucratic process that is organized and run by
> the PMC with oversight by the IPMC.
>
> http://incubator.apache.org/ip-clearance/index.html :
> "The intent is to simply help to ensure, and record, that due diligence
> (Software Grant, CLA, Corp CLA, license and dependencies) has been paid to
> the incoming code"
> "The receiving PMC is responsible for doing the work. The Incubator is
> simply the repository of the needed information."
> "Note that only lazy consensus is required."
>
>
> (1) It is separate from the SGA process for new podlings, but it is
> similar in that the Secretary will record the SGA and/or CCLA.
> (2) The documentation is confusing about whether or not podlings need to
> follow it or not.
>
>
> The documentation at https://incubator.apache.org/guides/ip_clearance.html
> discusses Podling IP Clearance.
>
> The documentation at http://incubator.apache.org/ip-clearance/index.html
> discusses non-Podling IP Clearance.
>
> Perhaps a rewrite of either or both of these would be useful. Patches
> welcome.
>
> (3) Top Level Projects are supposed to understand how to clear IP as that
> is a major part of the incubation process. If there are any questions the
> legal-discuss mailing list and JIRA are available.
> (4) The Incubator is already stretched to provide Mentoring to all of our
> Podlings and IP Clearance seems to be off topic and not really scalable.
>
>
> Wide visibility is one result of the process being performed under the
> auspices of the incubator. Lazy consensus means that overworked IPMC
> members do not need to be involved if they choose not to be. But they can
> still see that a big code base is being proposed going directly to a TLP.
>
> (5) Once a TLP graduates from the Incubator it seems regressive to have to
> go back unless there is a Community around the grant to be Incubated. That
> would lead to a Podling Proposal and not IP Clearance.
>
> I think that the IPMC should recommend to the Board that this recording
> process be fully moved to the Secretary.
>
>
> I'm afraid I don't see the problem that this change would solve.
>
>
> Regards,
> Dave
>
>
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org http://db.apache.org/jdo
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
>

Re: [DISCUSS] IP Clearance

[William A Rowe Jr]

On Tue, Jun 5, 2018 at 8:26 AM, Jim Jagielski  wrote:

>
> > On Jun 5, 2018, at 4:53 AM, Bertrand Delacretaz <
> bdelacre...@codeconsult.ch> wrote:
> >
> > On Mon, Jun 4, 2018 at 9:30 PM, Jim Jagielski  wrote:
> >> ...In other words, unless the code is for a podling, the IPMC shouldn't
> be involved, IMHO
> >
> > But it's good to have a central place to record those IP clearances,
> IMO.
>
> Since it's a foundation record, that should be the secretary's job, I
> think. That is, the responsible PMC does the IP clearance and then submits
> that info/record to the ASF secretary for filing.


That doesn't do any good to the community if this is recorded privately.

Unlike ICLA/CCLA documents which are quasi-private (the existence
of a committer account is sufficient to document that the appropriate
forms are on file), other projects that might lean on another project's
imported component, or want to re-integrate previously cleared external
IP need to be able to see that the initial IP clearance occurred. That's
how the notices of IP clearance to general@i.a.o have been useful.

Re: IP Clearance terms

[William A Rowe Jr]

On Thu, Jan 12, 2017 at 6:06 AM, John D. Ament  wrote:
> IMHO, IP Clearance in of itself is confusing.  For software being
> relicensed (under an SGA) it shouldn't be needed.

Well, it is needed, even where that devolves to "has all SGA paperwork
for this incoming contribution and corresponding ICLAs been received
and acknowledged?"

> In addition, like any other podling coming in, work may be needed
> to generate a valid release from the donation.  It may not just work.

That is independent of the IP Clearance. It's the same issue as any
brand new work created here by committers with ICLAs. Nowhere
does the ASF enforce 'code quality' or similar metrics. If it doesn't
build, it's open source, so just reassemble all the pieces.

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

Re: SVN Change?

[William A Rowe Jr]

On Sat, Jun 4, 2016 at 10:21 AM, Marvin Humphrey 
wrote:

> On Sat, Jun 4, 2016 at 8:13 AM, John D. Ament 
> wrote:
> > On Sat, Jun 4, 2016 at 11:02 AM Marvin Humphrey 
> > wrote:
> >
> >> On Sat, Jun 4, 2016 at 7:21 AM, John D. Ament 
> >> wrote:
> >> > All,
> >> >
> >> > Did anyone change something recently in SVN? I pulled this morning and
> >> got
> >> > back a larger than expected amount of content.  It seems like the
> whole
> >> > site tree's been duplicated.
> >>
> >> http://svn.apache.org/viewvc?view=revision=1746519
> >>
> >>
> > :-(
> >
> > Any thoughts on how to fix this? Is it just a matter of deleting a
> > directory tree?
>
> Yeah, it's just `svn rm FULL_URL`.  I took care of it.
>
> Please folks: always preview before you commit. With Subversion,
> that's `svn diff`.
>

The way to revert without causing a huge update is to remove the target
tree, and
svn cp -r{rev-before-break} https://s.a.o/r/a/tlp/o/trunk
https://s.a.o/r/a/tlp/o/trunk
which basically backspaces between what was messed up to what should now be
present, which is usually a minimal delta to most people's checkouts

Re: Possible ASF Incubator Project transfer..

[William A Rowe Jr]

On Thu, Mar 3, 2016 at 5:39 PM, Reza Rahman  wrote:

> Yep, understood. We will give it an honest effort
>

No doubt, we appreciate the sincerity.

Note that there are multiple aspect that would require license grants and
provisions
that complicate any Java-ecosystem grant to the ASF.  It isn't strictly
limited to a
given library or framework.  The TCK license terms themselves effectively
killed
more than one ASF effort, and make the consideration/donation of JSR-related
works nearly impossible, at least not as implementation of "named"
specifications
within that ecosystem.  Even a completely renamed/rescoped 'fork' is
questionable.

I find this all highly improbable, but stranger things have happened over
the past
10 years, so if you would like to pursue this, we have the resources to
facilitate
and help frame the scope of grants required to make such an offer happen.

Cheers,

Bill

Re: Single person developed project

[William A Rowe Jr]

The technical reason for "no solo projects" that already answer your
question
lies in the ASF governance model, which is based on meritocracy where all
who participate in the project are expected to be part of its oversite
(there is
no allowance for a "BDFL" (Benevolent Dictator For Life) management model.

Every decision has to be (at least passively) agreed to by a minimum of
three
members of the project, and this particularly includes releases which must
be
actively approved by 3+ positive votes.

Since a solo effort will not have the ability to perform a release, the ASF
has
no interest in creating stillborn communities-of-one.  I hope this
clarifies the
earlier answers.  But you certainly describe or point out the source code to
the project you would like to incubate, and solicit additional contributors
on
either the general@incubator or the dev@community lists.



On Mon, Feb 15, 2016 at 2:47 AM, Amareshwari Sriramdasu <
amareshw...@apache.org> wrote:

> Hi all,
>
> Wanted to know if a single person developed project can get incubated in
> Apache. Any doc links would be helpful as well.
>
> Thanks
> Amareshwari
>

Re: OK to distribute some GPL licensed build tools?

[William A Rowe Jr]

On Jan 10, 2016 4:26 PM, "Justin Mclean"  wrote:
>
> Hi,
>
> Changing subject so not to pollute the Singa VOTE thread.
>
> So it seem the GPL with this special exception are OK to distribute.
[3][4]
>
> Looks like our documentation may need to be updated/clarified in a couple
of places.
>
> For instance:
> - The "GNU Free For All” license is not listed as a Category A license [1]
> - Special exceptions to the GPL are not allowed [2]. Except for this
special exception that is!

There is no modification to the license.  The files in question are
dual-licensed, either GPL or the terms of your OSS software which uses
autoconf, which in our case is AL 2.0.

> - When distributing GPL software with this exception do we need to
mention so in LICENSE? Do we also need to distribute GPL text in COPYING as
indicated in the header text?

No.  We don't ship GPL software, the applicable terms are AL 2.0 :)

RE: [IPMC Projects] may be in need of^w^w^w^w^ware looking for help!

[William A Rowe Jr]

Agreed this is in the scope of comdev, but in terms of the data collection
and aggregation process, you have many willing test subjects aggregated on
this list, which sure beats broadcast mails to pmcs@.
On Jan 10, 2016 7:15 PM, "Ross Gardler"  wrote:

> jira is exactly how I used to run GSOC, I think the process remains
> roughly the same. The goal WA to have a list of tasks marked as "mentor
> available". This list could bf used throughout the year, not just GSOC.
>
> I built searches for this but it never really got traction. I still think
> it's a good idea though.
>
> Assuming folks agree with this approach I guess that makes ComDev the
> right place.
>
> Ross
>
> Sent from my Windows Phone
> 
> From: Roman Shaposhnik
> Sent: ‎1/‎10/‎2016 4:35 PM
> To: general@incubator.apache.org
> Subject: Re: [IPMC Projects] may be in need of^w^w^w^w^ware looking for
> help!
>
> On Sun, Jan 10, 2016 at 4:13 PM, Tom Barber 
> wrote:
> > Just to second some of that, both incubator and outside, it would be cool
> > if the ASF had a 'jobs board' of sorts, where projects could add
> "adverts"
> > for people when they are short of specific help. Or conversely if I'm
> bored
> > and want to do something a bit different where can I find projects who
> have
> > a need for my skill set?
> >
> > I can search distinct projects, but it would be nice to have a central
> > location.
>
> The easiest way would be to have a JIRA view looking for open tickets
> marked in a certain way. Then projects can start using the flags and
> get represented.
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

RE: [IPMC Projects] may be in need of^w^w^w^w^ware looking for help!

[William A Rowe Jr]

On Jan 9, 2016 14:58, "Ross Gardler"  wrote:
>
> Everyone should read the subject and reset.

+1 - the original subject line corresponds to that projects interested in
new activity.

3-5 times a week a student or IT hobbiest or professional developer or
website designer pings dev@community.a.o asking 'I would like to
contribute, where do I start?'  These are of the 30-500 who looked at
apache.org pages with the same question.  The stock answer is always
'choose a project that interests you, and dive right in'.

Is there a way to reframe this discussion as a collaboration of incubating
projects to create a landing page, perhaps with a query-by- programming
languages/skills/components needed that includes the terse project and
audience summaries for incubating efforts?  Somewhere dev@community can
direct newcomers to help find their 'fit' or area of interest in the
foundation?

TLPs have it sort-of-easy, most are well known names to their audiences.
Incubation efforts are less so, recently renamed and just assembling all
the pieces with the expected gaps throughout.

Who would be interested in such an effort?  Wondering if the Whimsy PMC
might be the platform to build such an ASF 'projects' search board?

Re: Non-voted Release Candidate binary downloadable from project homepage possible?

[William A Rowe Jr]

On Jan 7, 2016 20:48, "John D. Ament"  wrote:
>
> All,
>
> I wanted to get others opinions.  Currently Freemarker creates two
> artifacts - one is a GAE compatible module, the other is a regular
> library.  They are created from two distinct branches in their SCM.  Are
> those artifacts voted on together or separately?

The source code tarball is the subject of the release vote.  Since these
are two branches used to create two separate packages, I would expect these
are subject to two distinct votes.

The resulting binaries or other output from building these packages are not
subject to a vote, they just need to be reproducible by anyone who obtains
the sources.

Re: Concerted may be in need of help

[William A Rowe Jr]

On Sat, Jan 9, 2016 at 1:27 PM, Chris Nauroth 
wrote:

>
> As a Concerted mentor, I agree with the concern about lack of activity.  I
> think this was a difficult month for the project considering both the
> general drop in participation and the typical drop in activity that we
> should expect to happen around the end-of-year holidays.  The monthly
> reporting schedule implicitly requires that an incubating project show
> some kind of demonstrable progress month-to-month.  Still, other podlings
> did manage to sustain activity and complete a report during this time.
>
> I see John has already raised concern about lack of activity in the
> mentor/shepherd notes.  I just seconded that myself.
>
> Can we consider giving the PPMC a chance to reset and aim to re-establish
> steady activity this month?


What is the steady activity requirement that has been injected into
incubation?

There are plenty of examples of projects that have enjoyed months and some
years of lull between bursts of activity, usually around new requirements
and
interests by patch submittors or committers.

By this reconning, there have been a number of times measured in weeks or
months that the httpd and tomcat projects should have been folded.  Do we
really believe that a steady state of activity is healthy?  On the
contrary, it
is the bursts of new activity that lead our projects into new and
interesting
territory, not an n commits/mo target.

That said, we don't want podlings to linger here; release early, release
often,
demonstrate that new contributors are recognized as committers/[p]pmc
members, and show us [incubator] that there isn't much more mentorship
required for the effort to proceed in the model of the ASF.  A project that
cannot get to a point of release in some reasonable time, e.g. a year or
two, or who takes down their shingle and announces they can't attract a
three+ community to sustain their effort, such projects should be retired.

Re: Help for the Log4cxx podling

[William A Rowe Jr]

On Fri, Jan 8, 2016 at 10:19 AM, Thorsten Schöning <tschoen...@am-soft.de>
wrote:

> Guten Tag William A Rowe Jr,
> am Freitag, 8. Januar 2016 um 15:33 schrieben Sie:
>
> > Forty forks means 40 prospective committers.
>
> Or just people, like some of those currently involved, which change
> things once in a while because of bugs or such. I'm always just happy
> if my fixes are simply merged without participating in further
> development too much.


Hallo Thorsten,

Of course, 2 patches doesn't really make a "committer".  Lots of people
file jira tickets, fork code and patch two things, and never look back at
it.
If it solves their problem, they have other things.  But others probably
have
been making minor fixes or even enhancements for a while and it would be
good to invite them all to subscribe to the dev@ list and share their hopes
and thoughts on log4cxx's sustained success.


> > Nothing is solved by "moving"
> > the project to github if their changes are never moved back to the ASF.
>
> I disagree: I'm doing at least some level of support and merge patches
> once a while, depending on their nature and such. The problem now is
> that such an amount of work and "community" ;-) would not be enough
> for your incubation rules and the Apache way, so you would need to
> decide that it's "better" to keep me off the repo entirely instead of
> just letting me do what I'm able to provide AND what is somewhat
> requested by at least some users. That's a decision you make based on
> your project/organisation rules, but it doesn't change if there's at
> least some demand for maintenance of any kind, it's just that the
> project doesn't fit to your rules anymore.
>

Not sure which aspects of ASF's rules you refer to?

If you mean "Projects must ship releases, projects may not point users
at the dev repo - without calling out that this is unreleased code" then if
log4cxx cannot abide, the project needs to be shelved.  The mark stays
at the ASF.  Any fork can pick a new name for itself but it is simply not
"Apache log4cxx" any longer.

If you mean that patches are picked up from github merge requests, vs.
patches must be submitted via Jira, there is no such rule.  If you mean
that it is more convenient to perform git merge requests into an ASF git
repo as the canonical source code tree, that too is being worked on to
simplify the workflow for 'svn adverse' projects.

I'm trying to understand whether we are looking at a cultural refusal to
ever put a post in the stand and say "this is a release, there will be other
releases, but this is our release as of now"?  Or is this simply a matter
of preferring git to svn?  The former is a requirement, the later is easily
adapted as we clarify how the ASF will insist on a true history of the
project development.  That effort is being pursued and Apache log4cxx
can be accommodated, hopefully in short order.

Hadoop does this today working with git, here's their explanation;
https://wiki.apache.org/hadoop/HowToCommit

There are other rules - invite frequent patch submittors to become new
committers, bring them to the PMC as well based on their contribution,
allow every project participant a voice in the direction of project based
on merit, no a fiefdom.  But I don't expect that was the complaint?

The problem and difference to GitHub I see now with the Attic is, that
> you have a huge, centralized SVN repo, which is very hard to clone for
> interested persons like me for technically reasons. When I tried some
> years ago, you actively blocked me just because I fetched revisions a
> week or so... :-) So if you decide that the project is dead, with the
> same decision you might prevent people access to the very valuable
> history of the project simply for practical reasons, because we are
> not allowed to clone it 2 weeks or the amount of data is just to huge
> with all those empty revisions or whatever.
>

Not familiar with that history so I can't comment.  But Attic code is
abandonware, it exists for others to pick back up, much like we tried
to accomplish by incubating log4cxx.  I'd hate to see that happen if
there are a group of 3+ people who will actively participate in reviewing
and blessing a release candidate, but if Apache log4cxx does not have
those three people, and is not creating any releases, it simply is not
a project.


> If the project is additionally hosted on GitHub and not only in Attic,
> it would be simpler for still interested people to fork and make use
> of it. I see that as somewhat special to Apache's Attic concept, and
> maybe even the use of SVN, though I like SVN a lot: To me it looks
> like that hosting all Attic projects on a platform enabling easier
> forking of the entire project history would be a great idea.
>

I can't say whether a read-on

Re: Help for the Log4cxx podling

[William A Rowe Jr]

On Fri, Jan 8, 2016 at 3:31 AM,  wrote:

> As a user (and small time contributor once) of log4cxx, I would vote for a
> move to a central hosting on github. I don't mind what happens to the
> project in terms of the apache organization as I use log4cxx as a
> stand-alone library - and I guess many others use log4cxx in the same
> fashion. However, putting it in a read-only repo is effectively declaring
> it dead and forcing everyone who uses it to either create individual forks
> or rewrite code using alternative libraries. That will be a shame for a
> library that probably for most users (me certainly) Just Works :-)
>

In the ASF, "creating open source software for the public good" means
releasing it.

I am happy to sign up to mentor the project out of the incubator, but that
should be
a 12 week project, tops.  We would need to see commits from at least three
and
preferably five committers.  Who are these people?


> The trouble on github at the moment is that there are up to 40 potential
> forks on there with no central one - as the github.com/apache/log4cxx is
> very out-of-date...
>

Forty forks means 40 prospective committers.  Nothing is solved by "moving"
the project to github if their changes are never moved back to the ASF.

It's not enough to simply apply all of the merge requests; the ASF strongly
holds that we don't do 'one man shows'.  We work to attract many committers
and prevent the benevolent-dictator-for-life and hit-by-a-bus conundrums.

So if the project demonstrates that they can 1. recruit at least a handful
of the
github fork maintainers to participate at log4cxx and sign on as
committer/ppmc
members, and 2. assemble a 0.11 release candidate, review and vote to
release
it, I'll jump on to ease the transition to a full fledged PMC.

If that PMC wants to move from svn to git as their primary development
history,
work is in progress at the ASF to facilitate that.  There is a functional
place to
further develop the software here.  But if these two things can't happen,
this is
past time to land in the attic for others to run with elsewhere.

Either it is effectively in the attic with no code changes anyways, or
these code
changes aren't being released to the public, but users are being directed
to use
the bleed dev repo, which is against the spirit of the ASF's release early
and
release often policy.

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

[William A Rowe Jr]

On Mon, Nov 2, 2015 at 7:08 AM, Rich Bowen  wrote:

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

I'm wondering, though, how this varies from our preference for the
'scratch-your-own-itch' model? In this case, it might be one programmer,
or might be a customer of that programmer who noted a bug, or might
be a small collaborative team working at their day job. All of these have
every right to scratch their specific itch.

In any case, the ASF and the dev@ list never dictate 'Jira ticket A
is more important than Jira ticket B', any of the committers are welcome
to work on any features, any open Jira tickets, anything that they feel
improves a given project's code. It does not matter if this is a volunteer
or employee, everyone is given equal treatment.

Where this goes full-stop 

Re: Short form IP clearance

[William A Rowe Jr]

On Sun, Nov 1, 2015 at 6:38 AM, Sam Ruby  wrote:

> On Sun, Nov 1, 2015 at 7:20 AM, Marvin Humphrey 
> wrote:
> > On Sun, Nov 1, 2015 at 3:41 AM, John D. Ament 
> wrote:
> >> I don't think anyone in the incubator is begging to be responsible.  We
> >> just need a new process defined.
> >
> > Actually, since the Incubator continues to receive criticism for its
> > role in IP Clearance, I specifically request that the Incubator be
> > relieved of that role. If having the Incubator hold the power to
> > "meddle" causes such alarm, the Board should find somebody else to do
> > this work.
>
> I don't think we should be looking to the Board directly for this, we
> should be looking to Legal Affairs to reaffirm, adjust, or revoke this
> arrangement.
>

And Legal Affairs has tangential control over Incubator, but the board is
responsible
for the IPMC charter, so if you want to change the scope of this project,
the board
is the final arbiter.

Some of this might be confusion over Incubator's role.  From memory,
incubator
generally didn't 'vote' on incoming other PMC code bases, but maintained the
canonical list of imports (the format is this committee's creation and
choice),
and the general@i.a.o list was used to 'announce' the importation of
external
code bases.  If someone at g@i.a.o noticed something amiss, they are always
welcome to point out whatever IP provenance issue they perceive to a
receiving
committee (often the IPMC itself for incubating code bases).

If we trust the importing PMC to understand IP provenance, which we do
because
each of them maintain code bases, than this whole issue of IPMC non-voting
vs. record keeping becomes much simpler.  Since the IPMC is good at specific
things, such as recording entry to the ASF, it still seems like a smart
place for
the records.  The alternative seems like adding a converse to the attic
project,
perhaps we could title it Apache Doormat?

> We have enough to worry about with our primary responsibility of
> > incubating podlings. We don't need more reasons for powers-that-be to
> > give us grief.
>
> The powers that be (a.k.a., the board) either need to reinstate Jim as
> VP of Affairs or find a replacement, and then hold that individual
> (and associated committee) accountable for revisiting this issue.
>

That's extra confusing, I don't see where in the prior meeting minutes or
any
other ASF resources where there is not an active VP Legal Affairs?  I think
you are confusing process (act of resigning, recognition of a resignation,
appointing a replacement) with the actual motivation for someone to hold
a role.

You did a nice job of reinforcing Marvin's concern about micromanagement.
Reading this statement above and the tone you used, I personally wouldn't
be keen to serve as an officer under your directatorship.  /boggle

Re: Short form IP clearance

[William A Rowe Jr]

On Thu, Oct 22, 2015 at 5:16 PM, Sam Ruby  wrote:

> On Thu, Oct 22, 2015 at 5:37 PM, Greg Stein  wrote:
> > On Thu, Oct 22, 2015 at 6:45 AM, Jim Jagielski  wrote:
> >
> >> First and foremost, I have not followed this thread almost at
> >> all. I've been at ATO2015 and then traveling.
> >>
> >> What I will say, whether it has been said or not, that
> >> as VP Legal, I will work w/ the Incubator on whatever issues
> >> or questions they may have. If it's time for a conversation
> >> between VP Legal and Incubator re: IP clearance, one that
> >> has not happened for at least a decade, iirc, then I am
> >> fine with that as well and am ready to do so.
> >
> > Please read the thread: it contains my part of that conversation that I
> > think needs to happen.
>
> I'll summarize my position as situations requiring special IP
> Clearance procedures (i.e., not a simple patch or even a committer
> making a huge change, but events such as bulk importing code that was
> previously hosted publicly elsewhere) are infrequent enough events and
> important enough risks that having a second set of eyes (from outside
> of the receiving PMC) is in order.  I don't have a strong opinion as
> to whether IP Clearance for podlings and PMCs should be managed
> separately or together.  As long as it continues to be done via lazy
> consensus, I also don't see burden.


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

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

[William A Rowe Jr]

On Fri, Aug 21, 2015 at 11:00 AM, Jim Jagielski j...@jagunet.com wrote:


  On Aug 20, 2015, at 10:23 AM, Benson Margulies bimargul...@gmail.com
 wrote:
 
  On Thu, Aug 20, 2015 at 9:52 AM, Jim Jagielski j...@jagunet.com wrote:
  Coming in late.
 
  A snapshot is not a release. Licenses kick in at distribution/
  release.
 
  Are you sure? When you have a public source control repo, with a
  LICENSE file at the top, I would think that this counts as a legal
  'publication' under the terms of the license.
 
  if not, just what is the legal status of source code snipped from our
  repositories?
 

 A file that exists on a public source repo, with an associated
 license is, of course, covered under that license. The issue is
 what is the combined, derivative work under? I can, for example,
 take a handful of ALv2 files, combine them as-is and license
 the WORK as GPLv3 for example.

 Furthermore, a release should have such things as a NOTICE file,
 etc, as required. Again, no idea if that is included in a snap-shot
 or not.

 A release is such that the release artifact is verified as
 compliant w/ the ALv2, and is an official action of the foundation;
 A snapshot may or not be verified but for sure is not an
 official action and the person providing the snapshot does
 so at their own risk.


I was working from some significant miss-assumptions which I won't go into
here, to avoid confusing other readers, not unless I understand things
thoroughly.

On Fri, Aug 21, 2015 at 10:51 AM, Jim Jagielski j...@jagunet.com wrote:


 I did NOT SAY that... holy moley. I said that licenses kick in
 at a release, but I not not say that they don't kick-in at
 other times; also, a release is guaranteed to be under ALv2
 (it is our work) and there is no guarantee on said snapshot,
 depending on how it is created.


Yes, I should have given your statement the benefit of the doubt.  Whether
your statement had been incomplete, outright wrong, or absolutely on point,
my venting was inexcusable.

On Fri, Aug 21, 2015 at 11:04 AM, Jim Jagielski j...@jagunet.com wrote:


 Cut it out.


I apologize to you for my antagonistic tone.  It was a combination of being
several days deep into a head cold, and fundamentally misunderstanding the
provenance of svn.

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

[William A Rowe Jr]

On Aug 21, 2015 1:54 AM, Greg Stein gst...@gmail.com wrote:

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

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

 This is why Debian has Iceweasel instead of Firefox.

A very useful point that Greg raises, where does the ASF want to draw that
line?  C.f. for a good narrative;

https://en.m.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_the_Debian_project

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

[William A Rowe Jr]

On Fri, Aug 21, 2015 at 10:41 AM, Jim Jagielski j...@jagunet.com wrote:


  On Aug 20, 2015, at 8:27 PM, William A Rowe Jr wr...@rowe-clan.net
 wrote:
 
  On Aug 20, 2015 08:52, Jim Jagielski j...@jagunet.com wrote:
 
  Coming in late.
 
  A snapshot is not a release. Licenses kick in at distribution/
  release.
 
  I want to fix FUD before it infests the rafters and subfloor.  I really
  have never read something so stupid or ill phrased...
 
  Every contributor committing code to any ASF project, or even
 contributing
  it to us in public forums (including our mailing lists, our bug trackers,
  etc) is committing that code under the AL or has designated explicitly
 what
  licence it came in under (commit message: forked from BSD-licensed code
  base at {URL}.)
 
  It is generally AL code all the time.  I don't know where you invented a
  'kick-in' concept, but unless the committers are violating their
 ICLA/CCLA,
  nothing could be further from the truth.
 
  There is also a trademark issue as well... only the ASF
  can declare something as a release.
 
  There we agree :)

 Please reread what was said... We are talking *releases* here.
 Making something publicly available is NOT A RELEASE. It may be
 under a license, but is IS NOT A RELEASE.


I reread what you wrote,

 A snapshot is not a release.

We know this and agree on this, and you just responded to the obvious but
failed to address the second half of your statement.

 Licenses kick in at distribution/release.

They do?  This is the statement of the VP Legal, so whether it is right or
wrong, here at the ASF we attempt to honor the 'spirit' of the policy of
other licensors when we use their code, and we would hope others would
honor the 'spirit' of our policies here.  It that is the underlying
assumption, that the code is not licensed by the ASF until a formal release
occurs, then we need to revisit the many implications of that philosophy.

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

[William A Rowe Jr]

On Fri, Aug 21, 2015 at 10:51 AM, Jim Jagielski j...@jagunet.com wrote:


  On Aug 20, 2015, at 11:19 PM, William A Rowe Jr wr...@rowe-clan.net
 wrote:
 
  On Thu, Aug 20, 2015 at 8:52 AM, Jim Jagielski j...@jagunet.com wrote:
 
 
  A snapshot is not a release. Licenses kick in at distribution/
  release.
 
 
  Lets just imagine if Jim, VP Legal is actually correct in his
  interpretation, and that there are no AL 2.0 licenses applicable to our
  source code repositories, svn or git.
 

 I did NOT SAY that... holy moley. I said that licenses kick in
 at a release, but I not not say that they don't kick-in at
 other times; also, a release is guaranteed to be under ALv2
 (it is our work) and there is no guarantee on said snapshot,
 depending on how it is created.


Ok, so a license applies to the release.  A license applies to the sources
in SVN, to the sources in snapshots, ad nasuem...

A license also applies to the snapshot.  I'd suggest that all
snapshots/nightly builds etc, any of them distributing ASF code, have to
carry the COPYRIGHT and NOTICE that any other distribution is required to
have.  They must be present in the source control tree.  Leaving out the
LICENSE and NOTICE from a non-release is no more correct than leaving them
out of the release itself.  But the kick in meme doesn't serve us well.

Back to the top-post, enforcing that any releases from any packager
correspond to what we've published as an ASF release, that authority comes
from asserting our marks, and we spell out how we enforce this in AL 2.0
section 6.  But the question of what is close enough to the ASF release
and what is arguably confusing to users is really up to the individual
PMC's because only they are familiar with their users expectations and what
constitutes a fork, vs. a practical distribution of the source code they
released. We offer reasonable leeway to distributors at the apr and httpd
projects and haven't run into too much confusion...

...except in one case, we did have an external entity shipping
pre-release-vote binaries without clarifying that these were not releases.
They were asked to stop, and voila, that entity is now a much more
respected member of the extended community, just because we asked and they
obliged.

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

[William A Rowe Jr]

On Thu, Aug 20, 2015 at 8:52 AM, Jim Jagielski j...@jagunet.com wrote:


 A snapshot is not a release. Licenses kick in at distribution/
 release.


Lets just imagine if Jim, VP Legal is actually correct in his
interpretation, and that there are no AL 2.0 licenses applicable to our
source code repositories, svn or git.

Quoting http://apache.org/licenses/LICENSE-2.0 ...

2. Grant of Copyright License. Subject to the terms and conditions of this
License, each Contributor hereby grants to You a perpetual, worldwide,
non-exclusive, no-charge, royalty-free, irrevocable copyright license to
reproduce, prepare Derivative Works of, publicly display, publicly perform,
sublicense, and distribute the Work and such Derivative Works in Source or
Object form.

No, you may not modify the sources or derive those that reside within
version control of the ASF, until and upon the time when the project has
blessed that project as a release.  Patches to others' contributions to
source code control are not within the scope of this imaginary non-license
application.

3. Grant of Patent License. Subject to the terms and conditions of this
License, each Contributor hereby grants to You a perpetual, worldwide,
non-exclusive, no-charge, royalty-free, irrevocable (except as stated in
this section) patent license to make, have made, use, offer to sell, sell,
import, and otherwise transfer the Work, where such license applies only to
those patent claims licensable by such Contributor that are necessarily
infringed by their Contribution(s) alone or by combination of their
Contribution(s) with the Work to which such Contribution(s) was submitted.
If You institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work or a
Contribution incorporated within the Work constitutes direct or
contributory patent infringement, then any patent licenses granted to You
under this License for that Work shall terminate as of the date such
litigation is filed.

No, you may absolutely not test the code that has been committed to source
control without a patent license, which you do not have, until that time
when the ASF blesses the work and calls it a release.

4. Redistribution. You may reproduce and distribute copies of the Work or
Derivative Works thereof in any medium, with or without modifications, and
in Source or Object form

None of that, it's all straight out, none of it applies to your work at the
ASF until the release is blessed.  That includes passing off a patched fork
of a security fix to a reporter who claimed there was a defect in the
earlier release.

5. Submission of Contributions. Unless You explicitly state otherwise, any
Contribution intentionally submitted for inclusion in the Work by You to
the Licensor shall be under the terms and conditions of this License

Except when it isn't in Ross's and our VP Legal's own minds...

6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor, except
as required for reasonable and customary use in describing the origin of
the Work and reproducing the content of the NOTICE file.

Which wasn't a right in the first place, so no change here under any
interpretation...

7. Disclaimer of Warranty. Unless required by applicable law or agreed to
in writing, Licensor provides the Work (and each Contributor provides its
Contributions) on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied, including, without limitation, any
warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or
FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for
determining the appropriateness of using or redistributing the Work and
assume any risks associated with Your exercise of permissions under this
License.

Except that perhaps the ASF is liable, under our VP Legal's interpretation,
for works which do reside in source control and were not, in fact, released
to the general public?  [Ad nauseam 8. and 9.]

Let's just not go this direction, because it is plainly false. Jim, it
would truly be helpful if you spoke up for or in contradiction to your
earlier statements, here...

Cheers,

Bill

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

[William A Rowe Jr]

On Aug 20, 2015 08:52, Jim Jagielski j...@jagunet.com wrote:

 Coming in late.

 A snapshot is not a release. Licenses kick in at distribution/
 release.

I want to fix FUD before it infests the rafters and subfloor.  I really
have never read something so stupid or ill phrased...

Every contributor committing code to any ASF project, or even contributing
it to us in public forums (including our mailing lists, our bug trackers,
etc) is committing that code under the AL or has designated explicitly what
licence it came in under (commit message: forked from BSD-licensed code
base at {URL}.)

It is generally AL code all the time.  I don't know where you invented a
'kick-in' concept, but unless the committers are violating their ICLA/CCLA,
nothing could be further from the truth.

 There is also a trademark issue as well... only the ASF
 can declare something as a release.

There we agree :)

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

[William A Rowe Jr]

On Aug 20, 2015 8:19 PM, William A Rowe Jr wr...@rowe-clan.net wrote:

 On Aug 20, 2015 7:39 PM, Alex Harui aha...@adobe.com wrote:
 
 
 
  On 8/20/15, 5:27 PM, William A Rowe Jr wr...@rowe-clan.net wrote:
 
  It is generally AL code all the time.  I don't know where you invented
a
  'kick-in' concept, but unless the committers are violating their
  ICLA/CCLA,
  nothing could be further from the truth.
 
  Committers sometimes make mistakes.  IIRC, Justin recently caught a
  mistake where some files accidentally got their non-AL headers replaced
  with AL headers.
 
  Large codebase contributions, especially initial podling code grants
might
  be messy as well until scrubbed and approved for an official ASF
release.
  I know from experience.

 We don't disagree on this point.  Sometimes, they are caught through the
release process, or by peer review.  Other times, we must retract the claim
we offered.

 Nothing changes the fact that code is either offered under the AL 2.0 or
another license, unless the author/licensor changes their license
retroactively.

Your comment also hones in on the logical fallacy our VP fell into... While
it may be true that the ASF granted its own AL 2.0 license to the release
package, the ASF is unable to change component licenses in incompatible
ways.  And the warranty the ASF offers on an inaccurate license claims is -
nil - c.f. AL 2.0

However, if our repositories are under another license, that VP needs to
make public this information, because I never got the memo, and I must
notify friends and the many companies I advise and consult to that they all
need to cease looking at the ASF's repositories, and let their respective
legal departments each sort this all out, if those repositories are
licensed with terms and conditions differing from the AL 2.0.

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

[William A Rowe Jr]

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

 I do not agree with this interpretation when viewed from a legal angle
 (though I do agree from a trademark angle). I have a feeling that the root
 of my disagreement is the same as the root of Jim's earlier statement
 (though I may be mistaken).


You've lost me already, but let's unwind this...


 There are two points of IP due diligence in an Apache project: At the
 point of contribution where the IP is validated by the committer and zero
 or more people who review the patch. The second phase of IP validation is
 at the point of release, where 3 our more PMC members validate that the
 foundation can legally release the code.


No, 3 or more PMC members make a best-effort that the code meets our
qualifications for release.  Not being copyright and patent atty's, we
presume they did not cast their votes based on a legal definition of due
diligence.


 This means that taking a snapshot and building a release is *not*
 trademark-acceptable since the foundation, through the project PMC has not
 approved the release, therefore it is not an Apache release.


That much we agree on...

Only the ASF gets to say what is an ASF release and to do so requires a
 vote of the PMC. It has nothing to do with the number of changes made to
 what is in our repositories. It has everything to do with whether it's a
 release of the foundation.


Accurate...


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


Here is where there is some room for interpretation, the httpd project can
probably be built more than 10^9 different ways (I extrapolate this from a
Chipotle drink cup that claimed the number of permutations of their
quick-service faux-tex-mex menu)


 (lets ignore the fact that some people vote on releases without doing
 proper validation, that's why we require 3 +1 votes, the assumption is that
 at least one of them did the job properly)


Define Proper, I haven't read that
http://www.apache.org/dev/release/proper.html page yet.

You still didn't comment on the license under which the repository is
licensed, so this wasn't a terribly helpful post.

From: William A Rowe Jrmailto:wr...@rowe-clan.net
 Sent: ‎8/‎20/‎2015 7:17 PM
 To: general@incubator.apache.orgmailto:general@incubator.apache.org
 Subject: Re: What is the legal basis for enforcing release policies at ASF?

 On Thu, Aug 20, 2015 at 9:03 PM, Benson Margulies bimargul...@gmail.com
 wrote:

  This thread started as a discussion of Linux distros and trademarks.
  Perhaps I could try to return it there?
 
  If a distro takes a release of Apache X, compiles it with minimal changes
  that adapt it to the environment, and distributes it, I believe that
 it's a
  fine thing for them to call it simple Apache X, and acknowledge our
 marks.
 
  If a distro takes a release of Apache X, and make significant changes to
  it, and then distributes it, I believe that it's not OK with us for them
 to
  simply call it Apache X. I've seen some evidence that Gentoo Linux makes
 a
  regular habit of this, because their policies drive them to make some
  pretty scary changes in some cases. Others may not share my view.
 
  Further, if someone takes a snapshot (small 's') from source control and
  starts from that, with minimal changes, I think that this would also be
  trademark-acceptable, so long as they accurately describe what they did.
 
  The operative concept here, as Shane has taught it, is 'confusion in the
  marketplace.' If some third party behaves so as to cause confusion as to
  the identity of Apache X, there's a trademark issue. If not, not.
 

 You summed this up to the best of my understanding ... +1.  If our legal VP
 agrees (and retracts earlier FUD) it appears we are entirely in agreement.

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

[William A Rowe Jr]

On Thu, Aug 20, 2015 at 9:03 PM, Benson Margulies bimargul...@gmail.com
wrote:

 This thread started as a discussion of Linux distros and trademarks.
 Perhaps I could try to return it there?

 If a distro takes a release of Apache X, compiles it with minimal changes
 that adapt it to the environment, and distributes it, I believe that it's a
 fine thing for them to call it simple Apache X, and acknowledge our marks.

 If a distro takes a release of Apache X, and make significant changes to
 it, and then distributes it, I believe that it's not OK with us for them to
 simply call it Apache X. I've seen some evidence that Gentoo Linux makes a
 regular habit of this, because their policies drive them to make some
 pretty scary changes in some cases. Others may not share my view.

 Further, if someone takes a snapshot (small 's') from source control and
 starts from that, with minimal changes, I think that this would also be
 trademark-acceptable, so long as they accurately describe what they did.

 The operative concept here, as Shane has taught it, is 'confusion in the
 marketplace.' If some third party behaves so as to cause confusion as to
 the identity of Apache X, there's a trademark issue. If not, not.


You summed this up to the best of my understanding ... +1.  If our legal VP
agrees (and retracts earlier FUD) it appears we are entirely in agreement.

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

[William A Rowe Jr]

On Thu, Aug 20, 2015 at 9:11 PM, Christopher ctubb...@apache.org wrote:

 It sounds to me like you're saying that the license under which code is
 offered (to anybody who encounters it) is independent of the license
 declaration attached to the project.


No, the license is that which was granted by the author, and I think you
missed my followup by a few minutes, so I will quote myself here...

Your comment also hones in on the logical fallacy our VP fell into...
While it may be true that the ASF granted its own AL 2.0 license to the
release package, the ASF is unable to change component licenses in
incompatible ways.  And the warranty the ASF offers on an inaccurate
license claims is - nil - c.f. AL 2.0

However, if our repositories are under another license, that VP needs to
make public this information, because I never got the memo, and I must
notify friends and the many companies I advise and consult to that they all
need to cease looking at the ASF's repositories, and let their respective
legal departments each sort this all out, if those repositories are
licensed with terms and conditions differing from the AL 2.0.
Obviously, I think our VP Legal isn't taking his job seriously of advising
the community on the specific legal particularities of the software we
create, which is why I'm going to stand pat until someone offers up a
compelling argument over why anyone is not able to take any of the AL 2.0
code out of ASF repositories, released or not, and re-purpose it for
whatever they desire.

But don't name it by Apache {foo} unless {foo} PMC sanctioned the release
of the code.  It's entirely in trademark law, and our license and copyright
law gives them everything they need to utilize the code, released or not.

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

[William A Rowe Jr]

On Aug 20, 2015 7:39 PM, Alex Harui aha...@adobe.com wrote:



 On 8/20/15, 5:27 PM, William A Rowe Jr wr...@rowe-clan.net wrote:

 It is generally AL code all the time.  I don't know where you invented a
 'kick-in' concept, but unless the committers are violating their
 ICLA/CCLA,
 nothing could be further from the truth.

 Committers sometimes make mistakes.  IIRC, Justin recently caught a
 mistake where some files accidentally got their non-AL headers replaced
 with AL headers.

 Large codebase contributions, especially initial podling code grants might
 be messy as well until scrubbed and approved for an official ASF release.
 I know from experience.

We don't disagree on this point.  Sometimes, they are caught through the
release process, or by peer review.  Other times, we must retract the claim
we offered.

Nothing changes the fact that code is either offered under the AL 2.0 or
another license, unless the author/licensor changes their license
retroactively.

Re: apache binary distributions

[William A Rowe Jr]

On Thu, Aug 20, 2015 at 8:09 AM, Niclas Hedhman nic...@hedhman.org wrote:

 On Thu, Aug 20, 2015 at 1:06 AM, William A Rowe Jr wr...@rowe-clan.net
 wrote:

  There are some special things here we do have absolute control over. If a
  project wants to provide the 'official' build, why not start signing
 the .jar?

 Good idea, but to be practical to users, the certificate for the signing
 needs to be part of the certificate chain of the JVM (otherwise those would
 be needed to be installed on every host). I don't know how willing infra
 would be to support PKI at ASF for this, otherwise many projects will be
 limited due to cost (I could be wrong by now and that there are totally
 free CAs)


That infrastructure now exists through code signing service by Symantec.
One PMC member (or more) gets their own unique log in, pushes the artifact
(.jar, in this example) to the service and is returned a signed artifact
reflecting the ASF providence.

The interesting thing is the actual cert is unique to the object, so if it
is discovered that it was compromised, the signature can be revoked (good
luck having sig revocations active at boot time, but otherwise this is
quite useful.) And because there is a history, we know who precisely
requested each object signing.

Re: apache binary distributions

[William A Rowe Jr]

On Wed, Aug 19, 2015 at 4:39 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 We could define a hierarchy of right to use the mark: pmc has ultimate
 right, if the pmc are not producing a packaging for that system then the
 developers of the packaging system have the right to define who can use the
 mark in relation to their packaging system only.


FWIW, the Foundation (board level) has the legal final authority, they
delegate this to the VP Trademarks, who shares that delegation with the
individual PMCs to adapt to each of their own unique circumstances.

At no time do we state that others creating a binary from our released
tarball/source is infringing our mark, if the result of what they built is
limited to ASF sources - not extended or patched in a 'significant way'.
PMC's must determine what is significant in this context... if someone
patched httpd for 128 bit int sizes, that PMC would probably shrug (and
work out the right patch upstream.) Any PMC distributing sources for a .jar
are likely to flip out over modifying the public API's, and rightfully so.
And we've noted here, many ASF project builds allow various things to be
toggled-in/toggled-out. Clear labeling is a good way to avoid a PMC
objecting to the use of the mark.

There are some special things here we do have absolute control over. If a
project wants to provide the 'official' build, why not start signing the
.jar? Because only the ASF committers sign code as the ASF under the
authority of the PMC, there is no concern about that .jar being a
third-party component. Users could still build that .jar, because we give
them the sources, on purpose, to deliberately do that.

With few exceptions, downstream is very easy to work with when the PMC
addresses their concerns clearly and politely.


 The aim here would be to make our software available easily in different
 packaging systems. The pmc may want to take ownership of popular packaging
 systems, so we'd need to be able to trump others


Keep in mind, every package distributor has their own policy for who gets
naming priority. It can be helpful to point out that the ASF owns the mark,
and should generally have priority, but the politics of the thing is that
individual contributors to each package distributor have to earn their
karma, just as we require here at the ASF. A signed vs. and unsigned build
may also carry weight in those discussions.

Re: apache binary distributions

[William A Rowe Jr]

On Aug 9, 2015 8:33 PM, Roman Shaposhnik ro...@shaposhnik.org wrote:

 On Fri, Aug 7, 2015 at 12:46 AM, Bertrand Delacretaz
 bdelacre...@apache.org wrote:
  On Fri, Aug 7, 2015 at 2:50 AM, Roman Shaposhnik ro...@shaposhnik.org
wrote:
  ...is Apache Brand meant to protect *any* possible object/binary
  artifact or only those that PMC actually care about?...
 
  IMO any object/binary created from our source code has to be clearly
  identified as not coming from the ASF

As a reminder, based on the foundation core purpose, the ASF releases open
source code for consumption by the general public at no charge.

While convenience binaries are shipped by many projects, others pointedly
refuse (subversion is one example where all binary builds are thirdparty).
The complexity of the number of potential build is one driving factor...
Compile once-and-done for Java is much different than a cross platform
machine code result.

 Well, the real question is: do we aspire to have a monopoly on certain
 binary convenience artifacts? IOW, if a Hadoop PMC blessed and RPM
 as one of those artifacts, does it mean that only that RPM (however
 potentially screwed up it is from the standpoint of Fedora packaging
 guidelines) is the RPM that can be called Hadoop?

  If Kermit distributes a compiled version of httpd for example I would
  expect that to be labeled as Kermit's distribution of the Apache HTTP
  Server.
 
  And if that's done properly I would expect filenames to reflect this
  where possible, so Kermit's binary package should be named like
  kermit-httpd-2.4.16.tgz to help prevent confusion.

 Well, this is not what's happening: http://pkgs.org/search/httpd

A couple things here.  Our claim to Apache HTTP Server or Apache httpd
marks are strong.  But HTTP alone is a protocol name, while httpd was the
name of the binary of earlier (and other later) unix server daemons.

The next is that many vendors compile httpd.  They are encouraged to do
so.  If they label it apache-httpd, it aught to consist of ASF sources.  If
they label it kermits-httpd, it is likely a portmanteau of Kermit's modules
and patches with ASF sources combined.

If a vendor who hated the AL 2.0 (some did/still do?) decided to ship their
improved Apache httpd 2.0 based on their patches to 1.3 (under the AL
1.1) we would have had words, and likely a CD letter to them eventually.

Finally Apache HTTP Server was a very early mark, early abuse was not as
effectively policed.  So the approach to correcting abuse has been a strong
emphasis on polite requests to avoid community confusion.  Where that
fails, only then do we escalate.

Covalent/Springsource/VMW/Pivotal have a long history of renaming where
confusion would result.  RavenSSL was Apache httpd+mod_ssl, build upon
RSA not OpenSSL for US domestic users looking for patent licensing.
tcServer is Apache Tomcat combined with many enterprise extensions.  The
guidelines and Trademark usage constraints are rather straightforward.
Where vendors have built-upon httpd, it is often as an extension to an ASF
base package.  RH GPL-licensed mod_cluster is but one example of this.

Re: Are tests part of the release?

[William A Rowe Jr]

On Aug 9, 2015 4:05 AM, Justin Mclean jus...@classsoftware.com wrote:

 Hi,

  Are tests are part of the release?

 If they are included as source code in the released artefact yes :-)

Well put.  The Apache HTTP Server has several 'test' modules which are
embedded in release tarballs.  The 'test framework' is an eternal work in
progress and has never been proposed for release, httpd devs simply consume
and expand test/framework/trunk/ as new exceptions or interesting subjects
for testing are identified.  Not sure it has ever been tagged or branched
even until recently.

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

[William A Rowe Jr]

On Aug 7, 2015 3:20 PM, Benson Margulies bimargul...@gmail.com wrote:

 On Fri, Aug 7, 2015 at 12:08 PM, Gregory Chase gch...@pivotal.io wrote:
  Does ...based on Apache Hadoop require a clear dependency notation as
to
  which versions of Apache component releases are part of the commercial
  distribution?

 No, it cannot. Trademark law is not a matter of such distinctions, and
 our very own Apache License imposes no such complexity.

Correct, and I don't expect we would ever enforce such a covenant on the
use of an ASF mark.

However, in the context of offering ASF software in the commercial or
noncommercial spaces, providing that information in some manner is just
good form and helpful to all end users.

Please never claim it is based on an unreleased version number.  Many
projects refer to foo 1.5.2-dev until 1.5.2 is released.  But if it is
based on 1.5.2-dev, this probably corresponds to 1.5.1+ patches, not the
actual 1.5.2 that will ship in the future.

Note that in the case of these projects here, it is important to note that
the code base is incubating (phrased as Apache Incubator Project Foo or
Apache Foo, incubating).  This isn't a concern for bundling TLP project
sources.

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

[William A Rowe Jr]

On Thu, Aug 6, 2015 at 7:50 PM, Roman Shaposhnik ro...@shaposhnik.org
wrote:

 Hi!

 while answering a question on release policies and ALv2
 I've suddenly realized that I really don't know what is the
 legal basis for enforcing release policies we've got
 documented over here:
http://www.apache.org/dev/release.html

 For example, what would be the legal basis for stopping
 a 3d party from releasing a snapshot of ASF's project
 source tree and claim it to be a release X.Y.Z of said
 project?


Nothing other than the Trademarks.

If someone wants to call httpd trunk 3.0.1-GA, they cannot do this as
Apache httpd 3.0.1-GA or Apache HTTP Server 3.0.1-GA.

They can certainly release trunk under the AL license and call it Kindred
Http Server 3.0.1-GA, based on Apache HTTP Server. That is a statement of
fact and not an abuse of the mark, IMHO. (If it was not actually based on
Apache HTTP Server, then that would similarly be a Trademark infringement
as it is a false use of the mark.)

There are no less than two marks, one is the name of the foundation itself
in conjunction with Open Source Software, and the other is the specific
project name.

Re: [IP CLEARANCE] HornetQ code grant

[William A Rowe Jr]

On Tue, Jul 7, 2015 at 1:54 PM, John D. Ament john.d.am...@gmail.com
wrote:

 This link is only available to ActiveMQ PMC Members.  Do you have a members
 link?
 Ideally I'm just looking for a link back to the CCLA/SGA.


In every case where you encounter this...


 On Tue, Jul 7, 2015 at 7:28 AM Gary Tully gary.tu...@gmail.com wrote:

  For some confirmation  and content of the CCLA filing see:
 
 
 https://mail-search.apache.org/pmc/private-arch/activemq-private/201409.mbox/ajax/%3c540a3a4d23744_759a10de0fc73...@whimsy-vm.mail%3E


s#/pmc/#/members/# ... so ...

https://mail-search.apache.org/members/private-arch/activemq-private/201409.mbox/ajax/%3c540a3a4d23744_759a10de0fc73...@whimsy-vm.mail%3E

Re: [DISCUSS] Geode Incubation proposal

[William A Rowe Jr]

I am a proposed mentor associated with Pivotal, well away from my own
technology and engineering teams.  I'm not good enough with darts to hit
that side of the org chart from this side of the room, but really would like
to see the contribution succeed, so I'm approaching this as always with
my ASF hat, as a facilitator and educator.  I've had enough conversations
to trust that this is doable.

There seem to be no further issues raised, and there have been nearly
2 weeks for more concerns, questions and other commentary.  Roman,
this appears to be vote-worthy.  Incubation can't begin unless incubation
is begun...

Yours,

Bill


On Wed, Apr 15, 2015 at 11:48 PM, Konstantin Boudnik c...@apache.org wrote:

 +1 on what Justin said. And I am not affiliated w/ Pivotal in _any_ way.

 Cos

 On Mon, Apr 13, 2015 at 08:10AM, Justin Erenkrantz wrote:
   On 13 Apr 2015, at 06:39, Ted Dunning ted.dunn...@gmail.com wrote:
  
   I think it is common to take a quick look at code coming in.  In
 
  To be clear, there were conversations with Jim (as VP Legal) prior to
  this submission.  The ASF wouldn't accept the software grant until the
  Incubator approved the proposal.  Pivotal wouldn't release it as ALv2
  until the ASF accepted the grant.
 
  It's a chicken-and-egg problem - seeing the code through the
  click-through evaluation license is the least bad scenario that drives
  this proposal forward.
 
  As a mentor unaffiliated with Pivotal, I'm not worried about the
  provenance checks - Pivotal is ready to execute the software grant and
  release it as ALv2.

RE: [DISCUSS] Geode Incubation proposal

[William A Rowe Jr]

Ross,

do we evaluate source code at the incubation-entry level, or do we evaluate
proposed development goals and development community propositions? I'm
curious about your thoughts.

Yours,

Bill
On Apr 13, 2015 12:16 AM, Ross Gardler (MS OPEN TECH) 
ross.gard...@microsoft.com wrote:

 Pivotal are asking me to agree to an evaluation license which I cannot
 view before I sign up. So I have to review the privacy policy first.

 Pivotal's privacy policy goes a *long* way beyond the point I am
 comfortable with when getting open source software (or deciding whether I
 want to agree with an evaluation license I can't read). I guess your
 defense could be that it's not open source yet, that's fine, but you are
 asking me, as an IPMC Member, to make a judgement on the validity of the
 proposal but I can't evaluate the code since I can't access it or the
 license under which I am allowed to view it.

 Most importantly, the export and license obligations you mention are
 something that have to go away before we can accept the project (or more
 accurately before it can graduate). Since I can't evaluate the code or the
 license I have no way of evaluating whether this is possible. There is no
 mention of such an item under known risks or the crypotography section
 of the proposal so what's this export stuff about (assuming the license
 thing is the evaluation license)?

 Given the points above I do not see how I can evaluate this proposal in
 its current form.

 Ross

 -Original Message-
 From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of
 Roman Shaposhnik
 Sent: Sunday, April 12, 2015 11:56 PM
 To: general@incubator.apache.org
 Subject: Re: [DISCUSS] Geode Incubation proposal

 Since I'm getting a few off-list questions, I just want to make one point
 clear:

 On Sun, Apr 12, 2015 at 8:53 PM, Roman Shaposhnik ro...@shaposhnik.org
 wrote:
  I'd also like to be able to review the source referred to in the
  proposal without having to sign up to  the Pivotal network - how can
 I do that?
 
  The issue here is export and license compliance. Unfortunately,
  singing up is the only way to go right now. Why is it problematic for
 you?

 The software currently is NOT under ALv2. It is available under the
 evaluation license. The whole point of the proposal is to make it available
 under ALv2 as an Incubating project.

 Our apologies for making folks click through the evaluation license.

 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: Committer Voting and Vetos

[William A. Rowe Jr.]

Understand there is a radical difference between majority, consensus and 
unanimity.  The HTTP Server project has successfully operated by unanimity, 
although many of us have experience of having the single holdout block progress.

I don't believe majority is sufficient in these sorts of matters.  In most 
projects, contributors are part of one or two major organizational players.  
That vocal minority protects a valued third voice.

But an intractable project member is also an issue.  If you are looking for 
unanimity in the face of an obstructionist, your choices are to move toward 
plurality or consensus ... or drop an obstructionist from the PMC roster.

The HTTP Server PMC has succeeded in working through these issues without 
evicting a project member, and continuing to make progress.

Noah Slater nsla...@apache.org wrote:

Another way of wording this would be: the CouchDB community feels that for
non-technical decisions, a single -1 vote should never block a majority
consensus. The idea being that if the reasons for the -1 vote were
compelling enough, others would change their position.

It happened recently on a PMC I sit on. Many people were in favour of an
action, and one person was against. The action was blocked.

If this happens regularly enough, you can end up never taking any actions.

Of course, how close to absolute consensus you want to require depends on
two things:

- The nature of the decision
- The shape of your community

For young projects, I would recommend being strict, and then loosening up
if you start to have problems.



On Friday, 26 September 2014, Noah Slater nsla...@apache.org wrote:

 As the primary author of the CouchDB bylaws, I will weigh in here.

 Agree with Ross on the discussion stuff. We actually codify this
 attitude in our bylaws.

 http://couchdb.apache.org/bylaws.html#decisions

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

 Wrt to the approval model of voting in committers...

 cf. http://couchdb.apache.org/bylaws.html#approval

 We chose lazy 2/3 majority, i.e. requires three binding +1 votes and
 twice as many binding +1 votes as binding -1 votes.

 Very specifically (and this is spelled out in the bylaws) with the
 CouchDB project, we only want a -1 vote to have veto power within the
 context of code review on a release branch.

 There are historical reasons for this. We found that some members of
 our community were casting -1 votes fairly carelessly, and expecting
 to be able to halt what the majority of the PMC felt were beneficial
 initiatives (including elections).

 For us, moving to lazy majority or lazy 2/3 majority for most big
 decisions was a way to improve our decision-making ability, allowing
 us to actually make changes to the project, whereas before we had been
 quite sclerotic.

 As Joe correctly hits on, some of this was due to me and others
 attempting to make some fairly large changes to the project since
 about 2012, when we ran into some major issues.

 One of the changes I was driving was the redefinition of what a
 committer is. I wanted to lower the barrier to entry. Whereas before
 we tended to only elect people who were contributing code, I wanted to
 expand that and start electing people who were doing other things,
 like documentation, translation, marketing, design, community
 management, and so on.

 This is just one example. But making these sorts of changes
 (essentially things that require cultural shifts) is hard when one
 person is able cast a -1 vote and shut down an initiative that
 everyone else is behind.



 On 26 September 2014 16:46, Ross Gardler (MS OPEN TECH)
 ross.gard...@microsoft.com javascript:; wrote:
  Trying to build on Joes answer below
 
  Given that the ASF is about consensus the vote for.at should be mostly
 irrelevant. Nominations should have been thoroughly discussed before the
 vote is called. The vote should be a formality required by the bylaws to
 demonstrate consensus.
 
  What I mean is there should never be a veto vote cast. The PMC should
 have already discussed the reasons why someone has their concerns. Those
 reasons should either have been supported (and no vote called) or talked
 through and withdrawn.
 
  An example... An individual was proposed, the PMC discussed. Two people
 felt it was too early because the individual had bit contributed much code,
 and thus their code quality could bit be assessed.  Everyone recognized the
 individual was contributing to user support, documentation, design etc. In
 order to have the objections removed a PMC member offered to mentor the new
 committee should code contributions prove to be problematic. This approach
 was agreed, the vote was called and passed.
 
  That individual is now a member of the foundation. Had we bot brought
 then in at the earliest 

Fwd: [ANN] Apache Syncope 1.0.0-RC3-incubating released

[William A. Rowe Jr.]

This seems very odd to me, certainly unusual among Apache projects.

The -dev and -user lists (and even general@incubator) are used to announce that
a release candidate is available and should be tested for readiness to become
an actual release.  Some projects use differently-numbered alpha and beta
designations in a similar manner.

A release candidate is, by definition, something which is not yet a release.
It doesn't seem like annou...@apache.org is an appropriate channel.  The amount
of traffic that list would carry if every 'might become a release' candidate
was offered over what is supposed to be a lower-bandwidth, higher priority list
for users to pick up released updates.

My 2c nonbinding.

Bill


 Original Message 
Subject:[ANN] Apache Syncope 1.0.0-RC3-incubating released
Date:   Thu, 26 Jul 2012 21:43:06 +0200
From:   Fabio Martelli fmarte...@apache.org
To: annou...@apache.org



The Apache Syncope team is pleased to announce the release of Syncope 
1.0.0-RC3-incubating
from the Apache Incubator.

Apache Syncope is an Open Source system for managing digital identities in 
enterprise
environments, implemented in JEE technology .

The release will be available *within 24h from*:
http://incubator.apache.org/syncope/downloads.html

The full change log is available here:
http://s.apache.org/tah
https://cwiki.apache.org/confluence/display/SYNCOPE/Espressivo#Espressivo-1.0.0RC1incubating(June1st,2012)

We welcome your help and feedback. For more information on how to report 
problems, and to
get involved, visit the project website at

http://incubator.apache.org/syncope/

The Apache Syncope Team

Best regards,
F.



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

Re: Lucene.NET status (Was: [Incubator Wiki] Update of May2012 by PrescottNasser)

[William A. Rowe Jr.]

On 5/9/2012 6:34 PM, Joe Schaefer wrote:
 Jukka:
 
 Thanks my friend.  The way you have been running the IPMC during your
 tenure as chair addresses just about everything I have ever bitched
 about regarding the Incubator.  I really appreciate what you are doing
 and the time it must take to do it, but it does not go unnoticed.

++1, no disrespect to those before you including dedicated mentors and
idea-people but this is measurably more effective.

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

Re: Shepherds for podling reports

[William A. Rowe Jr.]

On 5/4/2012 1:27 PM, Greg Stein wrote:
 In the Board agenda, we have a line where each Director can state they have
 reviewed the report (before the meeting). They can also append queries and
 comments. Little mini-discussions kinda happen in those comments.
 
 Point here is: provide a similar location for IPMC members (including
 shepherds) to list their review/approval. There is no strict need to divvy
 the reviews. Jukka is doing that as a transitionary measure until people
 get into it.

The approach would require just a couple of things;

 * designate a private report-review.txt file svn path which provides svn
   notification to the incubator-private list.  Private, because both personal
   and confidential questions may be asked and answered in the scope of that
   approval/question/comment review file.

 * populate that file each month with the list of reports.  Those reports
   themselves could continue to persist in the wiki or could be transfered
   into that internal edit/discuss report file.

A comment to that svn review file would be broadcast, so that answers and the
followup can either occur as a subsequent commit (asked and answered), or can
evolve into an incubator-private mail list dialog (or be referred over to the
podling-dev or podling-private list for clarification).

In all I like the idea.

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

Re: Question RE a non-ASF hosted project requiring contributors to have a signed ICLA submitted to the ASF

[William A. Rowe Jr.]

On 4/19/2012 9:03 AM, Stephen Connolly wrote:
 
 I have a non-ASF hosted project (jszip.org hosted on github in case you are
 interested), which I am hoping to build enough of a developer community
 (currently it is just me) around to be able to bring it into the ASF.
 
 To this end, I am licensing it under the ASL.

Sensible; although this would be the AL.  There is no 'S' in license v2.0.

 I don't want to have to maintain the ICLAs and CCLAs of contributors.
 
 Would it be OK if instead I just require that they have a signed ICLA with
 the ASF and that they grant the copyright to the ASF since my eventual
 intent is to bring this project into the ASF (once I have sufficient
 community to bring it in that is! ;-) )
 
 Thanks for considering this question.

It has been repeatedly argued that ICLA, CCLA are not actually necessary to
produce an AL 2.0 work.  They help clarify intent.  If you have another way
of clarifying intent, use that.  Document it, at least for yourself.  Take
our jira and bugzilla account creation logic, you license all contributions
made under your account as AL code.  And the AL has its own intrinsic language
to help assure AL contributions are recognizably AL.

Now, none of these people will become committers at the ASF without an ICLA,
end of story.  But that's up to them if they want to travel with the code,
in any case you have an AL work coming in, and for every committer who tags
along and files an ICLA, the better the paper trail becomes.

AL clause 5 puts the burden on the contributor to show they expressly and
carefully avoided granting an AL if they send you their work, end of story.





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

Re: [VOTE] Graduate JSPWiki from Incubator

[William A. Rowe Jr.]

On 4/15/2012 5:46 PM, Juan Pablo Santos Rodríguez wrote:
 we have made two releases following
 the ASF policies and guidelines. Thanks to the mentorship we have received
 through this period, we have learnt to self-govern and grow our community
 using accepted Apache practices.

As noted by others, this seems counter-factual.  Although candidates
may have been prepared, no candidate was voted for release and therefore
no candidate was a release.  Made no releases would be an accurate
statement, as would Made two candidates.  Candidates are not sufficient
for graduation as I understand incubator policy.

Due to placing an unapproved candidate into distribution, I trust that
the second comment, finishing 'learning... accepted Apache practices'
is also a statement due to be revisited.  I'm sure JSPwiki mentors will
be circling the wagons, and working out what went wrong, and ensuring
everyone involved understands how the mistakes occurred, and any missing
documentation will be added to incubator guidance documents.

 Please cast your votes:
 
 [  ]  +1 Graduate JSPWiki from Incubator
 [  ]  +0 Indifferent to graduation status of JSPWiki
 [  ]  +1 Reject graduation of JSPWiki from Incubator
 
 This vote will remain open for at least 72 hours from now.

At this time, it would be prudent to withdraw this vote from consideration
address all identified concerns, and wait for another day to put forward
this vote again, once i's are dotted, and t's are crossed.



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

Re: [VOTE] Graduate JSPWiki from Incubator

[William A. Rowe Jr.]

On 4/17/2012 3:57 AM, Ross Gardler wrote:
 -1
 
 Unless I am mistaken JSPWiki has not yet made a release under the
 Apache license:
 
 Release 2.9 as first Apache release
 https://issues.apache.org/jira/browse/JSPWIKI-717

http://www.apache.org/dist/incubator/jspwiki/

Apparently this was released.

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

Re: Extraordinary OpenOffice security patch (Was: [Incubator Wiki] Update of April2012 by robweir)

[William A. Rowe Jr.]

On 4/12/2012 2:59 AM, ant elder wrote:
 On Thu, Apr 12, 2012 at 8:37 AM, Ross Gardler
 rgard...@opendirective.com wrote:
 On 12 April 2012 07:48, Dave Fisher dave2w...@comcast.net wrote:

 ...

 Sorry, I can't remain mute, but I offended anyone, sorry, but this was 
 wrongly done. I don't know a better way

Don't, these concerns can and should be aired.  Any deviation from the
usual ASF practices should be defended (and defensible) or they should be
discarded.  I don't think you are wrong to be disturbed by the process,
but I do expect most of the AOOo PPMC will find what actually transpired
was reasonable, under the circumstances, after you _all_ discuss it in
postmortem evaluation.  That's dev@ list business.

 As one of the inner circle I am not offended. All your points are
 valid. Thank you for sharing them.

 This was the first and, in all likelihood the last time such an
 unusual circumstance will arise. There is no right or wrong way of
 handling these things.

 Had we included x then y would have felt excluded, this is what we are
 seeing here. However, the line must be drawn somewhere.

 
 Surely at the ASF the line is at PMC membership. If only a subset of
 the PPMC is trusted enough to be part of some inner circle then the
 PPMC should be disbanded and reformed from just that inner circle.
 Equally for the Incubator PMC, if Noel or who ever was chair should
 have been told then the Incubator PMC should have been included.

I'll refer to httpd, since it has the longest track record of security
incident handling.  There is about 1/4 of the httpd PMC who choose to be
active as part of the security list.  That group will go to the effort
to respond to reports, test reported defects, write patches, test patches
and help get the trunk or branch into some state that we can have a release.

If the incident is (or becomes) publicly known, the security@ list wipes
their hands of it, this mechanism is only used for embargoed issues.
There is sometimes a parallel discussion on security@ when a publicly
discussed flaw or patch has undisclosed security implications, but that's
pretty rare.

Well over half of the httpd PMC doesn't participate a whole lot in the
first place, including voting on release candidates, so expanding the
knowledge of undisclosed vulnerabilities to that group makes zero sense.
As a PMC member, any of them would be welcome to join the security team,
just as any can leave it if they don't have time or interest to follow
the security space.

I don't think we can compare the current AOOo situation; the PMC here
is effectively the IPMC, the only group of people with binding votes.
95% of that PMC should not have had advance knowledge of the specifics
of these defects, because 95% have little to do with AOOo on a daily
basis.  The people who would do the testing/verification/patch authoring
and further testing and verification needed to be on that list, but of
course are not binding PMC members [yet].  And of course there are even
meta security lists of lists in this case, owing to multiple projects
which are based on the common source code and subject to the same or very
similar defect exposures.

So the AOOo has assembled a hybrid model of some mentors and some of those
committed developers.  Certainly the project is going to refine policy going
forwards.  If I could do it over at httpd, I'd suggest anyone who has not
participated in the resolution of the past 'X' defects would be booted from
that security team.  [Gently nudged off might be more diplomatic.]  Perhaps
some combination of incidents and period of time.  security@ participation
is not some privilege, it's added responsibility to the PMC and project by
each of its subscribers.

But the point is that simply for issues of email transport compromise,
the people subscribed to that list need to pay extra attention to strictly
using ssl transport rather than plain text over public and private networks,
and that list needs to be broadcast to those people who will act on those
security emails, and to absolutely nobody else.

AOOo will continue to refine its practices in security@ handling, and I'd
trust them to make balanced and measured compromises from what I've observed
so far in my role on the ASF Security Team.  Upon becoming a TLP it will be
much easier to balance karma, authority and responsibility for security fixes,
and these will come much more organically from a then-shipping ASF package
which already had been released by the whole of the PMC.

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

Re: Extraordinary OpenOffice security patch (Was: [Incubator Wiki] Update of April2012 by robweir)

[William A. Rowe Jr.]

On 4/12/2012 2:37 AM, Daniel Shahaf wrote:
 Dave Fisher wrote on Wed, Apr 11, 2012 at 23:48:05 -0700:
 Sorry, I can't remain mute, but I offended anyone, sorry, but this was
 wrongly done. I don't know a better way
 
 What about expanding the membership of ooo-security@?  Currently it has
 less than 10 subscribers.

That's ideal for a start.  The security team needs to escalate actual releases
to the private@ pmc list, if not the dev@ list at some point.  Joining the
security@ list isn't the answer to missing communications to private@.

That said, does it have the right ~10 subscribers?  Are more appropriate?

It seems that about 1/3 of the httpd PMC are on httds's list, while most
every tomcat PMC member is on tomcat's list.  The global ASF security team
list is actually smaller than either, and a handful of these are likely to
be ASF officers rather than specific committee members.  [Note that the ASF
wide list is a firehose of spam, it's not a pleasant place to hang out.]

So if ooo-security grows to 20 that shouldn't be surprising at all, but it
should be deliberate and measured based on specific contributions to finding
or fixing specific security defects, over a number of years.  It's another
list where merit can be helpful in helping it grow over time.


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

Re: Extraordinary OpenOffice security patch (Was: [Incubator Wiki] Update of April2012 by robweir)

[William A. Rowe Jr.]

On 4/11/2012 2:36 PM, Jukka Zitting wrote:
 
 It should be noted though that even though the /dist/incubator/ooo
 space was used to distribute these patches, they were and are not
 officially blessed by the Incubator PMC on behalf of the ASF.
 
 Should a similar case arise in the future, I'd prefer if a clearly
 separate area under /dist or some other place was used to prevent
 confusing these with official Apache releases.

Short of people.a.o/~luser/my-patch.tgz, I'm fairly certain that
can't happen with an incubating podling.  Everything under the space
/dist/ must exist under a PMC.  And if AOOo ever does on a broad
security patch distribution, inflicting that traffic on people.a.o,
infra will be taking names and kicking asses.

As chair, you should have been brought into this loop, but with the
change from Noel I can see how this oversight happened.  Sorry about
that.  It's probably another example why the current infrastructure
schema simply isn't plausible.


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

Re: Is there an ASF license for Apple's Apple Developer Program ?

[William A. Rowe Jr.]

On 4/6/2012 10:17 AM, Rob Weir wrote:
 On Tue, Apr 3, 2012 at 1:43 PM, William A. Rowe Jr. wr...@rowe-clan.net 
 wrote:
 On 3/31/2012 8:43 AM, Rob Weir wrote:
 On Fri, Mar 30, 2012 at 7:20 AM, Ross Gardler 
 rgard...@opendirective.comwrote:

 There isn't (to my knowledge), I can imagine an increasing number of
 projects wanting such a thing though. Unless someone tells me I'm
 wrong and we already have one would you be interested in seeing if
 Apple are open to such an arrangement?



 I'd recommend first very careful review of the licensing terms first, on
 legal-discuss, to ensure that we're comfortable with any restrictions use
 of their SDK brings.  This would also help with other potential
 contributors who might have iOS apps they would like to contribute, but
 whose current analysis suggests that the Apple terms are incompatible.

 nonsense

 These are the very same SDK tools that these very same Apache Committers 
 already
 use on a daily basis.

 
 The issue, of course, is not what you do with the Apple SDK in the
 privacy of your own bedroom.  The question is about creating
 dependencies for releases and the restrictions these bring to
 downstream consumers.If you want to just say those are questions
 for the individual PMC's to resolve, then I'd agree, but I then note
 that the IPMC is the PMC for podlings, so my point is in order.

But it's apropos of nothing, yet.  Who has their login to WWDC handy?  How
many entitlements appear in your list of SDK's and other Apple developer
features?  500?  5000?  At least 50 full frameworks, supported, deprecated
and historical, alone.

Name ONE SDK from WWDC which a podling has a specific desire to deploy,
and then, we can look at its license.  Name one from Novell, or Microsoft.
We've done this a number of times at APR and HTTP Server projects.  But
until you identify a particular SDK, this isn't actually a productive
discussion to even a single podling.  When you have identified a specific
SDK, have a reference to it's license and decided you can't work out if
it is class A, B or X relative to an AL ASF work, then file a jira ticket
with the legal team, point to the license, and they can help sort it.
So it still would be unlikely to be worth email traffic to discuss, since
the jira ticket is both deliberative and archival of the decision.


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

Re: Is there an ASF license for Apple's Apple Developer Program ?

[William A. Rowe Jr.]

On 3/31/2012 8:43 AM, Rob Weir wrote:
 On Fri, Mar 30, 2012 at 7:20 AM, Ross Gardler 
 rgard...@opendirective.comwrote:
 
 There isn't (to my knowledge), I can imagine an increasing number of
 projects wanting such a thing though. Unless someone tells me I'm
 wrong and we already have one would you be interested in seeing if
 Apple are open to such an arrangement?


 
 I'd recommend first very careful review of the licensing terms first, on
 legal-discuss, to ensure that we're comfortable with any restrictions use
 of their SDK brings.  This would also help with other potential
 contributors who might have iOS apps they would like to contribute, but
 whose current analysis suggests that the Apple terms are incompatible.

nonsense

These are the very same SDK tools that these very same Apache Committers already
use on a daily basis.

The only modulo here is that some have access through work.  Some purchase their
own access.  Some have been comp'ed subscriptions individually or through other
organizations.

This simply makes the same tool for a committer free or discounted from what
they already paid.  For example, I was an MSDN subscriber through work for some
years, as a consultant for some years, took a break from my subscription on some
other years.  Now, I'm using a subscription donated for ASF committers.  Nothing
changed.

Sure, you can have a discussion about whether some WizBang API introduces new
licensing restrictions, platform lock-in, etc.  But we are NOT GOING TO BEGIN
auditing the Oracle Developer Suite, the Microsoft Developer Network, the Apple
Developer Network, the IBM HP VMware Google RedHat Citrix Adobe Amazon (OH GOD
MAKE IT STOP!!!) developer tool program for every possible future quirk.

There are real questions to be asked about specific tools and specific api's in
the open source and closed source world and the projects which are affected need
to do their homework and work with ASF legal to resolve ambiguity.  But any of
these examples includes hundreds of tools and api's and sdk's which have no
intersection with an ASF code base.

If Jim works out some connections for ASF  Apple and you use Apple then enjoy
that perk, and otherwise, please EIGNORE?  Thanks :)


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

IP Clearance? NAK

[William A. Rowe Jr.]

On 3/1/2012 4:17 PM, Roy T. Fielding wrote:
 On Mar 1, 2012, at 9:20 AM, William A. Rowe Jr. wrote:
 
 Perhaps you are signing up to do that ip-clearance, since it doesn't
 seem to be coming from the committer.
 
 IP clearance for an existing committer is BULLSHIT.  I already cleared
 that with Legal when I was chair of this project.

Somehow, having chaired the HTTP Server project for 2 years, I had missed
the memo.  This information is not being communicated.  Thank you for
enlightening me, our chair Eric, and the rest of the TLP communities.

The HTTP Server Project will proceed to ignore the IP Clearance process
laid out by the Incubator for all incoming contributions from any actual
project committer or their employer, until informed otherwise by the
President of the foundation.


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

Re: IP Clearance? NAK

[William A. Rowe Jr.]

On 3/1/2012 9:08 PM, Greg Stein wrote:
 
 Why don't you stop with your passive-aggressive bullshit, and read the
 thread over on legal-discuss where we talked about fixing the short
 form IP Clearance process. The IP policies have not changed, but they
 *should*, along the lines Roy suggests in that thread.

Greg; Roy just stated, it's not applicable and invalid.

Ergo the project will ignore this process until either 1. the Legal
Committee or 2. the ASF President inform the HTTP project of specific
external steps that it must follow with respect to IP intake offered by
committers (and as proxy for their employers).

Incubator isn't actually given any jurisdiction over projects.  Legal
committee is... and Roy states that Legal cleared HTTP from following
this (quoting) BULLSHIT process in respect to committer contributions.

I am getting incredibly frustrated with the fact that three founders and
current board members have no common institutional memory.  You three
probably should just hang up the hats already if you can't agree for even
a single day on a recollection any particular precedent. I might be passive
aggressive some days, but I'm not a psychopathic schizophrenic as the three
headed RoyGregJim beast is.

In the meantime, there is a project to run.  Roy acting as a former
officer has informed Eric, the current chair, and myself, a former chair,
of specific internal and official communication with the legal committee
that this process is not applicable to contributions from committers, and
we will respect Roy's recollection as former Chair until we hear otherwise
from an officer (not a schizo Director) of the foundation.


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

Re: IP Clearance? NAK

[William A. Rowe Jr.]

On 3/1/2012 9:49 PM, Sam Ruby wrote:
 
 I don't know what statement Roy is referring to, so I won't challenge
 it directly.  Instead I will ask that people work together to find out
 what processes are right for the ASF at this point in time, even if
 these processes are different than the ones that we used 10, 5, or
 even just 2 years ago.

In this specific case, I trust Roy to inform us if it meets the narrow
response he received with respect to a single committer's creation on
behalf of their employer (as we understand this submission) or if it
has some additional considerations.

Given that the President of the foundation hasn't objected for two
months to these code imports without IP clearance, obviously the
project is in the right.  If you don't agree the committee or board
would take that up with the President.

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

Re: [VOTE] RAT Ready To Graduate As Apache Creadur Top Level Project

[William A. Rowe Jr.]

On 2/26/2012 10:03 AM, Robert Burrell Donkin wrote:

 --8---
 [X] +1 the RAT community feels ready to graduate as Apache Creadur
 ---

Cheers!

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

Re: A modest proposal to use JIRA

[William A. Rowe Jr.]

On 2/14/2012 5:16 PM, Benson Margulies wrote:
 I propose a JIRA project for the incubator as a better way to recruit PMC
 members for tasks such as granting karma to new committers.

+1.  Shown to be highly effective at legal and infrastructure.


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

Re: [RESULT] [VOTE] Jukka Zitting for PMC Chair

[William A. Rowe Jr.]

On 2/13/2012 1:14 PM, Mattmann, Chris A (388J) wrote:
 Hi Noel,
 
 Thanks, for the record, the VOTE passes
 
 On Feb 13, 2012, at 9:30 AM, Noel J. Bergman wrote:
 
 I believe that we can call this vote, now, and request that the Board
 install Jukka as the new PMC Chair.

Action item: Board meeting this week; who's writing the resolution?


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

Re: [VOTE] Jukka Zitting for IPMC Chair (was Re: NOMINATIONS for Incubator PMC Chair)

[William A. Rowe Jr.]

With all three other candidates having checked it, sure looks like
we found consensus!

 [X] +1 Recommend Jukka Zitting for the IPMC chair position.



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

Re: [DISCUSS] [VOTE] Jukka Zitting for IPMC Chair (was Re: NOMINATIONS for Incubator PMC Chair)

[William A. Rowe Jr.]

On 2/9/2012 10:49 AM, Jim Jagielski wrote:
 
 On Feb 9, 2012, at 11:10 AM, Andrus Adamchik wrote:
 

 Well, if there's an election, the fair thing is to include all candidates 
 and see who gets the majority. A vote on just one candidate is odd. 

 
 Agreed.
 
 I suggest that this VOTE be withdrawn, and a true election,
 with all candidates be done.

Or as we say in the Windows world... ctrl+alt+delete.

+1, a public vote is not the issue, /shrug.  Listing all remaining candidates
(with clear withdrawals from Chris and Benson) is how it must be done.

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

Re: [DISCUSS] [VOTE] Jukka Zitting for IPMC Chair (was Re: NOMINATIONS for Incubator PMC Chair)

[William A. Rowe Jr.]

On 2/9/2012 11:29 AM, Dave Fisher wrote:
 
 (1) Why is the IPMC different from other PMCs and holding a personnel VOTEs  
 on a public ML?

Just to clarify this single issue; by rights, adding committers and
committee members is a personal issue about those individuals.  But
choosing a representative for the board is committee business, not
business about personal matters.  I don't mind which way committees
choose to do it, nor whether they are secret ballots.



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

Re: PMC chair vs. reorg proposals

[William A. Rowe Jr.]

On 2/6/2012 12:49 PM, Doug Cutting wrote:
 On 02/05/2012 11:40 AM, Benson Margulies wrote:
 If the board decides to go that way, I am happy to see Chris in charge
 of the transition.
 
 It's not the board's decision to make.  The folks in the Incubator need
 to decide what they as volunteers want to do.  As a board member, either
 approach is acceptable to me.
 
 Also, there doesn't need to be just a single approach.  If there's not a
 clear consensus one way or the other then some folks might try an
 experiment with direct-to-TLP incubation while some others might try
 revitalizing the IPMC.

This is a very good point (and closely maps the experiment already
suggested of a few test-cases).

I wonder which of the three candidates would be willing stewards of both
approaches simultaneously?  I would love to hear all three of their
thoughts, if this were the direction the Incubator chooses to proceed.



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

Re: Anyone care to talk to ComDev? (was Re: Time to vote the chair?)

[William A. Rowe Jr.]

On 2/6/2012 12:29 AM, Bertrand Delacretaz wrote:
 On Sat, Feb 4, 2012 at 2:06 AM, Ross Gardler rgard...@opendirective.com 
 wrote:
 My biggest problem is that the proposal moves undefined responsibilities to
 ComDev while none of the candidates have actually spoken to ComDev about
 this
 
 As a comdev PMC member, I am opposed to making that PMC responsible
 for the incubator.apache.org docs. I don't think comdev has any spare
 capacity at the moment, so I don't see the docs improving there.
 
 -Bertrand
 
 [1] http://wiki.apache.org/incubator/IncubatorDeconstructionProposal

Note that I had proposed something slightly different, where ComDev would
own all process docs which apply to the smooth functioning of all projects,
incubating or TLP.  Its guidelines wouldn't be focused on IP for example
(that's on the VP, Legal) but on the health and well being of project
communities.  Most of these documents are already written, and simply need
to be updated to state Here are recommendations to all projects; these
are mandatory requirements for incubating projects.

Incubation docs, which are rules by-reference-to the general process docs,
plus the incubation wiki would all still be on VP, Project Incubation, and
their small officer committee to edit and maintain them.

I'd gather that you and Luciano don't believe that the committee has even
that bandwidth.  But I'd suggest there are individuals at incubator whose
primary interest is documenting the process.  If the ComDev adopted these
general documents, I trust you would gather new participants at ComDev.

By filtering incubation rules as part of VP, Project Incubation role
along with the board's decisions, those debates don't have to fall onto
ComDev.  If ComDev wants to switch a general suggestion into a requirement
or a requirement into a suggestion for all TLP's, that would be for them
to discuss and increase the traffic on the ComDev list.

Again, the very guts of the Chris proposed deconstruction is that there
are rules, and there are recommendations for every ASF project to follow,
and this artificial incubating v.s. tlp distinction is a bit absurd.  The
only delta should those few suggestions to all projects which are actually
so important that they are requirements on the incubating projects, until
graduation.

Note that transitioning best practices documentations into asf-wide,
www.apache.org/dev/* resources under ComDev could happen at any point,
independent of all the proposals on the table.  If it's what both ComDev
and Incubator want to do.

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

Re: PMC chair vs. reorg proposals

[William A. Rowe Jr.]

On 2/6/2012 1:33 PM, Benson Margulies wrote:
 
 It seems to me that one of the ideas would require some board
 assistance: Roy's 'IPMC as board' structure, in which, it seems to me,
 podlings (sooner or later) take binding votes on their own releases
 and committers, but the board delegates supervision to the IPMC
 instead of doing all if it.

   NOW, THEREFORE, BE IT RESOLVED, that a Project Management
   Committee (PMC), to be known as the Apache Incubator PMC, be
   and hereby is established pursuant to the Bylaws of the
   Foundation; and be it further

   RESOLVED, that the Apache Incubator PMC be and hereby is
   responsible for the acceptance and oversight of new products
   submitted or proposed to become part of the Foundation;
   and be it further

+  RESOLVED, that the Apache Incubator PMC be and hereby is
+  responsible for the creation, dissolution and oversight of
+  incubating project management subcommittees of the Foundation;
+  and be it further

   RESOLVED, that the Apache Incubator PMC is responsible for
   providing guidance and ensuring that subcommittees under its
   purview develop products according to the Foundation's philosophy
   and guidelines for collaborative development; and be it further

[s/subprojects/subcommittees/ above]

   RESOLVED, that the Apache Incubator PMC is responsible for
   regularly evaluating products under its purview and making the
   determination in each case of whether the product should be
   abandoned, continue to receive guidance and support, or
   proposed to the board for promotion to full project status
   as part of an existing or new Foundation PMC; and be it further



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

Re: PMC chair vs. reorg proposals

[William A. Rowe Jr.]

On 2/5/2012 10:20 AM, Christian Grobmeier wrote:
 
 No. With all respect for Noel - we have discussed this multiple times
 now. There is a need for a change because some administrative stuff
 was delayed. There is a need for a change because on of us demanded it
 (Bill if I remember right). Why should we wait again and re-discuss
 everything? There is nothing wrong with doing the election now.

You most certainly remember wrong.  I pointed out the less-than-tactful
aspects of the call for an election/replacement (which was unfortunately
both at the same time), and some mechanical answers which would help
this or any other committee push for a chair election without insult
to the efforts of the standing chair, and why it is NOT an insult to ask
for an election after their initial year of service.

But I entirely agree Noel should stay on for a bit longer, until it is
clear that Chris and Benson agree on which should be elected and how
they would serve as chair the committee, because I for one am going to
vote Noel if either is so disagreeable as to be unable to gather support
or gather consensus.  Right now they are on very polar ends of the whole
discussion, which suggests neither until the incubator and board choose
a path forward.



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

Re: Anyone care to talk to ComDev? (was Re: Time to vote the chair?)

[William A. Rowe Jr.]

On 2/5/2012 12:37 AM, Luciano Resende wrote:
 
 One thing that is not clear on the proposal is that it says that
 releases will be responsibility of the TLPs, but it doest not suggest
 or require that the actual existing ASF members that are part of the
 TLP have to vote on the release. This might become an issue with
 podlings that are not so experienced with the IP issues, etc and
 official ASF releases from these podlings might have issues.
 
 I'd recommend that, during the incubation period of the TLP,  releases
 are required to have at least 3 votes from existing ASF members. This
 might still be a little overhead, but at least it's members of the
 PMC, and the TLP would not have to go chase IPMC on the general list
 to get release approval.

Here again, this suggests excessive paranoia.  We've had broken releases
from plenty of TLP's... they do get sorted out over time.

It might be worthwhile to require 3 ASF members on the initial release,
2 on the next, 1 on the following and then trust the committee to follow
the established precedent.  I believe that in the Incubating Project
Requirements and Guidelines (a different document than the proposal, one
that will be created and refined over time, largely the existing incubator
docs today to start with) ... projects should earn incremental trust and
authority.  You've raised one good example.


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

Re: PMC chair vs. reorg proposals

[William A. Rowe Jr.]

On 2/5/2012 1:40 PM, Benson Margulies wrote:
 
 Just to set the record straight and get out of the way, *my* position
 is that I do not feel particularly qualified to lead the charge in
 presiding over the disassembly of the incubator. My alternative
 proposal is not my 'election platform' -- it's just an alternative --
 and as much Ralph's now as mine. If the incubator isn't disassembled,
 it has to find some compromise between (to oversimplify) you and Joe,
 and it's one possibility.

Which was entirely my point.  You don't have 'platforms'.  You each
'champion' entirely different approaches to solving the issues that
everyone agrees do exist, today.

So without knowing which direction we travel, it is hard to select
the most appropriate candidate.  Or rather, selecting one of the two
candidates pretty much sets forward a direction.  So as the chief
advocates of two competing proposals, it's no longer possible to
discern the candidate from the proposal.

Or rather, if either of you were elected to guide in a direction you
very much disagreed with, you would be very frustrated, and probably
end up as a disappointing leader of any efforts at all.

I'd rather have an election in 2 or 3 months after IPMC or the board
decides what will happen next.  And depending on how the two of your
positions and ideas shift over that time in these discussions, it's
entirely possible you each make equivalently successful leaders over
the final consensus that is drawn up.  For Noel to serve and just let
the current discussion play out sounds great to me.


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

Re: Evolution instead of a revolution (Was: Time to vote the chair?)

[William A. Rowe Jr.]

On 2/4/2012 2:07 PM, William A. Rowe Jr. wrote:
 
 [offlist]

(sorry, trying to respond individually to keep down the noise, stupid
trackpad+palm of my thumb sometimes lets notes fly prematurely.  My bad.)

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

Re: TL;DR

[William A. Rowe Jr.]

On 2/4/2012 12:45 PM, Dave Fisher wrote:
 
 If it is different from Chris's then I think Bill should write his proposal.

Dave, mine is not difference in process, substance or requirements.

Chris and 7 board members are now familiar with the delta, which is
really not up for incubator to choose.  The question is simply whether
the board will oversee the process, documented by ComDev, with a third
driver in the incubating project entry/exit process (a VP in addition
to the Chairman and Mentors), or not.

Because that VP is simply a board-delta, it's going to be up to the
board, if the new schema is adopted, whether they want that additional
driver to take some load off of their collective plate.  I assume they
will, Chris assumes they won't, and the board, not this committee, is
going to be the one to decide that.

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

Re: TL;DR

[William A. Rowe Jr.]

On 2/4/2012 3:05 AM, ant elder wrote:
 
 I also agree with a comment from Sam on another thread about wouldn't
 it be possible to get to just a single chair candidate. That doesn't
 seem to be happening yet so as there are all these plans going on to
 get rid of the Incubator altogether can't we put the chair election on
 hold for now to see what happens? I'm sure Noel will be up for hanging
 on a few more months while all the other plans are worked out.

+1... I can see Noel 'hanging out a while longer' while things are unwound
here, if that is the decision that is arrived at.  It might be beneficial
if not too-many-things changed all-at-once.


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

Re: Incubator, or Incubation?

[William A. Rowe Jr.]

On 2/3/2012 11:11 AM, Sam Ruby wrote:
 On Fri, Feb 3, 2012 at 5:26 AM, Greg Stein gst...@gmail.com wrote:
 Below is *precisely* my view on the matter. Bill annoys me sometimes
 :-P, but I have to say that I'm in 100% concurrence with him w.r.t
 thoughts/positioning below.
 
 While I agree that in an ideal world that's how things *ought* to
 operate, do we the name of a potential chair who is ready, willing,
 and able to execute on such?

Chris is clearly willing, he authored the plan.

Moreso, there are those of us who would support him in execution of
such an effort.

But is he willing to stay the 6 months beyond dissolving the IPMC as the
VP, Project Incubation if the board believes such a post is necessary,
particularly if the board hasn't convinced him of its value?  I can't
answer for him, but I trust there will be enough participants for the
board to select a different individual if 1) it wants that post beyond
dissolution of IPMC, and 2) Chris can't bring himself to continue.

That particular inflection point is quite a ways down the road, even
in the fastest of plans to begin adopting Foo Project, Incubating TLPs.

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

Re: Nomination of Chris Mattman for the IPMC Chair (was: Re: NOMINATIONS for Incubator PMC Chair)

[William A. Rowe Jr.]

On 2/3/2012 8:07 AM, Sam Ruby wrote:
 On Fri, Feb 3, 2012 at 7:34 AM, Benson Margulies bimargul...@gmail.com 
 wrote:
 It seems to me that the proposed new scheme will take quite a bit of
 setting up. There is some writing to do. More to the point, if I were
 the board, I would want to pilot the new scheme for some time before
 tearing down the existing incubator. All of this looks to me like more
 than 2 months.

 A trial balloon: the board appoints Chris to run a PMC to set this up
 and try it out -- with the intention of being a short-lived
 phenomenon. Meanwhile, Noel or I or some other nominee continue to
 make the best of the incubator as we have it, including the gradual
 modifications pushed by Sam and Joe. If the board eventually decides
 that the ipmc is entirely obviated by the membership and comdev, we'll
 hire a bagpiper for the closing ceremony. If it turns out that a small
 IPMC providing support and assistance to 'probationary projects' is
 desired, we'll go on a diet.

 I just don't think it is realistic to imagine that in 60 days from
 some near-term board meeting, we can set up this new plan, debug it,
 and transition the existing clutch. While this can't avoid ending up
 as electioneering, I don't think it a good idea to simply appoint an
 IPMC chairman who is focussed like a laser beam on this restructuring
 to the exclusion of making the best of what we're currently doing.
 
 This makes sense to me.  Podlings are an obvious granularity to try out this.
 
 Over a period of years we dissolved Jakarta.  We started by graduating
 Ant and Tomcat to be TLPs.  This was once a new concept.  Over time,
 less and less remained under the umbrella.
 
 Selecting individual podlings that seem best equipped to try out the
 new experiment would be a reasonable way to proceed.

I'm actually thinking the thru-process test might be more useful.  Take
the next two incubating projects 'accepted', put Chris and I each on one
of them with another few mentors each as usual, give them the board
resolutions to create them as Project, Incubating accountable to the
policies proscribed by the VP, Incubator, and see how the process flows.
Chris and I have each incubated a few projects all the way through, so
it should be easy for us to note obstacles and roadblocks that need to
be corrected through docs and policy revisions.


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

Re: Mentors as the core of the IPMC

[William A. Rowe Jr.]

On 2/3/2012 7:58 AM, Jim Jagielski wrote:
 One thing I would like to be bantered about:
 
 Long ago, it was customary to have a single mentor for a podling.
 Nowadays, the feelings are the more, the merrier.

By the same measure, there is a role of Champion.  If we can avoid
fracturing that role into co-champions or vice-champions, then you
have the titular head of the first iteration of the committee, and
the go-to person accountable to the board.


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

Re: Evolution instead of a revolution (Was: Time to vote the chair?)

[William A. Rowe Jr.]

On 2/3/2012 11:47 AM, Karl Wright wrote:
 +1 on this.  Work the bugs out before everyone transitions.

One doesn't preclude the other.  As I wrote in response to an almost
entirely different thread, Podlings are accountable to the Incubator
PMC.  A Project, Incubating would be accountable to the policies of
the Incubator VP.

Both can co-exist.  The documentation is near-identical.  One does
not have the independent ability to release code, the other does.
One changes their composition by notifying IPMC, the other would
change their composition by notifying the board.  One has no actual
titular head, but a vague 'Champion' and several 'Mentors' overseeing
the day to day operation and interaction in the project.  The other
would have a titular head, VP e.g. 'Champion', and several 'Mentors'
overseeing the day to day operation and interaction in the project.

One goes through a process to have the IPMC ratify that it is ready
to be a TLP, and the IPMC presents a resolution to the board to
establish a regular project of the ASF, and appointing its first
Chair/VP.  The other would self-certify the same graduation checklist,
and present a resolution to the board to establish a regular project
of the ASF, replacing the Project, Incubating committee, and appointing
an appropriate Chair/VP (to replace the Champion) at that time.

What is missing is the entry documentation into this process, and
the exit documentation from this process.  This is what I would hope
to present to the Board for consideration and generic right track/
wrong track guidance at their February meeting.


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

Re: Evolution instead of a revolution (Was: Time to vote the chair?)

[William A. Rowe Jr.]

On 2/3/2012 12:51 PM, Franklin, Matthew B. wrote:
 
 So that everyone affected by these proposals has the opportunity to engage in 
 the discussion, I recommend that we pull these out of e-mail for a while and 
 ask everyone who has a new plan for the incubator to draft proposals on the 
 wiki as Chris did.  At that point, we could have a bake-off discussion where 
 the community has the ability to evaluate and chime in with their 
 concerns/comments/suggestions.

Funny you mention it, the Incubator itself was the product of a bake off
between two proposed resolutions, still recorded in the board minutes :)


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

Re: Incubator, or Incubation?

[William A. Rowe Jr.]

On 2/3/2012 4:46 PM, Mattmann, Chris A (388J) wrote:
 On Feb 3, 2012, at 2:37 PM, Roy T. Fielding wrote:
 
 On Feb 3, 2012, at 2:00 PM, Sam Ruby wrote:
 There is a place in the middle, which very much intrigues me.  Instead
 of replacing 1 IPMC with n PMCs, having n+1 PMCs, with the Incubator
 playing a role much like legal or trademarks (or infra or press
 or...).  In particular, when problems arise the board would direct the
 PPMC to work with this group.

 This group would be much smaller than the current Incubator, but would
 continue indefinitely.

 IMO, that sounds like ComDev.  ComDev was created, at least in part, to
 complete the documentation tasks that Incubator dropped and act as an
 Apache-wide community builder regardless of project status.
 
 +1, Roy. In my proposal, that is ComDev.

And the proposed edit doesn't change ComDev's role one bit in terms of
the documentation of ASF project documentation, either.

The only proposed edit if the board desires would be to retain a VP,
Project Incubation as the board's agent in making things happen when
the champion/mentors are less familiar with the technical details, and
align the day to day process of incubation to address the board's ever
evolving requirements and concerns.

Think of VP, Project Incubation as the Board's and ComDev's agent for
change as it becomes necessary.  Like VP, Java Community it would be
a stub/inactive placeholder most of the rest of the time.


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

Re: Evolution instead of a revolution (Was: Time to vote the chair?)

[William A. Rowe Jr.]

On 2/3/2012 5:55 PM, Ralph Goers wrote:
 
 Disbanding the PMC seems to me to be a very reactionary approach to the 
 problem. 

That's because disbanding the IPMC isn't in response to /that/ problem,
so little wonder you are confused.

Disbanding the IPMC, and making PPMC contributors part of their own
committees, gives them voices in a process that they are locked out of.

One recent response was to hand pick a select few of the PPMC contributors
who went above and beyond, and give these exalted few individual membership
in the IPMC, so their votes would be binding.

But Roy has always been fond of saying that if you are creating the code
you should be the one with voting privileges.  All of 'you'.

Making each 'podling' an actual committee, with additional restrictions
due to their 'freshness' and new exposure to ASF culture, gives the core
of each new podling the voice and authority to act on their own code.

And /that/ is the problem that we are trying to solve ;)


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

Re: Evolution instead of a revolution (Was: Time to vote the chair?)

[William A. Rowe Jr.]

On 2/3/2012 7:06 PM, Ralph Goers wrote:
 
 It would be perfectly reasonable to me for the IPMC to find other ways for a 
 PPMC to have binding votes.

I don't see a reasonable alternative structure.  Feel free to propose one.

I explored the idea of having subcommittees make these releases.  That
would /still/ mean having the board acknowledge those who are doing the
voting, or making a rather complex structure of the board conveying the
responsibility for granting code review/approval karma to another body.

It all falls back on the board.  Right now, we are running two boards,
one over incubating efforts and one over 'mature' projects; one is
empowering projects and the other emasculating them.  This is really
quite silly and seems we aught to quit it already.

My interest goes beyond any of those topics, though.  Incubator is very
tedious.  Very little is resolved.  Deck chairs are shuffled.  But at
the end of the day, projects don't have ownership of their code, many
micro-managers do, we aren't necessarily creating better projects than
Chris's proposed structure, and the entire process and participation is
simply not enjoyable (except to the sadists or masochists).



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

Re: Anyone care to talk to ComDev? (was Re: Time to vote the chair?)

[William A. Rowe Jr.]

On 2/3/2012 7:06 PM, Ross Gardler wrote:
 
 Do any of the candidates want to take a little time to define the role they
 see for ComDev?

Sounds like additional documentation for the proposal

Committee:  Previous responsibility   ---   Revised responsibility
_   ___   __

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

Re: Evolution instead of a revolution (Was: Time to vote the chair?)

[William A. Rowe Jr.]

On 2/3/2012 7:19 PM, Ross Gardler wrote:
 On 4 February 2012 01:06, Ralph Goers ralph.go...@dslextreme.com wrote:
 The main problem I see, and what Joe seems to complain about a lot, is that 
 mentors seem to fail at mentoring.  Creating a
 project that reports to the board whose mentors stop mentoring just pushes 
 the problem to the board, which is IMO not what they
 should be having to deal with.
 
 I agree. This proposal in its current form solves on problem (IPMC
 inefficiencies) and moves another the problem (inadequate mentoring),

No.

The existing problem remains the revised problem.  Any solution applicable
to the IPMC intervening in a dysfunctional PPMC applies to the Champion and
VP, Incubator intervening in a dysfunctional PMC, Incubating.

Except that the board is likely to be much less tolerant and much quicker
to disband a failed effort that the motley band of IPMC has been.

The problem set is identical, and this proposal does not address it any
better or worse than the current committee structure.

The problem varies in one dimension only; in the IPMC, the general@ comes
to the rescue of absent mentors.  That won't be possible in the revised
structure without the rescuers signing up and committing to mentor the
Project, Incubating as PMC members.  And since there are many complaints
about insufficient commitment, this is probably not a bad thing.


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

Re: TL;DR

[William A. Rowe Jr.]

On 2/3/2012 7:38 PM, Ross Gardler wrote:
 
 All nominees have said they back the radical reform plan. That plan as
 it currently stands reads, to me, as nuke the IPMC and pass all
 responsibility for ensuring projects are adequately mentored to
 ComDev. 

Ross, I'm not a candidate.  But I certainly don't believe that.

Pass all responsibility for mentoring to the incubating projects and
the members, and responsibility for ensuring they are mentored to the
board.  That means mentors must appeal to members and committers for
mentorship and members will need to step up if they want to adopt new
projects into the ASF.  And should the board see they are not adequately
mentored, the board has a simple remedy; terminate the effort.

I really think that mentorship will no longer be a great issue, if it
is upon the incubating projects to yell when they receive no guidance
or oversight.  And it will no longer be necessary to join the IPMC to
become a mentor.

I believe ComDev should own the documentation of operating a healthy
PMC, and the VP, Incubation should maintain a very trivial list pointing
into that documentation and demanding measurable results against that
documentation.  Incubator is a many-too-layered onion today, and it
seems people keep trying to wrap Chris's proposal in more layers of
Onion, because it is insufficiently complex to result in 100 people
arguing with one another for days on end.


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

Re: Evolution instead of a revolution (Was: Time to vote the chair?)

[William A. Rowe Jr.]

On 2/3/2012 7:40 PM, Ralph Goers wrote:
 
 
 I thought I did.  The proposal that Chris put forth seems to make podlings 
 formal PMCs that report to the board simply so they have authority to vote on 
 releases, add new committers, etc..  My proposal is to give podlings the 
 authority to make the releases and add new committers as long as they have 
 approval of their mentors. It doesn't require a change in bylaws or even, so 
 far as I can tell, explicit board approval to do this. It might require 
 someone to change the voting page to clarify that the incubator works 
 differently. Big deal.

That's not a proposal the board can ratify at the next board meeting.

Try again.  It's not all that simple.  Give it a shot :)

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

Re: Evolution instead of a revolution (Was: Time to vote the chair?)

[William A. Rowe Jr.]

On 2/3/2012 7:47 PM, Ralph Goers wrote:
 
 On Feb 3, 2012, at 5:27 PM, William A. Rowe Jr. wrote:

 The existing problem remains the revised problem.  Any solution applicable
 to the IPMC intervening in a dysfunctional PPMC applies to the Champion and
 VP, Incubator intervening in a dysfunctional PMC, Incubating.
 
 So why wouldn't the VP, Incubator have a committee to help him?  Shoot even 
 the Attic has a committee.

I've stated previously, I believe they will appoint one, with some of
the helpful individuals who will ensure things get done.  The VP is the
one accountable and I'm sure that person would find people to share the
load, just as with the Attic.

 Except that the board is likely to be much less tolerant and much quicker
 to disband a failed effort that the motley band of IPMC has been.

 The problem set is identical, and this proposal does not address it any
 better or worse than the current committee structure.
 
 Well, to be blunt, that sucks.

No.  In all reality, it doesn't.  Far too many resources were drained in
the past five years on a handful of projects which never had a hope of
graduating.  An example was Blue Sky.  This will force mentors to pick
their battles, stand by their battles, and not to completely walk away
from them for months at a time.

 The problem varies in one dimension only; in the IPMC, the general@ comes
 to the rescue of absent mentors.  That won't be possible in the revised
 structure without the rescuers signing up and committing to mentor the
 Project, Incubating as PMC members.  And since there are many complaints
 about insufficient commitment, this is probably not a bad thing.
 
 Couldn't disagree more.  Getting rid of threads like these would make the 
 list quite useful as podlings could actually ask for help and not have to 
 wade through endless discussions to get it.  With the alternative the 
 discussions will be forced to move to members@ or some other obscure list.

And show me evidence over the past /eight/ years where that has happened?
Let's stop hand waving and produce examples and cases we can discuss.

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

Re: Evolution instead of a revolution (Was: Time to vote the chair?)

[William A. Rowe Jr.]

On 2/3/2012 9:01 PM, Franklin, Matthew B. wrote:
 
 Personally, I feel that walking in the door as a full PMC with authority
 could be just as problematic in the long run as not granting it once the
 community has demonstrated viability.

I think that everyone here agrees.  These would not be 'full PMC's... the
ASF has a general 'set your own policies, hands off until it's broke' policy
towards projects.

Nobody is suggesting that an incoming 'project under incubation' would be
free of such rules, policies or oversight.  Where usual TLP's are free to
set the most flexible policies that suit their participants, any project
under incubation has a more stringent set of ComDev defined 'best practices'
that they must and will follow.  If as a full TLP they decide a tweak here
or there help their community, it's up to the board to permit that.  And
generally, the board is flexibly permissive.

But with one Champion not of the project itself, but of the ASF, and several
additional mentors/overseers/ombudsmen, no incubating effort is going to
enjoy the free reign that TLP's have.  If only all projects had that sort
of supervision, the foundation would be quite secure in knowing that all
projects are running as non-factional, non-partisan and non-commercial
efforts to create software for the public good.

Good concerns to raise, but i think they are unfounded in light of the
current proposal[s].

Bill

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

Re: Nomination of Chris Mattman for the IPMC Chair (was: Re: NOMINATIONS for Incubator PMC Chair)

[William A. Rowe Jr.]

On 2/3/2012 8:41 PM, Ross Gardler wrote:
 Lets not forget that the model referred to *included* the IPMC. The
 IPMC once had a useful function, it was a safety net for fledgling
 communities.

The IPMC never served that purpose.  Projects were scuttled even in
its first year.

The IPMC served to take the complexity of bringing in new code off of
the board of directors.  Little more.

The IPMC in turn replaced Jakarta as the repository of interesting
experiments that might or might not fly, and similarly replaced Jakarta
as the home of vague and uncertain direction for new efforts.  Nothing
more.

A large percentage of the first 25 incubating efforts are failures,
not because of the incubator, but in spite of it.  The incubator
failed to increase the success rate of the average effort.

And the board would have failed in bringing in new efforts, and the
Incubator would have failed as spectacularly as Jakarta, except that
Chris and others recognize the few good bits to be gleaned from the
whole experiment, and can relieve the board of the majority of the
headaches it was avoiding, in partnership with ComDev.

We now not only internalize, and can voice the process, but we have
documented the process.  Anyone can read it.  Any member can help
mentor it, and point people to the appropriate docs.

The incubator truly is done.  It is the most public, most ineffective
old boys club ever to infest OSS.  It has digested and documented all
of the useful bits, and persists in infernally arguing over the rest
of the undocumented and mostly irrelevant bits.  It does so in a very
embarrassingly public way.

There are three memes to associate with those who resist the change
that Chris has correctly proscribed;

 1. Lack of control is hard.  We all want authority.  The incubator
gave every member a podium and soapbox to stand upon and speak
across with authority.  And even in discord and disagreement, we
are ASF members, so clearly we individually know better.  [Given
the number of ASF members leaving the incubator recently, one
might question that.]

 2. Fear of missteps is hard.  We've watched every project at the ASF
teeter, occasionally trip, and rarely but significantly fall upon
their 'face' due to missteps.  So it's hard to give up control
because we know better how to avoid all that.  [The administration
and day to day activity of incubator would suggest we don't].

 3. Risk of failure is hard.  There will be projects which are going
to fall flat whether the incubator provides them 24x7 counseling
or makes them do all the work themselves.  There is nothing that
the present IPMC does which alleviates or even mitigates this fact.
[In spite of everyone's best intentions.]

The incubator is a classic story of too many cooks spoiling the broth.
There is no more added value which can be offered by the situation
at the incubator today.  The results of the incubator in terms of
documentation and process are excellent.  It's time to eliminate the
differentiation between 'not yet a project' and 'a full project too
long neglected' and focus all ASF resources across the board at all
of the projects, incubating and established, and stop wasting time
hoping that some special sauce only from the back kitchen makes that
difference.



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

Re: TL;DR

[William A. Rowe Jr.]

On 2/3/2012 9:16 PM, Ross Gardler wrote:
 On 4 February 2012 01:56, William A. Rowe Jr. wr...@rowe-clan.net wrote:
 
 Pass all responsibility for mentoring to the incubating projects and
 the members, and responsibility for ensuring they are mentored to the
 board.
 
 The projects then turn to where?

That is the question to answer :)  We are not the Savior Himself, we
are not going to solve every problem, we are kidding Ourselves if we
believe otherwise.

The established, non-incubating projects then turn to where?

Answer that question, and you've solved the *ENTIRE* riddle :)


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

Re: Incubator, or Incubation?

[William A. Rowe Jr.]

Wow... a post that was too long even for me :)  We might want to break
this down into a couple of distinct topic threads for simplicities sake.

Anyways, just one commment;

On 2/2/2012 10:56 AM, Mattmann, Chris A (388J) wrote:
 
 On Feb 1, 2012, at 6:38 PM, Greg Stein wrote:
 
 I can easily see a small group of
 people maintaining that overall status and recommendation to graduate.
 I can see this group shepherding the initial incubating-TLP resolution
 to the Board. (a graduation resolution, if needed, could easily be
 handled by the TLP itself by graduation time)
 
 I can see what you and Bill are saying too and it's not a blocker for me, 
 but I'd urge you to consider the extra overhead that it would add, compared
 to the benefit of simply saying, the incoming project is simply any other 
 ASF project, has the notion that those 3 ASF members that MUST be 
 on the incoming project's PMC as identified in their proposal. And that
 those 3 ASF members could come from a collective set of what you guys
 are saying is this special, reduced IPMC like entity. I'm guessing that
 organically that's what would happen anyways. Only a small set of 
 ASF members will volunteer to be on these incoming projects and help
 shepherd them in just the way it works today.

You mention also No need for the position anymore. Just another report to
have to read as a board member, and someone to middle-man, when what the
board ought to be doing is talking to the new project's VP, day 1.

What I have tried to clearly state is; don't think of this VP as the
middle man.  Think of this VP as the expediter.  The one who takes a whole
stack of customs, duty, shipping and tarriff forms, and boils it down to
Fill this in, and we'll submit these things.

This VP would not be in the middle.  They would be on the sideline.  If
the mentors are entirely capable, perhaps ex-PMC chairs themselves, then
marvelous.  If they are PMC members who have never submitted a resolution
in their lives, the VP is there to assist.

The VP keeps the files on process.  Not the lofty PMC Bylaws and Best
Practices and Nurturing Your Community documents, but the cookie cutter
Your proposal should state formal documentation.  Think in terms of
ASF Legal, or better yet, Trademarks.  They don't stand 'over' any
committee.  They gather, define and communicate process.  That is the
role of VP, Project Incubation.  Individual PMCs (even incubating PMCs)
assume the *responsibility* for following those processes.  Not a traffic
cop, but a tourist guide.

It seems outside of the remit of ComDev to deal with this aspect, just
as it's outside the remit of ComDev to do the actual logistics of retiring
to and caring for the projects in the Attic.  Sure, ComDev will have some
good 'getting started', 'how to' docs about both incubation and retirement.
But they aren't the resolution wranglers charged with following up on the
board's feedback.  If a new incubating PMC resolution is broken, that VP
would step in to guide the mentors and podling to fix their proposal before
the board reconsiders it at a subsequent meeting.

So yes, it is a necessary task the board is going to delegate out, whether
it is framed as the IPMC, or the VP, Project incubation.  It can't be left
in a hundred different hands to drop.


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

Re: Incubator, or Incubation?

[William A. Rowe Jr.]

On 2/2/2012 12:27 PM, Mattmann, Chris A (388J) wrote:
 
 I guess the key difference between this small (but important) part of 
 our interpretation of this Incubator fix resolution that we're discussing
 is the following:
 
 You (and maybe Greg?) feel that you need 1 VP guy (and perhaps 
 a committee/or not) to help out these projects-from-day-1-new-projects
 that will be coming into the ASF, and that you need information flow up
 from that guy and responsibility/culpability from that guy to the board, 
 and on down from it. 

Nope, that VP would not be a flow-through.  Not even visible when things
are working optimally;

 I, on the other hand, feel that the N(=3?) ASF members that have to be
 part of the new project's PMC from day 1, and that that new project's 
 VP (from day 1), are sufficient to provide that information flow up, and
 responsibility/culpability. And guidance. And pointers to ASF resources
 like ComDev (which will hold the Incubator docs), like Legal, like etc.
 Just like the way it works today on our projects. 

Exactly.  When those N(=3) mentors don't have it together, this VP can
step in to facilitate.  Those mentors have to follow this VP's documented
process flow established to expedite things for the board's benefit. When
(not if) the process changes and evolves, it's on this VP to make the
necessary modifications.

But that VP won't be a gating factor if the mentors are experienced with
the process.  Responsibility for incubating projects is /not/ on the VP.


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

Re: Incubator, or Incubation?

[William A. Rowe Jr.]

On 2/2/2012 12:49 PM, Mattmann, Chris A (388J) wrote:
 
 OK. If that VP isn't a flow-through and isn't visible when things are working
 optimally, then why have him/her?

Because when the process needs revision, and it will, the board doesn't want to
revise it.  ComDev shouldn't have to revise it.  The board wants to point to one
individual and say 'this part is broke, fix it', and have it done.

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

Re: Time to vote the chair?

[William A. Rowe Jr.]

On 2/2/2012 8:15 PM, Benson Margulies wrote:
 
 I support your direction of delegating more authority to podlings by
 identifying qualified contributors and adding them to the IPMC. I also
 support the general direction of Bill's proposal to demolish the
 incubator

Credit where credit is due, this is not my brainchild.  Although I did
believe that, yes, putting an assortment of individuals into the very
complex IPMC to represent their very narrow interest in a podling was
counterproductive, I totally support the idea, and I've tried to offer
a few refinements gleaned from serving on the ASF board in the past.

All credit belongs to Chris Mattmann, I simply retitled the thread
when responding to his post
Message-ID: 25c5ae77-6949-493e-bbd5-eb20869a2...@jpl.nasa.gov

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

Re: Nomination of Chris Mattman for the IPMC Chair (was: Re: NOMINATIONS for Incubator PMC Chair)

[William A. Rowe Jr.]

On 2/2/2012 10:20 PM, Mattmann, Chris A (388J) wrote:
 Thanks Christian.
 
 I'll accept, thanks for your kind words, and for those of Marvin and 
 Joe, and the comments from Benson and others.
 
 I will note that should I be elected into this role, I will state that 
 I don't intend to be in it very long as I don't intend for it to exist
 much longer. Should I be elected I will immediately move to 
 a proposal/resolution phase and recommendation to the board
 to dissolve the Incubator PMC, and to ratify the elements of my
 proposal.
 
 I realize that Rome wasn't built in a day, but I'm optimistic
 that it can be built not longer after that.

I'm happy to support you in that effort, even as an assistant chair
(and I'd decline Noel's nomination, thanks though for the thought).

I think once it's proposed the board will make clear why the position
still needs to be filled, even if they accept such a radical rethinking
of the process.  I think you would make a good choice on both sides of
the transition, once there is a clear scope for the other side of the
tunnel.

I'm happy to help with some of the structure of the incubating-project
resolutions, but my time is a bit too limited to handle the copy and
paste between situations.  Thinking that the gist of the transition be
considered and nominally approved or denied by the board in February,
and that in the succeeding three months, those project up for reporting
with three+ accountable mentors be put forward as incubating projects
(unless ready for graduation).  Between now and the consideration of
those first projects in March, the structure of incubator.a.o would
need to be altered slighly.

By June, we are left with a handful of projects which simply don't have
mentors or participants to propel them even to the stage of being a TLP
under incubation.  And that month would be the logical point to refer
them to the Attic if their IP is clean, or discard them altogether if
resources can't be mustered.  It's a long ways off, so lots of time to
intervene between now and then.




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

Re: Time to vote the chair?

[William A. Rowe Jr.]

On 2/2/2012 7:56 PM, Benson Margulies wrote:
 I have a lateral thought.  Assuming for the moment that Chris has
 accepted or will accept a nomination, why not recommend *both* of us
 to the board as co-chairs? The IPMC is special. New members pop up all
 the time and need to be fed to the board; projects need karmic
 assistance, etc. Having two will improve coverage. A variation on this
 theme would be to call one of us Chair and the other Vice-Chair, with
 the Vice-Chair empowered to pitch in on acks and karma, and the chair
 responsible for the reports.

The board has, as a rule, not approved co-chairs, but will entertain
an assistant chair, which really isn't a logistical headache.  If there
is a problem, they are still chasing or replacing the chair.


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

Re: Nomination of Chris Mattman for the IPMC Chair (was: Re: NOMINATIONS for Incubator PMC Chair)

[William A. Rowe Jr.]

On 2/2/2012 11:38 PM, Mattmann, Chris A (388J) wrote:

 However, please note that the re-org still has a position that is at least
 analogous.  You would not be getting off so easily.  ;-)
 
 :) Nope, it doesn't actually. Please read the thread carefully. That is 
 what is being suggested by Bill and by Greg, but I see room to convince
 them otherwise. I think they'll see the light. 

You don't need to convince me :)  You would need to convince the board,
and I don't expect them to be receptive.  I would rather go forward with
a VP, Project Incubation than to have the board dismiss the proposal out
of hand, if that's how they would have it.

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

Re: [DISCUSS] Syncope to Join the Apache Incubator

[William A. Rowe Jr.]

On 2/1/2012 12:51 PM, Greg Stein wrote:
 On Wed, Feb 1, 2012 at 08:56, Benson Margulies bimargul...@gmail.com wrote:
 ...
 I'm also trying, more pointedly, to head off the 'AWOL mentor' problem
 by asking mentors to think about, and state, the commitment they are
 making.
 
 But your approach is pre-judging them. I think it is better to be
 optimistic -- that people *will* continue as proper Mentors. Trust,
 but verify. *IF* somebody goes AWOL, then deal with it at that time,
 rather than simply assuming that up front.

+1

 Find a way to detect an AWOL mentor rather than requesting these
 uncomfortable justifications.

++1

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

re: Incubator, or Incubation?

[William A. Rowe Jr.]

On 1/31/2012 5:05 PM, Mattmann, Chris A (388J) wrote:
 
 On Jan 31, 2012, at 1:28 PM, Roy T. Fielding wrote:

 Having said that, I should note that the context of Incubator is
 significantly different than a normal PMC.  If incubator wants to structure
 itself more like a board and less like a project, I really don't have
 much to say against that.  Note that it should effect all of the decision
 guidelines that give veto power, not just personnel decisions.
 
 Isn't that the problem right now though? Like it or not, the Incubator PMC
 has evolved into a mini-board, in the worse sense of the word. You guys
 have a monthly meeting via telecon; an agenda; a set of action items, and 
 you still don't get everything that you want to get done, done.
 
 A very small percentage of folks within the IPMC actually maintain that type
 of board-like oversight over its podlings. And thus, because of that, the more
 I think about it, quite honestly, I don't know what the Incubator PMC is doing
 other than delay the inveitable eventuality that many of these projects will 
 graduate and become TLPs and thus the board's problem; whereas many 
 of them will not graduate, and become not Apache's problem. We have an 
 Attic for projects that make it to TLP for that. Heck, we have SVN and could
 even reboot Incubator dead projects if a group of individuals came along
 and wanted to maintain the code.
 
 My conclusion from all the ruckus recently has been that the Incubator PMC
 is nothing more than an Incubator mailing list where many ASF veterans 
 and those that care about the foundation discuss (and sometimes argue)
 about the foundation's policies and interpretations of law that not even 
 lawyers
 are perfect at -- we're all human yet we try and get on our high horse here
 and act like we speak in absolutes and the will of one or a small subset is
 the will of the many when we all know that in the end, if it's not fun 
 anymore,
 we wouldn't be here. 
 
 What would be so bad about saying that the Incubator, over its existence, 
 has served its purpose and has devolved into an umbrella project of the type
 that we are looking to get rid of at the Foundation. I agree with Bill on the 
 perspective that I'm sure at some point (and it's probably already happened), 
 we will experience Jakarta type symptoms and potentially may go down that
 road. Instead of couching it as scary HUGE change that several Apache 
 vets have expressed to me that the Foundation doesn't like, how about we 
 don't call it a change at all; and simply a success. IOW, the Incubator 
 itself
 has graduated and it's time for it to be Attic'ed.
 
 In replacement, I propose the following concrete actions:
 
 1. Move the Incubator process/policy/documentation, etc., to ComDev - I 
 agree with gstein on this. I think it could be maintained by the ASF community
 folks there, and updated over time. But it's not vastly or rapidly changing 
 really
 anymore. 
 
 2. Discharge the Incubator PMC and the role of Incubator VP -- pat everyone 
 on 
 the back, go have a beer, watch the big game together, whatever. Call it a 
 success, not a failure.
 
 3. Suggest at the board level that an Incubation process still exists at 
 Apache, 
 in the same way that it exists today. New projects write a proposal, the 
 proposal
 is VOTEd on by the board at the board's next monthly meeting, and those 
 that cannot be are QUEUED for the next meeting, or VOTEd on during out of 
 board inbetween time on board@. Refer those wanting to Incubate at Apache
 to the existing Incubator documentation maintained by the ComDev community.
 Tell them to ask questions there, about the process, about what to do, or if
 ideas make sense. But *not* to VOTE on whether they are accepted or not. 
 
 4. Require every podling to have at least 3 ASF members on it, similar to the
 current Incubator process. 
 
 5. Operate podlings *exactly the same* as a TLP. There is a chair. There is a
 committee. Committee members have binding VOTEs on releases. 
 
 I'm sure folks will argue this is blasphemy or that it will just add to the 
 board's
 work, or that  I'm ugly ... whatever. The fact of the matter is we kick 
 spinning
 around in circle's trying to fix process issues that have been band-aided for 
 years and that are now leaking like a sieve whenever we decide it's time to 
 shine a light on them. When things are going well in the Incubator, it's 
 not 
 because they are well. It's because no one is asking questions and they've
 chosen to ignore some of the gaping holes on the poor wounded body that
 remains. And then when some folks go and point out the gaping holes, we 
 get these huge song and dances that don't amount to anything other than
 the old mantra incremental change; don't rock the boat too much; XXX board
 member won't go for it; not here at Apache. Whatever.
 
 I think the board knows there is an issue with the Incubator. A lot of IPMC
 members do too. Some of us have spoken up; others 

Re: Incubator, or Incubation?

[William A. Rowe Jr.]

On 2/1/2012 4:52 PM, Benson Margulies wrote:
 At the risk of seeming trite, +1, but ...
 
 This lengthy proposal shifts the supervision responsibility of
 podlings from an big IPMC to a set of mentors approved by the board at
 the advice of a small iPMC. 

No.  Forget IPMC.  The VP, Project Incubation and their committee doesn't
advise, the members as a whole do, and propose the initial list of mentors.
general@ doesn't change, it's still the place for 'me, too!' offers to
mentor an incoming proposal.  But yes, that set of mentors provides the
initial guidance to the project and is responsible for reporting to the
board.  As a board reporting committee, the board too also has supervision
based on those reports.  One thing that does not change; every ASF member
has oversight privilage over most every private list at the ASF, including
our current PPMC and new Incubating PMC private lists.

 In other words, a project is born when
 three? foundation members, or others deemed appropriate by the small
 iPMC, are constituted as a project by the board, with one (the
 recently invented champion) as the chair.

When 3+ mentors step up on general, the members participating on general@
give something approaching consensus, the VP, Project Incubation simply
submits a resolution and the board takes it up and passes it (as is, or
amended).  And yes, the champion is the logical first-chair until the
project graduates or they are replaced for other reasons.

The board could also take up a resolution to charter an Incubating PMC
without the advisory vote on general@.  That is a bit different than
today, when imposing a podling onto Incubator would be somewhat absurd.

 It seems to me that this ups the ante quite a bit on the accidental
 argument I started about mentor qualifications. The board absolutely
 does not want to have to provide direct supervision all the podlings:
 that's what the Board's formal feedback to the IPMC just now is about.
 So, under this scheme, the particular mentors that make up the initial
 PMC of a project are the ones the Board is trusting, and if any step
 down, they absolutely need to be replaced.

Bingo :)

 I support proposing this structure to the Board, but I wouldn't be
 terribly surprised if the answer is 'no'.

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

Re: Incubator, or Incubation?

[William A. Rowe Jr.]

On 2/1/2012 5:14 PM, Mattmann, Chris A (388J) wrote:
 
 On Feb 1, 2012, at 2:52 PM, Benson Margulies wrote:

 It seems to me that this ups the ante quite a bit on the accidental
 argument I started about mentor qualifications. The board absolutely
 does not want to have to provide direct supervision all the podlings:
 
 It certainly makes your proposal about mentor qualifications important, 
 yes. But I wouldn't say that the 2nd part naturally follows. Why wouldn't
 the board want to supervise podlings? IOW, what's the difference between
 ~100 Apache projects, versus ~150? We're going to grow to 150 some-day
 anyways and I bet we'll still have a board of 9 directors.

Today, the board reviews some 30 reports, one of which is many pages long.
Under the proposed schema the board might review some 50 reports, each of
which is several paragraphs long, and the net length of the monthly board
report doesn't change at all.  Even the two or three paragraphs of
commentary usually offered by the VP would still be there, observing the
comings and goings of general@ activity.

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

Re: Incubator, or Incubation?

[William A. Rowe Jr.]

On 2/1/2012 5:11 PM, Mattmann, Chris A (388J) wrote:
 
 On Feb 1, 2012, at 2:25 PM, William A. Rowe Jr. wrote:

 I'd modify your proposal just a smidge.  Keep an Incubator VP with a very 
 small
 operational committee just to help move the podling through the entire 
 process
 of wrangling the necessary proposal, votes and board resolutions.  Some 
 amount
 of process documentation would remain under that VP and their committee.
 
 I think this modification adds overhead that I think we have already. ComDev
 can provide this guidance and I think that's what the natural purpose for it 
 is.

Simply, there needs to be someone (backed by a committee with specific 
individual
responsibilities, if that person likes) to shepherd state changes into a board
resolutions, ensure they hit the board agenda, maintain what we call the
'incubation web site' today, and answer inquiries about 'how do we go about X?'
You can suggest that the directors, members and site-dev people take on all of
those tasks, but we know that randomly distributed responsibilities don't work
out so well.  That's why there is now a collection of these VP roles at the ASF.

 Take VP, Project Incubation out of the role of judging incoming or 
 graduating
 projects.  Leave general@ for the process of submitting a proposal to come in
 as an incubating podling or leave by way of graduation, the attic, or 
 graveyard
 (full purge in the rare case of questionable IP provenience).

 Make every podling a proper PMC to include its mentors.  Make a choice 
 between
 including all listed initial contributors, or instead, have the mentors 
 promote
 the actual contributors given time and merit, based on a well thought out and
 somewhat predictable flowchart.

 Have ComDev drive the effort to ensure all projects are nurtured by finding 
 new
 mentorship of old, graduated projects as well as incubating projects who had 
 lost
 their mentors.  This might avoid some cases of the board imposing a full PMC 
 reset
 on established projects.

 Most importantly, have the voting by the full membership on general@ to 
 recommend
 to the board accepting a podling or graduating a podling to a TLP.
 
 If the full membership is making the recommendation then i see no need for a 
 VP
 Incubator and I think it should be disbanded. However, I agree with your 
 statements
 above and think they jive with my proposal. 

I view this more as giving the members the opportunity to raise questions and 
issues
of how a particular project proposal would fit here, which is what they do 
anyways.
This only makes it more formal.  You keep the VP simply as the record keeper and
executor of the decisions on general@.

  Why?  Given
 the example of the hotly contested AOO podling, if the membership 
 (represented
 by Incubator PMC members) did not ultimately have the discussion that was 
 held,
 and if the board had 'imposed' accepting AOO on the foundation, it would have
 done internal harm.  Now maybe only 50 of the members care to review 
 proposals
 and cast such votes.  That's OK, they are still representative of the 
 membership.
 If a member wants to gripe on the member's private list, they can be gently 
 but
 emphatically nudged to take their concerns to the general@ discussion of the
 proposed project.
 
 Yes yes yes. Perfect. That's right. Let the membership VOTE for the proposal 
 and then recommend to the board. That's a great idea. And I guess that would
 mean that general@ stays around. I could live with that so long as the VP 
 Incubator and the IPMC is discharged. As I said, I think they have more than
 served their purpose. 

Well, the scope of general@ shrinks dramatically, although it can continue to be
a place for a recently approved project to holler help, we need more help!.

You might view the VP as overlapping the Champion.  But do we want every one
of the Champions to have to be intimately familiar with the form of the board
resolutions, or consolidate some of the book-keeping?  VP Project Incubation
works with those Champions.  Much like the foundation-wide security@a.o team
works with all the individual projects as a resource, but isn't responsible
for the oversight of individual project security defects.

I don't see this working without an appointed coordinator.

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

Re: Nomination of Chris Mattman for the IPMC Chair (was: Re: NOMINATIONS for Incubator PMC Chair)

[William A. Rowe Jr.]

On 2/1/2012 6:52 PM, Christian Grobmeier wrote:
 On Thu, Feb 2, 2012 at 1:46 AM, Benson Margulies bimargul...@gmail.com 
 wrote:
 don't we also have jukka?
 
 Jukka expressed (to be found somewhere in the archives) he does not
 need additonal workload at the moment. In addition he is already
 JackRabbit Chair, not sure, but I think 2 chair roles are not possible
 at one time.

Of course it's possible, there's one individual holding 6 offices at
once right now.  But is it desirable?  That's another question.

As he said he's too busy ATM, guess that thread is complete.

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

Re: [DISCUSS] eliminate vetoes on personnel votes

[William A. Rowe Jr.]

On 1/30/2012 6:06 PM, Joe Schaefer wrote:
 It is clear that with all the turmoil of late and people
 lightly tossing around -1's that the notion of having veto
 authority over personnel matters makes little sense on this
 PMC.  Therefore I propose we adopt the policy that personnel
 votes are by straight majority consensus, iow no vetoes allowed.
 
 I intend to offer a policy vote on this issue over the coming
 days and that vote, as with all procedural votes, is NOT subject
 to veto.

Just FTR; as a proposal to modify a policy/process which requires
consensus today, your eventual [VOTE] does require consensus to be
adopted.  You can't do an end run around the current policy with
a simple majority.

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

Re: [DISCUSS] eliminate vetoes on personnel votes

[William A. Rowe Jr.]

On 1/31/2012 11:38 AM, Joe Schaefer wrote:
 
 Plainly wrong:  It has been repeatedly established (even by the Chair)
 that policy decisions here are not subject to veto.  This is one of those 
 times.
 Furthermore the documentation [1] clearly points out that procedural issues
 are to be decided by majority consensus, and nothing could be more procedural
 than a vote about how to count votes.
 
 [1] http://www.apache.org/foundation/voting.html

You assert this is simply policy.  I assert that this is a fundamental
to project bylaws, much like we don't fork (if we don't), or all
votes require 3 +1's.  You change such things only by consensus or by
board mandate.

Greg just finished explaining that only the chair can submit any
changes to the PMC.  Try changing that with a simple majority vote.


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

Re: [DISCUSS] eliminate vetoes on personnel votes

[William A. Rowe Jr.]

On 1/31/2012 11:12 AM, Greg Stein wrote:
 
 I'm a little unclear on wrowe's original message talking about
 supermajority and whether that was for *addition* or for *removal*.
 I'm assuming that it was only about addition because I've never seen
 any PMC-based ejection of a PMC member. The Board has wiped out PMC
 rosters before, but I really don't foresee any need to discuss (here)
 rules around removal.
 
 So we're only talking about addition.

Talk about what you want.  The subject line was clearly inclusive of
all.

 Please remember that these are *recommendations* to the Board. In
 effect, there is really no such thing as a veto, except that a Chair
 may simply refuse to send a request to the Board for the addition when
 a -1 appears. (and note the Board could do an end-around anyways and
 simply put that person on the PMC regardless of the vote/Chair(!))

Right right... this is only binding on committee recommendation which
is then subject to the decision of the chair which is then subject to
the decisions of the board, yadda yadda.

 In that light, we're talking about what kinds of voting results
 should be forwarded by the Chair? If the Chair sends a request to the
 Board to add somebody and reports 5 +1 votes, 2 -1 votes... would
 that be sufficient? 2/3rds or 3/4ths doesn't really matter. The Board
 is going to investigate the consensus and what is going on behind
 those negative votes.
 
 Shoot. If the Chair doesn't forward that result, somebody else could
 forward it with hey. we think $JOHN should be on the PMC, but the
 Chair isn't forwarding cuz of these negative votes. Bang. Again, an
 inspection results.

Good points.

 I think the short answer gets back to Joe's suggestion (and my
 concurrence): simply allow for a majority vote; forward that to the
 Board; let them decide.
 
 Keep it simple. Rules don't matter much when you're talking about
 forwarding recommendations to the Board.

Ok, let's keep it concensus, if you want to keep it anything.



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