Re: per-version hints proposal

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Dec  9 11:46, Corinna Vinschen wrote:
> 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.

Even simpler:

- cygport gets a new command, e. g.

    cygport foo.cygport {promote|untest|currify}

  This command has only one purpose.  It creates and uploades new
  $PVR.hint files without the test: marker to the maintainers upload
  area.

  Shouldn't these files be picked up by calm and overwrite the existing
  PVR.hint files and the test marker is gone?


Corinna

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

Attachment: signature.asc
Description: PGP signature