www-infrastructure-dev mailing list archives

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

> On Jan 22, 2015, at 3:09 AM, sebb <sebbaz@gmail.com> wrote:
> On 21 January 2015 at 17:42, Alan D. Cabrera <list@toolazydogs.com> wrote:
>>> On Jan 21, 2015, at 1:54 AM, Daniel Gruno <humbedooh@apache.org> wrote:
>>> On 2015-01-21 09:47, jan i wrote:
>>>>> Can we all agree that we need to put this into LDAP?
>>>> I agree with you  that LDAP is the right place for such information, and
>>>> do not see so many podlings fail that it should be a major concern. However
>>>> I think a discussion on general@i.a.o is needed.
>>>> If PPMC/committers maintenance of a podling is moved to LDAP, the mentors
>>>> and/or PPMC will no longer be able to maintain it them self. The script to
>>>> update LDAP is only available to officers (chairs) and infra, meaning we
>>>> move a task and the incubator chair needs to agree to that.
>>>> If incubator agrees on this approach then I assume David (v.p. infra) will
>>>> be relatively easy to convince.
>>>> rgds
>>>> jan i
>>> Podlings are experiments, not actual projects, in as much as a podling is no
more than a sub project much like mod_ftp or the Nth commons sub-project. Are you suggesting
we add LDAP groups for all sub projects? We have LDAP (UNIX) groups for committers for the
sake of maintaining a working authorization/authenication scheme, which is a moot point for
incubator where we exercise universal commit bit.
>>> As I understand it, the sentiment seems to be "let's put it in LDAP instead of
tracking it in a file".
>>> Let's list some pros and cons for this LDAP idea as opposed to using the auth
file for tracking:
>>> Pros:
>>> - it's in LDAP instead of a text file.
>>> - it may (or may not) be easier to get a list of project members
>>> Cons:
>>> - Our current setup would be invalidated
>>> - We'd have to change our account and podling request processes
>>> - We'd have to change the graduation process significantly
>>> - The Incubator chair would have to manage all this or we would have to rework
how LDAP works
>>> - We'd have to create a new OU for this, which would mean yet more work on all
auth schemes
>>> - There would/could be disputes over what is canonical at graduation if a resolution
conflicts with LDAP
>>> - We would have to import all the previously established podlings into LDAP (this
would be no small task)
>>> - We would likely create precedence for all sub-projects to have their own LDAP
group (yet another OU?)
>>> - Unless someone from the Infra PMC steps up to do this voluntarily, it would
have an added cost of $N to do.
>>> - The auth file would have to have all its current podling auth entries changed
to LDAP.
>>> If the only reason for moving to LDAP is "I won't have to change a text file",
then I really fail to see the reason to do this.
>>> What is the actual gain here? It certainly won't make anything easier for infra.
>>> How does it in any way compare to the cost of doing such a move?
>> I understand why you’re hesitant to take this on.  You manage volunteer staff and
have a limited budget for those who are paid.  From your point of view what we have “works”
and there are higher priority items that you are responsible for getting done.
>> With that said, I would point out that your long list of “cons” is symptomatic
of the problem caused by not putting podling committer and PPMC information in LDAP.  The
current mechanism of capturing podling group information is disparate, brittle, and inconsistent.
 I don’t think that you’re claiming that the current setup is ideal; you just have to
deal with limited resources to get things done.
>> What I am proposing is that I construct a plan to get us to a better place.  I will
create the conversion scripts, LDIF files, etc. and coordinate the effort with the podlings.
 All I need is the assistance of someone w/ the privileges and the experience to review my
proposed changes.  I will do the overwhelming bulk of the work.
>> I don’t think there’s anything to lose by this proposal.  If I don’t follow
up w/ what I propose then we are simply left with our current state of affairs.  If I deliver,
we’ll be in better shape overall and things will be much more simple and consistent.
>> wdyt?
> I think there may be a much simpler solution to this.
> The podling committers are already (or can be) added to the svn-auth file.
> AIUI if  the podling group is not actually used (e.g. for SVN auth)
> then it is just ignored.
> So it seems to me it would be simple to add podling-ppmc groups to the file.
> This would probably mean a minor tweak to the scripts that generate
> the people.a.o website, and possibly also to whimsy, but the changes
> would be relatively minor.
> Assuming there is no objection from infra to adding these entries,
> then this would have the advantage of simplicity (and speed of
> implementation).
> The podling could then easily manage its committer and PPMC lists as
> they would be in the same place.
> Much easier to see whether the lists are correct.

Placing group information into the svn-auth file is a very poor practice.  It mixes concerns;
here management of a group of committers be it git or svn and actual svn permissions.  A very,
very, poor practice indeed.

The only reason that podling committers, remember some podling committers not all, are in
that file is because they are not in LDAP. 


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