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

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



Hi, 

> Dear Alexander, backport.org people, and everybody,
> 
> If I understand correctly, it is planned to incorporate the backports.org
> service as an official Debian repository.
Thats true. 
> 
> I would like to know if the policy of use for backports.debian.org has already
> been discussed, drafted or decided. In particular:
The current agreement is that everything will stay the same and that future
changes will stay in the hands of the backports team. 

>  - Will there still be separate keyrings?
Thats not clear yet, currently it seems - due to technical limitations in dak
- we will start with our own dak instance which means with our own keyring.
But this will be changed in the future. 

>  - Will there still be a screening at the first upload: a NEW queue?
Yes. 
>  - Who will be allowed to upload backports?
Every DD and probably every DM after he is added to our keyring. 

>  - Will the upload policy change?
There are some small changes planned, but nothing fundamental. 

> 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. 

Alex


Reply to: