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 <seb...@gmail.com> wrote: > 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 > >
