New software created for Ubuntu

Wed Jun 2 00:17:38 BST 2010

On 1 June 2010 19:23, Iain Lane <laney at ubuntu.com> wrote:
> Hello,
>
> On Mon, May 31, 2010 at 04:03:52PM +0100, Matt Zimmerman wrote:
>>
>> On Fri, Apr 30, 2010 at 11:33:09AM +0200, Raphael Hertzog wrote:
>>>
>>> Ubuntu is developing more and more software of its own and often Debian
>>> reintegrates the software but later on. I wonder why you are not
>>> integrating new software immediately in Debian:
>>> - you would benefit from the feedback of the debian community sooner
>>>  and avoid some packaging churn later on [1]
>>> - even when you have constraint of integration with other software in
>>>  debian and that you're blocked, you can have a ubuntu-specific packaging
>>>  thanks to the dpkg-vendor framework and still share the source package
>>>  between both distributions
>>> - you would have some explicit responsibility in maintaining the software
>>>  that you create
>>
>> When discussing this problem, I think it's important to bear in mind the
>> difference between "packaging for Debian" and "maintaining in Debian".
>>  The
>> former is a relatively easy (for Ubuntu software) one-time event.  The
>> latter is an ongoing commitment and investment of time and effort.
>
> It is, but we are talking about Ubuntu (Canonical?) developed software here.
> I presume that the developers are committed to maintianing their packages in
> Ubuntu. Maintenance in Debian is not much effort beyond that; receiving and
> responding to bugs as apporpriate, as well as making sure that the software
> is well integrated into Debian. This shouldn't require much (if any) work
> over getting the package working in Ubuntu.
>

"well integrated into Debian"

My GSoC project is to work on usb-creator. And I've already spend
significant amount of time on debranding the icons, package
descriptions (the UI still mentions Ubuntu a little bit). Then
exporting translations is a bit non-trivial, because in ubuntu we get
those via language-packs and generally when you develop Ubuntu
specific software you don't have to worry about maintaining
translations, you get them independent from your package. After doing
this work I've also had quite a bit of head-scratching to do how to
make build branded packages based on dpkg-vendor fields and make sure
the package doesn't fail when $vendor branding is not available.

After done all of this, the ITP blew up with a bike-shed discussions
about package name & inclusion of debian-menu files. It's ok I'm
almost finished sorting them out. But as it currently stands, so far
I've seen hostility a too much knit-picking. I will continue despite
this experience because I kind of got used to this kind of treatment
in Debian. And when I do merges & syncs from debian and notice QA-like
improvements that good be done to the package, I do create debdiff
against debian or patches against $debian-package-vcs and submit BTS
bug and link it to lp sync/merge bug to keep in a eye on it. Those do
get included in debian eventually, but not in a timely fashion.....

>>
>> It's easy to ask why, if a program is already packaged for Ubuntu, why it
>> shouldn't be in Debian as well.  The reason is that it needs a maintainer
>> in
>> Debian.  We can't simply copy the packages across.  Each package in Debian
>> requires a maintainer who is looking after it, who is actively keeping up
>> with Debian procedures, watching the Debian bug list, and so on.
>>
>
> I would propose that the teams (Desktop, DX, …) form alioth teams to
> maintain their packages as appropriate. We have enough Ubuntu developers
> who are also Debian developers and can sponsor.
>

Speaking how pkg-crosswire-devel team works. We started off with
alioth project, alioth mailing list & BTS with bzr branches. Soon
after we created a team on launchpad and host branches there. And we
have kept only mailing list from alioth (simply cause we are lazy to
switch to launchpad mailing list, too many subscribers already ;-) )

So far launchpad has many features that helped us to work with debian
& upstreams. Linking bugs across distributions, packages and upstream
bug tracking systems has been extremely valuable when upstreams
approches and says please push this commit there in there. Within half
a hour we have packages build in developer-preview ppa, upstream test
those and we push to "testing" ppa to get responses from bug
reporters. And it's just awesome to be able to do $ bzr merge
-rsvn:4096..4098 lp:upstream to get critical patches. We also test
packages for RPM based distros using openSUSE build service.

None of these features are provided by alioth. It would be great if
alioth could at least get integration with BTS and / or to have some
build-daemons available for test builds.

Please point me to at least one packaging team that uses alioth
collaboration features. So far I've seen packaging teams use BTS,
mailinglists and ssh code hosting. And arbitrary people cannot push
branches to alioth without joining the team first.

pkg-crosswire-devel team has 15 upstream developers, 2
debian-developers (act as sponsors) and a handful ubuntu prospective
developers (packagers) and so far we have maintained excellent
communications with Debian & Ubuntu and upstream communities.

I'm sorry but alioth is not a valid platform for
cross-distro/cross-project collaboration unless it's API will open-up
to external services to hook into it.

>> Sometimes, this can be the same person, but usually not.  Regardless, it
>> is
>> a significant additional workload (especially if the person is not a DD
>> already).
>>
>> Thus, I don't think it's reasonable to expect Ubuntu packagers (in
>> general)
>> to also maintain their packages in Debian.  Where individual circumstances
>> permit, this is of course a good thing, but it can't be a prerequisite for
>> doing Ubuntu packaging work.
>
> I don't think I agree. It seems to me like this wouldn't be so much more
> work, but would in the end provide for better software, and better
> Debian-Ubuntu relations (Debian wouldn't so much be Ubuntu without the shiny
> bits).
>

Hmmm.... usb-creator is a tiny app. The ITP has been in debian has
been for a while and it didn't look like those who filed attemped to
contact ubuntu about it. And it did require non-trivial packaging to
get it right into chameleon state where it builds and integrates into
debian & ubuntu seamlessly.

I really want to improve Debian-Ubuntu relations but so far it looks
like Debian doesn't want to do any work in adopting or helping to
adopt changes back.

Ubuntu over the years continues to improve the relationship by getting
(redirecting) people into Debian development, but I yet to see debian
maintainers pro actively keeping an eye on their packages in Ubuntu
and merging the changes as they become available (and everyone does
see the ubuntu box on their packages.qa.d.o)

Majority of ubuntu developers have sid & squeeze pbuilders /
cowbuilders. Do debian maintainers test their packages in ubuntu
pbuilder before pushing the change.

There have been mind-set changes among some dd's who do login to their
launchpad accounts, respond to bug reports on launchpad, apply to be
per-package uploaders and become eventually ubuntu members, MOTU's and
developers. But on the relative scale IMHO Ubuntu is currently better
at this.

>>
>> Perhaps a useful middle ground would be to create a system to connect
>> Ubuntu
>> packages which are not yet in Debian with Debian developers who are
>> interested in packaging them?
>
> We talked about this in the session. #debian-ubuntu is open for business.
> But in the specific case raised in the OP to this thread, Debian developers
> were interested in porting the packaging of some Ubuntu software and were
> trying to engage with the Ubuntu developers but apparently without success.
> This seems like something to fix.
>

Please give examples =) #debian-ubuntu so far has been very responsive
and friendly platform for these discussions.

Also keep in mind that Ubuntu Developer pool is much smaller than
Debian's (especially if you subtract all the people who are both
Debian&Ubuntu developers simultaneously), yet archive size is the same
and ubuntu developed tools & applications is smaller than debian's as
well.

ps. sorry for such strong-opinionated email but i've been holding this
up ever since I've stated debian/ubuntu development ~1.5 years ago.