Merges - Pinging Previous Uploaders
ubuntu at kitterman.com
Tue Jul 17 21:56:18 BST 2007
On Tuesday 17 July 2007 16:10, Jordan Mantha wrote:
> 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.
Well, less changelog entries, that's the real diff. The MoM output had 3,797
lines to it. It's not that I don't trust people, it's that this one would
have been very hard for ANYONE who didn't know what to expect to get right.
It's not a question of getting in trouble, but of being polite and respecting
my interest and contribution. Also, in this particular case it's a question
of saving yourself a lot of work.
> 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".
I doubt anyone who wasn't already familiar or didn't spend a huge amount of
time studying it would have got the right two lines out of the 3,767 line
For most merges there isn't that much of a rush. If firing off an e-mail
delays a merge by a day or two, I don't see the problem. From my perspective
that's a lot less trouble than adding files in the package or filing bugs in
Launchpad. If there's a real reason for a rush, then by all means go ahead.
> > 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
Sure, but a quick look in debian/changelog should make it clear who, if
anyone, ought to be pinged.
> 2. it's confusing for new people (email-> IRC mapping is often troublesome
> at first)
This is true, but they can ask on IRC. At the very least, they'd probably be
better off to give their debdiff to a MOTU that's looked at the package
> 3. it promotes ownership and obligation (do I really want to get pinged for
> *every* package I merge?)
No, but there's a balance here. I do (my own fault, no one imposed it on me)
feel a sense of obligation to some of the key packages I've fixed/merged.
> 4. it slows down the process because it is yet another "approval" to get
Only trivially. Equally it may yield valuable information that may make the
entire process go more quickly/smoothly.
> 5. it's using a person (and one person at that) to store important package
Sure, but that already happens.
> 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.
Yes, that's a good theory, but in many cases there is no substitue for
> 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
Well that's pretty much how I think it should be. This entire discussion got
kicked off by people saying they can merge whatever they want, whenever they
want without any invovlement in the team.
I think that we are heading down the road of entirely too much bureacracy and
not enough working together. Not strictly the same subject, but today
dholbach and I both uploaded the same package, but different versions. We'll
see which gets published. Part of the problem there is that we are currently
tracking upstream version upgrades both on LP and in REVU. Trying to keep
status in one place is very hard. Two is insane. For the moment, until
sanity returns, I'm not going to waste my Ubuntu time on filling out forms.
I'll leave new upstream versions to others because I'm sure I'd get the
paperwork wrong again.
More information about the Ubuntu-motu