www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Date Thu, 22 Jan 2015 15:34:43 GMT
AIUI PPMCs have no legal status within the ASF.

If LDAP committee entries are created for them, then the tooling needs
to be adjusted to cater for this.
There is other data that really needs to go into LDAP as well.
AIUI changing LDAP structure is not trivial so ideally all the changes
need to be done at once.

However if my suggestion of adding -ppmc entries to asf-auth is
acceptable to Infra, then this can be implemented very quickly.

The podling status files can then be updated to point to the extracted
data on people.a.o or whimsy as appropriate.

There will then be a single source of the data (the asf-auth file).

That would (I think) be a worthwhile improvement on the current situation.

If access to the asf-auth file is provided via a REST API then it
won't matter if the data is later moved into LDAP, as the API
implementation can just be changed.

This would also be a useful test of the REST API.
Any teething problems would only affect non-critical applications.

On 22 January 2015 at 15:04, Alan Cabrera <list@toolazydogs.com> wrote:
>> On Jan 22, 2015, at 6:57 AM, jan i <jani@apache.org> wrote:
>>> On Thursday, January 22, 2015, Alan D. Cabrera <adc@toolazydogs.com> wrote:
>>>> On Jan 22, 2015, at 4:45 AM, sebb <sebbaz@gmail.com <javascript:;>>
>>> wrote:
>>>> On 22 January 2015 at 12:20, jan i <jani@apache.org <javascript:;>
>>> <mailto:jani@apache.org <javascript:;>>> wrote:
>>>>> On Thursday, January 22, 2015, sebb <sebbaz@gmail.com <javascript:;>>
>>> wrote:
>>>>>> On 21 January 2015 at 17:42, Alan D. Cabrera <list@toolazydogs.com
>>> <javascript:;>
>>>>>> <javascript:;>> wrote:
>>>>>>>> On Jan 21, 2015, at 1:54 AM, Daniel Gruno <humbedooh@apache.org
>>> <javascript:;>
>>>>>> <javascript:;>> 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
>>>>>> and I
>>>>>>>>> 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
>>> meaning
>>>>>> we
>>>>>>>>> move a task and the incubator chair needs to agree to
>>>>>>>>> If incubator agrees on this approach then I assume David
>>> 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
>>>>>> working authorization/authenication scheme, which is a moot point
>>>>>> 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
>>>>>>>> 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
>>> if
>>>>>> a resolution conflicts with LDAP
>>>>>>>> - We would have to import all the previously established
>>> 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
>>> 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
>>>>>> 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”
>>>>>> symptomatic of the problem caused by not putting podling committer
>>> PPMC
>>>>>> information in LDAP.  The current mechanism of capturing podling
>>>>>> 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
>>>>>> 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
>>> 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
>>>>>> 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
>>>>>> they would be in the same place.
>>>>>> Much easier to see whether the lists are correct.
>>>>> +1 would be nice if the podling status pages could also use this
>>>>> information, so PPMC do not need to maintain multiple places.
>>>> Note that the existing podling status pages don't seem to have a
>>>> standard format for the PPMC members.
>>>> So updating them from other sources is likely to be tricky. Or indeed
>>>> extracting the information.
>>>> Maybe if that issue were fixed there would be no need to involve
>>>> changes to Infra processes or data.
>>> Status files have a use, being able to scrape information form those HTML
>>> files are not one of them.  That is a very, very, poor practice.
>>> No, ultimately those files should be automagically be generated from
>>> canonical sources of data, removing yet another source of data that needs
>>> to be maintained.
>> Yes but please do not forget the biggest problem with LDAP remain
>> undiscussed. Do we really want to make a system where mentors/PPMC cannot
>> make updates, but need to go through IPMC. chair or infra (this is the case
>> with ldap and not likely to change).
> You bring up a good point. But this is a tooling problem and one that can easily be solved
by wrapping up the management of all these groups in a rest API. This API can be accessed
by a variety of tools including whimsy.
> My general efforts here are not simple busywork. Disparate sources of data, often wildly
inconsistent, need to be consolidated. The consolidated, canonical, data sources need to be
put behind rest APIs where they can be accessed by a variety of tooling, including whimsy.
Once we get to this state all manner of automation is possible.
> Regards,
> Alan

View raw message