Hi Bart, On Sat, Mar 27, 2021 at 07:38:17AM +0100, Bart Martens wrote: > On Fri, Mar 26, 2021 at 11:43:27PM +0100, Yadd wrote: > > Le 26/03/2021 à 22:38, Andreas Tille a écrit : > > > Any idea what to do (besides uploading all packages obtained from > > > Github right after the release)? > > > > This breaks also more than thousand package from JS Team. > > > > We could perhaps handle that with uscan then each time GitHub changes > > its website, only uscan should be updated. > > Yes. Or maintain watch files outside the packages.
Fine for me - but what is our QA tool chain using. As far as I know tracker.d.o and other tools are relying on UDD and the information is fed from the uploaded watch file. Or am I wrong with this assumption? > Or use "fakeupstream.cgi" > for popular platforms like github. > https://salsa.debian.org/qa/qa/blob/master/cgi-bin/fakeupstream.cgi For the moment there are four suggestions for watch files maintained inside the package: 1. use the string suggested in `man uscan` https://github.com/<user>/<project>/tags (?:.*?/)?v?(\d[\d.]*)\.tar\.gz 2. enable uscan to interpret some @GITHUBREGEX@ 3. asking for a new github redirector on qa.debian.org as there is for sf.net (or PyPI) 4. use "fakeupstream.cgi" (this service is new to me) All suggestions sound promising to me to be more sustainable than the current situation. For sure it would mean editing *lots* of d/watch files (and upload once the new release cycle will start) I wonder whether we could come up with some suggestion which of these (or may be even other suggestions?) is the most promising one and all those who now feel forced to change their watch files will possibly change to the same string (automatically) instead of picking a random option. I admit my prefered way would be to do this via lintian-error plus lintian-brush to cure the issue. Kind regards Andreas. -- http://fam-tille.de
