You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@community.apache.org by Mark Cox <mj...@apache.org> on 2019/03/05 12:16:30 UTC
DOAP futures (ASF project metadata)
Last year I worked with DOAP maintainers on some new security related
fields. My plan was to get ASF projects to publish useful metadata around
where to get security policies, contacts, and lists of errata in their DOAP
files. I think this is useful for vendors who use Apache projects in
their products, projects being used as dependencies to others, as well as
all the security industry that have their own incomplete databases. It
also means we could make pages like
https://apache.org/security/projects.html automated.
The more I looked into it however the more RDF seemed like something no one
else really cares about anymore. And while adding a "security contact" to
the projects DOAP files that have a dedicated address is easy, we'd also
have to get every other projects DOAP file updated with the default.
Outside of Apache some folks are recommending the use of security.txt
(mostly website reporting) or security.md files (github mostly) but neither
are what I'm looking for and this is an area we can lead by example.
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. I see the scripts get fixed from
time to time when they break, and new projects are still encouraged to make
them, and the PR folks have liked the ability to create lists of projects
that specify certain keywords, but I've not found any discussion about them
in general. Any pointers appreciated, or contact with people also
interested in project metadata!
Regards, Mark
ASF Security
Re: DOAP futures (ASF project metadata)
Posted by Dave Fisher <da...@comcast.net>.
Hi -
> On Mar 6, 2019, at 4:51 AM, Shane Curcuru <as...@shanecurcuru.org> wrote:
>
> Bertrand Delacretaz wrote on 3/5/19 7:23 AM:
>> Hi,
>>
>> On Tue, Mar 5, 2019 at 1:16 PM Mark Cox <mj...@apache.org> 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. Gitbox.apache.org/repositories.json provides ground truth on all Apache git repositories.
I would certainly like to be involved …
Regards,
Dave
>
> 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 dist.apache.org <http://dist.apache.org/>.
>
> Presuming board/ops/infra make this a real project (i.e. funding and
> timeline), where should the design discussion happen?
Regards,
Dave
>
> --
>
> - Shane
> Director & Member
> The Apache Software Foundation
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
Re: DOAP futures (ASF project metadata)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Mar 6, 2019 at 1:52 PM Shane Curcuru <as...@shanecurcuru.org> wrote:
> ...Presuming board/ops/infra make this a real project (i.e. funding and
> timeline), where should the design discussion happen?...
My preference is here and we can use
https://issues.apache.org/jira/projects/COMDEV for tracking and
https://cwiki.apache.org/confluence/display/COMDEV/ComDev+Wiki for
requirements etc. if needed.
As you mention, I have suggested allocating some ASF budget to help
with the operational aspects of this, it will take a few weeks until
we know more, but as always if someone wants to start hacking that's
cool.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: DOAP futures (ASF project metadata)
Posted by Shane Curcuru <as...@shanecurcuru.org>.
Bertrand Delacretaz wrote on 3/5/19 7:23 AM:
> Hi,
>
> On Tue, Mar 5, 2019 at 1:16 PM Mark Cox <mj...@apache.org> 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).
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.
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: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: DOAP futures (ASF project metadata)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Tue, Mar 5, 2019 at 1:16 PM Mark Cox <mj...@apache.org> 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....
I don't know of any concrete plans besides
https://issues.apache.org/jira/browse/INCUBATOR-231 which touches this
for incubating projects, but I think there's a real need for
consolidating project metadata to avoid duplication.
It looks like Whimsy is using YAML data from
http://svn.apache.org/repos/asf/incubator/public/trunk/content/podlings/
for podlings but I don't see why that should be separate from
projects, a podling is just a project with a "podling" state or
something.
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.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org