Hi!
Here's the ideas that I have heard (and written) during the "Supporting
15.000 packages" BoF which happened during DebConf7. I should probably
have posted this earlier, but, well, better now than never...
Removing packages from the archive
----------------------------------
Most people attending the BoF seemed to agree that we had just too many
packages in the archive. How can we figure out which ones would need to
be removed, then?
* When packages look abandonend, fill a RC bug saying "if you don't
close this bug in a month, will ask for removal".
=> That was done already done by the Q&A team.
=> It's hard to know if a package should be orphaned or removed
directly.
* Have a new release policy of not releasing orphaned packages in
stable. Interested maintainers would then have to adopt them or
let them be removed by the Q&A team.
* User reviews of packages could help to get a more general overview of
the package usefulness which can't be really seen in the BTS (some
packages for not that usefull software are all good on the packaging
standpoint).
Marking package unsupported/less supported
------------------------------------------
The security team is already overloaded. Is there any point on
supporting every single "minimal http server"? Which kind of support
can we offer for bad PHP web applications? How could we deal with
dead/stubborn upstream?
* If we agree that we have unsupported packages, how to mark them as
such? A possible solution would be to add an extra-section like
Ubuntu. Another one is to use the Debtags framework. The later is
far more flexible and we can also more easily change package state
over time. People attending the BoF seemed to have a consensus about
*not* adding an extra section.
* If we drop security support for a package, user of stable should be
notified...
* Experienced admins can already manage to get a good picture of one's
package state of maintaince (using popcon, bug reports, etc.) — it's
more a problem for unexperienced users.
* Get maintainer input (moderated in some ways?) about software and
package quality. Some possible tags:
- maintainer is user of the package?
=> If every maintainer would be more responsible, this should be a
RFA.
- obscure/fringe package (used by not many people)
- upstream is dead
- upstream is dead but the maintainer(s) will fix bugs
- software development status (alpha, beta, stable, mature)?
- suited for local/restricted (network) use only
* Should more packages be only available in experimental?
=> The project should probably define a clear policy for experimental
and back it up with the need infrastructure.
Getting more packages into volatile
-----------------------------------
Some upstreams do not want to give any kind of support for older
versions (last example ion3). Within our current framework, these
packages should probably be in volatile.
Volatile currently have only 11 packages. Should we extend volatile's
scope to incorporate more packages?
Cheers,
--
Jérémy Bobbio .''`.
lunar@debian.org : :Ⓐ : # apt-get install anarchism
`. `'`
`-
Attachment:
signature.asc
Description: Digital signature