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 12:20:56 GMT
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.

rgds
jan i

>
> >
> > Regards,
> > Alan
> >
> >
> >
> >
>


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

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