On 11/23/05, Reinhard Tartler <[EMAIL PROTECTED]> wrote:
On 11/23/05, John Dong <[EMAIL PROTECTED]> 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
[email protected]
http://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
-- ubuntu-backports mailing list [email protected] http://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
