incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ross Gardler (MS OPEN TECH)" <>
Subject RE: [DISCUSS] Whimsy PMC
Date Tue, 28 Apr 2015 18:25:12 GMT
I've often wondered why we don't open source more of the infra code. Maybe this is the reason.

Perhaps we need a new "brand" for such projects. Something like "Apache Foo (Infra)". This
would be similar to the "(Incubator)" branding. We could even adopt some of the same policies
(e.g. no press releases). If we find third parties start using and contributing to such code
we can drop the "(Infra)" part.

I'm really not sure this is necessary (see my earlier response), but since come folks have
a concern I thought I'd throw it out there. If it makes you, David, as VP Infra more comfortable
making infra produced code available then we should probably do it.


-----Original Message-----
From: David Nalley [] 
Sent: Tuesday, April 28, 2015 10:55 AM
Subject: Re: [DISCUSS] Whimsy PMC

On Mon, Apr 27, 2015 at 10:18 PM, Mattmann, Chris A (3980) <>
> I’ll note that the only person I see from infra that has been proposed 
> in the current PMC is Jake Ferrel:
> * Acquia: Jake Farrell
> Someone also correct me in that I don’t think Jake is a paid infra 
> contractor.
> In addition the way I see this is that it is no different e.g.,
> than contributing upstream to FreeBSD or whatever - Infra contractors 
> may fix something and decide it’s in the ASF’s best interests to 
> contribute it upstream - same may happen for Whimsy. But to date, ASF 
> infra folk that are contractors I believe are not proposed to be 
> directly paid to contribute to Whimsy. Should they do so, great.
> But in the famous words of Sam Ruby let’s deal with this if there is 
> an actual data point instead of hypotheticals.

I apologize for the double post.
Yes, infra frequently submits patches to upstream projects.
We also maintain our own set of patches for software that we use.
And we write a decent amount of software. gitpubsub, all of the github integration, CMS, etc.

Earlier this year, I was looking at what needed to be prioritized from an allocation of people.
 I spoke about a number of things with Ross and Rich, commented about conversations I had
had earlier in 2014 about Whimsy. The timesaving and workflow benefits to exec officers and
board members was emphasized.
To be perfectly explicit - since mid-January - Dan Norris, a paid infra contractor, has been
focused on Whimsy, the secretary workbench, etc. Some of that time has been understanding
how things work today, defining a plan on making Whimsy better supported, improving monitoring
ability, getting us closer aligned to how we want software to be deployed, and dealing with
feature requests.

And here is where my conflict comes in.

With my VP Infra hat on, assuming there are no objections, my plan is to continue to task
Dan Norris with that work. Whimsy is important to the operation of the foundation; and people
come to infra when it isn't working. As long as those two remain true, Whimsy will remain
something that I allocate folks time to, and in the case of Dan, I plan on allocating the
bulk of his time there.

With my ASF member/Board member hat on, I see this as the Foundation deciding that a project
is important to the Foundation; and despite the fact that 'we don't pay for development' and
that 'we pick runners not winners', we've effectively decided that this TLP is worth expending
money on development for. That does worry me from a precedent standpoint. Is there a difference
in us allocating developer time to a TLP as opposed to a codebase in the private infra svn
There are some; whether they matter or not remains a question.
We don't release internal software. We don't brand it as Apache $foo.

If this path is good for whimsy, it might be good for other projects infra has as well that
are primarily written (now) by infra contractors. Gitpubsub, svngit2jira, etc. but could be
used more widely.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message