Differences between revisions 1 and 2
Revision 1 as of 2006-07-31 15:22:25
Size: 45
Editor: AdamBarratt
Comment:
Revision 2 as of 2006-08-01 09:58:49
Size: 1464
Editor: AdamBarratt
Comment: Stick in some text that should make an ok starting point
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Dummy page to start documenting removals on > is there a comprehensive list of how to title requests against
> ftp.debian.org? Perhaps we could make one on wiki.debian.org

It's one of those things that nobody seems to have found the appropriate
tuits for. I think about doing it every so often but then get distracted;
Jeroen has talked about documenting the format in the past (hence the Cc).
I'm also not entirely sure whether such documentation belongs somewhere more
"official" (e.g. 5.9.2 of the Developer's Reference) as there's more
information that should probably be written down somewhere relating to
removals - e.g. "if the package is still listed in debian/control then
you'll just get the bug reassigned to the package, requesting that gets
fixed first".

Likewise, the DevRef section might want to expand on the comments on
"testing" removal (as there's no point asking ftpmaster for such removals)
and a mention of "rene" so that maintainers know they don't need to request
removals for source packages no longer building any binaries, etc.

The syntax is basically

  RM: <source package> <architecture> -- <reasons>

where:

  <architecture> is of the form "[arch(| arch)*]" and should be omitted
unless
  you're requesting a partial removal (i.e. only removing the binaries for
some
  architectures, as in this case)

and

  <reasons> approximately corresponds to the list at the head of
  http://ftp-master.debian.org/removals.txt, plus comments

Adam

> is there a comprehensive list of how to title requests against > ftp.debian.org? Perhaps we could make one on wiki.debian.org

It's one of those things that nobody seems to have found the appropriate tuits for. I think about doing it every so often but then get distracted; Jeroen has talked about documenting the format in the past (hence the Cc). I'm also not entirely sure whether such documentation belongs somewhere more "official" (e.g. 5.9.2 of the Developer's Reference) as there's more information that should probably be written down somewhere relating to removals - e.g. "if the package is still listed in debian/control then you'll just get the bug reassigned to the package, requesting that gets fixed first".

Likewise, the ?DevRef section might want to expand on the comments on "testing" removal (as there's no point asking ftpmaster for such removals) and a mention of "rene" so that maintainers know they don't need to request removals for source packages no longer building any binaries, etc.

The syntax is basically

  • RM: <source package> <architecture> -- <reasons>

where:

  • <architecture> is of the form "[arch(| arch)*]" and should be omitted

unless

  • you're requesting a partial removal (i.e. only removing the binaries for

some

  • architectures, as in this case)

and

Adam