On Wed, 6 Sept 2023 at 09:13, Jarek Potiuk <ja...@potiuk.com> 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 <something>" 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 <rbo...@rcbowen.com> 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
