Re: Centralise DOAPs?
On Fri, 8 Sept 2023 at 14:17, Peter Hunsberger wrote: > > You could standardize on website located data with something like: > > project.apache.org/doap This has long been the suggestion, as the location is unlikely to change - unlike repo URLs. > using the current data format, maybe with an extra layer of subproject in > there somewhere. > > Even if the project frequently updates the site (including that location > for some reason) it doesn't mean you have to invalidate any cache, just > stick to something like a monthly crawl of the data > > However, getting projects to do this could be an interesting exercise! Exactly. This is one reason why I suggest centralising the DOAPs. > Peter Hunsberger > > > On Fri, Sep 8, 2023 at 5:22 AM sebb wrote: > > > On Fri, 8 Sept 2023 at 10:41, Bertrand Delacretaz > > wrote: > > > > > > Hi, > > > > > > On Fri, Sep 8, 2023 at 12:26 AM sebb wrote: > > > > ...I think it would be worth considering setting up a central store > > for DOAPs... > > > > > > As we require our projects to have a website anyway, wouldn't it be > > > better to get that information from the project's homepage instead of > > > a separate file ? > > > > > > As you mention, I think it's only the fields that rarely change that > > > are actually useful: the project's description, a few useful URLs, > > > programming language, communications channel URLs, project category, > > > code repository and download URLs, that's probably all we need ? > > > > > > That info can be embedded in HTML, for example using elements, > > > Open Graph [1] maybe, with some ASF-specific extensions such as > > > og:asf:category ? > > > > > > This would put the information in a natural place for projects to > > > maintain it, and Open Graph metadata has other benefits. > > > > > > OTOH this means writing a conversion layer that, starting from a list > > > of *.apache.org subdomain names, grabs that data and converts it to a > > > format that's useful for projects.a.o. > > > > > > Another option would be to embed the current DOAP format using a > > >
Re: Centralise DOAPs?
On Fri, 2023-09-08 at 15:30 +0100, sebb wrote: > On Fri, 8 Sept 2023 at 15:10, wrote: > > > > On Thu, 2023-09-07 at 23:26 +0100, sebb wrote: > > > I think it would be worth considering setting up a central store > > > for > > > DOAPs. > > > This was suggested in the past, but was rejected, I think mainly > > > because PMCs were expecting to have to make regular updates to > > > DOAPs, > > > e.g. when releases are made, so wanted to keep them with the > > > code. > > > > > > It's a pain keeping the releases section of DOAPs up to date > > > (even if > > > they are local to code). > > > Now that there is an automated releases listing, I wonder whether > > > there is any point keeping the info in the DOAP as well? > > > > > > The rest of the fields in a DOAP rarely change, so it matters > > > less if > > > the DOAP is stored in a different repo from the code to which it > > > relates. > > > > > > If DOAPs were moved to a shared GitHub repo, I think it would be > > > much > > > easier for maintenance purposes. Some issues such as fixing an > > > incorrect repo URL or download page link could be dealt with by > > > anyone > > > with suitable karma. > > > > > > Just a thought. > > > > I'm a little torn on this one. It would certainly make it a lot > > easier > > for *me*, but at the expense of making it harder for the projects. > > How so? Just in that they'd have to go somewhere else to maintain this one piece of data, separate from the rest of their project. I agree it's not a *big* inconvenience. And also, most projects would do it once, and then never again. I may be persuaded. :) > > I would certainly like to have the ability to address some of the > > awful > > phrasing, grammar, and just bad project descriptions, without > > having to > > navigate every project's different contribution process. > > And without needing to involve the project unnecessarily. Yeah, I think I'm persuaded. Particularly if we drop the 'releases' section of projects.a.o and simply point to the projects' download pages rather than trying to duplicate data that's already maintained elsewhere. - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Centralise DOAPs?
On Fri, 8 Sept 2023 at 15:10, wrote: > > On Thu, 2023-09-07 at 23:26 +0100, sebb wrote: > > I think it would be worth considering setting up a central store for > > DOAPs. > > This was suggested in the past, but was rejected, I think mainly > > because PMCs were expecting to have to make regular updates to DOAPs, > > e.g. when releases are made, so wanted to keep them with the code. > > > > It's a pain keeping the releases section of DOAPs up to date (even if > > they are local to code). > > Now that there is an automated releases listing, I wonder whether > > there is any point keeping the info in the DOAP as well? > > > > The rest of the fields in a DOAP rarely change, so it matters less if > > the DOAP is stored in a different repo from the code to which it > > relates. > > > > If DOAPs were moved to a shared GitHub repo, I think it would be much > > easier for maintenance purposes. Some issues such as fixing an > > incorrect repo URL or download page link could be dealt with by > > anyone > > with suitable karma. > > > > Just a thought. > > I'm a little torn on this one. It would certainly make it a lot easier > for *me*, but at the expense of making it harder for the projects. How so? They would still be able to make changes by fixing a single file. And the contribution process would be much easier than it is with some projects. > We'd > also have to go back around to every project to educate about this > change, and address 100 different objections to the change Provided that we did the initial setup of the central DOAPs, we'd just have to say where the DOAPs are now located. > What would be cool is if Git had something equivalent to svn externals, > so that we could have the best of both worlds. Maybe some day, Git will > catch up to where svn was 10 years ago. ;-) I don't see how that would help. We already have a central register. Having Git externals would not help with maintenance, as it would still only allow project people to update the DOAP. > If, on the other hand, we are able to extract the frequently-changing > stuff (ie, releases) from this data, and reduce it just to the seldom- > changing stuff, as you suggest, this would be worth doing. It's not > clear to me how big a lift that is, though. > > I would certainly like to have the ability to address some of the awful > phrasing, grammar, and just bad project descriptions, without having to > navigate every project's different contribution process. And without needing to involve the project unnecessarily. > > - > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Centralise DOAPs?
On Fri, 2023-09-08 at 07:20 -0700, Dave Fisher wrote: > > > > If, on the other hand, we are able to extract the frequently- > > changing > > stuff (ie, releases) from this data, and reduce it just to the > > seldom- > > changing stuff, as you suggest, this would be worth doing. It's not > > clear to me how big a lift that is, though. > > Every release ever is at http://archive.apache.org/dist/ if it is not > there then it’s not a release. Yes, I'm aware of that. What I'm saying what's not clear is how much work is involved incorporating that information into projects.a.o - or, indeed, if we want to at all. - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Centralise DOAPs?
from mobile (sorry for typos ;) On Fri, Sep 8, 2023, 21:10 wrote: > On Thu, 2023-09-07 at 23:26 +0100, sebb wrote: > > I think it would be worth considering setting up a central store for > > DOAPs. > > This was suggested in the past, but was rejected, I think mainly > > because PMCs were expecting to have to make regular updates to DOAPs, > > e.g. when releases are made, so wanted to keep them with the code. > > > > It's a pain keeping the releases section of DOAPs up to date (even if > > they are local to code). > > Now that there is an automated releases listing, I wonder whether > > there is any point keeping the info in the DOAP as well? > > > > The rest of the fields in a DOAP rarely change, so it matters less if > > the DOAP is stored in a different repo from the code to which it > > relates. > > > > If DOAPs were moved to a shared GitHub repo, I think it would be much > > easier for maintenance purposes. Some issues such as fixing an > > incorrect repo URL or download page link could be dealt with by > > anyone > > with suitable karma. > > > > Just a thought. > > I'm a little torn on this one. It would certainly make it a lot easier > for *me*, but at the expense of making it harder for the projects. We'd > also have to go back around to every project to educate about this > change, and address 100 different objections to the change > > What would be cool is if Git had something equivalent to svn externals, > so that we could have the best of both worlds. Maybe some day, Git will > catch up to where svn was 10 years ago. ;-) > > If, on the other hand, we are able to extract the frequently-changing > stuff (ie, releases) Full information about releases already available at reporter.a.o :) from this data, and reduce it just to the seldom- > changing stuff, as you suggest, this would be worth doing. It's not > clear to me how big a lift that is, though. > > I would certainly like to have the ability to address some of the awful > phrasing, grammar, and just bad project descriptions, without having to > navigate every project's different contribution process. > > > - > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
Re: Centralise DOAPs?
Sent from my iPhone > On Sep 8, 2023, at 7:11 AM, rbo...@rcbowen.com wrote: > > On Thu, 2023-09-07 at 23:26 +0100, sebb wrote: >> I think it would be worth considering setting up a central store for >> DOAPs. >> This was suggested in the past, but was rejected, I think mainly >> because PMCs were expecting to have to make regular updates to DOAPs, >> e.g. when releases are made, so wanted to keep them with the code. >> >> It's a pain keeping the releases section of DOAPs up to date (even if >> they are local to code). >> Now that there is an automated releases listing, I wonder whether >> there is any point keeping the info in the DOAP as well? >> >> The rest of the fields in a DOAP rarely change, so it matters less if >> the DOAP is stored in a different repo from the code to which it >> relates. >> >> If DOAPs were moved to a shared GitHub repo, I think it would be much >> easier for maintenance purposes. Some issues such as fixing an >> incorrect repo URL or download page link could be dealt with by >> anyone >> with suitable karma. >> >> Just a thought. > > I'm a little torn on this one. It would certainly make it a lot easier > for *me*, but at the expense of making it harder for the projects. We'd > also have to go back around to every project to educate about this > change, and address 100 different objections to the change > > What would be cool is if Git had something equivalent to svn externals, > so that we could have the best of both worlds. Maybe some day, Git will > catch up to where svn was 10 years ago. ;-) > > If, on the other hand, we are able to extract the frequently-changing > stuff (ie, releases) from this data, and reduce it just to the seldom- > changing stuff, as you suggest, this would be worth doing. It's not > clear to me how big a lift that is, though. Every release ever is at http://archive.apache.org/dist/ if it is not there then it’s not a release. > > I would certainly like to have the ability to address some of the awful > phrasing, grammar, and just bad project descriptions, without having to > navigate every project's different contribution process. Regards, Dave > > > - > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org >
Re: Centralise DOAPs?
On Thu, 2023-09-07 at 23:26 +0100, sebb wrote: > I think it would be worth considering setting up a central store for > DOAPs. > This was suggested in the past, but was rejected, I think mainly > because PMCs were expecting to have to make regular updates to DOAPs, > e.g. when releases are made, so wanted to keep them with the code. > > It's a pain keeping the releases section of DOAPs up to date (even if > they are local to code). > Now that there is an automated releases listing, I wonder whether > there is any point keeping the info in the DOAP as well? > > The rest of the fields in a DOAP rarely change, so it matters less if > the DOAP is stored in a different repo from the code to which it > relates. > > If DOAPs were moved to a shared GitHub repo, I think it would be much > easier for maintenance purposes. Some issues such as fixing an > incorrect repo URL or download page link could be dealt with by > anyone > with suitable karma. > > Just a thought. I'm a little torn on this one. It would certainly make it a lot easier for *me*, but at the expense of making it harder for the projects. We'd also have to go back around to every project to educate about this change, and address 100 different objections to the change What would be cool is if Git had something equivalent to svn externals, so that we could have the best of both worlds. Maybe some day, Git will catch up to where svn was 10 years ago. ;-) If, on the other hand, we are able to extract the frequently-changing stuff (ie, releases) from this data, and reduce it just to the seldom- changing stuff, as you suggest, this would be worth doing. It's not clear to me how big a lift that is, though. I would certainly like to have the ability to address some of the awful phrasing, grammar, and just bad project descriptions, without having to navigate every project's different contribution process. - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Centralise DOAPs?
You could standardize on website located data with something like: project.apache.org/doap using the current data format, maybe with an extra layer of subproject in there somewhere. Even if the project frequently updates the site (including that location for some reason) it doesn't mean you have to invalidate any cache, just stick to something like a monthly crawl of the data However, getting projects to do this could be an interesting exercise! Peter Hunsberger On Fri, Sep 8, 2023 at 5:22 AM sebb wrote: > On Fri, 8 Sept 2023 at 10:41, Bertrand Delacretaz > wrote: > > > > Hi, > > > > On Fri, Sep 8, 2023 at 12:26 AM sebb wrote: > > > ...I think it would be worth considering setting up a central store > for DOAPs... > > > > As we require our projects to have a website anyway, wouldn't it be > > better to get that information from the project's homepage instead of > > a separate file ? > > > > As you mention, I think it's only the fields that rarely change that > > are actually useful: the project's description, a few useful URLs, > > programming language, communications channel URLs, project category, > > code repository and download URLs, that's probably all we need ? > > > > That info can be embedded in HTML, for example using elements, > > Open Graph [1] maybe, with some ASF-specific extensions such as > > og:asf:category ? > > > > This would put the information in a natural place for projects to > > maintain it, and Open Graph metadata has other benefits. > > > > OTOH this means writing a conversion layer that, starting from a list > > of *.apache.org subdomain names, grabs that data and converts it to a > > format that's useful for projects.a.o. > > > > Another option would be to embed the current DOAP format using a > >
Re: Centralise DOAPs?
Please don't embed in HTML, this is Metadata that should be easily consumable by external tools IMO. Gary On Fri, Sep 8, 2023, 6:28 AM Christopher wrote: > I think many projects already have their doap files on their website, do > that's not really improving anything. It doesn't make much difference > editing the fields embedded in HTML or in its own separate file. > > On Fri, Sep 8, 2023, 05:41 Bertrand Delacretaz > wrote: > > > Hi, > > > > On Fri, Sep 8, 2023 at 12:26 AM sebb wrote: > > > ...I think it would be worth considering setting up a central store for > > DOAPs... > > > > As we require our projects to have a website anyway, wouldn't it be > > better to get that information from the project's homepage instead of > > a separate file ? > > > > As you mention, I think it's only the fields that rarely change that > > are actually useful: the project's description, a few useful URLs, > > programming language, communications channel URLs, project category, > > code repository and download URLs, that's probably all we need ? > > > > That info can be embedded in HTML, for example using elements, > > Open Graph [1] maybe, with some ASF-specific extensions such as > > og:asf:category ? > > > > This would put the information in a natural place for projects to > > maintain it, and Open Graph metadata has other benefits. > > > > OTOH this means writing a conversion layer that, starting from a list > > of *.apache.org subdomain names, grabs that data and converts it to a > > format that's useful for projects.a.o. > > > > Another option would be to embed the current DOAP format using a > >
Re: Centralise DOAPs?
On Fri, 8 Sept 2023 at 11:28, Christopher wrote: > > I think many projects already have their doap files on their website, do > that's not really improving anything. It doesn't make much difference > editing the fields embedded in HTML or in its own separate file. It's useful to be able to submit the DOAP file to a validation service; that's not really possible for embedded data. > On Fri, Sep 8, 2023, 05:41 Bertrand Delacretaz > wrote: > > > Hi, > > > > On Fri, Sep 8, 2023 at 12:26 AM sebb wrote: > > > ...I think it would be worth considering setting up a central store for > > DOAPs... > > > > As we require our projects to have a website anyway, wouldn't it be > > better to get that information from the project's homepage instead of > > a separate file ? > > > > As you mention, I think it's only the fields that rarely change that > > are actually useful: the project's description, a few useful URLs, > > programming language, communications channel URLs, project category, > > code repository and download URLs, that's probably all we need ? > > > > That info can be embedded in HTML, for example using elements, > > Open Graph [1] maybe, with some ASF-specific extensions such as > > og:asf:category ? > > > > This would put the information in a natural place for projects to > > maintain it, and Open Graph metadata has other benefits. > > > > OTOH this means writing a conversion layer that, starting from a list > > of *.apache.org subdomain names, grabs that data and converts it to a > > format that's useful for projects.a.o. > > > > Another option would be to embed the current DOAP format using a > >
Re: Centralise DOAPs?
I think many projects already have their doap files on their website, do that's not really improving anything. It doesn't make much difference editing the fields embedded in HTML or in its own separate file. On Fri, Sep 8, 2023, 05:41 Bertrand Delacretaz wrote: > Hi, > > On Fri, Sep 8, 2023 at 12:26 AM sebb wrote: > > ...I think it would be worth considering setting up a central store for > DOAPs... > > As we require our projects to have a website anyway, wouldn't it be > better to get that information from the project's homepage instead of > a separate file ? > > As you mention, I think it's only the fields that rarely change that > are actually useful: the project's description, a few useful URLs, > programming language, communications channel URLs, project category, > code repository and download URLs, that's probably all we need ? > > That info can be embedded in HTML, for example using elements, > Open Graph [1] maybe, with some ASF-specific extensions such as > og:asf:category ? > > This would put the information in a natural place for projects to > maintain it, and Open Graph metadata has other benefits. > > OTOH this means writing a conversion layer that, starting from a list > of *.apache.org subdomain names, grabs that data and converts it to a > format that's useful for projects.a.o. > > Another option would be to embed the current DOAP format using a >
Re: Centralise DOAPs?
On Fri, 8 Sept 2023 at 10:41, Bertrand Delacretaz wrote: > > Hi, > > On Fri, Sep 8, 2023 at 12:26 AM sebb wrote: > > ...I think it would be worth considering setting up a central store for > > DOAPs... > > As we require our projects to have a website anyway, wouldn't it be > better to get that information from the project's homepage instead of > a separate file ? > > As you mention, I think it's only the fields that rarely change that > are actually useful: the project's description, a few useful URLs, > programming language, communications channel URLs, project category, > code repository and download URLs, that's probably all we need ? > > That info can be embedded in HTML, for example using elements, > Open Graph [1] maybe, with some ASF-specific extensions such as > og:asf:category ? > > This would put the information in a natural place for projects to > maintain it, and Open Graph metadata has other benefits. > > OTOH this means writing a conversion layer that, starting from a list > of *.apache.org subdomain names, grabs that data and converts it to a > format that's useful for projects.a.o. > > Another option would be to embed the current DOAP format using a >
Re: Centralise DOAPs?
Hi, On Fri, Sep 8, 2023 at 12:26 AM sebb wrote: > ...I think it would be worth considering setting up a central store for > DOAPs... As we require our projects to have a website anyway, wouldn't it be better to get that information from the project's homepage instead of a separate file ? As you mention, I think it's only the fields that rarely change that are actually useful: the project's description, a few useful URLs, programming language, communications channel URLs, project category, code repository and download URLs, that's probably all we need ? That info can be embedded in HTML, for example using elements, Open Graph [1] maybe, with some ASF-specific extensions such as og:asf:category ? This would put the information in a natural place for projects to maintain it, and Open Graph metadata has other benefits. OTOH this means writing a conversion layer that, starting from a list of *.apache.org subdomain names, grabs that data and converts it to a format that's useful for projects.a.o. Another option would be to embed the current DOAP format using a
Re: Centralise DOAPs?
I love this idea! +1 On Thu, Sep 7, 2023, 18:26 sebb wrote: > I think it would be worth considering setting up a central store for DOAPs. > This was suggested in the past, but was rejected, I think mainly > because PMCs were expecting to have to make regular updates to DOAPs, > e.g. when releases are made, so wanted to keep them with the code. > > It's a pain keeping the releases section of DOAPs up to date (even if > they are local to code). > Now that there is an automated releases listing, I wonder whether > there is any point keeping the info in the DOAP as well? > > The rest of the fields in a DOAP rarely change, so it matters less if > the DOAP is stored in a different repo from the code to which it > relates. > > If DOAPs were moved to a shared GitHub repo, I think it would be much > easier for maintenance purposes. Some issues such as fixing an > incorrect repo URL or download page link could be dealt with by anyone > with suitable karma. > > Just a thought. > > Sebb > > - > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
Centralise DOAPs?
I think it would be worth considering setting up a central store for DOAPs. This was suggested in the past, but was rejected, I think mainly because PMCs were expecting to have to make regular updates to DOAPs, e.g. when releases are made, so wanted to keep them with the code. It's a pain keeping the releases section of DOAPs up to date (even if they are local to code). Now that there is an automated releases listing, I wonder whether there is any point keeping the info in the DOAP as well? The rest of the fields in a DOAP rarely change, so it matters less if the DOAP is stored in a different repo from the code to which it relates. If DOAPs were moved to a shared GitHub repo, I think it would be much easier for maintenance purposes. Some issues such as fixing an incorrect repo URL or download page link could be dealt with by anyone with suitable karma. Just a thought. Sebb - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
