New software created for Ubuntu

[David Paleino]

On Monday 03 May 2010 06:13:59, Dmitrijs Ledkovs wrote:
> I'm GSoC student working on Ubuntu usb-creator. It is a general
> software and I don't see any reason why it cannot be Debian
> branded as well e.g. Debian USB Creator.
> 
> [..]
> 
> Although usb-creator is much smaller application than software
> center, does it make sence to push changes to Debian as well?

It would be great, yes.
Reducing the delta, as much as possible, between the two distributions is a 
good thing, IMO.
Mind you, the rest of this message talks about "new software created for 
Ubuntu", not specifically of usb-creator.

> With software and themes developed for Ubuntu we would still want to reveal
>  it in Ubuntu first =) otherwise we are "loosing" our competitive edge over
>  Debian.

I don't think people choose Ubuntu because software appears there first ;-)

> The idea is to keep high quality packaging suitable for both distributions
>  and derivatives. But I have some ubuntu->debian "policy" questions:
> 
> 1) Numbering schemes
> 
>    Ubuntu        Debian
> 1  NNN           NNN-1
> 2  NNN-0ubuntu1  NNN-1
> 3  NNN-1+ubuntu1 NNN-1~debian1
> 3  NNN           NNNdebian1
> 
> Generally during development we want to keep our version number higher then
> debian and avoid having these packages popping up in Merge-o-Matic. Also
>  during development cycle these packages will have frequent uploads and
>  probably considered experimental by debian quality standards. So which
>  version numbering scheme shall we use?

Ideally, you should separate upstream and distribution development. This means 
that, as upstream of usb-creator, you'll release a X.Y version. Then someone 
(you, we, or even together, it doesn't matter who), uploads (being a DD, or 
through a sponsor) X.Y-1 to Debian. This means "the first revision of the 
Debian package". After X.Y-1 lands in testing, we can requestsync it to 
Ubuntu, if there are no other changes. If changes are needed, then 
X.Y-1+ubuntu1 can be uploaded in Ubuntu (means: "the first Ubuntu revision 
based on the first Debian one").

IMO, to give a "+ubuntuN", there should be a good reason, i.e. different 
behaviours which can be done at build-time (dpkg-vendor?) should be 
implemented in one single package.

> 2) watch file pointing to orig.tar.* archive.ubuntu.com to play nice with
>  PTS

This could be done only if you upload the package to Ubuntu first. If you 
separate upstream and Ubuntu roles, then you'd have to keep an orig.tar.* 
somewhere else.
Otherwise, we could end up with this situation:

Ubuntu        Debian
X.Y-1         X.Y-1~debian1
X.Y-0ubuntu1  X.Y-1

(the second will then probably appear as a possible merge). However, this is a 
decision that you, as Ubuntu, should follow. I can't say much here :)

> 3) "upstream" bugtracker being launchpad project and/or ubuntu package on
> launchpad

Many packages in Debian have their upstream bugtracker as LP -- one coming to 
my mind is wicd. And it's not Ubuntu-specific (nor affiliated with it, in any 
way), I'd say ;-)

> 4) translations export
> 
> These type of projects are generally translated by Ubuntu Translation Group
>  and uploaded into the archive independently of the tarballs via langpacks.
>  I don't believe launchpad can drop ubuntu translations onto upstream
>  project branches yet. So when creating a release for debian a tarball
>  needs to be cut with translation export from Rosetta or translations
>  should be packaged as a separate tarball component for debian with
>  dpkg-vendor magic.

dpkg-vendor, or dpkg v3 source format, which allows multiple tarballs to be 
merged at build-time. However, I haven't used it yet, and Raphael might give 
more info on this topic.

> 5) Branding
> 
> Images, icons, desktop files, documentations and references to distro name.
> 
> All images either replaced at build time or use XDG icon/theme spec and
> substitute vendor name in desktop files/documentation/ui at build time?
> 
> Or keep it neutral? Cause with these packages Ubuntu building strong brand
> identity and we would want to keep it like that.

I recently saw a thread on debian-devel (or maybe IRC discussion, who knows), 
on giving Debian a "proper look" as well. Since nothing's decided (and maybe 
never will), let's assume two brandings: "ubuntu" and "neutral".
For packages where Ubuntu is upstream, an idea could be to keep a directory 
hierarchy with both brandings inside the source, let's say:

data
|- ubuntu
|- |- icons
|- \- ...
|- neutral
|- |- icons
\- \- ...

Then, at build-time, through debian/rules + dpkg-vendor we could decide which 
bits to install where. This would ensure no useless delta is generated between 
the two source-packages (while the binary packages obviously have different 
content)

> Also what about debian users who want Ubuntu branding and vice versa?
> dpkg-reconfigure magic? We also have Kubuntu, Xubuntu, Studio etc.... Do
>  they need branded Software Centers or Usb Creators?

This depends if dpkg-vendor can "detect" the various Ubuntu versions (I 
suppose it depends on the files it finds in /etc/dpkg/origins/). If it does, 
then it's up to you, as upstream, and Kubuntu, Xubuntu, [..] people.

As upstream, you might want to provide a "general" Ubuntu branding, which 
should be used on all Ubuntu derivatives.
On the other hand, you could just add more brandings under data/ (see example 
above), and expand debian/rules accordingly.
This could also be done programmatically, i.e. without the need to add each 
derivative in debian/rules -- for example you could call the directories under 
data/ the same as the output of dpkg-vendor, and fallback to "neutral" if you 
can't find an appropriate one.

Kubuntu, Xubuntu, [..] maintainers should then add something to 
/etc/dpkg/origins/.

If dpkg-vendor doesn't allow this (I don't really know, haven't used it yet), 
I believe this is a point of improvement.

> 6) Maintainance
> 
> Keep bzr-buildpackage branches on launchpad with a debian branch to merge
>  fixes such that we can build both ubuntu & debian branded packages
>  painlessly and merge changes easily.
>
> 7) Release schedule
> 
> On ubuntu 0-day upload to debian 15-day delay queue?

I can't understand both these points -- can you please expand them a bit?

Thank you,
David


[0] http://alioth.debian.org

-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20100503/953f4713/attachment-0001.pgp