incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Category-B tarballs in SVN (was Re: External libraries)
Date Fri, 13 Jan 2012 12:31:42 GMT
On Fri, Jan 13, 2012 at 6:16 AM, Ross Gardler
<> wrote:
> On 13 January 2012 01:31, Rob Weir <> wrote:
>> On Thu, Jan 12, 2012 at 8:03 PM, Ross Gardler
>> <> wrote:
>>> It was said in reply to the VP Legal
>>> affairs saying "That [holding MPL code in SVN] normally is highly
>>> discouraged / not allowed."
>> You are putting words in Sam's mouth.    The topic there was about
>> forking MPL components, i.e., having an Apache project act as a
>> maintainer of a fork of MPL and doing MPL development.
> If I am putting words in Sams mouth then I apologise. However, the
> goal posts appear to be moving here. I thought I was safe quoting from
> that thread since you referred to it yourself, indicating that it gave
> approval for what you want to do. It can't be relevant in your defence
> and not in mine.
> Are we talking at cross-purposes?

I'm trying to develop understanding.  To me it appears (and this is my
personal opinion only) that you are cobbling together quotes out of
context to support an undocumented position.  So yes, we are talking
at cross-purposes.

It might be worth going back to the IPMC discussion from December on
"concerns about high overhead in Apache incubator releases".  There
were a lot of good comments, along the lines of:

"there aren't that many rules so before assuming something really is a
rule try to find where its document that it is, and if no one can find
that doc then
its not a rule. Also, rules are only defined on policy pages so just
because some "guide" type page says something doesn't make it true."


"Not everything was written in docs, and still not.
Not everything needs to be, as lots is common sense.
The email archives are "documents".

Once one understands the principles of why the ASF as a foundation
needs to do certain things, then the so-called rules are obvious


"Enumerate these principles and demonstrate the logical entailment of
source releases."

That is why it would be particularly useful if you could articulate
some reasoning behind your statements, rather than just say something
not-very-useful like "I am the policy book" and claiming some
unwritten policy without even defining what that unwritten policy is.
If you explain the reasoning, then this and other things should amount
to "common sense".

> ...
>> You might check out this thread for another angle on the subject, also
>> from Sam, dealing with dev tools:
> It's interesting that you should refer to that thread. Notice that it
> is me who started that thread. I spent my personal time on the
> legal-discuss thread because my position [1] as a mentor was not
> accepted as being correct by the community. Funny how I find myself in
> exactly the same position again and again.


> I'm really not sure why Rob thinks this thread supports the position
> that no policy of "no copyleft in our servers". I'm sure I must be
> missing something. I therefore looked back at Pedro's original
> objection and realise that he his objecting to both a release and
> graduation. Perhaps this is the point of confusion.

You are getting lost in the weeds.  The point about that thread, or at
least what I hoped would catch your eye, was Sam's statement, which he
says in several other threads, so I'd consider it to be something
worth understanding as a general rule, is that technical workarounds
to ASF policy are not acceptable.  Specifically, if something is out
of policy for a release, then moving it to another host does not solve
the problem.  You need to distinguish what the essential problem is,
and for that it is unavoidable (IMHO) to go back to the basic
questions of what is in a release and what obligations and
restrictions does that put on Apache and consumers of our releases.

So Pedro's proposal to simply move MPL code to Google Code or whatever
solve nothing.  And any interpretation of ASF policy that thinks that
something real is solved by shuffling code around with not a a single
bit's different to the actual releases, is ministerial at best.

> My support is for Pedro is limited to the graduation point. AOO can do
> a release from the incubator in this way, but in order to graduate it
> needs to either get approval for hosting of copyleft code or it needs
> to remove it.

In other words, you agree with me, that this is not a problem for our
release.  I realize there are additional graduation requirements.
There were shorter ways of saying this.

>>> As we've said many times before the ASF is not a place where every
>>> rule is written down. This has its advantages and its disadvantages.
>>> The nearest I can provide is the one you linked to in your mail in the
>>> above discussed thread. It can be found at
>> I understand that.  That's why I asked if you could not point to a
>> policy, whether you could make a cogent argument for why something
>> like this would be problematic.
> If you understand that not everything is written down then you should
> also understand that as a mentor I *am* the policy book. I'm certainly
> an imperfect one, that's why there are other mentors and why we refer
> to others where necessary.

The problem, of course, is that everything that is *not* ASF policy is
also not written down.

> I grow tired of arguing about policy, every other ASF podling I work
> with spends time understanding why policy exists and then finds ways
> to either work within it or ask for changes. Why is that not the case
> here?

I'd love to understand 1) What the policy actually is here, and 2) Why
it exists.  That is why I've asked several times if you could explain
it, even if you could not point to it,

> ...
>> Fine.  And if Pedro or anyone else wants to go hunting for this policy
>> that may or may not exist,
> The policy *does* exist. It is being expressed here by a mentor. It is
> also expressed in the very threads you link to. If the policy needs to
> change then make the case to those able to make those changes (the
> larger ASF Legal board committee).

So what is the policy?

> Pedro does not need to put effort into supporting his objection to
> graduation without approval because I support his position based on
> the evidence before me at this time. It is the PPMCs collective
> responsibility to work to remove that objection. Each individual in
> the PPMC therefore has a choice:
> a) work within the policy
> b) get approval for exceptions to the policy
> c) ignore it and hope someone else resolves the problem before graduation
> d) demonstrate to the community that the objection is not valid
> I think Rob is working towards d), but either I am fundamentally
> misunderstanding something or I am unconvinced. Since the last bit of
> evidence is a thread I started in order to clarify the situation the
> last time this arose I have nothing more to say, and hope that if
> others can see my mistake they will point it out so that I may change
> my opinion.

If you, as a mentor and IPMC member, can articulate the policy and the
reason behind the policy, then who knows, maybe I'd agree that it is
fine.  It seems you now agree that the policy is not an impediment to
podling releases.  In any case, I can't argue for a change if you
won't state what the policy is.

> In the meantime I see different people starting to work with Pedro to
> explore the options around a) and b) (thank you).

Again, we really need to internalize what Sam is saying about
technical workarounds.  And maybe even Robert's emphasis on working
backwards from what is an a release and what that means for users of
our releases.  Trying to turn ASF policy into an exercise in quote
collection, absent any discussion of the context and principles behind
them, leads only to a rigid formalism that helps no one.

> Ross
> [1]

View raw message