Re: RFC: many PMCs have not provided DOAPs
On Tue, Sep 5, 2023 at 6:45 PM wrote: > On Tue, 2023-09-05 at 17:19 +0100, sebb wrote: > > I doubt it will ever be possible to ensure that fields like releases > > are kept up to date. > > It appears that we have *some* projects that update the doap file as > part of their release runbook. But, yeah, not all of them. > Wicket does it as part of the site generation: This file in our git repository: https://github.com/apache/wicket-site/blob/asf-site/doap.rdf Gets transformed by jekyll into this for publishing: https://wicket.apache.org/doap.rdf So whenever we update the site for a new release, the doap and atom RSS feed get updated as well. Martijn
Re: RFC: many PMCs have not provided DOAPs
We just added DOAP for airflow (core project) and I am planning to add release information for it automatically as well now when I see it working. I have a question about good practices though, before I make the next step - which is automating generation of all the DOAPs of ours. In the Apache Airflow PMC we are regularly releasing ~ 90 packages. Almost all of them come from the same monorepo and are technically separate artifacts / releases and they have their own releases (each of the packages follows SemVer versioning and they versioning is independent in each package). I believe the idea of DOAP is that if a PMC releases more than one project, each of them should have its own DOAP? So I am thinking about adding (automatically) DOAPs for all the ~90 packages (we have airflow core + airflow providers). Is that a good idea ? I believe it will inflate and impact the total numbers (out of the sudden, Python will become the strong second in the pie-chart here https://projects.apache.org/ and we will have almost 90 "Apache Airflow Provider " projects in the various lists produced by ` projects.apache.org" - pretty much dominating some categories (you can see all the provider packages we release here: https://airflow.apache.org/docs/#providers-packagesdocsapache-airflow-providersindexhtml ) Is that something that we consider as "good practice" and expected to happen in this case? Will that cause problems for anyone ? J. On Wed, Sep 6, 2023 at 9:32 AM Martijn Dashorst wrote: > On Tue, Sep 5, 2023 at 6:45 PM wrote: > > > On Tue, 2023-09-05 at 17:19 +0100, sebb wrote: > > > I doubt it will ever be possible to ensure that fields like releases > > > are kept up to date. > > > > It appears that we have *some* projects that update the doap file as > > part of their release runbook. But, yeah, not all of them. > > > > Wicket does it as part of the site generation: > > This file in our git repository: > https://github.com/apache/wicket-site/blob/asf-site/doap.rdf > > Gets transformed by jekyll into this for publishing: > https://wicket.apache.org/doap.rdf > > So whenever we update the site for a new release, the doap and atom RSS > feed get updated as well. > > Martijn >
Re: RFC: many PMCs have not provided DOAPs
On Wed, 6 Sept 2023 at 09:13, Jarek Potiuk wrote: > > We just added DOAP for airflow (core project) and I am planning to add > release information for it automatically as well now when I see it working. > > I have a question about good practices though, before I make the next step > - which is automating generation of all the DOAPs of ours. > > In the Apache Airflow PMC we are regularly releasing ~ 90 packages. Almost > all of them come from the same monorepo and are technically separate > artifacts / releases and they have their own releases (each of the packages > follows SemVer versioning and they versioning is independent in each > package). > > I believe the idea of DOAP is that if a PMC releases more than one project, > each of them should have its own DOAP? If they are independent products - i.e. can be used independently - then I would say yes. However if they are effectively part of the same product then it is less clear. So for example Commons components can all be used independently and have individual DOAPs Likewise HttpComponents. I'm not sure why HTTPServer singles out mod_ftp; I'm not sure it would be useful to include all the add-on HTTP modules. > So I am thinking about adding (automatically) DOAPs for all the ~90 > packages (we have airflow core + airflow providers). Is that a good idea ? Seems to me that individual providers are a level of detail that are best documented within the project itself. The purpose of the site is to provide information about ASF projects. Would it help the general public to have all these extra details? However it might make sense to add a generic provider DOAP that describes the role that providers play in the ecosystem. > I believe it will inflate and impact the total numbers (out of the sudden, > Python will become the strong second in the pie-chart here > https://projects.apache.org/ and we will have almost 90 "Apache Airflow > Provider " projects in the various lists produced by ` > projects.apache.org" - pretty much dominating some categories (you can see > all the provider packages we release here: > https://airflow.apache.org/docs/#providers-packagesdocsapache-airflow-providersindexhtml > ) > > Is that something that we consider as "good practice" and expected to > happen in this case? Will that cause problems for anyone ? No and yes ;-} > J. > > > On Wed, Sep 6, 2023 at 9:32 AM Martijn Dashorst > wrote: > > > On Tue, Sep 5, 2023 at 6:45 PM wrote: > > > > > On Tue, 2023-09-05 at 17:19 +0100, sebb wrote: > > > > I doubt it will ever be possible to ensure that fields like releases > > > > are kept up to date. > > > > > > It appears that we have *some* projects that update the doap file as > > > part of their release runbook. But, yeah, not all of them. > > > > > > > Wicket does it as part of the site generation: > > > > This file in our git repository: > > https://github.com/apache/wicket-site/blob/asf-site/doap.rdf > > > > Gets transformed by jekyll into this for publishing: > > https://wicket.apache.org/doap.rdf > > > > So whenever we update the site for a new release, the doap and atom RSS > > feed get updated as well. > > > > Martijn > > - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: RFC: many PMCs have not provided DOAPs
Thanks Sebb. Very useful/much appreciated. > If they are independent products - i.e. can be used independently - then I would say yes. Nope. They are "extensions" of the "core" airflow. You cannot use them without "some" version of airflow installed as well. > Seems to me that individual providers are a level of detail that are best documented within the project itself. Agree > However it might make sense to add a generic provider DOAP that describes the role that providers play in the ecosystem. I like that idea. Less hassle, less "entities" to worry about and we anyhow release them together in "bulk". Question: I see that we have "Release name" in releases that could allow us to group all releases for the same providers. Maybe it would be a good idea to make some "artifact identifier" not only name ? Or maybe the "name" is not really something that is used anyway and we could repurpose it for the provider name - for example "Apache Airflow Provider Google" for example for all "Google provider" releases? One worry I have is about the sorting order when releases will be displayed on the "projects" page - it would be grouped if they could be put together and we could see all the releases of a provider together - rather than all of them mixed together. J. On Wed, Sep 6, 2023 at 12:29 PM sebb wrote: > On Wed, 6 Sept 2023 at 09:13, Jarek Potiuk wrote: > > > > We just added DOAP for airflow (core project) and I am planning to add > > release information for it automatically as well now when I see it > working. > > > > I have a question about good practices though, before I make the next > step > > - which is automating generation of all the DOAPs of ours. > > > > In the Apache Airflow PMC we are regularly releasing ~ 90 packages. > Almost > > all of them come from the same monorepo and are technically separate > > artifacts / releases and they have their own releases (each of the > packages > > follows SemVer versioning and they versioning is independent in each > > package). > > > > I believe the idea of DOAP is that if a PMC releases more than one > project, > > each of them should have its own DOAP? > > If they are independent products - i.e. can be used independently - > then I would say yes. > > However if they are effectively part of the same product then it is less > clear. > > So for example Commons components can all be used independently and > have individual DOAPs > Likewise HttpComponents. > I'm not sure why HTTPServer singles out mod_ftp; I'm not sure it would > be useful to include all the add-on HTTP modules. > > > So I am thinking about adding (automatically) DOAPs for all the ~90 > > packages (we have airflow core + airflow providers). Is that a good idea > ? > > Seems to me that individual providers are a level of detail that are > best documented within the project itself. > > The purpose of the site is to provide information about ASF projects. > Would it help the general public to have all these extra details? > > However it might make sense to add a generic provider DOAP that > describes the role that providers play in the ecosystem. > > > I believe it will inflate and impact the total numbers (out of the > sudden, > > Python will become the strong second in the pie-chart here > > https://projects.apache.org/ and we will have almost 90 "Apache Airflow > > Provider " projects in the various lists produced by ` > > projects.apache.org" - pretty much dominating some categories (you can > see > > all the provider packages we release here: > > > https://airflow.apache.org/docs/#providers-packagesdocsapache-airflow-providersindexhtml > > ) > > > > Is that something that we consider as "good practice" and expected to > > happen in this case? Will that cause problems for anyone ? > > No and yes > ;-} > > > > J. > > > > > > On Wed, Sep 6, 2023 at 9:32 AM Martijn Dashorst < > martijn.dasho...@gmail.com> > > wrote: > > > > > On Tue, Sep 5, 2023 at 6:45 PM wrote: > > > > > > > On Tue, 2023-09-05 at 17:19 +0100, sebb wrote: > > > > > I doubt it will ever be possible to ensure that fields like > releases > > > > > are kept up to date. > > > > > > > > It appears that we have *some* projects that update the doap file as > > > > part of their release runbook. But, yeah, not all of them. > > > > > > > > > > Wicket does it as part of the site generation: > > > > > > This file in our git repository: > > > https://github.com/apache/wicket-site/blob/asf-site/doap.rdf > > > > > > Gets transformed by jekyll into this for publishing: > > > https://wicket.apache.org/doap.rdf > > > > > > So whenever we update the site for a new release, the doap and atom RSS > > > feed get updated as well. > > > > > > Martijn > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
Incorrect categories in DOAPs
I've just noticed that there are some DOAPs using rather odd categories. For example 'C', 'PHP', 'Groovy', 'SQL'. Seems to me that these are languages, not categories. I think these should be disallowed as categories; they just clutter the category listings and distort the statistics. WDYT? Sebb - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Incorrect categories in DOAPs
On Wed, 2023-09-06 at 11:53 +0100, sebb wrote: > I've just noticed that there are some DOAPs using rather odd > categories. > > For example 'C', 'PHP', 'Groovy', 'SQL'. > > Seems to me that these are languages, not categories. > > I think these should be disallowed as categories; they just clutter > the category listings and distort the statistics. > > WDYT? +1 - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: RFC: many PMCs have not provided DOAPs
Perhaps if we used the information in these files to drive creation of the board report templates in whimsy, projects would have some stronger incentive to keep them up to date? Or ... maybe we do that already? I'm not sure though because for example we provide https://git-wip-us.apache.org/repos/asf/lucene.git"/> Yet whimsy's reports on number of commits for the Lucene project doesn't seem to be observing that repo, but rather some other ones. On Tue, Sep 5, 2023 at 12:21 PM sebb wrote: > > On Tue, 5 Sept 2023 at 16:28, wrote: > > > > On Tue, 2023-09-05 at 17:11 +0200, Martijn Dashorst wrote: > > > I think a lot of DOAP files may be out of date as well. At least for > > > Wicket > > > we have moved our site SCM from svn to git a long time ago, but > > > didn't > > > realise that project.a.o needed updating. > > > > > > Suffice to say, Wicket has had several (major and minor) releases > > > since > > > 2015-02-02... > > > > Hmm. Isn't that information available somewhere else, without having to > > manually update a file? > > > > But, yeah, this is a great point. Thanks for mentioning it. > > The DOAP syntax allows for a lot of data that is better stored elsewhere. > > The bits that are unique to the DOAP are less likely to change, for example: > - pmc > - short and long description > - language(s) > - category(ies) > - homepage > - standard(s) if any > > I think these are the most important from the point of view of showing > the range of projects at the ASF and enabling people to find a project > that suits their interests and skills. > > I doubt it will ever be possible to ensure that fields like releases > are kept up to date. > It should be possible to get an idea of releases from the distribution > repo (though the file naming can make that a bit of a challenge!) > > Likewise the SVM and download URLs should be readily available from > the homepage. > > > > --Rich > > > > - > > 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 > - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Incorrect categories in DOAPs
+1 śr., 6 wrz 2023, 14:03 użytkownik napisał: > On Wed, 2023-09-06 at 11:53 +0100, sebb wrote: > > I've just noticed that there are some DOAPs using rather odd > > categories. > > > > For example 'C', 'PHP', 'Groovy', 'SQL'. > > > > Seems to me that these are languages, not categories. > > > > I think these should be disallowed as categories; they just clutter > > the category listings and distort the statistics. > > > > WDYT? > > > +1 > > > - > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
Drop list of languages and categories?
It's a bit of a pain to maintain two copies of the lists of languages and categories. Seems to me that the pages https://projects.apache.org/categories.html https://projects.apache.org/languages.html don't provide anything that is not available from the drop-down list on the DOAP creation form. I think they should be dropped. Sebb - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: RFC: many PMCs have not provided DOAPs
On Wed, 6 Sept 2023 at 13:51, Michael Sokolov wrote: > > Perhaps if we used the information in these files to drive creation of > the board report templates in whimsy, projects would have some > stronger incentive to keep them up to date? Or ... maybe we do that > already? I'm not sure though because for example we provide > > > > rdf:resource="https://git-wip-us.apache.org/repos/asf/lucene.git"/> > > > > Yet whimsy's reports on number of commits for the Lucene project > doesn't seem to be observing that repo, but rather some other ones. Whimsy does not report on commit counts. Perhaps you mean reporter? > On Tue, Sep 5, 2023 at 12:21 PM sebb wrote: > > > > On Tue, 5 Sept 2023 at 16:28, wrote: > > > > > > On Tue, 2023-09-05 at 17:11 +0200, Martijn Dashorst wrote: > > > > I think a lot of DOAP files may be out of date as well. At least for > > > > Wicket > > > > we have moved our site SCM from svn to git a long time ago, but > > > > didn't > > > > realise that project.a.o needed updating. > > > > > > > > Suffice to say, Wicket has had several (major and minor) releases > > > > since > > > > 2015-02-02... > > > > > > Hmm. Isn't that information available somewhere else, without having to > > > manually update a file? > > > > > > But, yeah, this is a great point. Thanks for mentioning it. > > > > The DOAP syntax allows for a lot of data that is better stored elsewhere. > > > > The bits that are unique to the DOAP are less likely to change, for example: > > - pmc > > - short and long description > > - language(s) > > - category(ies) > > - homepage > > - standard(s) if any > > > > I think these are the most important from the point of view of showing > > the range of projects at the ASF and enabling people to find a project > > that suits their interests and skills. > > > > I doubt it will ever be possible to ensure that fields like releases > > are kept up to date. > > It should be possible to get an idea of releases from the distribution > > repo (though the file naming can make that a bit of a challenge!) > > > > Likewise the SVM and download URLs should be readily available from > > the homepage. > > > > > > > --Rich > > > > > > - > > > 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 > > > > - > 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: RFC: many PMCs have not provided DOAPs
hm, whatever it is that populates the data we get that helps to seed board reports. Sorry, maybe that's reporter? On Wed, Sep 6, 2023 at 9:13 AM sebb wrote: > > On Wed, 6 Sept 2023 at 13:51, Michael Sokolov wrote: > > > > Perhaps if we used the information in these files to drive creation of > > the board report templates in whimsy, projects would have some > > stronger incentive to keep them up to date? Or ... maybe we do that > > already? I'm not sure though because for example we provide > > > > > > > > > rdf:resource="https://git-wip-us.apache.org/repos/asf/lucene.git"/> > > > > > > > > Yet whimsy's reports on number of commits for the Lucene project > > doesn't seem to be observing that repo, but rather some other ones. > > Whimsy does not report on commit counts. > Perhaps you mean reporter? > > > On Tue, Sep 5, 2023 at 12:21 PM sebb wrote: > > > > > > On Tue, 5 Sept 2023 at 16:28, wrote: > > > > > > > > On Tue, 2023-09-05 at 17:11 +0200, Martijn Dashorst wrote: > > > > > I think a lot of DOAP files may be out of date as well. At least for > > > > > Wicket > > > > > we have moved our site SCM from svn to git a long time ago, but > > > > > didn't > > > > > realise that project.a.o needed updating. > > > > > > > > > > Suffice to say, Wicket has had several (major and minor) releases > > > > > since > > > > > 2015-02-02... > > > > > > > > Hmm. Isn't that information available somewhere else, without having to > > > > manually update a file? > > > > > > > > But, yeah, this is a great point. Thanks for mentioning it. > > > > > > The DOAP syntax allows for a lot of data that is better stored elsewhere. > > > > > > The bits that are unique to the DOAP are less likely to change, for > > > example: > > > - pmc > > > - short and long description > > > - language(s) > > > - category(ies) > > > - homepage > > > - standard(s) if any > > > > > > I think these are the most important from the point of view of showing > > > the range of projects at the ASF and enabling people to find a project > > > that suits their interests and skills. > > > > > > I doubt it will ever be possible to ensure that fields like releases > > > are kept up to date. > > > It should be possible to get an idea of releases from the distribution > > > repo (though the file naming can make that a bit of a challenge!) > > > > > > Likewise the SVM and download URLs should be readily available from > > > the homepage. > > > > > > > > > > --Rich > > > > > > > > - > > > > 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 > > > > > > > - > > 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 > - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
ASF Project Stats for Lucene
Hello- While looking through the ASF Project Stats dashboard for Lucene, I noticed that metrics around commit, PR and issue activity seem incorrect. It looks like it's possibly observing the apache/lucenenet GitHub project instead of apache/lucene. Is there a good way to go about fixing this? Is this the right group to reach out to? Here's the dashboard I'm referencing: https://reporter.apache.org/wizard/statistics?lucene Cheers, -Greg
Re: Drop list of languages and categories?
Fully Agree. I looked at those when I recently learned about DOAP and I hoped they will give some more information, yet all my hope was gone when I looked at them. J, On Wed, Sep 6, 2023 at 3:09 PM sebb wrote: > It's a bit of a pain to maintain two copies of the lists of languages > and categories. > > Seems to me that the pages > https://projects.apache.org/categories.html > https://projects.apache.org/languages.html > don't provide anything that is not available from the drop-down list > on the DOAP creation form. > > I think they should be dropped. > > Sebb > > - > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
