Re: per-version hints proposal

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

[-- Attachment #1: Type: text/plain, Size: 3192 bytes --]

On Dec  8 19:30, Jon Turney wrote:
> On 30/08/2016 13:24, Jon Turney wrote:
> > This file is called override.hint.
> 
> While not a great deal of use is made of test versions, this mechanism
> doesn't seem to be working well for that, and there have been several
> requests to improve it.
> 
> There's no automation to generate override.hint, and writing it correctly
> requires too much knowledge about how calm is going to process it.
> [...]

ACK.  It's kind of backwards compared to the new layout with per-version
hint files.

> The proposal to address this is:
> 
> Add support to calm for a 'test:' line in PVR.hint, marking a version as a
> test version.

ACK

> If multiple versions are marked test, the highest version will be used as
> the test version in the generated setup.ini (and thus offered for
> installation using the 'exp' control in setup.)
> 
> (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.

> 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.

> cygport will be updated to (details TBC) accept a --test flag which is
> significant to the cygport package stage, and adds this 'test:' line to all
> the generated PVR.hint files.

--test would be fine.

> To promote a package from test to curr, a script will be run on sourceware
> to remove the test: line from the existing PVR.hints in a given package
> subtree, for a given VR.
> 
> Since this requires shell access on sourceware, if you don't have that, you
> can ask here or on #cygwin-developers.

I don't think this is feasible.  The maintainer should have control
over the promotion from test to curr.  I'm not affected by this since
I generate new versions as soon as I promote, so this is more maintainers
like JonY, for whom a rebuild and reupload of the gcc packages just to
promote test to curr is quite a burden.

First, not well thought out proposal:

- cygport gets a new command, e. g.

    cygport foo.cygport {promote|untest|currify}

  This command has only one purpose.  It uploads a file !untest
  to the maintainers upload area, with a single line containing
  the version number from the foo.cygport file, i. e.

  - Fetch $PVR from foo.cygport, e. g.  2.24-1.
  - echo "$PVR" > !untest
  - lftp !untest to cygwin.com:maintainer-area

- While creating the ini file, calm looks for !untest files.  If one
  is available, check the version number.  If there's a matching PVR.hints
  file, drop the test marker.  Continue with creating the ini file.

> 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?


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]