Return-Path: X-Original-To: apmail-infrastructure-dev-archive@minotaur.apache.org Delivered-To: apmail-infrastructure-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B6BDC17385 for ; Tue, 20 Jan 2015 22:48:41 +0000 (UTC) Received: (qmail 13310 invoked by uid 500); 20 Jan 2015 22:48:41 -0000 Delivered-To: apmail-infrastructure-dev-archive@apache.org Received: (qmail 13163 invoked by uid 500); 20 Jan 2015 22:48:41 -0000 Mailing-List: contact infrastructure-dev-help@apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: infrastructure-dev@apache.org Delivered-To: mailing list infrastructure-dev@apache.org Received: (qmail 13151 invoked by uid 99); 20 Jan 2015 22:48:40 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Jan 2015 22:48:40 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=10 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates 209.85.220.179 as permitted sender) Received: from [209.85.220.179] (HELO mail-vc0-f179.google.com) (209.85.220.179) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Jan 2015 22:48:36 +0000 Received: by mail-vc0-f179.google.com with SMTP id la4so5222153vcb.10 for ; Tue, 20 Jan 2015 14:48:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=4pgrD8ZY5CLLRWGsMwhubyGCbBYQ5zfv3hUzqvvzRF4=; b=trif0Xii9DhQqLlZTHAv7RF92gnTW0AaMu10mktPUA5JtW+sHMzPs5C9Ye35g2uxvL 5O+h+XtqhoJCRYaUr99IpIuEfMRfyo1OczC+TOzhMJj062+9zK8ZSbh8gTpYE7k1tDxo HjT59kHo/OED8FjZ10mXAWfoMeY71oc61cVlUjdXMUd/fxR89EcdgKb5yp1wjxPMnO9M emy/UmCC4yoUS0UpPwJ3l2OIuxuXY+/n7Dg4fruenW2ReR8ffjuZ2vccI0VPnE99M55E UrGedUy093JvSEs9UlvOWjI3U9N6rxXMufv6hTpw1wiSqySctv10aQlIwE6FKfqr+os/ KUTg== MIME-Version: 1.0 X-Received: by 10.52.253.234 with SMTP id ad10mr15368777vdd.54.1421794096399; Tue, 20 Jan 2015 14:48:16 -0800 (PST) Received: by 10.52.36.174 with HTTP; Tue, 20 Jan 2015 14:48:16 -0800 (PST) In-Reply-To: References: <4E0AE711-6F64-434C-86C9-A9811FC729D6@toolazydogs.com> <60F650F7-DEC5-4922-BC52-1D35092941CD@toolazydogs.com> <99E03293-38A7-45C6-8E59-6C39B6066733@toolazydogs.com> <412025A4-8FB0-44AE-9D2F-74DE9BA27E17@toolazydogs.com> <27CE4081-5F33-40E3-AC0F-F7823E3197BE@toolazydogs.com> <45FDAEE3-8701-4BA3-B3C3-57A7A7DDE6E1@toolazydogs.com> <933D3493-8B77-44F3-A76F-C7C80328DFAB@toolazydogs.com> Date: Tue, 20 Jan 2015 22:48:16 +0000 Message-ID: Subject: Re: Brooklyn not in http://people.apache.org/committers-by-project.html From: sebb To: "infrastructure-dev@apache.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On 20 January 2015 at 21:12, Alan D. Cabrera wrote: > >> On Jan 20, 2015, at 1:00 PM, David Nalley wrote: >> >> On Tue, Jan 20, 2015 at 3:14 PM, Alan D. Cabrera > wrote: >>> >>>> On Jan 20, 2015, at 12:04 PM, David Nalley wrote: >>>> >>>> On Tue, Jan 20, 2015 at 3:01 PM, Alan D. Cabrera wrote: >>>>> >>>>>> On Jan 20, 2015, at 11:56 AM, David Nalley wrote: >>>>>> >>>>>> On Tue, Jan 20, 2015 at 2:50 PM, Alan D. Cabrera > wrote: >>>>>>> >>>>>>>> On Jan 20, 2015, at 11:31 AM, jan i wrote: >>>>>>>> >>>>>>>> On 20 January 2015 at 20:22, Alan D. Cabrera > wrote: >>>>>>>> >>>>>>>>> >>>>>>>>>> On Jan 20, 2015, at 11:19 AM, jan i wrote: >>>>>>>>>> >>>>>>>>>> On 20 January 2015 at 20:12, Alan D. Cabrera >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Jan 20, 2015, at 11:08 AM, sebb wrote: >>>>>>>>>>>> >>>>>>>>>>>> On 20 January 2015 at 18:12, Alan D. Cabrera >>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On Jan 20, 2015, at 10:08 AM, David Nalley w= rote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is there a reason it needs to be added? >>>>>>>>>>>>> >>>>>>>>>>>>> That seems like an odd question and I would turn it around an= d ask, is >>>>>>>>>>> there a reason why it shouldn=E2=80=99t? >>>>>>>>>>>>> >>>>>>>>>>>>>> IIRC that page is derived from the authorization file for SV= N - >>>>>>>>>>>> >>>>>>>>>>>> Yes >>>>>>>>>>>> >>>>>>>>>>>>>> Brooklyn doesn't use svn, so no listing. >>>>>>>>>>>> >>>>>>>>>>>> It does not *need* an entry in asf-auth, but one can be provid= ed. >>>>>>>>>>>> >>>>>>>>>>>>> Time to fix the tooling=E2=80=A6 :) Where=E2=80=99s the code= that generates those >>>>>>>>>>> pages? >>>>>>>>>>>> >>>>>>>>>>>> The tooling is not broken. >>>>>>>>>>>> >>>>>>>>>>>> There is currently no readily accessible data defining the mem= bers of >>>>>>>>>>>> the Brooklyn podling. >>>>>>>>>>>> >>>>>>>>>>>> Once a podling graduates, it will have an LDAP group. >>>>>>>>>>> >>>>>>>>>>> Then what about all the other podlings that are on this page? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Documentation for podlings says you should update that file, so = I did it >>>>>>>>>> for corinthia even though we use git, and it worked nicely. >>>>>>>>> >>>>>>>>> What file are you speaking of? >>>>>>>>> >>>>>>>> >>>>>>>> this one >>>>>>>> https://svn.apache.org/repos/infra/infrastructure/trunk/subversion= /authorization/asf-authorization-template >>>>>>>> >>>>>>>> Search for "bookkeeper=3Dbreed" >>>>>>>> >>>>>>>> You need to add brooklyn after that line. Commit the file and the = rest >>>>>>>> happens automatically within 24 hours (people.a.o is updated with = a cron >>>>>>>> job). >>>>>>> >>>>>>> Is there a corresponding authorization file for git? >>>>>>> >>>>>> >>>>>> No >>>>>> Git authorization is much more coarse. >>>>>> tl;dr - we parse the name of the repo before the first delimiter and >>>>>> look for a PMC in LDAP by that name and see if the committer is a >>>>>> member of that LDAP group. >>>>> >>>>> By PMC I think you mean project, correct? But I=E2=80=99m not sure i= f podlings are in LDAP. >>>>> >>>> >>>> No. >>>> I meant PMC >>>> Podlings are not projects in the top level sense, and have no entry in= LDAP. >>> >>> So for podlings it=E2=80=99s all incubator committers, as Jan said in a= nother email? >>> >> >> Correct. >> >>> The podling committer membership and PPMC membership information seems = to be spread around if at all. Does it make sense to create LDAP groups fo= r them to provide a canonical source? >>> >> >> In my experience, podlings don't do a good job of keeping up with the >> data that needs to be stored in so many locations. >> (Their website, their status file, the svn auth file). Adding yet >> another place to keep up with things seems the wrong direction to >> head. > > I=E2=80=99m hearing a description of all the complicated things that occu= r because we don=E2=80=99t put podling membership information in LDAP. What complicated things? > We can simplify that, that=E2=80=99s a tooling issue. > there=E2=80=99s no requirement to have membership information in a websit= e and if there is it should be auto generated from LDAP anyway > the status file should be auto generated from LDAP anyway > the svn auth file should be pulling info from LDAP and does do that for n= on-podlings Not every group in the SVN auth file is in LDAP >> Presumably if we added an LDAP group for the podling we'd also need to >> add a PPMC group for the podling as well. No, I don't think that would be required. Or a good thing, because PPMCs are not PMCs. > > Yes, and that would be a good thing. It would be more work for Infra and the podling. There is no distinction between PPMC and podling committers. This only occurs once the podling graduates. >> I am also not sure that it gives a lot of advantages, and I know it >> adds overhead, overhead that can currently only be dealt with by a PMC >> Chair. With that said, what problem are we actually trying to solve? > > The problem that there is no source for PPMC membership at all and that p= odling membership is implicitly managed in an SVN auth file. The source is the SVN auth file. > Frankly, I=E2=80=99m surprised that I=E2=80=99m getting pushback in putti= ng podling group information in LDAP. It would be more work overall. The LDAP group would have to be created (and then deleted if the podling does not graduate). And the group would still have to be maintained by someone. It's no harder to update the SVN auth file than to update LDAP. Indeed I would say it is simpler. And it's obvious who is already in the gr= oup. > > Regards, > Alan > > >