[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Purpose and policy of the future backports.debian.org.



> > The current upload policy is well adapted to the fact that a backport can be
> > maintained by a different person from the official package maintainers. But
> > when backports are prepared by the same team as the main package, can the rules
> > be relaxed ?
> I don't understand this question. Currently its already possible - and
> preferred - if the maintainer of a package also work on the backport. I don't
> see what can be relaxed here. 
> 
> > Lastly, in echo to the xulrunner thread, I would like to know if it will be
> > possible to maintain a pakcage in backports.org when it is not targetted at a
> > stable release (for instance, when the program is still in a fast development
> > stage).
> I don't think so. Rhonda (who will get a new ftpmaster for bpo if we moved)
> thinks like me. For a simple package like flashplugin-nonfree this is
> possible, but xulrunner is a monster with all its dependencys and its a
> security nightmare. I don't see that backports is appropriate for such a
> package.

Thanks for the fast answer!

First of all, I would like to make clear that I am not trying to bikeshed
xulrunner: I am more self-centered than this and was only thinking on how to
use backports.debian.org for the Debian Med packages (this is why I opened a
separate thread).

When I asked about relaxing the rules, I was in particular thinking about
upload of backports prepared by the original maintainer, before testing
migration. For instance in some cases, it is crystal clear from the debdiff and
the maintainer's tests on his computer that some changes uploaded to unstable
will not introduce new bugs. Updating the backport at the same time would save
some time and simplify our schedules (no upload echo 10 days later). The other
constraint that I would be interested to be lifted is the passage through the
NEW queue when the backport maintainer is the original maintainer, but if it
requires toolchain development, I understand that this would not be done (again
the goal is to remove issues from the radar after upload).

I think that backports.debian.org will be a tremendous addition to our
distribution, that will distinguish us from many others, and I thank you for
all the hard work and perseverence that lead to this. Since it opens many
possibilities, I think that it is important to have a discussion in advance to
make sure that the vision of the uploaders and the administrators fit well. In
particular, I think that the question of whether backports should only exist
for packages that are aimed at a stable release is a very important one. For
some of the packages I maintain, I predict that my users will be much more
interested in snapshots (to be consistent over a project) or backports of the
main package. In that sense, although the package in stable may be released and
maintained with care, it will be more a byproduct than the real aim.

By the way, will the backports.debian.org uploads archived on
snapshots.debian.org?

Cheers,

-- 
Charles


Reply to: