| 169 |
rid of the hacks made everywhere to send a copy of the mails to the PTS, |
rid of the hacks made everywhere to send a copy of the mails to the PTS, |
| 170 |
packages would be (progressively) modified to indicate |
packages would be (progressively) modified to indicate |
| 171 |
“Maintainer: <source>@pkgmaint.debian.org” in their control file. |
“Maintainer: <source>@pkgmaint.debian.org” in their control file. |
| 172 |
|
The current content of the field would be moved to the “Uploaders” field. |
| 173 |
|
|
| 174 |
Until all packages have been converted, the PTS would forward copies of |
Until all packages have been converted, the PTS would forward copies of |
| 175 |
the mails to ensure that the new infrastucture can still be used for all |
the mails to ensure that the new infrastucture can still be used for all |
| 179 |
orphan their packages and are still listed as maintainers in many released |
orphan their packages and are still listed as maintainers in many released |
| 180 |
packages. |
packages. |
| 181 |
|
|
| 182 |
|
QUESTION: It would be cleaner if DAK, the BTS, and all relevant services, |
| 183 |
|
could stop sending mails to the Maintainer field, and would instead always |
| 184 |
|
send the mail to the new infrastructure. That way we wouldn't need to |
| 185 |
|
change the Maintainer field and there would be no transition period. |
| 186 |
|
|
| 187 |
|
The new infrastructure would then be configured with initial subscriptions |
| 188 |
|
for emails listed in Maintainer fields (except for mailing lists, since |
| 189 |
|
the infrastructure aims to replace them). |
| 190 |
|
|
| 191 |
### Leveraging UDD |
### Leveraging UDD |
| 192 |
|
|
| 193 |
At least the PTS has been parsing Sources/Packages files by itself, as |
At least the PTS has been parsing Sources/Packages files by itself, as |
Parent Directory
| 
Revision Log
| 
Patch