pre-spec discussion: modified-source backports

On 11/23/05, Reinhard Tartler <siretart at gmail.com> wrote:
>
> On 11/23/05, John Dong <jdong at ubuntu.com> wrote:
> > http://ubuntubackports.org/wiki/index.php/SourceChanges
> Could you please  http://wiki.ubuntu.com/SpecSpec as template?
>
> > I've started drafting up some of these ideas... Comments appreciated.
> > > MY PROPOSAL:
> > >
> > > Two types of source-changed backporting should be spec'ed and brought
> to
> > the Tech Board for review:
> > >
> > > (1) MAIN Packages: Approval by either prominent maintainer figure or
> mdz
> > (?), changes ultimately done by a Ubuntu developer
> > > (2) UNIVERSE Packages: Approval through review by multiple MOTU
> members
> > (maybe through the REVU system)
>
> I think that one MOTU who is working with the backports team should be
> sufficient.


Ok, slomo was the one who suggested multiple MOTU reviewers.

> > What do you guys think? Surely we'll need more specific guidelines about
> > what kind of changes specifically should be allowed (i.e. build-dep
> changes,
> > unpatching upstream-specific changes [i.e. Launchpad Integration under
> > Hoary], etc)?
>
> Consider this: For dapper, we want to jump on soyuz, a complete new
> infrastructure. I don't think that the ubuntu team has enough time and
> energy left to implement a new upload target for the backporters.
> perhaps the launchpad/soyuz team can arrange something for you, but
> this needs to be specified as well.
>
Now for the backporting policy: build-dep changes should be okay, but
> I'm not that confident with 'unpatching upstream-specific changes'.
> Whats that? we are shipping software, developed by their upstreams.


I meant changes in Dapper that were specific in Dapper, like how launchpad
integration got added to Breezy and caused most main packages to be
unbackportable. Most of those are in the debian/patches directory and could
be easily and cleanly removed without affecting the package much.

With a clause like that, you could render the whole policy quite
> unpracticable, because your are effectively allowing everything.
>
> I have another question to be cleared in advance: Are packages in
> -backports being build against the stable release or against the
> -backports repository as well? You see the difference?


Yes, I see the difference. By default, built against stable release because
I want people to be able to pick backports independently from the rest of
the distribution. But when pulling new packages back, I may introduce new
library packages that aren't in Breezy at all (like libtorrent/rtorrent
addition in Dapper), in which case it's only possible to compile against
breezy-backports's libtorrent.

A small thing I'd really want to have: I'd like to be able to specify
> which specific package from backports I install on my system, just
> like http://backports.org. There I can put the following in my
> /etc/apt/sources.list:
>
> deb http://backports.org/backports unstable firefox pmount evms
>
> to only have firefox, pmount and evms backported, and nothing else.
> Every package to be backported has it's own 'tiny' archive, where the
> whole toolchain it needs is backported. This allowes maximum
> flexibilty. OTOH, this requires more maintenance on both the archive
> masters and the uploaders.


Currently I have 2 options with ubuntu backports: either I take all
> backports or none. I find this very unsatisfactory.


I'd like to have this too, that'd be a cool feature. :). Even cooler would
be a frontend/GUI for Dapper to choose backports :)

--
> regards,
>    Reinhard
>
> --
> ubuntu-backports mailing list
> ubuntu-backports at lists.ubuntu.com
> http://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ubuntu.com/archives/ubuntu-backports/attachments/20051123/39dee2aa/attachment.htm