community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: DOAP futures (ASF project metadata)
Date Fri, 08 Mar 2019 23:17:31 GMT
Hi -

> On Mar 6, 2019, at 4:51 AM, Shane Curcuru <> wrote:
> Bertrand Delacretaz wrote on 3/5/19 7:23 AM:
>> Hi,
>> On Tue, Mar 5, 2019 at 1:16 PM Mark Cox <> wrote:
>>> ... So before investing too more time into this, I wanted to find out if
>>> there's been any real attempt or plan or investigation to replace the DOAP
>>> files within ASF with something else....
> ...snip...
>> It might take some initial effort to consolidate that data and fix the
>> software that uses it but I think it's well worth it. Considering that
>> this is infrastructure related, we might ask for funding for this
>> initial cleanup task as I'm not sure we'll get there with volunteer
>> energy only.
> Indeed, centralizing project (including podling) metadata - somehow! -
> is a real need that we've never been able to meet.  I also support
> finding funding for this to task infra to work on it (which is a topic
> for other lists, but it's important to note it here).

I’m currently working on the podling clutch related metadata from ground truth.

Podlings.xml is a key part of this and is currently hand edited. An editing error this morning
caused Whimsy roster pages to fail. I was able to fix this quickly and the new podling caused
new error states in the incubator clutch process which I fixed.

My goal with the clutch is multiple.

(1) Improve Incubator workflows to better inform podling’s about their state wrt graduating
to become an Apache TLP.

(2) Improve the process so that all incubator state is found in the ground truth and from
adaptation to a decade old reporting structure. For example of the 51 podlings last week.
50 use gitbox yet Git was not really accommodated. provides
ground truth on all Apache git repositories.

I would certainly like to be involved …


> Key design criteria:
> - Easy to maintain the whole system.
> - Easy to consume for all users - whimsy especially (since other places
> rely on that), the www.a.o website, *plus* external consumers who might
> want to scrape our project universe.
> - Easy for projects to update.  In particular, having Maven,
> Cocoon/Forrest, GitHub plugins to auto-generate needed data is key; we
> can't ask all projects with existing widely-used tooling to have to add
> unusual steps to their release processes.

As much data as possible should be found in the state of our systems.
For example we should be able to create a download json for a release by examining the svn
for <>.

> Presuming board/ops/infra make this a real project (i.e. funding and
> timeline), where should the design discussion happen?

> -- 
> - Shane
>  Director & Member
>  The Apache Software Foundation
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message