Re: Policy for Debian Qt/KDE Maintainers Group
> Infact, points 2.4, 2.5, 2.6 and 2.7 were included not only for but
> especially for you -- you complained about "feeling unhappy with
> justifying all changes you do to others".
Sure. I like points 2.4 - 2.7. I'm simply asking how it's better than the
current system (which is working fine for me, though of course this
doesn't mean it's working fine for everybody).
> However, point 2.8 explicitly advances team work and all
> members of the team are encouraged to make use of it. The point here is to
> _allow_ others to commit changes but to _disallow_ them if one feels unhappy
> with it.
It's worth noting that, with the exception of who administers CVS
accounts, this entire policy is easily implemented with the current
system (and to some extent simply describes current behaviour).
> > I think the biggest inconvenience I forsee is with the BTS - I'd have to
> > start keeping track of multiple maintainer email addresses, and it will
> > be more difficult to track the bugs in the packages that I'm looking
> > after amongst the significant noise of kdelibs, kdebase, qt, etc.
> >
> There is no real inconvenience. Since I guess you know the names of the
> packages you maintain, you can still easily find the bugs which belong
> to your packages by searching for the package name instead of the name
> of the maintainer.
Sure. Assuming I maintain six core KDE modules, this means that to find
all my bugs I have to make seven BTS queries (my email + six KDE modules)
instead of just one (my email). In particular, this means I would no
longer have one easy-to-manage TODO list but seven - another inconvenience.
Since almost all of the bugs reported against KDE are upstream (not
packaging bugs), I assume that the reason you want joint maintainership
is not actually for packaging help but for shared responsibility for bugs -
i.e., "my group is maintaining this package so I'd better help with
bugfixing". Is this true?
I'm not saying you've written a bad policy for joint maintainership.
It's simply the fact that for me personally, joint maintainership would
(I expect) be more of a hassle than a help. Note that other hassles
include having to check out debian/ separately from the sources and
perhaps even with a different version control system. The modules I
look after are not historically troublesome, and moving to joint
maintainership won't make me suddenly start fixing bugs in libs and base
because quite honestly I don't have the time.
Anyway, there's my thoughts on the matter.
Ben. :)
Reply to: