per-version hints proposal
Corinna Vinschen
corinna-cygwin@cygwin.com
Fri Dec 9 11:10:00 GMT 2016
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20161209/d54033ed/attachment.sig>
More information about the Cygwin-apps
mailing list