www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Date Fri, 23 Jan 2015 19:57:19 GMT

> On Jan 23, 2015, at 9:56 AM, Bertrand Delacretaz <bdelacretaz@apache.org> wrote:
> On Fri, Jan 23, 2015 at 5:00 PM, Alan D. Cabrera <list@toolazydogs.com> wrote:
>> ...At the moment, we have untold documented and undocumented processes that fiddle
>> the disparate and inconsistent set of metadata that represents the Apache Software
> You're suggesting a REST API to replace that, IMO a set of structured
> text files in a *single* svn folder combined with a validation script
> that people can apply before committing would also do the job.
> That's reasonably http-friendly and you'd just need to write the
> validation script.

I did consider that. Keeping the consolidated, canonical, non-LDAP, data in Subversion does
make sense.  Having Subversion serve up the data directly poses problems.

At my work we heavily use/used Subversion to manage our metadata for the same reasons you
mention with pre-commit hooks performing validation.  We are now in the process of ripping
much of it out; some of the reasons apply to the domain we wish to solve here.

My thinking is:

The granularity of access is complex.  We have to complex matrix of R/O and R/W permissions
for public, committer, PMC, ASF member, Board, PPMC.  Trying to fit that into Subversion files
and folder bends and rips your data in strange ways as one denormalizes data to get specific
permissions to work correctly.  Since the data gets bent and ripped the requisite pre-commit
logic gets split apart and so the security logic gets obfuscated.

Invariably one needs to read/write to something else, e.g. LDAP, etc. and keep it consistent.


View raw message