www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <j...@apache.org>
Subject Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Date Thu, 22 Jan 2015 14:57:02 GMT
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 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.


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).

rgds
jan i

>
>
> Regards,
> Alan
>
>
>

-- 
Sent from My iPad, sorry for any misspellings.

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