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 release

Re: ASF Project Stats for Lucene

Thanks Mike! Looks like the conversation went cold a while back. I'll ping on the Jira issue again to see if there's a way we can make progress. > Is it only Lucene project affected by this? Not sure. That's a good question! > We can always fallback to workarounds to compute stats for our quarte

[jira] [Commented] (COMDEV-302) add committe short description to committees listing

[ https://issues.apache.org/jira/browse/COMDEV-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762911#comment-17762911 ] Sebb commented on COMDEV-302: - Note that search works quite well to find projects > add comm

[jira] [Resolved] (COMDEV-528) Retired projects in DOAP list

[ https://issues.apache.org/jira/browse/COMDEV-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved COMDEV-528. - Resolution: Fixed These projects are now shown as being in the Attic > Retired projects in DOAP list > -

[jira] [Resolved] (COMDEV-328) Don't publish second-hand json files

[ https://issues.apache.org/jira/browse/COMDEV-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved COMDEV-328. - Resolution: Fixed > Don't publish second-hand json files > > >

Re: projects.a.o "maintainer" field

On Thu, 7 Sept 2023 at 18:19, Craig Russell wrote: > > I think projects would just put as the name and dev@project... as > the mail address. But there is already a mail-list field so it seems > redundant. > > So I agree that we should drop "maintainer". Agreed; it can be dropped from the creat

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

Not all DOAP fields are useful!

The DOAP create page includes several fields that I think have limited (if any use). This makes it harder for projects to use the page, so unless a field is genuinely useful, I think it should be dropped. There are several fields which are not available elsewhere, and should be considered essenti

Re: [PR] Consolidate decision-making documents, as per email on 2023-05-30 (comdev-site)

rbowen merged PR #128: URL: https://github.com/apache/comdev-site/pull/128 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@community.apa

Re: Proposal: Consolidate the various pages about voting/deciding

On Tue, 2023-05-30 at 15:45 -0400, rbo...@rcbowen.com wrote: > Proposal: Consolidate the various pages about voting/deciding See https://github.com/apache/comdev-site/pull/128 - To unsubscribe, e-mail: dev-unsubscr...@community.

[PR] Consolidate decision-making documents, as per email on 2023-05-30 (comdev-site)

rbowen opened a new pull request, #128: URL: https://github.com/apache/comdev-site/pull/128 As per email on 2023-05-30, subject line "Proposal: Consolidate the various pages about voting/deciding", which was agreed to by consensus. Proceeding based on that agreement. Adds redirects f

Re: projects.a.o "maintainer" field

Listing the PMC seems reasonable when I think about external tools consuming this information. We shouldn't assume knowledge of our default process IMO. Gary On Thu, Sep 7, 2023, 1:13 PM wrote: > With some attention on projects.a.o at the moment, I'd like to raise > the subject of the "maintain

Re: projects.a.o "maintainer" field

I think projects would just put as the name and dev@project... as the mail address. But there is already a mail-list field so it seems redundant. So I agree that we should drop "maintainer". Craig > On Sep 7, 2023, at 10:08, rbo...@rcbowen.com wrote: > > With some attention on projects.a.o at

projects.a.o "maintainer" field

With some attention on projects.a.o at the moment, I'd like to raise the subject of the "maintainer" field in the DOAP files. That field doesn't make sense in ASF-style projects. The "maintainer" is always going to be the project's PMC. I came across a few DOAP files that listed an individual name

Re: Valid languages for projects.apache.org

I agree too. Mxml has been around for sometime but it is specific to certain PMCs and is more a file format like Yaml. I wonder more about how we classify projects and project product based on whether or not the system consists of components and/or a service. Language makes more sense for descr

Re: Valid languages for projects.apache.org

I agree with Sebb, MXML is an XML _vocabulary_. Gary On Thu, Sep 7, 2023, 9:55 AM sebb wrote: > On Thu, 7 Sept 2023 at 13:36, Andrew Wetmore wrote: > > > > Apache Royale uses significant numbers of MXML files in applications. Is > > that sufficiently different from XML that we should add it? >

Re: Valid categories for projects.apache.org

I've already written about it in one of the previous talks - I think that we can have a good approximation of categories from the "Community Over Code". Except few language-specific categories there (Groovy which is clearly cut by "language" not category) pretty much tracks there are pretty nice

Re: Valid languages for projects.apache.org

On Thu, 7 Sept 2023 at 13:36, Andrew Wetmore wrote: > > Apache Royale uses significant numbers of MXML files in applications. Is > that sufficiently different from XML that we should add it? AFAICT MXML is a domain-specific superset of XML. I don't think that deserves a separate language category

Re: Valid languages for projects.apache.org

Apache Royale uses significant numbers of MXML files in applications. Is that sufficiently different from XML that we should add it? Virus-free.www.avast.com

Valid categories for projects.apache.org

As for languages, some DOAPs currently contain categories that don't agree with the current valid list. The outliers are: data-management-platform distributed-sql-database education ftp geospatial graphics hadoop IDE identity-management identity-provisioning integration Kerberos observability SDK

Re: Valid languages for projects.apache.org

ODBC and JDBC are APIs, not languages, I hope we can all agree on that. The "L" in XML and SQL stand for Language, so... ;-) Gary On Thu, Sep 7, 2023, 7:24 AM sebb wrote: > There are currently a few project DOAPs which use languages not in the > current valid list. > > These are: > > BASH/Bas

Valid languages for projects.apache.org

There are currently a few project DOAPs which use languages not in the current valid list. These are: BASH/Bash Freemarker Haxe JDBC ODBC SQL XML Whilst we could add Bash, we might then need to add all the other Shell languages. Freemarker is a templating language; could be added Haxe is a valid

Re: ASF Project Stats for Lucene

Hi Greg, I finally found the issue opened long ago to get to the bottom of this: https://issues.apache.org/jira/browse/COMDEV-425 See also this COMDEV list discussion: https://lists.apache.org/thread/6rsr8v982fjqgyopprqzw057cpzfnz3z It looks like Apache Kibble is somehow needing reconfiguration

Re: Drop list of languages and categories?

The duplicated copies of the lists have been replaced with a single JSON file: https://projects.apache.org/validation.json There is also a script to process that plus the list of committees into create.html: scripts/update_create.py The intention is to use the JSON file to validate and canonicali