[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#436093: Please decide on the "ownership" of the developers reference



* Ian Jackson (ian@davenant.greenend.org.uk) [070805 18:27]:
> It seems clear to me that Andreas wants to be the primary maintainer
> and to reserve the authority to make changes, grant commit access,
> etc.  Andreas: do you have any assistants/colleagues/etc. who would be
> willing to help you with that so that you don't become a bottleneck ?

What I consider important is that someone goes through all open issues,
and checks them (which doesn't always result in comments) - I think that
any package just needs this kind of clean up being performed. And as I'm
doing the cleanup since more than 2.5 years, I want to have a big enough
influence on what I need to clean up.

Currently, I have good work relationship to Wolfgang Borchert for the
docbook-transition, and to two translators (even though only French is
enabled currently). There are a few regular bug reporters (like Frank)
who I think I trust enough for committing by themself, but this topic
hasn't be raised.

In case it becomes obvious I am the bottleneck for this package (which
of course includes trying to get me working on "obvious applicable"
stuff before) I'm always happy to hand over lead maintainership (which
inludes in my opinion the obligation to either go through the open
issues, or make sure someone else does it) to someone else - in case
Marc Brockschmidt and Martin Zobel-Helas agree that I need to transfer
it, I will do so even if I disagree (which is just the default for any
of my Debian work - I trust both of them enough that they can together
make decisions for me if necessary). (But BTW, in case I would notice
someone is regularly feeding good patches to me, I think I would rather
make sure that person could actually commit, and would even trying to
get DSA to make the necessary group changes, and happily hand over lead
maintainership.)



> I'd also like each of you to answer: if the TC rules in your favour,
> how do you plan to deal with your opponent in this dispute ?

Basically, I don't see Raphael as opponent, but as having a different
opinion on how the commits should be done. And I think it is important
to have a decision because it avoids further grumblings, and we can work
out how we can continue working on it - we need a common starting point.
(In other words, if I could vote, I would vote "further discussion"
lowest.)

In case the TC decides I'm still the lead maintainer, I would like to
try to find out if there is a procedure that still satisfies my quality
requirements, and will allow Raphael to contribute in a way he likes.
Somehow, I am currently quite annoyed (which is perhaps not best but
natural), but I'm optimistic we can still work out something which is ok.
(That's basically not different from any other package or area I'm
responsible for.)

Unfortunatly, that can't be done now, because as long as Raphael insists
in having the exactly same say as I have, we won't find such a procedure
(because the procedure needs to violate that wish).


> Another possible way for the TC to decide on this kind of question is
> to ask the developers to each prepare a package and then for the TC to
> choose between them.  Do you think that would be appropriate in this
> case ?  Would it be a fair fight ?  How long would you need ?

I don't think it is appropriate for a couple of reasons (besides it
being a waste of time), because:
1. at the moment something is commited to CVS, the changes are already
active on the website;
2. this is not a classical package - basically, it is only a large
xml-file that is really relevant;
3. the next important aspects are to make the docbook transition active
on the webpage, which includes writing some scripts for the website
build.


Actually, I think I wouldn't take part in that, but rather go away from
maintaining the developers reference, and let other people do the time
consuming and unpopular tasks - it is not that I have too less to do
inside and outside Debian.



Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/



Reply to: