On 14/01/08 at 21:20 -0200, Otavio Salvador wrote:
> Luk Claes <[EMAIL PROTECTED]> writes:
>
> > Otavio Salvador wrote:
> >> Margarita Manterola <[EMAIL PROTECTED]> writes:
> >>
> >>> Proposal:
> >>> Implement a new file, that works similarly to the hints file, but that
> >>> causes uploads to unstable for selected packages to be rejected. Thus,
> >>> if a maintainer uploads, it won't get through so that it won't get in
> >>> the way of the transition.
> >>
> >> Could you elaborate what it differs from Enrico's previous proposal[1]?
> >
> > Enrico's idea is nice, but rather not workable in real life as it's the
> > maintainers who start transitions, not the Release Team. The current
> > proposal would only list transitions that are tracked by the Release
> > Team: someone of the team has to be available, has to track that
> > particular transition and bother to get packages rejected for that
> > transition...
>
> As far as I understood his idea, it's the same thing. A single place
> that would allow RM team to control dak processing to avoid unwanted
> uploads during transitions.
I'm not sure of the goal here. Is it:
(A) make sure maintainers are aware of the consequences of an upload
on ongoing transitions
(B) make sure that maintainers know they shouldn't upload, because their
packages are part of a transition tracked by the release team
(A) sounds really, really hard. Because it would mean: comparing what
britney would do in a few days if nothing wrong happens, with what
britney would do in a few days if package X is uploaded.
Maybe we could start by a simpler solution, not involving dak:
- parse the hints files
- get a list of source packages where:
- version in testing != version in unstable
- version in unstable is mentioned in a hints files
for each source package in that list, display a big warning on the PTS:
This package is mentioned in an hints file. It might be part of an
ongoing transition. Please don't upload without asking permission from
the release team, or you might add a long delay to the transition of a
lot of packages to testing.
That's easy to do, and you would avoid the frustrating case where a
maintainer is spoiling the RT's efforts.
--
| Lucas Nussbaum
| [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
