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 18:07:52 GMT
On 22 January 2015 at 18:54, Alan D. Cabrera <adc@toolazydogs.com> wrote:

>
> > On Jan 22, 2015, at 9:36 AM, jan i <jani@apache.org> wrote:
> >
> > On 22 January 2015 at 18:04, Alan D. Cabrera <adc@toolazydogs.com
> <mailto:adc@toolazydogs.com>> wrote:
> >
> >>
> >>> On Jan 22, 2015, at 8:14 AM, sebb <sebbaz@gmail.com> wrote:
> >>>
> >>> On 22 January 2015 at 15:52, Alan D. Cabrera <adc@toolazydogs.com>
> >> wrote:
> >>>>
> >>>>> On Jan 22, 2015, at 7:34 AM, sebb <sebbaz@gmail.com> wrote:
> >>>>>
> >>>>> 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.
> >>>>
> >>>> I am espousing for the creation of a new OU, i.e. Podlings.
> >>>
> >>> It would still require changes to LDAP and Infra processes.
> >>
> >> Changes in LDAP, of course, but these are new orthogonal changes.
> Changes
> >> to Infra processes, yes, but we are cleaning technical debt here and so
> >> that’s to be expected.  The change is not burdensome.
> >>
> >>>>> However if my suggestion of adding -ppmc entries to asf-auth is
> >>>>> acceptable to Infra, then this can be implemented very quickly.
> >>>>
> >>>> What is this asf-auth file? Is it the subversion authorization file?
> >>>
> >>> Yes.
> >>>
> >>> As noted else-thread that is how Corinthia committers are documented.
> >>
> >> Pointing to a prior use of a bad practice is not itself a justification
> of
> >> the bad practice.
> >>
> >
> > Why not make a step by step approach, looking at the mail is is obvious
> > that a LDAP change right now misses:
> > - backing from infra
> > - backing from the IPMC chair (who would need at least for a while to do
> > the job)
> > - a discussion if a REST API is so secure that Infra will allow it (to be
> > honest I would not)
> > - the tools that use the REST API.
> >
> > It is a lot more than just collecting the data.
> >
> > as Sebb suggested we can expand the svn-auth file, it is not perfect but
> it
> > collects the information PPMC and committer in one place. Once that is
> done
> > we could have a longer discussion on
> > - which information should in general be appended to LDAP (and do we want
> > LDAP to be our central repository for committer data)
> > - if yes, can we allow a REST API that updates LDAP, and how to make it
> > secure
>
>
> If you want to put PPMC and committer information in a Subversion
> authorization file, I can’t stop you.  What worries me, other than it is a
> bad practice, is that we’re simply adding more technical debt that needs to
> be undone; you guys are already using it as an excuse to not move to LDAP.
>
> But please, I am totally baffled by the pushback on putting this
> information in LDAP.  This is not rocket science and there’s not a lot of
> refactoring that needs to be done to get us in a good place.
>
I do not understand you are baffled, I among others have raised concern
about "just" doing it (not having it as a goal), and you really need to
address those concerns. All I have read it that you will assemble the data
and make sure we get a REST API, but how about the implications, the
discussions needed.

Lets assume  you had all the data ready tomorrow, it would not work because
the tooling is not ready and more importantly we have not agreed on the
tooling.

I like the idea of using LDAP for all this information, but I am also aware
that it is not a change we do over a weekend, it need to be discussed in a
lot more detail.

rgds
jan i.

>
>
> Regards,
> Alan
>
>
>

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