Hi Jeremias,
Jeremias Maerki <[EMAIL PROTECTED]> wrote on 11/15/2005 10:52:51 AM:
> Don't take what I wrote too much by the letter. Always add a little
> common sense. See below.
The problem is that when talking about processes it isn't
good to count on 'common sense'. Just to be clear we are
talking about 'theoretical' issues here not something that is
currently an issue.
> On 15.11.2005 15:49:39 thomas.deweese wrote:
> > Jeremias Maerki <[EMAIL PROTECTED]> wrote on 11/15/2005 08:28:11
AM:
> >
> > > In terms of the Apache bylaws the PMC is the only body that can do
> > > project decisions [1].
> >
> > It appears that they are the 'binding body' from the ASF point of
> > view, but as a PMC member I would really like to see an invitation
> > for the collection of other points of view (i.e. a vote on dev/user
> > for a release). In this case I'm sure it will be greeted with
> > enthusiasm, but I'm really hesitant to set precedent based on the
> > 'best case' situation.
>
> I've always intended to CC fop-dev for the release vote, but the vote
> will happen on [EMAIL PROTECTED] Everyone from the project is invited
> to vote and to express their opinion. If one of the non-PMC committers
> has a justified objection, nobody is ever going to ignore that.
Then it should be written in the 'By-laws' of the PMC, otherwise
when things 'go bad' they may be. In the end if things go very wrong
things could potentially be escalated to the Board, and that may be
enough of an escape clause.
> At least, I will see to that.
As long as you are head of the PMC.
> In the end, though, and from a legal POV, it's the PMC's call. That's
> also why I sent out another note that all committers who care about
> the project are invited to join the PMC. It's what the board
> encourages nowadays.
This is good of course.
> > As chair it appears that this is your call, so I'll just provide my
> > 2 cents.
>
> It's not my call, it's the PMC's. It's only my call when I see something
> go extremely wrong like it happened in the Avalon project.
Well some of the talk on legal seemed to indicate that from an
ASF point of view the chair of the PMC (as an officer of Apache)
was the primary controlling party and policy setting entity.
However in normal circumstances I agree the PMC as a whole should
be the one setting policy.
> If we as a PMC want to establish such an additional requirement,
> we can of course do that. Every PMC member is free to propose
> something like that. We'll then discuss it on the [EMAIL PROTECTED]
> list and if necessary vote on it.
I may try and do that (free time permitting, as I said I
don't consider this an issue right now it's more of a 'what if'
concern).
> But as I said, adding some common sense, an objection from a committer
> won't be ignored, so I don't think such an additional rule is strictly
> necessary.
These things are never an problem until they are a problem. ;)
> > > Where did you read this that a vote has to run a full week? AFAIK,
> > > the normal period is 72 hours [3].
> >
> > I think reading 'at least 72 hours' as 'normal period' is a little
> > misleading. It is far to common for people to disappear for a week's
> > vacation meaning that with just 72hrs an issue can come up be voted
> > before someone sipping margarita's in the Bahamas even knows what has
> > happened. I know that Batik always used 1 week for important votes
> > for exactly this reason. It can of course be terminated earlier if
> > all binding voters reply before the time is up.
>
> Fair enough. It's certainly a bad sign if somebody would want to rush
> through a vote when someone who will certainly object to the matter at
> hand was away. On the other side, you have to keep the project alive and
> always having to wait on the last person holds things up unnecessarily.
Actually for a release holding a week long vote seems entirely
appropriate to me, and I would challenge the notion that 'holding up'
a release 4-5 extra days for a proper vote has an impact on anything.
How long has it been since FOP was last released? does 4-5 days really
matter?
> That's why it's good if committers drop a short note to the list when
> they are away for a longer period.
Sure, but even if they do it's doesn't protect them from the 72hr rule
if someone chooses to exploit it (yes this would be a bad sign).
> > I think a clear distinction should be made between the minimum
> > required by the ASF and what we think is reasonable.
>
> Of course. My current focus is to go towards the rules the board wants
> to see followed, foremost of all: better oversight.
Right but what the board wants I think has to be viewed as a minimum.
> > Especially because in my mind the constituent projects under the
> > XML-Graphics PMC are probably more independent than many.
>
> Please explain. I'm a little worried about that comment.
Don't read too much into it. I'm just saying that it seems
that most of the multi-project PMC's have projects that 'grew
up' together and have overlapping committer bases as a result
often similar architecture, and target audience(s).
Most of that is not true in the XML-Graphics PMC. The
stuff that is going to be factored out into xml-graphics-commons
is essentially the only stuff that fit's this model.
FOP's design is very different from Batik's (Sax/DOM).
FOP's main audience is an 'offline/nearline' audience, a group
that is important to Batik as well, but Batik also has a large
and growing 'interactive' community.
Neither FOP nor Batik is really heavily dependent on the other,
FOP may be a bit more on Batik than the other way round but really
in both cases the linkages are fairly light if it came down to it
the links could be broken if needed (not that I'm suggesting that
should). Each would lose some functionality but neither would be
severely crippled.
The issue is that with essentially two independent camps
under one tent, if a significant difference of opinion develops
there is little common ground to stand on so you are likely to
end up with a really ugly scene. If there are strong rules about
how the PMC is organized it can help to keep differences of
opinion in check and make it clear what is in/out of bounds.
> > To be honest it makes me
> > quite uncomfortable that at least in theory Batik could be 'forced'
> > to have a release by FOP (even in spite of strong objections from the
> > Batik community). Now I don't consider this a serious concern right
now
> > but the fact that the possibility exists is IMHO bad.
>
> Seriously, Thomas, such a thing will never happen.
With the current set of people in the current circumstances I think
it is highly unlikely, but both of those can change (often astoundingly
quickly). I don't want to dwell on this too much, but I would suggest
that an additional rule like: a '-1' (with justification) from a PMC
member who is an active committer on the project being released _is_
a veto, a '-1' from PMC members who are not committers to the release
project should be weighed heavily but is not a veto.
> You know that the PMC
> members theoretically have write access to the Batik codebase but no
> non-Batik PMC member is ever going to touch the Batik codebase without
> invitation.
So what happens if they do? People do the darnedest things,
they may think they are just 'helping'.
What if one project refuses to incorporate patches needed for the
other? How long will the PMC allow the one project to inhibit the other?
What happens if the one project starts bundling a patched version of the
other?
At some point it becomes the PMC's responsibility to sort it out,
that is why the PMC members have commit privileges, isn't it?
These are 'dooms day' scenarios but these are the cases where the
rules are actually important, as long as we all agree we don't really
need rules.
> It's a matter of respect. If this would be a real problem we
> would need to split up XML Graphics into two projects.
I think you mean two PMC's, but in reality what is more likely is
that one group would take over the code base at Apache and it would
fork.
> I hope that clears things up a bit.
I don't think we ever had a real difference of opinion other
than the level of trust in unknown future people/circumstances ;)
I would like to have a rule to point to when one of these 'common
sense' issues comes up (at least then the rule needs to be changed),
before common sense is violated.
