xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <dev.jerem...@greenmail.ch>
Subject Re: XML Graphics PMC discussion - Wiki page created
Date Thu, 19 Feb 2004 16:05:07 GMT

On 17.02.2004 17:01:00 Thomas DeWeese wrote:
> Glen Mazza wrote:
> > Excellent write-up.  However, I haven't seen much support from the Batik
> > project yet in having an XML Graphics PMC, so we appear to need more buy-in
> > from them.  
> Hi all,
>     Vincent and I talked, and we both agreed that this is probably the
> right course of action.  The biggest reason we have been quiet on this
> issue is lack of resources.  I don't know what the formal requirements
> for a PMC are but it is pretty clear that Batik couldn't really have a
> PMC that differed significantly from the committer base.

But that's what is actually expected/preferred by the board as far as I
understand the discussions in the incubator and in other places. The
recent TLPs mostly have PMCs that go in this direction (committers=PMC).
In some way a XML Graphics PMC is not really going into this direction,
it's just a scaled-down XML project. While this addresses oversight
issue, it doesn't really emphasize the project=committers=PMC idea.

>     It would also be good to have some level of formal interaction
> between FOP/Batik (although we seem to have done fairly well thus
> far).

What do you have in mind?

I don't think we need a lot of formal stuff. This should establish
itself as we'll be much closer together. Things that are relevant to
both projects will simply be discussed on the common mailing list or on
the PMC list if it's a "special" matter. Of course, we will have to
define a charter which will define a few things but I don't think it
makes sense to start with that before we have some feedback on the
federation proposal.

> > As an alternative, it appears that much of what we're trying to accomplish
> > here can also be had by making Thomas DeWeese a committer on the FOP
> > project.  This would be an incredible gain for us (transcoder, SVG support
> > in FOP, etc), without needing to disrupt Batik, or needing to put too much
> > of FOP into shared components in order to obtain his help.  
>     I appreciate the sentiment but I doubt you would get much more out
> of me then you already do :)
> > Note that this
> > is not a long-term solution, though, esp. if multiple Batik committers would
> > also need to turn into FOP committers--something I'm leery on.  But it
> > appears an option to have us do this first for a few months or so, and then
> > decide on merging, shared components, etc., later.
>      While the proposal talks about the shared components I think that
> the common PMC just gives us a better framework for eventually
> creating them it does not need to happen immediately.  Also another
> side advantage of creating these components is that I think it would
> greatly promote participation on them.  When they are a small part of
> a huge project people don't want to invest the effort to figure out
> how to change things without breaking anything.  When/if they are
> standalone people can grasp the important bits easier.

My thoughts exactly.

>      I think the biggest difference in the short term will be that
> before releases, etc we will now need a vote from the graphics PMC -
> which will give FOP/Batik developers more 'heads up'.


>      As for the 'potentially problematic points', first it isn't
> clear that all committers on FOP/Batik would want/need to be
> committers on the shared projects (as long as at least one committer
> from each was).  This would actually be my preferred way to handle 
> them, essentially independent projects under the graphics umbrella. 
> Second the new guys seem to know when they shouldn't touch something,
> which makes them fine by me :)

+1 to all this. And as Bertrand said yesterday at lots.ch we can always
revert if something goes really wrong since we have CVS history.

Jeremias Maerki

To unsubscribe, e-mail: general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

View raw message