Merges - Pinging Previous Uploaders

Jordan Mantha mantha at
Tue Jul 17 21:10:57 BST 2007

On Tue Jul 17, 2007 at 03:25:16PM -0400, Scott Kitterman wrote:
> In addition, I've gotten it down to where the Debian/Ubuntu diff is:
> -  su clamav -p -s /bin/sh -c ". /lib/lsb/init-functions && start_daemon 
> $DAEMON -d --quiet"
> +  su clamav -p -s /bin/sh -c ". /lib/lsb/init-functions && start_daemon 
> $DAEMON $PIDFILE -d --quiet"
> I don't claim any proprietary rights over the package, but I strongly feel 
> that if another MOTU/hopeful is going to do something with it, I've earned 
> the courtesy of a discussion before you do.

Really? If the diff is really that small then it should be trivial for any
MOTU to do. I think it's awesome you're looking after clamav, but I really
don't see why somebody should get in "trouble" for  working on it without
asking your "permission" first. Again, there's no doubt that some packages
require more care and consideration, but I think "pinging" is a bad
practice because it's 2-party communication. To me it is like if a MOTU
Hopeful pm's me on IRC every time they have a question. I don't mind it if
they are new and perhaps a little shy when it comes to #ubuntu-motu, but at
some point it because an issue because I'm not always available and
often times people get more expertise or a broader set of idea if they ask
in #ubuntu-motu.

Scott, I'm a little curious as to why there needs to be discussion before
somebody merges clamav. Do you not trust other MOTUs to do it right? Are
there bigger things that need to be considered? I'm not really sure. I
think that's perhaps a better discussion than "should I poing the last
uploader before merging".
> Honestly, the more I think about it, the more I think the "Don't bother to 
> ping" camp has it exactly backwards about teamwork and team maintenance.  It 
> seems quite odd to me that one would argue in favor of not communicating 
> within the team to improve teamwork.  Maintaining as a team should be about 
> working as a team (which means communicating).

Well, it's true that what you're saying isn't anti-teamwork. For me
personally though, I don't like putting in road blocks or bottlenecks where
they aren't necessary. I'm in *no* way arguing in favor of not
communicating.  I'm simply saying that "Ping the last uploader" is far from
an ideal way to communicate as a team, IMO, because:

1. there is a distinct possibility the "last uploader" is not the one you
want to talk to 
2. it's confusing for new people (email-> IRC mapping is often troublesome
at first) 
3. it promotes ownership and obligation (do I really want to get pinged for
*every* package I merge?) 
4. it slows down the process because it is yet another "approval" to get
5. it's using a person (and one person at that) to store important package

So for the relatively small number of packages that really do need some
discussion before mergeing we are making people check for *every* merge. To
me this sort of polling is wasteful. If there is stuff that's going on with
a package that is that important, it should be available to the team. Use
bugs, wiki pages, emails to ubuntu-motu, a file in debian/ , but the info
should be open to everyone.  That's what I mean by team communication. Not
"you have to communicate with this person or that person", but rather "this
info is available to everyone". Communication that is 1:1 is going to be
not as efficient with at team this size.

This sort of stuff used to be basically team knowledge. People generally
knew what each others speciality was and if you were unsure of a merge
you'd ask them. I have no problem with people asking before they upload, in
fact I think there should be a lot more of that. This is one of the reasons
why MOTUship is not based soley on technical ability. You should know the
team (which implies knowing roughly who the "go to" people are)  and know
how to work as a team (know when to ask, when you need help, etc.) before
becoming a MOTU. This is also a reason why sponsorship is important as


More information about the Ubuntu-motu mailing list