Sync Request process questions

Reuben Thomas rrt at
Tue Dec 14 19:34:10 UTC 2010


I recently filed an Ubuntu bug making a sync request:

I got what looks like a cut-and-paste response pointing me to:

It reads:

Please update your bug so it follows the requirements for sync
Please be aware that the Natty would automatically sync the version
from Debian Squeeze if there were no Ubuntu specific changes in the
package. The most important thing is therefore to check whether these
changes are still needed.

I have nothing against cut-and-paste responses per se, they are a
useful way to save developer time in common situations. However, I
have two problems with this one:

1. Unlike many other excellent automatic responses, this one does not
thank me for my bug report. It implies that for anything to be done
for my bug report, I have to go and follow the instructions on the
page pointed to. But why should I? I have reported the bug, I have not
indicated that I am anything other than an ordinary user, why on earth
would you think I have the time or indeed the skills needed to triage
my own bug report against the criteria on this page? As it happens, I
have both the time and the skills, but I still choose not to work on
Ubuntu itself; I choose to spend my effort upstream (for example, I
helped to make some improvements to sudo recently), and downstream (in
this case, reporting this bug). In summary, this automatic response
looks rather ungrateful.

2. I went and had a look at the policy page on sync requests, and as
the response to my bug report indicates, it mentions more than once
that to justify a sync request, it should be proven that
Ubuntu-specific changes are no longer needed in the new Debian version
of the package. But the trouble is, there are situations such as the
present in which they are still needed, and for a good reason: there
are differences in policy between Ubuntu and Debian. So, the changes
will need to be forward-ported. I can see nothing explicit in the page
about this case, though common sense tells me that the Ubuntu-specific
patches would need to be triaged.

The implications from this are unfortunate:

a. We will do nothing unless you prove in detail that the package can
be synced to Debian. This implication could be removed by simply
making the automatic response to a sync request a little more
friendly: "Thank you for your sync request. We'll try to get around to
it, but you can help us immensely by following the procedure on this
page: ..."

b. When there are Ubuntu changes to a Debian package that need to
remain in a new version, we won't bother syncing the new version. This
is clearly false: there are many packages which are updated, even
though Ubuntu-specific changes need to be forward-ported. This
implication can be removed by adding instructions to the sync request
wiki page on what to do in this circumstance.

I hope these suggestions are useful: after getting the initial reply
to my bug report I was cross (because my bug report was apparently not
valued) and hopeless (because it looked as though unless I did lots of
work this package would not be synced), whereas I do not think this is
the true picture. Also, I have had no other contact from any Ubuntu
developer, even though I posted again to the bug report to explain why
I had asked for the package sync, and therefore explain the value of
my report. (There is clearly some value in users reporting why it is a
good idea to sync a certain package, as it shows both reasons and
demand for the newer version, which helps Ubuntu developers to choose
which packages to spend time syncing, when the syncing is not

Overall, so far I feel I have largely wasted my time on this report,
which is dispiriting. I feel moved to join and write to
ubuntu-devel-discuss because this is not the first time I've had such
an experience. I have four main problems with Ubuntu bug reports:

1. They get mechanised. I get cut and paste instructions (not a bad
thing in itself), and if I don't do exactly what they say, nothing
progresses (which is bad, because it reduces the interaction to a
mechanical, programmed one). Often, there is a better way to proceed
than simply to follow a standard process.

2. They get overwhelmed by clueless users. I don't know how to fix
this, sorry. I suspect it is a necessary price of Ubuntu's greater
friendliness to newbies relative to Debian, and of course newbies have
to be encouraged, educated, and turned into the next wave of experts.
I have this problem less with Debian, and indeed, when it is the right
thing to do, I report bugs direct to the Debian BTS.

3. Trying to answer the question "Do I report a bug to Ubuntu, Debian
or upstream?" itself costs a lot of time (especially when the answer
is that I should report it in two places). I may be missing ways to
streamline the process, but it seems it could still use further work.
Perhaps there is scope for a single guided reporting tool which itself
can report to any of the three places. At the moment I have manually
to choose whether I start with launchpad, reportbug, or some upstream
site where I probably have to register yet another account.

4. A single bug report is addressed by different developers, not all
of whom take the trouble to understand the whole picture. Hence, they
make incorrect decisions (often for example closing a bug when it's
not really fixed). I find this happens much less on Debian where most
packages typically have a single maintainer. I suspect this is a
downside of the MOTU system. The danger here is that I end up
respecting Ubuntu devs rather less than Debian developers, because
they seem (because of their greater breadth) less clueful. Also,
rather a lot of time is probably wasted as a result of poor decisions.
I hope that the greater flexibility of the MOTU system makes up for
it, but I'm not sure. (The converse problem on Debian is overloaded
maintainers who never get around to replying to a bug report, but I
don't think that happens any more often than on Ubuntu.)

Don't think I'm net-negative on Ubuntu: I am profoundly grateful that
it builds on Debian rather than starting from scratch, and I think
it's a brave decision, given the bureaucratic difficulties that
necessarily involves; not to mention the additional difficulties that
come from a far greater focus on the user (which is the why I use
Ubuntu and not Debian). I hope the above remarks have some use.


More information about the Ubuntu-devel-discuss mailing list