[gst-devel] GStreamer needs a maintainer

[Thomas Vander Stichele]

El mar, 16-12-2003 a las 14:27, Benjamin Otte escribió:
> On Tue, 16 Dec 2003, Ronald Bultje wrote:

> . But now that we're at it: who
> > would you accept as maintainer? And who's willing to maintain this
> > thing?

(snip)
The more important questions Ronald asked were left unanswered.

> It's not his job however to decide if
> - IRC is good enough for decisions

I don't *decide* this.  It is a matter of courtesy on your part to
inform people on the mailing list (ie, people who aren't always on IRC)
what gets decided on IRC.  For more important decisions, it has always
been the tradition (GST didn't start with your arrival :)) to use the
mailing list so everyone has a chance to chime in.  Two important things
that are left unsatisfied by IRC.

Reread that part: I'm not saying you can't decide stuff on IRC.  I'm
saying "don't use only IRC".  Use it as the tool it is created for.

> - we use a ChangeLog or not

You're twisting things around.
a) YOU decided we shouldn't use it.  YOU removed it from CVS, right
after I again made entries in the ChangeLog.
b) YOU force other people NOT to use the ChangeLog.  I never forced YOU
to use the ChangeLog.  If you don't want to use it, that's too bad.  But
why should you force me not to use it ?

Incidentally, the question "Why can't you guys use ChangeLog's like a
real project" is an often heard outsider question.  And I completely
agree.  Why anyone would think the sorry excuse of "check cvs commit
logs" is valid is beyond me :) I can understand though the reason of
being too lazy to update the ChangeLog, which is also fine by me.  It's
just not my style.  I love ChangeLogs for looking up changes.

So again; I didn't just decide this, and I don't force my beliefs on
this on other people.

> - all headers and plugins are put in gst-libs/gst

Again, a matter of common practice we've had long since.  We disagreed
on this one, no one else had an opinion (since it wasn't brought up on
the list), so in those cases I stick to common practice *or* reopen the
discussion.  In this case, I stuck to common practice, IE. "All headers
that aren't core that we install live in gst-libs/gst/..."

If
a) you had made sure the build wasn't broken by it in the FIRST place I
wouldn't have noticed
and
b) you had at least fixed the build, or tried to, in the complete week I
waited for you to come up with a fix,
you would have had your way anyway.  How long did you expect me to wait
before fixing your breaking the build ?

> - we seperate a gstreamer-gnome package

I didn't decide not to nor keep you from it.  You want this done, and I
think it's useless because not much would live in it.
In case you mean to say with this "why didn't Thomas implement my idea
yet to split this up" I guess you can guess why I haven't yet :)
In any case, *if* you really want to do this, then please wait until we
move to fdo (real soon now) so we can keep history.

> - we try to get 0.8 in Gnome 2.6
> - we want a caps rewrite in 0.8
> - we declare and API freeze and when

These I assume are generic points.

In general, as you've noticed, I'd like to stick to established
practices.  Those are mostly my deciding factors.  That doesn't mean
they can't be changed, it just means there has to be reason to do so. 
You being pissed off by someone else committing ChangeLog entries isn't
a reason, for example.


Really, do you want to keep up the petty bickering ? I'm going to do no
more than dispel any arguments you throw at me, but will keep from
mudslinging back.  

If you want to make this a constructive decision, suggest some things to
move us forward.  For example, suggest where we are going to get this
magical do-all end-all maintainer, because I don't see this happen.
I see more value in either a jeff-like person (for example, Uraeus), or
a sharing of responsibilities, where each person does stuff he's good
at.

I realize you're angry at stuff and you've said before you're
unmotivated, but try to suggest some positive stuff so we can help you
do what you like and the project benefits as a result.

Thomas