Re: per-version hints proposal

[Jon Turney <jon dot turney at dronecode dot org dot uk>]

On 09/12/2016 10:46, Corinna Vinschen wrote:
> On Dec  8 19:30, Jon Turney wrote:
> > On 30/08/2016 13:24, Jon Turney wrote:
> >
> > (Note to self: why isn't this control labelled 'test', which is an actual
> > english word???)
>
> Note to jturney, change it, don't be shy.

Patch sent :)

> > Versions marked as test cannot be used as curr: (so test versions are never
> > automatically promoted to curr)
> >
> > override.hint will continue to work, and, if one exists it takes precedence
> > over these rules.
>
> I would rather drop it as an evolutionary dead end.

It still has some potential uses, such as overriding curr:

[...]
> > I would like to provide an automatic mechanism to allow package maintainers
> > to promote their own test packages, but there are a few stumbling blocks in
> > the way of that, currently.
>
> -v?

So, this requires:

Making this change in the release area in a transactional way (so we can 
rollback if the upload fails.

Some way to request the removal of the test label.  This would probably 
be best if things were restructured as some kind of 'commands' from a 
'script', rather than certain files with funny names implying special 
actions, and moving files by default.

These are both new functionality, and I have no good ideas yet about how 
to do it, or when I might be able to work on it.

There are only a handful of packages using test versions at the moment 
(base-files, cygwin, gdb, readline, socat, xorg-server), so some sort of 
manual process to promote things until this gets a proper solution 
doesn't seem too demanding of manpower...