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 246A61783E for ; Thu, 22 Jan 2015 15:53:45 +0000 (UTC) Received: (qmail 68890 invoked by uid 500); 22 Jan 2015 15:53:45 -0000 Delivered-To: apmail-infrastructure-dev-archive@apache.org Received: (qmail 68763 invoked by uid 500); 22 Jan 2015 15:53:45 -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 68752 invoked by uid 99); 22 Jan 2015 15:53:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Jan 2015 15:53:44 +0000 X-ASF-Spam-Status: No, hits=0.3 required=10 tests=RCVD_IN_DNSWL_LOW,SPF_SOFTFAIL X-Spam-Check-By: apache.org Received-SPF: softfail (athena.apache.org: transitioning domain of adc@toolazydogs.com does not designate 209.85.192.181 as permitted sender) Received: from [209.85.192.181] (HELO mail-pd0-f181.google.com) (209.85.192.181) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Jan 2015 15:53:39 +0000 Received: by mail-pd0-f181.google.com with SMTP id g10so2315278pdj.12 for ; Thu, 22 Jan 2015 07:52:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :mime-version:subject:message-id:date:references:in-reply-to:to; bh=T+flIlNlhAAZrw23cfek4lawkcqSlupDpG6ugJdcmnw=; b=i8i5lklTAhUrT9kv3AAqOf8DBULG2HEWm+n3Er++VxvKM65lICmcQgBahyTa24XdBq KreJ3uGalurTeYmq6OPM5RfMsL67tpuY5VlsgrU2gQEMyjoVxZluUCw9CfQQXXdCVlya o7aBKaJs9Si369/R8oWV5OUmQbSo6wRXYomsN3hk1Pn6fX2Hy4chkAid6/N+tyVtZEPr btdmhdEw5EqVwp1PqXzkSPHApNNxYkDI8E4PLSpmNMyR50U+FRLsMOkNobkCHo3xU3v2 yqUhiPVmZfGA/1mEiM4dZjH/U5j9JALfzUXunlzZEfTJaGr4Avn0nDQ4e0fdbPotIk1Y Ux0A== X-Gm-Message-State: ALoCoQmeViWHRVK83asFb4p7hPRMWu0MZydV6DeSQgkxeg+S+Y/1KeZt0lg7yk61eSl6uavCtKFH X-Received: by 10.70.98.130 with SMTP id ei2mr3102003pdb.59.1421941953813; Thu, 22 Jan 2015 07:52:33 -0800 (PST) Received: from [10.112.32.183] ([166.170.41.29]) by mx.google.com with ESMTPSA id mz7sm6492799pdb.3.2015.01.22.07.52.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Jan 2015 07:52:31 -0800 (PST) From: "Alan D. Cabrera" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: Brooklyn not in http://people.apache.org/committers-by-project.html Message-Id: <7B9FC44C-EAE8-4C7B-BB3E-9DE8FC2A01DD@toolazydogs.com> Date: Thu, 22 Jan 2015 07:52:29 -0800 References: <4E0AE711-6F64-434C-86C9-A9811FC729D6@toolazydogs.com> <45FDAEE3-8701-4BA3-B3C3-57A7A7DDE6E1@toolazydogs.com> <933D3493-8B77-44F3-A76F-C7C80328DFAB@toolazydogs.com> <07AECD11-CA8F-42AB-8D3D-70B0D6764720@toolazydogs.com> <54BF775B.4040305@apache.org> <89AE5C12-B40D-4CF3-9084-4E2CD170111F@toolazydogs.com> In-Reply-To: To: "infrastructure-dev@apache.org" X-Mailer: iPhone Mail (12B440) X-Virus-Checked: Checked by ClamAV on apache.org > On Jan 22, 2015, at 7:34 AM, sebb wrote: >=20 > AIUI PPMCs have no legal status within the ASF. >=20 > 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. > 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? > The podling status files can then be updated to point to the extracted > data on people.a.o or whimsy as appropriate. >=20 > There will then be a single source of the data (the asf-auth file). >=20 > That would (I think) be a worthwhile improvement on the current situation.= >=20 > If access to the asf-auth file is provided via a REST API then it > won't matter if the data is later moved into LDAP, as the API > implementation can just be changed. >=20 > This would also be a useful test of the REST API. > Any teething problems would only affect non-critical applications. >=20 >=20 >> On 22 January 2015 at 15:04, Alan Cabrera wrote: >>=20 >>>> On Jan 22, 2015, at 6:57 AM, jan i wrote: >>>>=20 >>>> On Thursday, January 22, 2015, Alan D. Cabrera wr= ote: >>>>=20 >>>>=20 >>>>>> On Jan 22, 2015, at 4:45 AM, sebb > >>>>> wrote: >>>>>=20 >>>>> On 22 January 2015 at 12:20, jan i >>>> >> wrote: >>>>>> On Thursday, January 22, 2015, sebb >= >>>> wrote: >>>>>>=20 >>>>>>> On 21 January 2015 at 17:42, Alan D. Cabrera >>> >>>>>>> > wrote: >>>>>>>>=20 >>>>>>>>> On Jan 21, 2015, at 1:54 AM, Daniel Gruno >>> >>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>> On 2015-01-21 09:47, jan i wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Can we all agree that we need to put this into LDAP? >>>>>>>>>>=20 >>>>>>>>>> I agree with you that LDAP is the right place for such informati= on, >>>>>>> and I >>>>>>>>>> do not see so many podlings fail that it should be a major concer= n. >>>>>>> However >>>>>>>>>> I think a discussion on general@i.a.o is needed. >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> If incubator agrees on this approach then I assume David (v.p. >>>> infra) >>>>>>> will >>>>>>>>>> be relatively easy to convince. >>>>>>>>>>=20 >>>>>>>>>> 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 fo= r >>>>>>> incubator where we exercise universal commit bit. >>>>>>>>>=20 >>>>>>>>> As I understand it, the sentiment seems to be "let's put it in LDA= P >>>>>>> instead of tracking it in a file". >>>>>>>>>=20 >>>>>>>>> Let's list some pros and cons for this LDAP idea as opposed to usi= ng >>>>>>> the auth file for tracking: >>>>>>>>>=20 >>>>>>>>> Pros: >>>>>>>>> - it's in LDAP instead of a text file. >>>>>>>>> - it may (or may not) be easier to get a list of project members >>>>>>>>>=20 >>>>>>>>> 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 ha= ve >>>> 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 graduati= on >>>> 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 voluntaril= y, >>>> 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. >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> What is the actual gain here? It certainly won't make anything eas= ier >>>>>>> for infra. >>>>>>>>> How does it in any way compare to the cost of doing such a move? >>>>>>>>=20 >>>>>>>> I understand why you=E2=80=99re hesitant to take this on. You mana= ge >>>> volunteer >>>>>>> staff and have a limited budget for those who are paid. =46rom your= >>>> point of >>>>>>> view what we have =E2=80=9Cworks=E2=80=9D and there are higher prior= ity items that you >>>> are >>>>>>> responsible for getting done. >>>>>>>>=20 >>>>>>>> With that said, I would point out that your long list of =E2=80=9Cc= ons=E2=80=9D is >>>>>>> symptomatic of the problem caused by not putting podling committer a= nd >>>> PPMC >>>>>>> information in LDAP. The current mechanism of capturing podling gro= up >>>>>>> information is disparate, brittle, and inconsistent. I don=E2=80=99= t think >>>> that >>>>>>> you=E2=80=99re claiming that the current setup is ideal; you just ha= ve to deal >>>> with >>>>>>> limited resources to get things done. >>>>>>>>=20 >>>>>>>> What I am proposing is that I construct a plan to get us to a bette= r >>>>>>> place. I will create the conversion scripts, LDIF files, etc. and >>>>>>> coordinate the effort with the podlings. All I need is the assistan= ce >>>> of >>>>>>> someone w/ the privileges and the experience to review my proposed >>>>>>> changes. I will do the overwhelming bulk of the work. >>>>>>>>=20 >>>>>>>> I don=E2=80=99t think there=E2=80=99s anything to lose by this prop= osal. If I don=E2=80=99t >>>>>>> follow up w/ what I propose then we are simply left with our current= >>>> state >>>>>>> of affairs. If I deliver, we=E2=80=99ll be in better shape overall a= nd things >>>> will >>>>>>> be much more simple and consistent. >>>>>>>>=20 >>>>>>>> wdyt? >>>>>>>=20 >>>>>>> I think there may be a much simpler solution to this. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> So it seems to me it would be simple to add podling-ppmc groups to t= he >>>>>>> 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. >>>>>>>=20 >>>>>>> Assuming there is no objection from infra to adding these entries, >>>>>>> then this would have the advantage of simplicity (and speed of >>>>>>> implementation). >>>>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>> +1 would be nice if the podling status pages could also use this >>>>>> information, so PPMC do not need to maintain multiple places. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Maybe if that issue were fixed there would be no need to involve >>>>> changes to Infra processes or data. >>>>=20 >>>> Status files have a use, being able to scrape information form those HT= ML >>>> files are not one of them. That is a very, very, poor practice. >>>>=20 >>>> No, ultimately those files should be automagically be generated from >>>> canonical sources of data, removing yet another source of data that nee= ds >>>> to be maintained. >>>=20 >>>=20 >>> Yes but please do not forget the biggest problem with LDAP remain >>> undiscussed. Do we really want to make a system where mentors/PPMC canno= t >>> make updates, but need to go through IPMC. chair or infra (this is the c= ase >>> with ldap and not likely to change). >>=20 >> You bring up a good point. But this is a tooling problem and one that can= easily be solved by wrapping up the management of all these groups in a res= t API. This API can be accessed by a variety of tools including whimsy. >>=20 >> My general efforts here are not simple busywork. Disparate sources of dat= a, often wildly inconsistent, need to be consolidated. The consolidated, can= onical, data sources need to be put behind rest APIs where they can be acces= sed by a variety of tooling, including whimsy. Once we get to this state all= manner of automation is possible. >>=20 >>=20 >> Regards, >> Alan >>=20 >>=20