incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: Neutral / shared security list ...
Date Tue, 25 Oct 2011 00:55:12 GMT

On Oct 24, 2011, at 5:12 PM, Simon Phipps wrote:

> On 25 Oct 2011, at 01:25, Dave Fisher wrote:
>> Simon,
>> Please don't despair!
> :-)   Thanks, Dave. Encouragement accepted and appreciated.
>> I think that Rob is getting ahead of the situation. We need to reach a simple agreement
about this single issue before bringing up other obvious places of overlap.  I think we may
really be closer than we think.
> I hope so. The private feedback I have heard from some of the TDF committers is they
read the hostility clearly and have proceeded with starting a list as Michael Meeks proposed.
I fear my fence-mending skills may be inadequate at this stage.

It is unfortunate that an individual's positioning is taken for the whole of the ASF and the
AOOo project. "-1" is something that should be avoided.

Supporting MX for is a responsibility of the trademark owner and that is now
the ASF. The real thing is that to continue to use the ML hosting
at the ASF is required.

If the TDF now prefers to  a separate shared security list that is unfortunate. 

>> Not sure how much this is like your original proposal,
> Strong similarities :-)  My original outline was:
> ---
> "*  That be used as the shared meta-community security contact
list for projects deriving their source code from the former Sun-led project.
The list would be used for any valid meta-community security matter including especially announcement
> * That the list should be private to list members (and with the consent of the list,
to their project's private security list), with mutually agreed confidentiality, and populated
only with people known to the majority of the list members as bona-fides security-related
> *  That the list be populated only with the consent of the existing list members (suggested
process: a list member proposes a new list member with a brief explanation why they are a
good-faith and experienced security developer in the meta-community. Code-modification-style
voting takes place. A moderator adds the new member. In the event of mishap, list members
may be removed using the same process). 
> *  Agreeing who the moderators should be by list-member consensus"

This is the common sense approach. Thanks for presenting it.

> ---
>> but maybe the following is acceptable:
>> (1) The continues.
>> (2) The membership of securityteam ML should be open to individuals and forks/"downstreams"
as selected by the ML membership.
>> (3) The securityteam ML moderators are selected from the individual membership of
the securityteam ML.
>> (4) The securityteam ML is nominally under the governance of the ASF - either the
AOOo podling PPMC, the Apache Security Team, or even the Foundation Board. I think the AOOo
podling PPMC should be acceptable, but we can ask the other entities if that is not is not
neutral enough. We may ask the TDF to neutrally host some component and it would make sense
for each entity to trust the neutrality of the other entity (Rob's real point).
>> (5) No iCLAs are required.
>> (6) A set point for membership is determined when at least AOOo, TDF, and any other
OOo fork/"downstreams" who might appear within a reasonably short time period. The deadline
would need to be agreed.
>> (7) The ML will be hosted by the ASF when the MX for is moved to ASF Infrastructure.
> I do think some sort of "mission statement" along the lines I suggested would be helpful.
I think you hit most of the practical points, apart from some nuancing (AOOo and LO really
are peer projects at this stage, you know, we need to strenuously avoid any language implying
one is in some way hierarchically superior to the other!)

I tried to be ambiguous with fork/"downstream". There is a relationship, and whether it originates
as a fork, upstream, downstream, or upside-down relationship the relationship *IS* a *PEER*
relationship. (auf Deutsch, ist klar?)

>>> I suggest you go to their mailing lists and make your proposals. Maybe you can
earn TDF membership with your contributions?
>> This is a reasonable place to go to ask the TDF to host some component OOo by the
>> I'm currently curious if LO uses extensions.s.oo.o and templates.s.oo.o?
> It does at present but there's a replacement in beta-test right now - see

So, this could be a true point of co-operation, there was a thread about this and it did have
some good ideas.

Extensions and especially templates are likely to compatible. Given the licensing issues with
Apache hosting it does make more sense for the TDF to host these. No technical reasons why
the DNS for these couldn't point to servers hosted by the TDF.

But this is all moot if it becomes difficult to take an extra step and assure intercommunication.


> S.

View raw message