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:24:17 GMT

> On Jan 22, 2015, at 4:45 AM, sebb <sebbaz@gmail.com> wrote:
> 
> On 22 January 2015 at 12:20, jan i <jani@apache.org <mailto:jani@apache.org>>
wrote:
>> On Thursday, January 22, 2015, sebb <sebbaz@gmail.com> wrote:
>> 
>>> On 21 January 2015 at 17:42, Alan D. Cabrera <list@toolazydogs.com
>>> <javascript:;>> wrote:
>>>> 
>>>>> On Jan 21, 2015, at 1:54 AM, Daniel Gruno <humbedooh@apache.org
>>> <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 information,
>>> 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 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.
>> 
>> +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.


Regards,
Alan



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