You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Neil Graham <ne...@ca.ibm.com> on 2003/11/18 21:28:02 UTC
[VOTE]: next Xerces-J release (2.6.0) tomorrow
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: neilg@ca.ibm.com
----- Forwarded by Neil Graham/Toronto/IBM on 11/18/2003 03:20 PM -----
Berin Lautenbach
<berin@ozemail.co To: general@xml.apache.org
m.au> cc: XML PMC <pm...@xml.apache.org>
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 general@xml 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: general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: next Xerces-J release (2.6.0) tomorrow
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Wed, 19 Nov 2003, Venu wrote:
> here is my +1.
Hey - you guys worked the procedure out - a release backed by three
explicit +1's by your peers.
But yes - to confirm - this is the sort of explicitness we where looking
for.
Dw
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: next Xerces-J release (2.6.0) tomorrow
Posted by Venu <K....@Sun.COM>.
here is my +1.
-venu
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: neilg@ca.ibm.com
>
>
> ----- Forwarded by Neil Graham/Toronto/IBM on 11/18/2003 03:20 PM -----
>
> Berin Lautenbach
> <berin@ozemail.co To: general@xml.apache.org
> m.au> cc: XML PMC <pm...@xml.apache.org>
> 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 general@xml 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: general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: next Xerces-J release (2.6.0) tomorrow
Posted by Neeraj Bajaj <Ne...@Sun.COM>.
+1.
Regards,
Neeraj
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: neilg@ca.ibm.com
>
>
> ----- Forwarded by Neil Graham/Toronto/IBM on 11/18/2003 03:20 PM -----
>
> Berin Lautenbach
> <berin@ozemail.co To: general@xml.apache.org
> m.au> cc: XML PMC <pm...@xml.apache.org>
> 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 general@xml 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: general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
--
-- Neeraj
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: next Xerces-J release (2.6.0) tomorrow
Posted by Andy Clark <an...@apache.org>.
Neil Graham wrote:
> So here's my +1 for Xerces-J 2.6.0 to be released tomorrow (or Thursday, if
> a delay is needed).
Since Elena's proposed initialization change was
done in a non-breaking way, I give my full support
for the new release. :)
+1
--
Andy Clark * andyc@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: next Xerces-J release (2.6.0) tomorrow
Posted by Michael Glavassevich <mr...@apache.org>.
Here's my +1.
On Tue, 18 Nov 2003, 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: neilg@ca.ibm.com
---------------------------
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org