Fwd: ERROR: unexpected value 'go' for plc4x in http://plc4x.apache.org/plc4x-doap.rdf
Changes were made to project doap processing and now I get spammed with errors once a day. Please fix this asap or I’ll have to unsubscribe to site-...@apache.org! Why is a Comdev process sending errors there? Best, Dave Sent from my iPhone Begin forwarded message: > From: Projects > Date: September 8, 2023 at 7:10:37 PM PDT > To: Site Development > Subject: ERROR: unexpected value 'go' for plc4x in > http://plc4x.apache.org/plc4x-doap.rdf > Reply-To: site-...@apache.org > > ERROR: unexpected value 'go' for plc4x in > http://plc4x.apache.org/plc4x-doap.rdf
Re: [jira] [Updated] (COMDEV-436) parsereleases produces false releases for solr
Desubscribe
> Am 08.09.2023 um 21:34 schrieb Jan Høydahl :
>
>
> [
> https://issues.apache.org/jira/browse/COMDEV-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Jan Høydahl updated COMDEV-436:
> ---
>Description:
> When viewing [https://projects.apache.org/releases.html] and searching for
> "solr", there are too many "falase positives".
>
> See the "solr" section of
> [https://projects.apache.org/json/foundation/releases.json]
> {code:java}
> "solr": {
> "all.yaml": "2021-11-11",
> "index.yaml": "2021-11-11",
> "solr-0.5.0": "2021-11-11",
> "solr-0.5.0.tgz.prov": "2021-11-11",
> "solr-operator-0.5.0": "2021-11-11",
> "solr-operator-0.5.0.tgz.prov": "2021-11-11",
> "solr-operator-v0.5.0": "2021-11-11",
> "solrbackups.yaml": "2021-11-11",
> "solrclouds.yaml": "2021-11-11",
> "solrprometheusexporters.yaml": "2021-11-11",
> "zookeeperclusters.yaml": "2021-11-11"
> },
> {code}
> The script mistakes some files as releases, which are really not.
>
> Currently the Solr downloads repo [https://downloads.apache.org/solr/]
> contains only one release for the "solr-opereator" project, which is not a
> traditional java code release, but rather k8s Helm-charts and CRDs. The Solr
> main releases are currently in "lucene" so we don't expect them to show up
> here until the 9.0 release.
>
> So the expected output for the current contents is simply:
> {code:java}
>"solr": {
> "solr-operator-0.5.0": "2021-11-11",
> },
> {code}
>
> was:
> See the "solr" section of
> [https://projects.apache.org/json/foundation/releases.json]
> {code:java}
> "solr": {
> "all.yaml": "2021-11-11",
> "index.yaml": "2021-11-11",
> "solr-0.5.0": "2021-11-11",
> "solr-0.5.0.tgz.prov": "2021-11-11",
> "solr-operator-0.5.0": "2021-11-11",
> "solr-operator-0.5.0.tgz.prov": "2021-11-11",
> "solr-operator-v0.5.0": "2021-11-11",
> "solrbackups.yaml": "2021-11-11",
> "solrclouds.yaml": "2021-11-11",
> "solrprometheusexporters.yaml": "2021-11-11",
> "zookeeperclusters.yaml": "2021-11-11"
> },
> {code}
> The script mistakes some files as releases, which are really not.
>
> Currently the Solr downloads repo [https://downloads.apache.org/solr/]
> contains only one release for the "solr-opereator" project, which is not a
> traditional java code release, but rather k8s Helm-charts and CRDs. The Solr
> main releases are currently in "lucene" so we don't expect them to show up
> here until the 9.0 release.
>
> So the expected output for the current contents is simply:
> {code:java}
>"solr": {
> "solr-operator-0.5.0": "2021-11-11",
> },
> {code}
>
>
>> parsereleases produces false releases for solr
>> --
>>
>>Key: COMDEV-436
>>URL: https://issues.apache.org/jira/browse/COMDEV-436
>>Project: Community Development
>> Issue Type: Improvement
>> Reporter: Jan Høydahl
>> Priority: Major
>>Attachments: COMDEV-436.patch, releases.json
>>
>>
>> When viewing [https://projects.apache.org/releases.html] and searching for
>> "solr", there are too many "falase positives".
>> See the "solr" section of
>> [https://projects.apache.org/json/foundation/releases.json]
>> {code:java}
>> "solr": {
>> "all.yaml": "2021-11-11",
>> "index.yaml": "2021-11-11",
>> "solr-0.5.0": "2021-11-11",
>> "solr-0.5.0.tgz.prov": "2021-11-11",
>> "solr-operator-0.5.0": "2021-11-11",
>> "solr-operator-0.5.0.tgz.prov": "2021-11-11",
>> "solr-operator-v0.5.0": "2021-11-11",
>> "solrbackups.yaml": "2021-11-11",
>> "solrclouds.yaml": "2021-11-11",
>> "solrprometheusexporters.yaml": "2021-11-11",
>> "zookeeperclusters.yaml": "2021-11-11"
>> },
>> {code}
>> The script mistakes some files as releases, which are really not.
>> Currently the Solr downloads repo [https://downloads.apache.org/solr/]
>> contains only one release for the "solr-opereator" project, which is not a
>> traditional java code release, but rather k8s Helm-charts and CRDs. The Solr
>> main releases are currently in "lucene" so we don't expect them to show up
>> here until the 9.0 release.
>> So the expected output for the current contents is simply:
>> {code:java}
>>"solr": {
>> "solr-operator-0.5.0": "2021-11-11",
>> },
>> {code}
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.20.10#820010)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
-
To unsubscr
[jira] [Updated] (COMDEV-436) parsereleases produces false releases for solr
[
https://issues.apache.org/jira/browse/COMDEV-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated COMDEV-436:
---
Description:
When viewing [https://projects.apache.org/releases.html] and searching for
"solr", there are too many "falase positives".
See the "solr" section of
[https://projects.apache.org/json/foundation/releases.json]
{code:java}
"solr": {
"all.yaml": "2021-11-11",
"index.yaml": "2021-11-11",
"solr-0.5.0": "2021-11-11",
"solr-0.5.0.tgz.prov": "2021-11-11",
"solr-operator-0.5.0": "2021-11-11",
"solr-operator-0.5.0.tgz.prov": "2021-11-11",
"solr-operator-v0.5.0": "2021-11-11",
"solrbackups.yaml": "2021-11-11",
"solrclouds.yaml": "2021-11-11",
"solrprometheusexporters.yaml": "2021-11-11",
"zookeeperclusters.yaml": "2021-11-11"
},
{code}
The script mistakes some files as releases, which are really not.
Currently the Solr downloads repo [https://downloads.apache.org/solr/] contains
only one release for the "solr-opereator" project, which is not a traditional
java code release, but rather k8s Helm-charts and CRDs. The Solr main releases
are currently in "lucene" so we don't expect them to show up here until the 9.0
release.
So the expected output for the current contents is simply:
{code:java}
"solr": {
"solr-operator-0.5.0": "2021-11-11",
},
{code}
was:
See the "solr" section of
[https://projects.apache.org/json/foundation/releases.json]
{code:java}
"solr": {
"all.yaml": "2021-11-11",
"index.yaml": "2021-11-11",
"solr-0.5.0": "2021-11-11",
"solr-0.5.0.tgz.prov": "2021-11-11",
"solr-operator-0.5.0": "2021-11-11",
"solr-operator-0.5.0.tgz.prov": "2021-11-11",
"solr-operator-v0.5.0": "2021-11-11",
"solrbackups.yaml": "2021-11-11",
"solrclouds.yaml": "2021-11-11",
"solrprometheusexporters.yaml": "2021-11-11",
"zookeeperclusters.yaml": "2021-11-11"
},
{code}
The script mistakes some files as releases, which are really not.
Currently the Solr downloads repo [https://downloads.apache.org/solr/] contains
only one release for the "solr-opereator" project, which is not a traditional
java code release, but rather k8s Helm-charts and CRDs. The Solr main releases
are currently in "lucene" so we don't expect them to show up here until the 9.0
release.
So the expected output for the current contents is simply:
{code:java}
"solr": {
"solr-operator-0.5.0": "2021-11-11",
},
{code}
> parsereleases produces false releases for solr
> --
>
> Key: COMDEV-436
> URL: https://issues.apache.org/jira/browse/COMDEV-436
> Project: Community Development
> Issue Type: Improvement
>Reporter: Jan Høydahl
>Priority: Major
> Attachments: COMDEV-436.patch, releases.json
>
>
> When viewing [https://projects.apache.org/releases.html] and searching for
> "solr", there are too many "falase positives".
> See the "solr" section of
> [https://projects.apache.org/json/foundation/releases.json]
> {code:java}
> "solr": {
> "all.yaml": "2021-11-11",
> "index.yaml": "2021-11-11",
> "solr-0.5.0": "2021-11-11",
> "solr-0.5.0.tgz.prov": "2021-11-11",
> "solr-operator-0.5.0": "2021-11-11",
> "solr-operator-0.5.0.tgz.prov": "2021-11-11",
> "solr-operator-v0.5.0": "2021-11-11",
> "solrbackups.yaml": "2021-11-11",
> "solrclouds.yaml": "2021-11-11",
> "solrprometheusexporters.yaml": "2021-11-11",
> "zookeeperclusters.yaml": "2021-11-11"
> },
> {code}
> The script mistakes some files as releases, which are really not.
> Currently the Solr downloads repo [https://downloads.apache.org/solr/]
> contains only one release for the "solr-opereator" project, which is not a
> traditional java code release, but rather k8s Helm-charts and CRDs. The Solr
> main releases are currently in "lucene" so we don't expect them to show up
> here until the 9.0 release.
> So the expected output for the current contents is simply:
> {code:java}
> "solr": {
> "solr-operator-0.5.0": "2021-11-11",
> },
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
[jira] [Commented] (COMDEV-436) parsereleases produces false releases for solr
[
https://issues.apache.org/jira/browse/COMDEV-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17763231#comment-17763231
]
Jan Høydahl commented on COMDEV-436:
Uploaded a patch [^COMDEV-436.patch]
I ran the patched script locally and got the attached [^releases.json] file as
result, and it looks good. Solr section looks like
{code:java}
"solr": {
"solr-0.7.1": "2023-07-17",
"solr-9.3.0": "2023-07-17",
"solr-9.3.0-slim": "2023-07-17",
"solr-operator-0.7.1": "2023-07-17",
"solr-operator-v0.7.1": "2023-07-17"
} {code}
It's a bit sad that "solr-0.7.1" (solr helm chart) has the same prefix as the
main solr release.
Also, we have both a "solr-operator-0.7.1" (helm chart) and
"solr-operator-v0.7.1" (operator binaries). Not much to do with it unless there
is some hierarchy in the JSON and some standard way of detecting file types.
But the input of the script is simply a bunch of download folders and files, so
not easy,
> parsereleases produces false releases for solr
> --
>
> Key: COMDEV-436
> URL: https://issues.apache.org/jira/browse/COMDEV-436
> Project: Community Development
> Issue Type: Improvement
>Reporter: Jan Høydahl
>Priority: Major
> Attachments: COMDEV-436.patch, releases.json
>
>
> See the "solr" section of
> [https://projects.apache.org/json/foundation/releases.json]
> {code:java}
> "solr": {
> "all.yaml": "2021-11-11",
> "index.yaml": "2021-11-11",
> "solr-0.5.0": "2021-11-11",
> "solr-0.5.0.tgz.prov": "2021-11-11",
> "solr-operator-0.5.0": "2021-11-11",
> "solr-operator-0.5.0.tgz.prov": "2021-11-11",
> "solr-operator-v0.5.0": "2021-11-11",
> "solrbackups.yaml": "2021-11-11",
> "solrclouds.yaml": "2021-11-11",
> "solrprometheusexporters.yaml": "2021-11-11",
> "zookeeperclusters.yaml": "2021-11-11"
> },
> {code}
> The script mistakes some files as releases, which are really not.
> Currently the Solr downloads repo [https://downloads.apache.org/solr/]
> contains only one release for the "solr-opereator" project, which is not a
> traditional java code release, but rather k8s Helm-charts and CRDs. The Solr
> main releases are currently in "lucene" so we don't expect them to show up
> here until the 9.0 release.
> So the expected output for the current contents is simply:
> {code:java}
> "solr": {
> "solr-operator-0.5.0": "2021-11-11",
> },
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
[jira] [Updated] (COMDEV-436) parsereleases produces false releases for solr
[
https://issues.apache.org/jira/browse/COMDEV-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated COMDEV-436:
---
Attachment: releases.json
> parsereleases produces false releases for solr
> --
>
> Key: COMDEV-436
> URL: https://issues.apache.org/jira/browse/COMDEV-436
> Project: Community Development
> Issue Type: Improvement
>Reporter: Jan Høydahl
>Priority: Major
> Attachments: COMDEV-436.patch, releases.json
>
>
> See the "solr" section of
> [https://projects.apache.org/json/foundation/releases.json]
> {code:java}
> "solr": {
> "all.yaml": "2021-11-11",
> "index.yaml": "2021-11-11",
> "solr-0.5.0": "2021-11-11",
> "solr-0.5.0.tgz.prov": "2021-11-11",
> "solr-operator-0.5.0": "2021-11-11",
> "solr-operator-0.5.0.tgz.prov": "2021-11-11",
> "solr-operator-v0.5.0": "2021-11-11",
> "solrbackups.yaml": "2021-11-11",
> "solrclouds.yaml": "2021-11-11",
> "solrprometheusexporters.yaml": "2021-11-11",
> "zookeeperclusters.yaml": "2021-11-11"
> },
> {code}
> The script mistakes some files as releases, which are really not.
> Currently the Solr downloads repo [https://downloads.apache.org/solr/]
> contains only one release for the "solr-opereator" project, which is not a
> traditional java code release, but rather k8s Helm-charts and CRDs. The Solr
> main releases are currently in "lucene" so we don't expect them to show up
> here until the 9.0 release.
> So the expected output for the current contents is simply:
> {code:java}
> "solr": {
> "solr-operator-0.5.0": "2021-11-11",
> },
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
[jira] [Updated] (COMDEV-436) parsereleases produces false releases for solr
[
https://issues.apache.org/jira/browse/COMDEV-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated COMDEV-436:
---
Attachment: COMDEV-436.patch
> parsereleases produces false releases for solr
> --
>
> Key: COMDEV-436
> URL: https://issues.apache.org/jira/browse/COMDEV-436
> Project: Community Development
> Issue Type: Improvement
>Reporter: Jan Høydahl
>Priority: Major
> Attachments: COMDEV-436.patch
>
>
> See the "solr" section of
> [https://projects.apache.org/json/foundation/releases.json]
> {code:java}
> "solr": {
> "all.yaml": "2021-11-11",
> "index.yaml": "2021-11-11",
> "solr-0.5.0": "2021-11-11",
> "solr-0.5.0.tgz.prov": "2021-11-11",
> "solr-operator-0.5.0": "2021-11-11",
> "solr-operator-0.5.0.tgz.prov": "2021-11-11",
> "solr-operator-v0.5.0": "2021-11-11",
> "solrbackups.yaml": "2021-11-11",
> "solrclouds.yaml": "2021-11-11",
> "solrprometheusexporters.yaml": "2021-11-11",
> "zookeeperclusters.yaml": "2021-11-11"
> },
> {code}
> The script mistakes some files as releases, which are really not.
> Currently the Solr downloads repo [https://downloads.apache.org/solr/]
> contains only one release for the "solr-opereator" project, which is not a
> traditional java code release, but rather k8s Helm-charts and CRDs. The Solr
> main releases are currently in "lucene" so we don't expect them to show up
> here until the 9.0 release.
> So the expected output for the current contents is simply:
> {code:java}
> "solr": {
> "solr-operator-0.5.0": "2021-11-11",
> },
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
[jira] [Created] (COMDEV-535) parsereleases.py should not always strip -parent- from names
Sebb created COMDEV-535: --- Summary: parsereleases.py should not always strip -parent- from names Key: COMDEV-535 URL: https://issues.apache.org/jira/browse/COMDEV-535 Project: Community Development Issue Type: Bug Components: Reporter Tool Reporter: Sebb parsereleases.py currently replaces -parent- with '-' when classifying releases. This is not always appropriate. For example: netbeans/netbeans/19/netbeans-19-source.zip becomes netbeans-19, which is fine, but netbeans/netbeans-parent/netbeans-parent-4/netbeans-parent-4-source-release.zip becomes netbeans-4, which is not Similarly for Commons and Maven. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
[jira] [Commented] (COMDEV-425) Reporter tool's "Busiest GitHub topics" is missing "lucene" for Lucene project
[
https://issues.apache.org/jira/browse/COMDEV-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17763144#comment-17763144
]
Jan Høydahl commented on COMDEV-425:
I had a look at the reporter scripts and found
[kibble.py|http://svn.apache.org/viewvc/comdev/reporter.apache.org/trunk/scripts/rapp/kibble.py?view=markup]
which seems to have a regex bug, including all github repos with same prefix,
e.g lucene matches lucenenet. Uploaded a patch in [^COMDEV-425.patch]
> Reporter tool's "Busiest GitHub topics" is missing "lucene" for Lucene project
> --
>
> Key: COMDEV-425
> URL: https://issues.apache.org/jira/browse/COMDEV-425
> Project: Community Development
> Issue Type: Bug
> Components: Reporter Tool
>Reporter: Michael McCandless
>Priority: Minor
> Attachments: COMDEV-425.patch, Screen Shot 2021-09-09 at 5.34.16
> PM.png, Screen Shot 2021-10-21 at 8.55.58 AM.png,
> image-2021-10-21-08-56-15-016.png, lucene-kibble.png
>
>
> I am working on the quarterly board report for Apache Lucene, and noticed
> under the "Community Health" section that the "Busiest GitHub topics" seems
> to be missing the "lucene" GitHub repository.
> It seems to contain only {{lucene-solr}}, {{lucenenet}}, {{lucene-site}}.
> Likely something needs to be updated because Solr split out of Lucene, and
> Lucene's main (to be 9.0 release soon) branch is on a new(-ish) {{lucene}}
> repository: [https://github.com/apache/lucene]
> !Screen Shot 2021-09-09 at 5.34.16 PM.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
[jira] [Commented] (COMDEV-425) Reporter tool's "Busiest GitHub topics" is missing "lucene" for Lucene project
[
https://issues.apache.org/jira/browse/COMDEV-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17763142#comment-17763142
]
Jan Høydahl commented on COMDEV-425:
I filed PR [https://github.com/apache/comdev-projects/pull/3] - not for the
reporter but similar bug in bottom of
[https://projects.apache.org/committee.html?lucene] where lucenenet repos show
up.
> Reporter tool's "Busiest GitHub topics" is missing "lucene" for Lucene project
> --
>
> Key: COMDEV-425
> URL: https://issues.apache.org/jira/browse/COMDEV-425
> Project: Community Development
> Issue Type: Bug
> Components: Reporter Tool
>Reporter: Michael McCandless
>Priority: Minor
> Attachments: COMDEV-425.patch, Screen Shot 2021-09-09 at 5.34.16
> PM.png, Screen Shot 2021-10-21 at 8.55.58 AM.png,
> image-2021-10-21-08-56-15-016.png, lucene-kibble.png
>
>
> I am working on the quarterly board report for Apache Lucene, and noticed
> under the "Community Health" section that the "Busiest GitHub topics" seems
> to be missing the "lucene" GitHub repository.
> It seems to contain only {{lucene-solr}}, {{lucenenet}}, {{lucene-site}}.
> Likely something needs to be updated because Solr split out of Lucene, and
> Lucene's main (to be 9.0 release soon) branch is on a new(-ish) {{lucene}}
> repository: [https://github.com/apache/lucene]
> !Screen Shot 2021-09-09 at 5.34.16 PM.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
[jira] [Updated] (COMDEV-425) Reporter tool's "Busiest GitHub topics" is missing "lucene" for Lucene project
[
https://issues.apache.org/jira/browse/COMDEV-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated COMDEV-425:
---
Attachment: COMDEV-425.patch
> Reporter tool's "Busiest GitHub topics" is missing "lucene" for Lucene project
> --
>
> Key: COMDEV-425
> URL: https://issues.apache.org/jira/browse/COMDEV-425
> Project: Community Development
> Issue Type: Bug
> Components: Reporter Tool
>Reporter: Michael McCandless
>Priority: Minor
> Attachments: COMDEV-425.patch, Screen Shot 2021-09-09 at 5.34.16
> PM.png, Screen Shot 2021-10-21 at 8.55.58 AM.png,
> image-2021-10-21-08-56-15-016.png, lucene-kibble.png
>
>
> I am working on the quarterly board report for Apache Lucene, and noticed
> under the "Community Health" section that the "Busiest GitHub topics" seems
> to be missing the "lucene" GitHub repository.
> It seems to contain only {{lucene-solr}}, {{lucenenet}}, {{lucene-site}}.
> Likely something needs to be updated because Solr split out of Lucene, and
> Lucene's main (to be 9.0 release soon) branch is on a new(-ish) {{lucene}}
> repository: [https://github.com/apache/lucene]
> !Screen Shot 2021-09-09 at 5.34.16 PM.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
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 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 > > >
[jira] [Resolved] (COMDEV-302) add committe short description to committees listing
[ https://issues.apache.org/jira/browse/COMDEV-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved COMDEV-302. - Resolution: Fixed Fixed in r1912197 > add committe short description to committees listing > > > Key: COMDEV-302 > URL: https://issues.apache.org/jira/browse/COMDEV-302 > Project: Community Development > Issue Type: Wish > Components: Projects Tool >Reporter: Herve Boutemy >Priority: Major > > Committees by name show a list with the name only: > https://projects.apache.org/committees.html > adding the short description would help people find info, and would also > improve the rendering (the page is quite empty with this list on the left...) -- This message was sent by Atlassian Jira (v8.20.10#820010) - 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 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: [PR] Consolidate decision-making documents, as per email on 2023-05-30 (comdev-site)
bdelacretaz commented on PR #128: URL: https://github.com/apache/comdev-site/pull/128#issuecomment-1711411156 Looks good to me, thank you! I'd just add tags to the decision making page, suggest tags: ["pmc","governance","voting"] -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
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: Drop list of languages and categories?
On Thu, 7 Sept 2023 at 10:17, sebb wrote: > > 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 canonicalise > languages and categories. Now implemented. These entries are now canonicalised (case-adjusted) and messages are sent to site-dev for unexpected entries. Once the full lists are determined, the emails can be copied to the PMCs, and the entries dropped from statistics. > On Thu, 7 Sept 2023 at 01:25, Jarek Potiuk wrote: > > > > 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 > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
