application: main upload rights for xserver-xorg-video-geode

Martin-Éric Racine q-funk at
Wed Sep 9 16:04:34 BST 2009

On Wed, Sep 9, 2009 at 11:45 AM, Daniel
Holbach<daniel.holbach at> wrote:
> Am Dienstag, den 25.08.2009, 12:41 +0300 schrieb Martin-Éric Racine:
>> I'll be showing up at the August 27th MOTU Council meeting to apply
>> for the following:
>> upload rights to main (xserver-xorg-video-geode)
>> upload rights to universe (cups-pdf, upgrade-system)
>> My wiki page is at:
> You mentioned your dislike for some of Ubuntu's bureaucracy before. I
> just had a look at a few of your bug reports... some of them a bit
> older:
>      * Syncs that weren't checked:
>              *
>              *

I do my best to check these, but I sometimes might miss a few. Sorry.

>      * No sponsor subscription:
>              *
>              *
>              *
>              *
>              *

For this, I trust 'requestsync' to subscribe the right sponsoring team
for each package. Apparently, this didn't always work. Nowadays,
though, 'requestsync' offers much more intelligent management of these
sponsor subscriptions, which simplifies my life a lot. :)

>      * Pointless sync:
>              *
>              *
>              *

A matter of opinion.

>      * Freeze problems:
>              *
>              *
>              *
>              *
>              *

I suppose that from the perspective of a casual contributor focusing
on a few specific packages, release calendars (debian sync freeze,
feature freeze, alpha and beta releases, etc.) are not always
self-evident, especially for someone coming from Debian, where there's
fewer freeze phases. Anyhow, this has improved a lot, now that I added
the release iCal to my evolution subscription.

>      * Build not tested:
>              *

Actually, it was tested. However, it appears that what builds on
Debian doesn't necessarily build on Ubuntu as well, even using similar
dependency versions. Lesson learned, since then.

> Don't get me wrong: I'm not blaming your for making mistakes, we all do
> and if you have a look in Launchpad, you'll see that I did quite a few
> myself. Also am I not blaming you for preferring to "just" sync your
> changes from Debian.

Right, that is a conscious strategy that I've always kept to avoid
forks and preferably merge changes directly into Debian, because it
avoids a lot of pointless work in manually overwriting Ubuntu diffs
with updated Debian packages later on.

> What I do wonder is how well you feel yourself connected to the Ubuntu
> Development team and how well you think you're up to date on processes,
> freezes and everything we assume that Ubuntu Developers should know.

Probably a lot better nowadays than previously.

I think one specific aspect that remains unclear to me is the
distinction between what should go into an SRU, versus what should
preferably go into a backport. Right now, the impression I get is that
backports should be avoided, if only because the backport team has a
very nasty stance that one should "at least *try* getting your fix
approved as an SRU first and only come to us if it was denied, or else
we're gonna ignore you and kill baby kittens." That feels vague and
pointlessly rude. It also projects a rather sad idea of Ubuntu's
willingness to backport anything. I wonder why.

> Also I'm interested to hear what you think should be easier and what
> your suggestions for change are.

Getting back to your earlier question about what I meant by confusing
and outdated wiki content:

I remember a couple of years ago that I spent literally *days* trying
to make sense of the LTSP documentation on the Ubuntu wiki, without
coming to a definitive answer about what content was relevant or not.
In the end, after asking Oliver Grawert, it turned out that most of
the LTSP content was in fact deprecated and concerning specific older
Ubuntu releases, and yet very few of those pages had a warning that
the content is no longer current.

Likewise, looking for info about how to become an Ubuntu developer, I
found several pages that start by saying that the instructions are
elsewhere and yet still go ahead and try to explain what *was* the
process, before templates and other more formal approaches were

I think that what I mean is that a lot of wiki content needs to be
periodically janitored and mothballed in a systematic way.

However, most of the time, only people who are directly involved in
the process or project concerned by a given wiki page know what and
where the most up-to-date information is, which is why I seldom dare
mark any content as obsolete by myself.

In a similar way, I'm pretty much the only person in Ubuntu who knows
100% what is the current status of xf86-video-geode in all releases
since Hardy, which bugs have been fixed in which upstream version,
which changes fix what bug, what commit could potentially be
cherry-picked for an SRU, etc. As such, I pretty much systematically
document these issues in LP bugs, upstream README and Debian
ChangeLogs, such as in and
essentially try to maintain a tidy ship and leave as little lint
behind me as possible.

As it so happen, this is one approach that works well in Debian which
Ubuntu could adopt: *personally* keeping track of bugs affecting older
releases and of how newer releases might include backportable or
SRU'able fixes, then going ahead and releasing them. At Ubuntu, people
easily jump in to fix bugs that concern ubuntu+1, but they quickly
move along to contribute a fix to another package and seldom bother
checking whether a given fix might apply to the current biyearly
release or to the current LTS release.

Personally, I do this in a systematic way for xf86-video-geode,
because it affects hardware support in Ubuntu in a significant way.


More information about the Motu-council mailing list