Re: Centralise DOAPs?

[Christopher]

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 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.
>
> Sebb
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: ASF Project Stats for Lucene

[Greg Miller]

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 quarterly
reports, but it'd be nice if we could fix/trust reporter.apache.org!

Agreed. The workarounds aren't a big deal, but the reporter tool is trappy
since we'll just have to rely on our own sort of "tribal knowledge" to make
sure we know it can't be trusted. Hmm.

Cheers,
-Greg

On Thu, Sep 7, 2023 at 4:19 AM Michael McCandless 
wrote:

> 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 to look at
> GitHub not Subversion for its stats, but nobody seems to really know how to
> do that?  I think the issue happened on our migration from Subversion to
> GitHub (before the migration from Jira to GitHub issues).  But maybe the
> Jira -> GitHub issues migration made things even worse?
>
> We can always fallback to workarounds to compute stats for our quarterly
> reports, but it'd be nice if we could fix/trust reporter.apache.org!  Is
> it only Lucene project affected by this?
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Sep 6, 2023 at 3:29 PM Greg Miller  wrote:
>
>> 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
>>
>

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

[Sebb (Jira)]

[ 
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 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

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

[Sebb (Jira)]

 [ 
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
> -
>
> Key: COMDEV-528
> URL: https://issues.apache.org/jira/browse/COMDEV-528
> Project: Community Development
>  Issue Type: Bug
>  Components: Projects Tool
>Reporter: Claude Warren
>Priority: Minor
>
> The DOAP file  list [1] as listed the DOAP for Hivemind [2] which is a 
> retired project and the specified file has an error in it.  I believe that it 
> should be commented out as other retired projects have been.
> [1] 
> [https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects.xml]
> [2] 
> [http://svn.apache.org/repos/asf/hivemind/hivemind2/trunk/doap_Hivemind.rdf]
>  



--
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] [Resolved] (COMDEV-328) Don't publish second-hand json files

[Sebb (Jira)]

 [ 
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
> 
>
> Key: COMDEV-328
> URL: https://issues.apache.org/jira/browse/COMDEV-328
> Project: Community Development
>  Issue Type: Improvement
>  Components: PhoneBook
>Reporter: Sebb
>Priority: Major
>
> Originally, home.a.o extracted its own data files which it published in
> https://home.apache.org/public/
> However, the files there are now just copies of the ones created by Whimsy.
> It would be better to direct users to the originals.
> e.g. with a redirect?



--
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: projects.a.o "maintainer" field

[sebb]

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 create form.

If there is to be a default, it should be private@
Not all projects have a dev list; ultimately it is the PMC that is
responsible for the DOAP.

> Craig
>
> > On Sep 7, 2023, at 10:08, rbo...@rcbowen.com wrote:
> >
> > 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 in that
> > field, and that's misleading, at best.
> >
> > I'd like to drop 'maintainer' from the DOAP creation form. Are there
> > any objections to that?
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
>
> Craig L Russell
> c...@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

Centralise DOAPs?

[sebb]

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.

Sebb

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Not all DOAP fields are useful!

[sebb]

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 essential:
 Project name & PMC [needed for uniqueness and identification]
Short and long description
Categories
Programming Languages

These are all likely to be quite stable (languages might change), so
should only need to be set up once.

These should be readily available from the project website:
Bug database
Download page
Mailing lists page
SVN repository
Git repository

Experience shows that these are rarely maintained, so should probably
be dropped.
But if it is decided to keep them, there needs to be some way to check
that they are still correct.

The releases section is also a pain to maintain (and the syntax is awkward).
I'm not sure it is even needed, now that there is the Project Release Listing:
https://projects.apache.org/releases.html

Maintainer is completely unnecessary.

It might be useful to retain the Implemented standard, though it is
very rarely used.

I think simplifying the form would make it less of a chore for PMCs.

Sebb

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

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

[via GitHub]

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.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: Proposal: Consolidate the various pages about voting/deciding

[rbowen]

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.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

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

[via GitHub]

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 for the removed pages, and removes them from the site 
navigation.


-- 
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: projects.a.o "maintainer" field

[Gary Gregory]

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 "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 in that
> field, and that's misleading, at best.
>
> I'd like to drop 'maintainer' from the DOAP creation form. Are there
> any objections to that?
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: projects.a.o "maintainer" field

[Craig Russell]

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 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 in that
> field, and that's misleading, at best.
> 
> I'd like to drop 'maintainer' from the DOAP creation form. Are there
> any objections to that?
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
c...@apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

projects.a.o "maintainer" field

[rbowen]

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 in that
field, and that's misleading, at best.

I'd like to drop 'maintainer' from the DOAP creation form. Are there
any objections to that?


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Valid languages for projects.apache.org

[Dave Fisher]

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 describing components. But this a different discussion.

Best,
Dave

Sent from my iPhone

> On Sep 7, 2023, at 7:52 AM, Gary Gregory  wrote:
> 
> 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?
>> 
>> AFAICT MXML is a domain-specific superset of XML.
>> I don't think that deserves a separate language category.
>> 
>>> <
>> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
>>> 
>>> Virus-free.www.avast.com
>>> <
>> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
>>> 
>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>> 
>>> On Thu, Sep 7, 2023 at 8:31 AM Gary Gregory 
>> wrote:
>>> 
 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/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 language; could perhaps be added
> JDBC and ODBC are not languages; I think they should be dropped from
> the classification.
> SQL and XML can perhaps be considered languages
> 
> WDYT?
> 
> Sebb
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 
> 
 
>>> 
>>> 
>>> --
>>> Andrew Wetmore
>>> 
>>> Editor, Moose House Publications 
>>> Editor-Writer, The Apache Software Foundation 
>> 
>> -
>> 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: Valid languages for projects.apache.org

[Gary Gregory]

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?
>
> AFAICT MXML is a domain-specific superset of XML.
> I don't think that deserves a separate language category.
>
> > <
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> > Virus-free.www.avast.com
> > <
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >
> > On Thu, Sep 7, 2023 at 8:31 AM Gary Gregory 
> wrote:
> >
> > > 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/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 language; could perhaps be added
> > > > JDBC and ODBC are not languages; I think they should be dropped from
> > > > the classification.
> > > > SQL and XML can perhaps be considered languages
> > > >
> > > > WDYT?
> > > >
> > > > Sebb
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > > For additional commands, e-mail: dev-h...@community.apache.org
> > > >
> > > >
> > >
> >
> >
> > --
> > Andrew Wetmore
> >
> > Editor, Moose House Publications 
> > Editor-Writer, The Apache Software Foundation 
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Valid categories for projects.apache.org

[Jarek Potiuk]

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
"categories" of the software we have in the ASF - and they are "important
enough" that someone took the lead and decided to volunteer thinking that
it's worth to "carve it out" as an "entity" at Community over Code and
managed to communicate their intentions to speakers who responded to CFP
understanding what the "track category" is about.

There are few generic (Incubator, Community, Sustainability, Server Side
chat with infra) that apply to various "categories" so we can leave them out

>From the https://communityovercode.org/schedule/

* Search
* Streaming
* Big Data Storage
* Big Data Compute
* API/Microservices
* Cloud and Runtime
* Performance Engineering
* Web Servers (renamed from Tomcat and Httpd -> this is my attempt to
categorise it similarly to others rather than by names of Projects/PMCs )
* Fintech
* Data Engineering
* Content Wrangling
* Geospatial
* Frameworks
* Internet of Things

Sounds to me like a nice set of categories that seem current and even have
a chance to be regularly refreshed  - potentially we could adopt it as a
way to see if there are significant changes/new categories.

J

On Thu, Sep 7, 2023 at 1:39 PM sebb  wrote:

> 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
> search
> templating
> virtual-machine
>
> I think some of the above could be added, possibly under a more general
> heading.
> For example, graphics could make a reasonable category.
> However, distributed-sql-database and Kerberos seem too specific.
> ftp is probably part of network-client/network-server
>
> Plus the following, which are all languages.
> I think they can safely be disallowed as categories:
> C
> C++
> Go
> Groovy
> HTML
> Java
> PHP
> Python
> Regexp
> SQL
>
> Thoughts?
>
> Sebb
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Valid languages for projects.apache.org

[sebb]

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.

> 
> Virus-free.www.avast.com
> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Thu, Sep 7, 2023 at 8:31 AM Gary Gregory  wrote:
>
> > 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/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 language; could perhaps be added
> > > JDBC and ODBC are not languages; I think they should be dropped from
> > > the classification.
> > > SQL and XML can perhaps be considered languages
> > >
> > > WDYT?
> > >
> > > Sebb
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > For additional commands, e-mail: dev-h...@community.apache.org
> > >
> > >
> >
>
>
> --
> Andrew Wetmore
>
> Editor, Moose House Publications 
> Editor-Writer, The Apache Software Foundation 

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Valid languages for projects.apache.org

[Andrew Wetmore]

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

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Thu, Sep 7, 2023 at 8:31 AM Gary Gregory  wrote:

> 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/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 language; could perhaps be added
> > JDBC and ODBC are not languages; I think they should be dropped from
> > the classification.
> > SQL and XML can perhaps be considered languages
> >
> > WDYT?
> >
> > Sebb
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >
>


-- 
Andrew Wetmore

Editor, Moose House Publications 
Editor-Writer, The Apache Software Foundation 

Valid categories for projects.apache.org

[sebb]

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
search
templating
virtual-machine

I think some of the above could be added, possibly under a more general heading.
For example, graphics could make a reasonable category.
However, distributed-sql-database and Kerberos seem too specific.
ftp is probably part of network-client/network-server

Plus the following, which are all languages.
I think they can safely be disallowed as categories:
C
C++
Go
Groovy
HTML
Java
PHP
Python
Regexp
SQL

Thoughts?

Sebb

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Valid languages for projects.apache.org

[Gary Gregory]

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/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 language; could perhaps be added
> JDBC and ODBC are not languages; I think they should be dropped from
> the classification.
> SQL and XML can perhaps be considered languages
>
> WDYT?
>
> Sebb
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Valid languages for projects.apache.org

[sebb]

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 language; could perhaps be added
JDBC and ODBC are not languages; I think they should be dropped from
the classification.
SQL and XML can perhaps be considered languages

WDYT?

Sebb

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: ASF Project Stats for Lucene

[Michael McCandless]

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 to look at
GitHub not Subversion for its stats, but nobody seems to really know how to
do that?  I think the issue happened on our migration from Subversion to
GitHub (before the migration from Jira to GitHub issues).  But maybe the
Jira -> GitHub issues migration made things even worse?

We can always fallback to workarounds to compute stats for our quarterly
reports, but it'd be nice if we could fix/trust reporter.apache.org!  Is it
only Lucene project affected by this?

Mike McCandless

http://blog.mikemccandless.com


On Wed, Sep 6, 2023 at 3:29 PM Greg Miller  wrote:

> 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?

[sebb]

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.

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