Re: Using release-monitoring.org [was: uscan roadmap]
On Sat, Dec 4, 2021 at 3:34 AM Paul Wise wrote: > > Repology gets you mappings for all the source packages in Debian in one > download (assuming it has an export of the mappings, that may need to > be added), while the Anitya mapping requires a human to manually add a > mapping for each of the thousands of source packages in Debian. Not all > maintainers are going to bother and repetitive clicking is going to get > boring for the folks trying to make up for that. I'm sure there would be a way to automate this with repology data. > > Also, mapping on Repology sometimes needs to be adjusted manually. And > > sometimes they disagree and instead tell you to rename the source > > package in the distro (happened to me once), which is not really > > viable in Debian. > > I wasn't aware of the renaming part, seems kind of weird. See e.g. [1]: "Will not merge: Modules (e.g. python) without consistent prefix (e.g. python- or python3-) (common problem for Slackbuilds and Debian source packages). [...]" > > Yes it can't, but also I don't think this is something *release > > monitoring* should do. It is definitely a good use case and that is > > why there is a link to repology on the tracker (called "other > > distros"), but it has IMHO nothing to do with *automatic* release > > monitoring. Don't get me wrong, I actually like repology exactly for > > this particular reason. > > I was taking the thread topic to be the slightly more general area of > "monitoring when a package needs updating to a new upstream release, > snapshot or fork". New VCS snapshots in other distros fits that IMO. Ah right I see, I guess we then should separate more between fetching the tarball and scanning for versions to inform the maintainer - I don't think that these necessarily need to use the same technique. For informing the maintainer, repology might as well be an additional very useful tool. > The other issue with using Anitya is that Debian and Fedora have > different policies and culture for choosing which upstream versions to > update to. Debian strongly prefers LTS versions while Fedora are all > about the latest and greatest, which is a bit of a culture clash and is > likely to mean for some packages we couldn't use Anitya. I don't think this is an issue here - see [2]. The response differentiates between stable versions and other versions. I'm not sure how RCs are handled, but it would not be that difficult to implement. > In addition to independence there is the issue Jonas mentioned > elsewhere in the initial uscan thread that some Debian people prefer > the info to be maintained in the source package instead of elsewhere. Of course this would be optional. Regarding bootstrapping it might not be that good of an idea to use it for essential packages anyway. > > This sounds more reasonable to me than writing a tool that converts a > > new standard to the old one just as backup. > > Given the above, perhaps a way to sync a locally stored file and the > Anitya one, and then have uscan understand the Anitya format? I've been looking at the api (see [2]) for a bit and while not trying it out myself, afaik there is no functionality to download a tarball. While I like the idea of release-monitoring, I now feel like it doesn't fulfill the needs of Debian and probably newer will. So putting all watch files in a single salsa repo probably makes more sense, or something similar to offload it. On Sat, Dec 4, 2021 at 3:44 AM Scott Kitterman wrote: > > I think that there's a security consideration associated with all these > proposals for externalizing finding upstream updates. Currently watch files > and at least the redirectors I know of all run on Debian infrastructure or on > the systems of the Debian person doing the update. > > If one of these services were ever compromised it would provide a vector for > offering substitute upstream code (at least for the cases where upstream > releases aren't both signed by upstream and verified in Debian). I find that > prospect concerning. Good point, but I think this can be mitigated relatively easily - just always print the url of the tarball that is downloaded (which is a good idea anyway). The maintainer should know the url where the sources are hosted, and if the printed url somehow looks weird, it can be easily checked. Stephan [1] https://repology.org/project/symfit/report [2] https://release-monitoring.org/static/docs/api.html#post--api-v2-versions-
Re: Using release-monitoring.org [was: uscan roadmap]
On Sat, Dec 04, 2021 at 02:43:56AM +, Scott Kitterman wrote:
> I think that there's a security consideration associated with all these
> proposals for externalizing finding upstream updates. Currently watch files
> and at least the redirectors I know of all run on Debian infrastructure or on
> the systems of the Debian person doing the update.
I don't see how? At least repology just tells you "there is a new
upstream release", it doesn't tell you where to get it. It's up to the
maintainer to know where to download a new release.
Obviously if upstream is compromised and a new "release" is produced
that contains malicious code then there is a problem, but that is a
problem that is neither exacerbated nor mitigated by using repology.
> If one of these services were ever compromised it would provide a
> vector for offering substitute upstream code (at least for the cases
> where upstream releases aren't both signed by upstream and verified in
> Debian). I find that prospect concerning.
Validating that upstream releases are valid is part of the job of being
a maintainer in Debian. Having some helper service that tells you there
is a new release doesn't change that.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Re: Using release-monitoring.org [was: uscan roadmap]
On 2021-12-03 00:51, Paul Wise wrote: > The one issue I can think of with using release-monitoring.org is that > Debian becomes more reliant on an external service, while currently we > are completely independent of other distros for version checking. > > Converting the release-monitoring.org check to a watch file might be an > alternative to using it directly that maintains our independence. +1 Best, Andrius
Re: Using release-monitoring.org [was: uscan roadmap]
On December 5, 2021 1:51:48 AM UTC, Paul Wise wrote: >On Sat, 2021-12-04 at 02:43 +, Scott Kitterman wrote: > >> I think that there's a security consideration associated with all these >> proposals for externalizing finding upstream updates. > >Good point. > >> If one of these services were ever compromised it would provide a >> vector for offering substitute upstream code (at least for the cases >> where upstream releases aren't both signed by upstream and verified in >> Debian). I find that prospect concerning. > >I think the same concern should also apply to centralised upstream >development infrastructure like GitHub and also individual upstream >developers themselves. There isn't really any mitigation for malicious >code being pushed out beyond commit/release signing (both unpopular) >and (distributed) downstream code review. > >To mitigate the concern for upstream version monitoring we could prefer >debian/watch when it exists but fall back to release-monitoring.org >when one doesn't exist, have a tool to convert the Ayanita format into >debian/watch and have dh_make and similar try to create an initial >debian/watch by default. > >We need a culture of doing change review before updating to new >upstream releases, but often that isn't necessarily feasible, >especially for large projects with rapid change or when switching to >new forks of existing tools. > >> Currently watch files and at least the redirectors I know of all run >> on Debian infrastructure or on the systems of the Debian person doing >> the update. > >Some run on debian.org servers, and many run on debian.net domains. >However I don't think that that makes them immune to compromise. > Never claimed it did, but the knowledge that our security posture isn't invulnerable isn't an argument for making it worse. Scott K
Re: Using release-monitoring.org [was: uscan roadmap]
On Sat, 2021-12-04 at 02:43 +, Scott Kitterman wrote: > I think that there's a security consideration associated with all these > proposals for externalizing finding upstream updates. Good point. > If one of these services were ever compromised it would provide a > vector for offering substitute upstream code (at least for the cases > where upstream releases aren't both signed by upstream and verified in > Debian). I find that prospect concerning. I think the same concern should also apply to centralised upstream development infrastructure like GitHub and also individual upstream developers themselves. There isn't really any mitigation for malicious code being pushed out beyond commit/release signing (both unpopular) and (distributed) downstream code review. To mitigate the concern for upstream version monitoring we could prefer debian/watch when it exists but fall back to release-monitoring.org when one doesn't exist, have a tool to convert the Ayanita format into debian/watch and have dh_make and similar try to create an initial debian/watch by default. We need a culture of doing change review before updating to new upstream releases, but often that isn't necessarily feasible, especially for large projects with rapid change or when switching to new forks of existing tools. > Currently watch files and at least the redirectors I know of all run > on Debian infrastructure or on the systems of the Debian person doing > the update. Some run on debian.org servers, and many run on debian.net domains. However I don't think that that makes them immune to compromise. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Using release-monitoring.org [was: uscan roadmap]
On Sat, 04 Dec 2021 at 10:33:55 +0800, Paul Wise wrote: > The other issue with using Anitya is that Debian and Fedora have > different policies and culture for choosing which upstream versions to > update to. Debian strongly prefers LTS versions while Fedora are all > about the latest and greatest, which is a bit of a culture clash and is > likely to mean for some packages we couldn't use Anitya. For quite a few packages that have this branching structure, Debian would ideally have both - latest development versions in experimental, and LTS versions in unstable/testing/stable. In some packages I use a different d/watch for unstable and experimental (so that at least I can do a "uscan --download" on each branch and get the right thing), but that's one more thing to adjust when merging between branches, and the PTS can only remind me about one of them. It would be great if uscan (or equivalent) could show us both from one configuration file. smcv
Re: Using release-monitoring.org [was: uscan roadmap]
On December 3, 2021 12:12:47 PM UTC, Stephan Lachnit wrote: >On Thu, Dec 2, 2021 at 11:52 PM Paul Wise wrote: >> >> On Thu, 2021-12-02 at 23:36 +0100, Stephan Lachnit wrote: >> >> > If I understand correctly, release-monitoring already offers such a >> > mapping [1]. >> >> It seems like the Ayanita distro mapping needs to be done manually once >> per package, while using the Repology data would automatically get us >> the mapping for each existing package and all future packages. > >I mean it looks rather easy to do, just a couple of mouse clicks. >Compare that to writing a watch file at the moment (assuming one has >to do more than copy and paste the github example). > >> > Hm, I can't really think of an example where such a thing couldn't >> > also be implemented in release-monitoring.org. >> >> None of the three use-cases I listed can be done by it AFAICT. >> >> It can't check things that it doesn't have a check for, while >> individual package maintainers in various distros will update their >> packages and Repology will notice the new versions. > >Then the maintainer would just have to write a check, just like they >have to do now. > >Also, mapping on Repology sometimes needs to be adjusted manually. And >sometimes they disagree and instead tell you to rename the source >package in the distro (happened to me once), which is not really >viable in Debian. > >> It presumably doesn't look at the versions for all distros, so it can't >> do the cross-distro VCS snapshot choice check, while individual package >> maintainers in various distros know their packages well and might >> upgrade to a VCS snapshot in their distro, which Repology notices. > >Yes it can't, but also I don't think this is something *release >monitoring* should do. It is definitely a good use case and that is >why there is a link to repology on the tracker (called "other >distros"), but it has IMHO nothing to do with *automatic* release >monitoring. Don't get me wrong, I actually like repology exactly for >this particular reason. > >> It also isn't going to check locations it doesn't check yet, while >> individual package maintainers in other distros might do that after >> noticing their package hasn't been updated recently and then going >> searching for a new upstream and updating, which Repology notices. > >Fair point, but if we would work together on release-monitoring.org >with Fedora, there are more eyes on it as well as in the current >situation. >Repology still has more eyes of course, but then again the link to >Repology is right there on the tracker already if one is curious. > >> > Just one quick idea I had: what about a "fake" uscan backend? I.e. >> > something like `Version: release-monitoring.org` in d/watch. In that >> > case uscan will launch an external program that fetches the data from >> > there and gives it back to uscan, so that other tools stay unaffected >> > until a full transition is done. >> >> Excellent idea, that would be great to have. > >One more thought on this. If we go with version 5, maybe something like: > >Version: 5 >Source: release-monitoring.org > >Would also work for multiple sources then and in general would fit >nicely to the current idea for v5. It also solves the problem with the >tooling, watch files and uscan would still exist, but the "searching" >portion is offloaded. > >> The one issue I can think of with using release-monitoring.org is that >> Debian becomes more reliant on an external service, while currently we >> are completely independent of other distros for version checking. >> >> Converting the release-monitoring.org check to a watch file might be an >> alternative to using it directly that maintains our independence. > >Hm right, independence is a valid concern. Anitya itself is open >source [1] so we could host it easily, but of course the real problem >would be the stored data of the projects. I don't know if they are >hosted somewhere, but I'm sure the Fedora guys would be open to share >them with us, so that we could easily spin up a mirror in case there >are any problems (it's probably a good idea to host a read-only mirror >just in case). > >This sounds more reasonable to me than writing a tool that converts a >new standard to the old one just as backup. I think that there's a security consideration associated with all these proposals for externalizing finding upstream updates. Currently watch files and at least the redirectors I know of all run on Debian infrastructure or on the systems of the Debian person doing the update. If one of these services were ever compromised it would provide a vector for offering substitute upstream code (at least for the cases where upstream releases aren't both signed by upstream and verified in Debian). I find that prospect concerning. Scott K
Re: Using release-monitoring.org [was: uscan roadmap]
On Fri, 2021-12-03 at 13:12 +0100, Stephan Lachnit wrote: > I mean it looks rather easy to do, just a couple of mouse clicks. > Compare that to writing a watch file at the moment (assuming one has > to do more than copy and paste the github example). Repology gets you mappings for all the source packages in Debian in one download (assuming it has an export of the mappings, that may need to be added), while the Anitya mapping requires a human to manually add a mapping for each of the thousands of source packages in Debian. Not all maintainers are going to bother and repetitive clicking is going to get boring for the folks trying to make up for that. > Then the maintainer would just have to write a check, just like they > have to do now. Or you could get the most recent distro version for free without manual work by using the Repology data. While it isn't always the true latest release from upstream, often the latest distro version being newer than the Debian version is good enough to notify the Debian maintainer to update the package to the true latest release from upstream. > Also, mapping on Repology sometimes needs to be adjusted manually. And > sometimes they disagree and instead tell you to rename the source > package in the distro (happened to me once), which is not really > viable in Debian. I wasn't aware of the renaming part, seems kind of weird. > Yes it can't, but also I don't think this is something *release > monitoring* should do. It is definitely a good use case and that is > why there is a link to repology on the tracker (called "other > distros"), but it has IMHO nothing to do with *automatic* release > monitoring. Don't get me wrong, I actually like repology exactly for > this particular reason. I was taking the thread topic to be the slightly more general area of "monitoring when a package needs updating to a new upstream release, snapshot or fork". New VCS snapshots in other distros fits that IMO. > Fair point, but if we would work together on release-monitoring.org > with Fedora, there are more eyes on it as well as in the current > situation. > Repology still has more eyes of course, but then again the link to > Repology is right there on the tracker already if one is curious. Sure, I think we need all three solutions as they all fit different use-cases within the "update to latest release/snapshot/fork" arena; (see below for more about why) debian/watch, Anitya and Repology. There is already a bug about more Repology integration within the package tracker, and I was the one who did the existing tracker integration. > One more thought on this. If we go with version 5, maybe something > like: > > Version: 5 > Source: release-monitoring.org Looks good. > Would also work for multiple sources then and in general would fit > nicely to the current idea for v5. It also solves the problem with the > tooling, watch files and uscan would still exist, but the "searching" > portion is offloaded. Agreed. > Hm right, independence is a valid concern. Anitya itself is open > source [1] so we could host it easily, but of course the real problem > would be the stored data of the projects. I don't know if they are > hosted somewhere, but I'm sure the Fedora guys would be open to share > them with us, so that we could easily spin up a mirror in case there > are any problems (it's probably a good idea to host a read-only mirror > just in case). The other issue with using Anitya is that Debian and Fedora have different policies and culture for choosing which upstream versions to update to. Debian strongly prefers LTS versions while Fedora are all about the latest and greatest, which is a bit of a culture clash and is likely to mean for some packages we couldn't use Anitya. In addition to independence there is the issue Jonas mentioned elsewhere in the initial uscan thread that some Debian people prefer the info to be maintained in the source package instead of elsewhere. > This sounds more reasonable to me than writing a tool that converts a > new standard to the old one just as backup. Given the above, perhaps a way to sync a locally stored file and the Anitya one, and then have uscan understand the Anitya format? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Using release-monitoring.org [was: uscan roadmap]
On Thu, Dec 2, 2021 at 11:52 PM Paul Wise wrote: > > On Thu, 2021-12-02 at 23:36 +0100, Stephan Lachnit wrote: > > > If I understand correctly, release-monitoring already offers such a > > mapping [1]. > > It seems like the Ayanita distro mapping needs to be done manually once > per package, while using the Repology data would automatically get us > the mapping for each existing package and all future packages. I mean it looks rather easy to do, just a couple of mouse clicks. Compare that to writing a watch file at the moment (assuming one has to do more than copy and paste the github example). > > Hm, I can't really think of an example where such a thing couldn't > > also be implemented in release-monitoring.org. > > None of the three use-cases I listed can be done by it AFAICT. > > It can't check things that it doesn't have a check for, while > individual package maintainers in various distros will update their > packages and Repology will notice the new versions. Then the maintainer would just have to write a check, just like they have to do now. Also, mapping on Repology sometimes needs to be adjusted manually. And sometimes they disagree and instead tell you to rename the source package in the distro (happened to me once), which is not really viable in Debian. > It presumably doesn't look at the versions for all distros, so it can't > do the cross-distro VCS snapshot choice check, while individual package > maintainers in various distros know their packages well and might > upgrade to a VCS snapshot in their distro, which Repology notices. Yes it can't, but also I don't think this is something *release monitoring* should do. It is definitely a good use case and that is why there is a link to repology on the tracker (called "other distros"), but it has IMHO nothing to do with *automatic* release monitoring. Don't get me wrong, I actually like repology exactly for this particular reason. > It also isn't going to check locations it doesn't check yet, while > individual package maintainers in other distros might do that after > noticing their package hasn't been updated recently and then going > searching for a new upstream and updating, which Repology notices. Fair point, but if we would work together on release-monitoring.org with Fedora, there are more eyes on it as well as in the current situation. Repology still has more eyes of course, but then again the link to Repology is right there on the tracker already if one is curious. > > Just one quick idea I had: what about a "fake" uscan backend? I.e. > > something like `Version: release-monitoring.org` in d/watch. In that > > case uscan will launch an external program that fetches the data from > > there and gives it back to uscan, so that other tools stay unaffected > > until a full transition is done. > > Excellent idea, that would be great to have. One more thought on this. If we go with version 5, maybe something like: Version: 5 Source: release-monitoring.org Would also work for multiple sources then and in general would fit nicely to the current idea for v5. It also solves the problem with the tooling, watch files and uscan would still exist, but the "searching" portion is offloaded. > The one issue I can think of with using release-monitoring.org is that > Debian becomes more reliant on an external service, while currently we > are completely independent of other distros for version checking. > > Converting the release-monitoring.org check to a watch file might be an > alternative to using it directly that maintains our independence. Hm right, independence is a valid concern. Anitya itself is open source [1] so we could host it easily, but of course the real problem would be the stored data of the projects. I don't know if they are hosted somewhere, but I'm sure the Fedora guys would be open to share them with us, so that we could easily spin up a mirror in case there are any problems (it's probably a good idea to host a read-only mirror just in case). This sounds more reasonable to me than writing a tool that converts a new standard to the old one just as backup. Regards, Stephan [1] https://github.com/fedora-infra/anitya
Re: Using release-monitoring.org [was: uscan roadmap]
On Thu, 2021-12-02 at 23:36 +0100, Stephan Lachnit wrote: > If I understand correctly, release-monitoring already offers such a > mapping [1]. It seems like the Ayanita distro mapping needs to be done manually once per package, while using the Repology data would automatically get us the mapping for each existing package and all future packages. > Hm, I can't really think of an example where such a thing couldn't > also be implemented in release-monitoring.org. None of the three use-cases I listed can be done by it AFAICT. It can't check things that it doesn't have a check for, while individual package maintainers in various distros will update their packages and Repology will notice the new versions. It presumably doesn't look at the versions for all distros, so it can't do the cross-distro VCS snapshot choice check, while individual package maintainers in various distros know their packages well and might upgrade to a VCS snapshot in their distro, which Repology notices. It also isn't going to check locations it doesn't check yet, while individual package maintainers in other distros might do that after noticing their package hasn't been updated recently and then going searching for a new upstream and updating, which Repology notices. > Just one quick idea I had: what about a "fake" uscan backend? I.e. > something like `Version: release-monitoring.org` in d/watch. In that > case uscan will launch an external program that fetches the data from > there and gives it back to uscan, so that other tools stay unaffected > until a full transition is done. Excellent idea, that would be great to have. The one issue I can think of with using release-monitoring.org is that Debian becomes more reliant on an external service, while currently we are completely independent of other distros for version checking. Converting the release-monitoring.org check to a watch file might be an alternative to using it directly that maintains our independence. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Using release-monitoring.org [was: uscan roadmap]
On Thu, 2 Dec 2021, 23:17 Paul Wise, wrote: > At minimum we would need a way to map from release-monitoring.org > package names to Debian source package names. Assuming they use Fedora > source package names, then the Repology service provides such a mapping > and we could presumably could get a periodic export of that. > If I understand correctly, release-monitoring already offers such a mapping [1]. > I see using Repology as a complement to release-monitoring.org and > uscan, not as an alternative to them. It enables use-cases that aren't > possible with the other two. We automatically get version monitoring > for packages that don't have other version monitoring mechanisms. We > get monitoring of whether or not a particular package needs updating to > a VCS snapshot instead of waiting for an official release. We get > monitoring of versions even when upstream has moved to a different > location not monitored by other mechanisms. There are probably other > use-cases I can't think of right now. > Hm, I can't really think of an example where such a thing couldn't also be implemented in release-monitoring.org. > > Yes that makes sense, what I wonder is how much change is needed for > > putting watch files in a separate repo compared to going with > > release-monitoring.org (I don't know enough about the inner workings > > of our tools to answer this question). > > For the VCS idea it would be minimal, just vcswatch needs to also pull > debian/watch files out of VCS repos with commits not yet pushed to > Debian and then the version checking infra (zero idea where that went) > needs to pay attention to that data. > Oh right, that actually sounds pretty smart. > For fully moving debian/watch (and Homepage) out of Debian source > packages there would need to be a lot more work, probably migrating to > release-monitoring.org would be the way to go. > Just one quick idea I had: what about a "fake" uscan backend? I.e. something like `Version: release-monitoring.org` in d/watch. In that case uscan will launch an external program that fetches the data from there and gives it back to uscan, so that other tools stay unaffected until a full transition is done. In case there are others interested in this approach, I would be down to do some coding (when I find time). Regards, Stephan [1] https://release-monitoring.org/static/docs/user-guide.html#creating-new-distribution-mapping
Re: Using release-monitoring.org [was: uscan roadmap]
On Fri, 3 Dec 2021, Paul Wise wrote: I think this would be the best path forward - it would probably be not easy given that it changes entirely how the current system works, but it might be well worth the effort. Working together with another distribution would share the work for the distro. I'm sure if we are willing to join them they would accommodate us if there are any changes we would require (e.g. login via salsa instead of a fedora account). At minimum we would need a way to map from release-monitoring.org package names to Debian source package names. Assuming they use Fedora source package names, then the Repology service provides such a mapping and we could presumably could get a periodic export of that. release-monitoring.org has the ability to configure distribution-specific names for each package. Take for example pycurl, which has mappings for Fedora, Alpine, and Timesys: https://release-monitoring.org/project/7973/ It appears there are 314 packages that already have Debian mappings. Scott
Re: Using release-monitoring.org [was: uscan roadmap]
On Thu, 2021-12-02 at 15:57 +0100, Stephan Lachnit wrote: > I think this would be the best path forward - it would probably be not > easy given that it changes entirely how the current system works, but > it might be well worth the effort. Working together with another > distribution would share the work for the distro. I'm sure if we are > willing to join them they would accommodate us if there are any > changes we would require (e.g. login via salsa instead of a fedora > account). At minimum we would need a way to map from release-monitoring.org package names to Debian source package names. Assuming they use Fedora source package names, then the Repology service provides such a mapping and we could presumably could get a periodic export of that. > This however I think is not a good idea. Repology is very nice to > check what versions other distros have, but for projects that don't > have any external language-specific package repository like e.g. > python, it would mean that we could easily miss a new release (think > small projects written in C that are not in any other distro) and > wrongly formatted version from other distros would impact us > (unlikely, but still bad in theory). I see using Repology as a complement to release-monitoring.org and uscan, not as an alternative to them. It enables use-cases that aren't possible with the other two. We automatically get version monitoring for packages that don't have other version monitoring mechanisms. We get monitoring of whether or not a particular package needs updating to a VCS snapshot instead of waiting for an official release. We get monitoring of versions even when upstream has moved to a different location not monitored by other mechanisms. There are probably other use-cases I can't think of right now. > And since it requires the same infrastructure changes as going with > release-monitoring.org, it would be better to just use that. I think it would need different changes, especially since Debian doesn't have the same realtime notifications stuff as Fedora does. > Yes that makes sense, what I wonder is how much change is needed for > putting watch files in a separate repo compared to going with > release-monitoring.org (I don't know enough about the inner workings > of our tools to answer this question). For the VCS idea it would be minimal, just vcswatch needs to also pull debian/watch files out of VCS repos with commits not yet pushed to Debian and then the version checking infra (zero idea where that went) needs to pay attention to that data. For fully moving debian/watch (and Homepage) out of Debian source packages there would need to be a lot more work, probably migrating to release-monitoring.org would be the way to go. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Using release-monitoring.org [was: uscan roadmap]
On Thu, Dec 2, 2021 at 12:51 AM Paul Wise wrote: > > It might be a idea to look at how other distributions do checking for > new upstream releases and adopt some of their improvements. > > I note Fedora uses a service (that isn't Fedora specific) for this: > > https://release-monitoring.org > https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring/ I think this would be the best path forward - it would probably be not easy given that it changes entirely how the current system works, but it might be well worth the effort. Working together with another distribution would share the work for the distro. I'm sure if we are willing to join them they would accommodate us if there are any changes we would require (e.g. login via salsa instead of a fedora account). > Another idea would be to use the Repology service to notice when other > distros include a newer version of a package than Debian does. > > https://repology.org/ This however I think is not a good idea. Repology is very nice to check what versions other distros have, but for projects that don't have any external language-specific package repository like e.g. python, it would mean that we could easily miss a new release (think small projects written in C that are not in any other distro) and wrongly formatted version from other distros would impact us (unlikely, but still bad in theory). And since it requires the same infrastructure changes as going with release-monitoring.org, it would be better to just use that. > I also wonder if it is time to split debian/watch out of Debian source > packages, since upstream download locations generally change > independently of the Debian package and so information about upstream > download locations probably should be maintained independently. Yes that makes sense, what I wonder is how much change is needed for putting watch files in a separate repo compared to going with release-monitoring.org (I don't know enough about the inner workings of our tools to answer this question). Anyway, if using release-monitoring.org is too much work or nobody is willing to do it, I like the proposals for version 5 so far. Regards, Stephan
