+1
Thank you,
--
Elena Litani/ IBM Toronto
Neil Graham wrote:
>
>
>
> Hi folks,
>
> As the message below makes clear, the Apache Board is interested in
> ensuring that there is a process in place by which XML sub-projects can
> demonstrate that there is consensus within their communities about
> releases. I think we have consensus in this community that it's about
time
> for a new Xerces-J release, and that tomorrow is a good day for it; but
it
> looks like it would be prudent if we formalized things.
>
> So here's my +1 for Xerces-J 2.6.0 to be released tomorrow (or Thursday,
if
> a delay is needed).
>
> Cheers,
> Neil
> Neil Graham
> XML Parser Development
> IBM Toronto Lab
> Phone: 905-413-3519, T/L 969-3519
> E-mail: [EMAIL PROTECTED]
>
>
> ----- Forwarded by Neil Graham/Toronto/IBM on 11/18/2003 03:20 PM -----
>
> Berin Lautenbach
> <[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
> m.au> cc: XML PMC
<[EMAIL PROTECTED]>
> Subject: Re: XML PMC and
Oversight
> 11/18/2003 05:44
> AM
> Please respond to
> general
>
>
>
>
>
> G'day all,
>
> As some of you may be aware, we asked the board to comment on how
> involved the XML PMC should be in releases being made by the XML
> sub-projects. This was discussed at the board meeting, and Dirk came
> back with the response below (which is being forwarded in line with his
> OK in the 2nd last para).
>
> The basic thrust is that the PMC needs to have more active oversite of
> all code being committed and released within XML.
>
> Dirk has given two suggestions
>
> - grow the PMC and split into sub-groups, with each sub-group having
> responsibility around code and releases of a nominated subset of
> sub-projects; or
>
> - getting the current PMC more involved in releases and code commits of
> the sub-projects. This might involve formal review e-mail lists etc.
>
> There are other options, and it may be that no single option makes sense
> for all sub-projects. For example Xerces(C/J/P) probably has enough
> active committers to grow PMC membership to 4-6, who could provide
> direct oversite and report back to the broader PMC. (Does that make it
> a TLP I wonder :>.)
>
> That approach won't work for xml-commons or xml-security who have fairly
> low numbers of people, so maybe we need to aggregate a few together for
> review purposes. (Note that this would not imply a visible aggregation
> - they would still be separate in terms of names etc.)
>
> Anyway - the above are just musings for the moment. Am *very*
> interested in seeing all suggestions. I am happy to write something up
> as a response to the board, and write up any processes we think are
> necessary, but I think we need a full discussion by all xml@
> committers/contributors here in general@ first.
>
> As a final thought - whatever we do, we need to think about how we
> minimise overhead on all concerned, whilst ensuring we are meeting the
> expectations of the board.
>
> Cheers,
> Berin
>
>
> Dirk-Willem van Gulik wrote:
>
>>PMC,
>>
>>At the last board meeting we discussed your question about oversight. And
>>we agree that we have a puzzle here.
>>
>>What follows is not exactly a black and white answer - but more some
>>thoughs towards a solution. This because we recognize that the XML group
>>(like just about every other group) is special in some respects and does
>>not fit the mold perfectly. So do not take any of the text below as a
>
> sign
>
>>that the XML pmc is doing things fundamentally wrong or badly - it is
>
> just
>
>>that something is ill fitting.
>>
>>Now the key issue is that the board expects the PMC to carry out active
>>oversight with respect to their project(s). This essentially mean that we
>>exect the PMC to catch issues, say a release which is made without
>>sufficient +1's votes or lack of code review and thus be very close to
>
> the
>
>>code literally on a day to day basis.
>>
>>It is our opinion that in actual practice that means that any PMC will
>>either need an extremely vigilant committer in each project, or, more
>>realistically several. The latter has the added advantage that
>>controversial issues are more likely to be reported even if the reporter
>>is party to that issue. And because of this we consider just a single
>>representative on the low side. Having said that - it is of perhaps
>>possible to offset this single person issue by having very regular, and
>>well documented, meetings with very explicit mailing list archive review
>>cycles by the other PMC members.
>>
>>Now for this the number of people on the PMC may grow to be virtually all
>>committers, like in some other parts of the ASF. However this brings the
>>additional risk that if the group is very large the feeling of
>>resonsibility dillute; and that the level of oversight actually reduces
>
> as
>
>>no one feels personally responsible.
>>
>>Now given the size of the XML project - the sheer number of committers
>
> and
>
>>the large number of projecs - the above may simply never be realistic.
>>
>>So one thing we would like to ask the xml pmc to consider (or discuss on
>>the XML general list)
>>
>>-> splitting the xml PMC into three parts as to
>> make the scope more managable.
>>
>>and then
>>
>>-> aim to have 3 to NumberOfCommitters on a PMC
>> for each sub project.
>>
>>This does not mean that the XML project needs to be spliced 'visibly' -
>>and I could imagine a virtual aggregation so that [EMAIL PROTECTED] and
>>xml.apache.org continue to exist.
>>
>>But as said above - that is just one suggestion - other options could
>>revolve around the current PMC but having very regular well documented
>>review sessions. But the key property of any solution is that we, as the
>>board, want to 'see' realistic acitve oversight happening.
>>
>>So what we expect from you folks is think this over - feel free to move
>
> it
>
>>to general@ and/or your committer if you feel that is a more appropriate
>>venue - and ideally create a position by the next board meeting, or the
>>januari board meeting by the latest.
>>
>>And again - do not take any of the above as a vote of no convidence, we
>>are at this point not seriously worried - but we do want to see how we
>
> can
>
>>improve things long term and make things better.
>>
>>Thanks,
>>
>>Dw.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
