> From: Shane Curcuru <[EMAIL PROTECTED]>
> I agree the main discussion should happen on general@, however everyone has
> to forgive me for unpolished style writing in the airport.
>
> My feeling is xml should do two things, which hopefully both will make
> sense, and will address the issue:
>
> -- Split the ASF organizational structure up into 3ish PMC's to cover all
> the existing XML projects.
> This should give the required level of oversight without overwhelming the
> board.
Maybe.... Sooner or later (and it looks like it's
going to be sooner the way the ASF is adding
projects :>), the board is going to hit the top
limit of projects it can oversite adequately. If
we can come up with a way of splitting our
internal oversite up, but still have one report to
the board for all of xml.apache.org, then I think
there is a win for everyone.
So the feeling I got from Dirk's e-mail is that
the board does not want to see us fragment into
multiple TLPs that the board has to manage, as
then we simply push the problem to them.
However I think the split into three is probably
about right, it's just a matter of how do we
coordinate (do we coordinate?) those three groups.
Two options that spring to mind (derived from
Dirk's original e-mail) -
1. Three groups are there as oversite of the
code and release processes defined by the current
PMC. They simply document (in e-mail lists) the
OK that occurs before code releases etc. in line
with defined requirements. The current PMC
remains, made up of members of the three groups,
and is the group that actually defines the
requirements that the Code Review Groups (CRG -
feel free to re-name :>) follow, etc.
So basically the PMC would do almost what it does
today, but would devolve responsibility for
immediate code oversite to the CRGs who would then
*maybe* have a regular report back. (Possibly
as input to the broader report to the board
that we already do.)
In the event of issues the CRG would escalate to
the PMC that would then handle or escalate to the
board. I.e. if there is a license problem or
whatever, then it's still the responsibility of
the PMC to address. The CRG is purely there to
make sure our code is hygienic :>.
I kind of like this, as I suspect that we can set
these groups up and have minimal change within
the sub-projects (other than those necessary to
adapt to whatever the agreed processes are) and
yet still meet the requirement of the board.
2. Push much more into the CRGs (they would be
called something else, but I can't think of a
name at the moment). xml.apache.org oversite
would be a very small number of people that simply
co-ordinate the three groups at a very high level,
and the three groups pretty much set their own
standards etc. Problem here is that it becomes
much harder to show to the board that we are all
doing the right things, and xml.apache.org risks
starting to splinter into three different sets of
processes etc.
If we are going to go down this path, I think we
would be better off simply recommending that we
think it should be three TLPs and then move on.
> Also, I'm feeling that we can find 3 useful groups to split into;
> perhaps along functional lines like below (unless someone can point out
> some obvious community lines that would fit better?)
This is the bit that's been keeping me thinking.
> The Xerces', Xalans, and xml-commons are the base of the XML stack.
> Batik and graphics types in another project.
> DB-related projects in another spot.
> Where does forrest fit? This is an important one, because we use it for
> the website, and is an important 'showpiece' of much of our technology
> (yes, there's a reason we go through so much seeming rigamarole to build
> our website: eating our own really cool dogfood).
>
Another method of doing the split (probably not
as good :>) -
The Xalan/Xerces thing seems like an obvious
gathering to me.
I was then thinking maybe we could look at
grouping the "library" projects together. So
for example, xml-commons and xml-security both
provide library functions that are used by other
apps.
Finally have those that are pure applications in
the final group. Axkit/Forrest etc.
Don't know if it's as simple as that though :>.
> Personally, I'd like to keep them all under xml.apache.org since that's
> simplest, but whatever is fine.
>
> -- Clearly document some procedures for subproject management.
> This will both help with some committer confusion we've seen evidenced as
> well as providing for better 'provable' oversight.
> Note that here my feeling is that we should put some proposals on general@,
> wait for feedback, and then the PMC should simply decide the policies and
> codify them.
> Given that the issue of oversight is an organizational one, the PMC is the
> body that should decide the final polices. Yes, I want committer community
> input: but both because oversight is the PMC's job, and because it'll take
> a lot less time if we have a smaller group doing the work. (of course we
> have the question of if it's the current PMC or the new 3 PMC's who set
> this...)
The PMC (in its current form) will need to agree
and vote on the new processes and changes I think.
And I think we would probably want a board OK
before we did the change, so I was thinking around
1. Develop the new structure and formalise the
processes that Neil discussed the other day.
2. Vote within the current PMC that we are
comfortable with the suggested approach. I'd
say at this point we don't develop a new charter,
we just develop a position paper that we have
all agreed on.
3. Present the position to the board (as
requested by them).
4. Implement if the board is comfortable.
(Note that implementation will include the
required changes to the charter.)
My feeling - the more people that input, the
better. We may have to be arbitrary to get
somewhere if it gets out of hand, but lets see
how we go!
Cheers,
Berin
This message was sent through MyMail http://www.mymail.com.au
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
