Maintainer/XSBC-Original-Maintainer in Ubuntu packages

Luca Falavigna dktrkranz at
Fri Jun 12 21:57:39 BST 2009

Il giorno Fri, 12 Jun 2009 13:57:49 +0200
Morten Kjeldgaard <mok at> ha scritto:
> I think the XSBC-Original-Maintainer field doesn't work as intended,
> and that the field Maintainer field is redundant.

XSBC-Original-Maintainer was introduced during Dapper development cycle
after a discussion with Debian developers [1] to achieve these goals:
* changes introduced by Ubuntu developers are under Ubuntu
  developers' responsibility
* users usually contact maintainer if they have troubles, Debian
  maintainrs should not be bothered by Ubuntu changes
* give credit to Debian maintainers for their work on the package

Given that, XSBC-Original-Maintainer is completely useless in case of
local Ubuntu packages because its meaning is torn from what it means.


> Currently, we put the email address of this mailing list in the
> maintainer field. That is redundant, because the Maintainer: field of
> all packages in universe then is identical. It contributes no
> information other than what is already known by the package being in
> Universe. From the release string, it is quite easy to determine that
> this is an Ubuntu-only package, and it's already known that it's from
> Universe.

Not exactly. For each package uploaded, Launchpad UI displays two
fields, "Uploaded by" and "Maintainer", so users have two contacts to
send requests to in case it is needed. We cannot assume users know our
policies, give them references is a win-win choice. "Uploaded by" would
probably be the "real maintainer" of the package, so users could
contact a person interested in package anyway.

> One of our big problems is that people (understandably) love to get
> packages into Ubuntu e.g. via REVU. But often/occasionally/sometimes
> it happens that after getting the package uploaded, the packager
> disappears, leaving the package in an unloved and abandoned state.
> Although we encourage packagers to subscribe to bugs etc. of their
> packages on Launchpad, this is often not done. Perhaps because you
> have to remember to go to Launchpad yourself to subscribe to bugs.
> And, that is only possible quite some time -- often weeks -- after
> the package has been sponsored via REVU.
> I suggest that for -0ubuntu* packages, the maintainer field MUST be
> the Launchpad ID of the packager/contributor.

This will not fix the underlying issue: what if a pacakger leaves
Ubuntu, leaves Launchpad and deletes his/her account? Maintainer is no
longer visible by Launchpad, and users could be frustrating about Ubuntu
distributing old and unmaintained packages into their archives without
a person to contact in case of troubles. This is especially true if the
last uploader is equal to the maintainer.

> That would enable bug subscriptions etc. to be enabled automatically,
> and we would have a much better "handle" on the maintainers/packagers.
> Quite simply, I think it will make it easier to motivate packagers to
> take care of their packages.

Again, this is not the solution of the problem. Bug subscription is not
automatic for package maintainers, it also requires some work by
Launchpad developers, and I think it is not worth for a corner case. We
could enforce people to become bug contact after a package hits NEW (LP
already registers ubuntu/+source/packagename for NEW packages), but we
cannot check if users remove themselves as bug contact in the future.

> Let me underline that for _merged_ packages and Ubuntu _bugfixes_, the
> maintainer mangling policy makes more sense, because we cannot expect
> Debian maintainers to be responsible for what MOTUs and others have
> done to their packages. Here it makes sense to move the Debian
> maintainer to the XSBC-Original-Maintainer: field, and put something
> else in the Maintainer field.

What if we drop XSBC-Original-Maintainer for local Ubuntu packages,
leave only Maintainer field and let timestamp line in debian/changelog
determine who is interested and responsible for a given package?
XSBC-Original-Maintainer is not stored anywhere in LP, so there is no
way for users to access this field without looking at source package.


 . ''`.      Luca Falavigna
 : :'  :  Ubuntu MOTU Developer
 `. `'`     Debian Maintainer
   `-      GPG Key: 0x86BC2A50
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : 

More information about the Ubuntu-motu mailing list