You are viewing a plain text version of this content. The canonical link for it is here.
Posted to infrastructure-dev@apache.org by "Alan D. Cabrera" <li...@toolazydogs.com> on 2015/01/20 19:02:32 UTC
Brooklyn not in http://people.apache.org/committers-by-project.html
What do we need to do to add it?
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by jan i <ja...@apache.org>.
On Tuesday, January 20, 2015, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> > On Jan 20, 2015, at 11:31 AM, jan i <jani@apache.org <javascript:;>>
> wrote:
> >
> > On 20 January 2015 at 20:22, Alan D. Cabrera <list@toolazydogs.com
> <javascript:;> <mailto:list@toolazydogs.com <javascript:;>>> wrote:
> >
> >>
> >>> On Jan 20, 2015, at 11:19 AM, jan i <jani@apache.org <javascript:;>>
> wrote:
> >>>
> >>> On 20 January 2015 at 20:12, Alan D. Cabrera <list@toolazydogs.com
> <javascript:;>>
> >> wrote:
> >>>
> >>>>
> >>>>> On Jan 20, 2015, at 11:08 AM, sebb <sebbaz@gmail.com <javascript:;>>
> wrote:
> >>>>>
> >>>>> On 20 January 2015 at 18:12, Alan D. Cabrera <adc@toolazydogs.com
> <javascript:;>>
> >>>> wrote:
> >>>>>>
> >>>>>>> On Jan 20, 2015, at 10:08 AM, David Nalley <david@gnsa.us
> <javascript:;>> wrote:
> >>>>>>>
> >>>>>>> Is there a reason it needs to be added?
> >>>>>>
> >>>>>> That seems like an odd question and I would turn it around and ask,
> is
> >>>> there a reason why it shouldn’t?
> >>>>>>
> >>>>>>> IIRC that page is derived from the authorization file for SVN -
> >>>>>
> >>>>> Yes
> >>>>>
> >>>>>>> Brooklyn doesn't use svn, so no listing.
> >>>>>
> >>>>> It does not *need* an entry in asf-auth, but one can be provided.
> >>>>>
> >>>>>> Time to fix the tooling… :) Where’s the code that generates those
> >>>> pages?
> >>>>>
> >>>>> The tooling is not broken.
> >>>>>
> >>>>> There is currently no readily accessible data defining the members 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
> <
> https://svn.apache.org/repos/infra/infrastructure/trunk/subversion/authorization/asf-authorization-template
> >
> >
> > Search for "bookkeeper=breed"
> >
> > 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 that I know, but all committers in incubator have write access to
incubator git, if I have understood it correct.
rgds
jan i
>
> Regards,
> Alan
>
>
--
Sent from My iPad, sorry for any misspellings.
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
> On Jan 22, 2015, at 3:09 AM, sebb <se...@gmail.com> wrote:
>
> On 21 January 2015 at 17:42, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>
>>> On Jan 21, 2015, at 1:54 AM, Daniel Gruno <hu...@apache.org> 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.
Placing group information into the svn-auth file is a very poor practice. It mixes concerns; here management of a group of committers be it git or svn and actual svn permissions. A very, very, poor practice indeed.
The only reason that podling committers, remember some podling committers not all, are in that file is because they are not in LDAP.
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
> On Jan 23, 2015, at 9:41 AM, sebb <se...@gmail.com> wrote:
>
> On 23 January 2015 at 16:00, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>
>>> On Jan 23, 2015, at 7:48 AM, David Nalley <da...@gnsa.us> wrote:
>>>
>>> On Fri, Jan 23, 2015 at 10:27 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>>>
>>>>> On Jan 22, 2015, at 3:11 PM, Tony Stevenson <pc...@apache.org> wrote:
>>>>>
>>>>> Please note that there are some significant technical consequences to this (depending upon the exact nature of the changes) - for example adding that to an ou that was a child ou of the incubator )whcih it probably should be) will cause some of the services that query ldap tp incorrectly classify them, and perhaps there misuse them etc.
>>>>> It's not all doom and gloom. I'd rather see effort into getting other data into LDAP first - as this has been around for a long time, and the PPMC additions seems like such a small win for such a huge effort investment, right now. One day it will all be in LDAP.
>>>>>
>>>>
>>>> And maybe the Incubator will be a thing of the past by that time. ;)
>>>>
>>>> Anyway, I’d still like to help unless someone else is already working on this.
>>>>
>>>
>>> So my opposition to this is three fold.
>>>
>>> Today, LDAP is an authorization mechanism. More and more people are
>>> wanting it to become a source of truth. This difference is subtle, but
>>> a substantial one. For instance, if you look at the list of members
>>> per LDAP, you'll see folks who aren't actually members. There is a lot
>>> of technical debt present around in that arena that will have to be
>>> paid before we can began treating LDAP as a source of truth.
>>>
>>> We also have a lot of infra tooling built around the current way of
>>> doing things, including how projects in the incubator are graduated,
>>> how we handle authentication to various things and all of those are
>>> potentially affected, and would need to be reworked. That's not a good
>>> reason for not making changes, but it makes me reluctant to add all of
>>> this additional work and the need to pay this specific chunk of debt
>>> off right now given our other priorities. Part of that is looking at
>>> the opportunity cost to the foundation for not doing this work; in my
>>> mind that cost is that LDAP isn't authoritative and people maintain
>>> text files. Compared to what is on our plate, it's not close to being
>>> a priority just now.
>>>
>>> If, someone wanted to tackle this, and figures out all of the touch
>>> points and gets those fixed and working in a test environment first,
>>> more power to them, but even setting up the test environment is a
>>> non-trivial amount of work. And FWIW, I don't ever see the level of
>>> karma needed to make LDAP changes being changed - especially if we
>>> move to LDAP being a source of truth, if anything that may trigger a
>>> requirement that it be more restrictive than it is today.
>>
>> Thanks for the concise and lucid exposition. I totally understand where you’re coming from.
>>
>> At the moment, we have untold documented and undocumented processes that fiddle with the disparate and inconsistent set of metadata that represents the Apache Software Foundation. There is no way to get from “here” to “there” without building some kind of “interface” that represents where we want to be, move all of our processes onto this new interface, then start cleaning the disparate and inconsistent set of metadata behind the scenes.
>>
>> I think that this interface should be a simple REST API.
>>
>> Once we have this REST API then all manner of tooling is possible and infra can start cleaning/refactoring things at their own pace.
>>
>
> I think the first stage is ensuring that the current sources of data
> are documented and understood.
>
> Then decide (and document) what data we need to maintain.
>
> Then an API to access the data could be defined and built.
>
> There was some work done on the data aspect in the past, but it did
> not get very far:
>
> https://mail-search.apache.org/members/private-arch/records-discuss/ <https://mail-search.apache.org/members/private-arch/records-discuss/>
Agreed. Should I post my questions about data there?
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by sebb <se...@gmail.com>.
On 23 January 2015 at 16:00, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>> On Jan 23, 2015, at 7:48 AM, David Nalley <da...@gnsa.us> wrote:
>>
>> On Fri, Jan 23, 2015 at 10:27 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>>
>>>> On Jan 22, 2015, at 3:11 PM, Tony Stevenson <pc...@apache.org> wrote:
>>>>
>>>> Please note that there are some significant technical consequences to this (depending upon the exact nature of the changes) - for example adding that to an ou that was a child ou of the incubator )whcih it probably should be) will cause some of the services that query ldap tp incorrectly classify them, and perhaps there misuse them etc.
>>>> It's not all doom and gloom. I'd rather see effort into getting other data into LDAP first - as this has been around for a long time, and the PPMC additions seems like such a small win for such a huge effort investment, right now. One day it will all be in LDAP.
>>>>
>>>
>>> And maybe the Incubator will be a thing of the past by that time. ;)
>>>
>>> Anyway, I’d still like to help unless someone else is already working on this.
>>>
>>
>> So my opposition to this is three fold.
>>
>> Today, LDAP is an authorization mechanism. More and more people are
>> wanting it to become a source of truth. This difference is subtle, but
>> a substantial one. For instance, if you look at the list of members
>> per LDAP, you'll see folks who aren't actually members. There is a lot
>> of technical debt present around in that arena that will have to be
>> paid before we can began treating LDAP as a source of truth.
>>
>> We also have a lot of infra tooling built around the current way of
>> doing things, including how projects in the incubator are graduated,
>> how we handle authentication to various things and all of those are
>> potentially affected, and would need to be reworked. That's not a good
>> reason for not making changes, but it makes me reluctant to add all of
>> this additional work and the need to pay this specific chunk of debt
>> off right now given our other priorities. Part of that is looking at
>> the opportunity cost to the foundation for not doing this work; in my
>> mind that cost is that LDAP isn't authoritative and people maintain
>> text files. Compared to what is on our plate, it's not close to being
>> a priority just now.
>>
>> If, someone wanted to tackle this, and figures out all of the touch
>> points and gets those fixed and working in a test environment first,
>> more power to them, but even setting up the test environment is a
>> non-trivial amount of work. And FWIW, I don't ever see the level of
>> karma needed to make LDAP changes being changed - especially if we
>> move to LDAP being a source of truth, if anything that may trigger a
>> requirement that it be more restrictive than it is today.
>
> Thanks for the concise and lucid exposition. I totally understand where you’re coming from.
>
> At the moment, we have untold documented and undocumented processes that fiddle with the disparate and inconsistent set of metadata that represents the Apache Software Foundation. There is no way to get from “here” to “there” without building some kind of “interface” that represents where we want to be, move all of our processes onto this new interface, then start cleaning the disparate and inconsistent set of metadata behind the scenes.
>
> I think that this interface should be a simple REST API.
>
> Once we have this REST API then all manner of tooling is possible and infra can start cleaning/refactoring things at their own pace.
>
I think the first stage is ensuring that the current sources of data
are documented and understood.
Then decide (and document) what data we need to maintain.
Then an API to access the data could be defined and built.
There was some work done on the data aspect in the past, but it did
not get very far:
https://mail-search.apache.org/members/private-arch/records-discuss/
> Regards,
> Alan
>
>
>
Re: Brooklyn not in http://people.apache.org/committers-by-project.htmlhttps://projects-new.apache.org/
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Mar 16, 2015, at 7:34 AM, David Nalley <da...@gnsa.us> wrote:
>
> On Mon, Mar 16, 2015 at 10:24 AM, Tony Stevenson <to...@pc-tony.com> wrote:
>> Alan,
>>
>> I think in reality, we care far, far less about the tool itself than we do about the deployment and management of it.
>>
>
> This is true, to a degree.
> What we don't want to do is to write something ourselves and then
> having the long term maintenance burden. The allure of Syncope is that
> there is a community of folks building and maintaining the software.
> The less we have to maintain the better.
I can see this point. My thinking is that our processes are pretty short and simple and Syncope with its workflow may be overkill. I think it’s way more important to identify our data files that we need to manage and present a coherent REST API for tooling and websites such as whimsy, projects-new.apache.org, and panopticon.
Anyway, I just want to get this done, as well as the REST API for EZMLM, so I can get back to my stalled panopticon project.
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by David Nalley <da...@gnsa.us>.
On Mon, Mar 16, 2015 at 10:24 AM, Tony Stevenson <to...@pc-tony.com> wrote:
> Alan,
>
> I think in reality, we care far, far less about the tool itself than we do about the deployment and management of it.
>
This is true, to a degree.
What we don't want to do is to write something ourselves and then
having the long term maintenance burden. The allure of Syncope is that
there is a community of folks building and maintaining the software.
The less we have to maintain the better.
--David
Re: Brooklyn not in
http://people.apache.org/committers-by-project.html
Posted by Tony Stevenson <to...@pc-tony.com>.
Alan,
I think in reality, we care far, far less about the tool itself than we do about the deployment and management of it.
As David says, it must be deployed as a .deb, and be 100% in puppet and be idempotent too.
If you want help with this endeavour, please let me know and I can try to help you along.
--
Cheers,
Tony
On 16 March 2015 at 13:14:44, Alan Cabrera (list@toolazydogs.com) wrote:
> So, I've been futzing around with Syncope and the going has been slow. I seem to be struggling
> more with the framework and it's dearth of relevant documentation than actually getting
> a reasonable mock up working.
>
> My question is, how critical is it that we use this framework? I think that I could've gotten
> a lot more done if I just coded something up in python. In my opinion, Given the fluid nature
> of this effort I think this is the way to go.
>
> Once things have gelled and we have a firm idea on what needs to be managed and how, including
> the rest API, then we can make an effort to use this framework.
>
> Thoughts?
>
> Sent from my iPhone
>
> > On Feb 27, 2015, at 9:45 AM, David Nalley wrote:
> >
> > Nope, none at all.
> > Please deploy software as .deb packages all via puppet, with
> > configuration in the same place.
> >
> > --David
> >
> >> On Fri, Feb 27, 2015 at 11:49 AM, Alan D. Cabrera wrote:
> >>
> >>> On Feb 27, 2015, at 8:46 AM, David Nalley wrote:
> >>>
> >>> On Fri, Feb 27, 2015 at 11:42 AM, Alan D. Cabrera wrote:
> >>>>
> >>>>> On Jan 27, 2015, at 9:56 AM, Tony Stevenson wrote:
> >>>>>
> >>>>> On Tuesday, 27 January 2015, Alan D. Cabrera wrote:
> >>>>>
> >>>>>>
> >>>>>>>> On Jan 27, 2015, at 7:42 AM, Alan D. Cabrera > >>>>>>> > wrote:
> >>>>>>>
> >>>>>>>> We are still playing with the
> >>>>>>>> backend provider, and one of the options I am looking at is using
> >>>>>>>> Apache Syncope - this already provides many of the things you might
> >>>>>>>> expect to code up.
> >>>>>>>> Once we have settled on the backend, only then should you think about
> >>>>>>>> writing something up.
> >>>>>>>
> >>>>>>> Sure. Thanks for the heads up.
> >>>>>>
> >>>>>> BTW, what’s the ETA for this?
> >>>>> This is weeks away. I'll revert as soon as anything solid comes out.
> >>>>
> >>>> Hi Tony,
> >>>>
> >>>> How are things going on this?
> >>>
> >>> While it's important, and we are still talking about it - we have a
> >>> number of other pressing issues that are consuming lots of cycles.
> >>
> >> Would you mind if I ran with it?
> >>
> >>
> >> Regards,
> >> Alan
> >>
> >>
> >>
>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by Alan Cabrera <li...@toolazydogs.com>.
So, I've been futzing around with Syncope and the going has been slow. I seem to be struggling more with the framework and it's dearth of relevant documentation than actually getting a reasonable mock up working.
My question is, how critical is it that we use this framework? I think that I could've gotten a lot more done if I just coded something up in python. In my opinion, Given the fluid nature of this effort I think this is the way to go.
Once things have gelled and we have a firm idea on what needs to be managed and how, including the rest API, then we can make an effort to use this framework.
Thoughts?
Sent from my iPhone
> On Feb 27, 2015, at 9:45 AM, David Nalley <da...@gnsa.us> wrote:
>
> Nope, none at all.
> Please deploy software as .deb packages all via puppet, with
> configuration in the same place.
>
> --David
>
>> On Fri, Feb 27, 2015 at 11:49 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>
>>> On Feb 27, 2015, at 8:46 AM, David Nalley <da...@gnsa.us> wrote:
>>>
>>> On Fri, Feb 27, 2015 at 11:42 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>>>
>>>>> On Jan 27, 2015, at 9:56 AM, Tony Stevenson <to...@pc-tony.com> wrote:
>>>>>
>>>>> On Tuesday, 27 January 2015, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>>>>
>>>>>>
>>>>>>>> On Jan 27, 2015, at 7:42 AM, Alan D. Cabrera <list@toolazydogs.com
>>>>>>> <javascript:;>> wrote:
>>>>>>>
>>>>>>>> We are still playing with the
>>>>>>>> backend provider, and one of the options I am looking at is using
>>>>>>>> Apache Syncope - this already provides many of the things you might
>>>>>>>> expect to code up.
>>>>>>>> Once we have settled on the backend, only then should you think about
>>>>>>>> writing something up.
>>>>>>>
>>>>>>> Sure. Thanks for the heads up.
>>>>>>
>>>>>> BTW, what’s the ETA for this?
>>>>> This is weeks away. I'll revert as soon as anything solid comes out.
>>>>
>>>> Hi Tony,
>>>>
>>>> How are things going on this?
>>>
>>> While it's important, and we are still talking about it - we have a
>>> number of other pressing issues that are consuming lots of cycles.
>>
>> Would you mind if I ran with it?
>>
>>
>> Regards,
>> Alan
>>
>>
>>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by sebb <se...@gmail.com>.
Note that podling committers can still be added to
asf-authorization-template as locally defined groups, even if they use
git.
Podling ppmc groups can be defined in a similar way; just use the
suffix -ppmc rather than -pmc and the output should appear in
people.a.o
On 27 February 2015 at 17:45, David Nalley <da...@gnsa.us> wrote:
> Nope, none at all.
> Please deploy software as .deb packages all via puppet, with
> configuration in the same place.
>
> --David
>
> On Fri, Feb 27, 2015 at 11:49 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>
>>> On Feb 27, 2015, at 8:46 AM, David Nalley <da...@gnsa.us> wrote:
>>>
>>> On Fri, Feb 27, 2015 at 11:42 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>>>
>>>>> On Jan 27, 2015, at 9:56 AM, Tony Stevenson <to...@pc-tony.com> wrote:
>>>>>
>>>>> On Tuesday, 27 January 2015, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>>>>
>>>>>>
>>>>>>> On Jan 27, 2015, at 7:42 AM, Alan D. Cabrera <list@toolazydogs.com
>>>>>> <javascript:;>> wrote:
>>>>>>>
>>>>>>>> We are still playing with the
>>>>>>>> backend provider, and one of the options I am looking at is using
>>>>>>>> Apache Syncope - this already provides many of the things you might
>>>>>>>> expect to code up.
>>>>>>>> Once we have settled on the backend, only then should you think about
>>>>>>>> writing something up.
>>>>>>>
>>>>>>> Sure. Thanks for the heads up.
>>>>>>
>>>>>> BTW, what’s the ETA for this?
>>>>>>
>>>>>>
>>>>> This is weeks away. I'll revert as soon as anything solid comes out.
>>>>
>>>> Hi Tony,
>>>>
>>>> How are things going on this?
>>>>
>>>
>>> While it's important, and we are still talking about it - we have a
>>> number of other pressing issues that are consuming lots of cycles.
>>
>> Would you mind if I ran with it?
>>
>>
>> Regards,
>> Alan
>>
>>
>>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by David Nalley <da...@gnsa.us>.
Nope, none at all.
Please deploy software as .deb packages all via puppet, with
configuration in the same place.
--David
On Fri, Feb 27, 2015 at 11:49 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>> On Feb 27, 2015, at 8:46 AM, David Nalley <da...@gnsa.us> wrote:
>>
>> On Fri, Feb 27, 2015 at 11:42 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>>
>>>> On Jan 27, 2015, at 9:56 AM, Tony Stevenson <to...@pc-tony.com> wrote:
>>>>
>>>> On Tuesday, 27 January 2015, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>>>
>>>>>
>>>>>> On Jan 27, 2015, at 7:42 AM, Alan D. Cabrera <list@toolazydogs.com
>>>>> <javascript:;>> wrote:
>>>>>>
>>>>>>> We are still playing with the
>>>>>>> backend provider, and one of the options I am looking at is using
>>>>>>> Apache Syncope - this already provides many of the things you might
>>>>>>> expect to code up.
>>>>>>> Once we have settled on the backend, only then should you think about
>>>>>>> writing something up.
>>>>>>
>>>>>> Sure. Thanks for the heads up.
>>>>>
>>>>> BTW, what’s the ETA for this?
>>>>>
>>>>>
>>>> This is weeks away. I'll revert as soon as anything solid comes out.
>>>
>>> Hi Tony,
>>>
>>> How are things going on this?
>>>
>>
>> While it's important, and we are still talking about it - we have a
>> number of other pressing issues that are consuming lots of cycles.
>
> Would you mind if I ran with it?
>
>
> Regards,
> Alan
>
>
>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Feb 27, 2015, at 8:46 AM, David Nalley <da...@gnsa.us> wrote:
>
> On Fri, Feb 27, 2015 at 11:42 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>
>>> On Jan 27, 2015, at 9:56 AM, Tony Stevenson <to...@pc-tony.com> wrote:
>>>
>>> On Tuesday, 27 January 2015, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>>
>>>>
>>>>> On Jan 27, 2015, at 7:42 AM, Alan D. Cabrera <list@toolazydogs.com
>>>> <javascript:;>> wrote:
>>>>>
>>>>>> We are still playing with the
>>>>>> backend provider, and one of the options I am looking at is using
>>>>>> Apache Syncope - this already provides many of the things you might
>>>>>> expect to code up.
>>>>>> Once we have settled on the backend, only then should you think about
>>>>>> writing something up.
>>>>>
>>>>> Sure. Thanks for the heads up.
>>>>
>>>> BTW, what’s the ETA for this?
>>>>
>>>>
>>> This is weeks away. I'll revert as soon as anything solid comes out.
>>
>> Hi Tony,
>>
>> How are things going on this?
>>
>
> While it's important, and we are still talking about it - we have a
> number of other pressing issues that are consuming lots of cycles.
Would you mind if I ran with it?
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by David Nalley <da...@gnsa.us>.
On Fri, Feb 27, 2015 at 11:42 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>> On Jan 27, 2015, at 9:56 AM, Tony Stevenson <to...@pc-tony.com> wrote:
>>
>> On Tuesday, 27 January 2015, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>
>>>
>>>> On Jan 27, 2015, at 7:42 AM, Alan D. Cabrera <list@toolazydogs.com
>>> <javascript:;>> wrote:
>>>>
>>>>> We are still playing with the
>>>>> backend provider, and one of the options I am looking at is using
>>>>> Apache Syncope - this already provides many of the things you might
>>>>> expect to code up.
>>>>> Once we have settled on the backend, only then should you think about
>>>>> writing something up.
>>>>
>>>> Sure. Thanks for the heads up.
>>>
>>> BTW, what’s the ETA for this?
>>>
>>>
>> This is weeks away. I'll revert as soon as anything solid comes out.
>
> Hi Tony,
>
> How are things going on this?
>
While it's important, and we are still talking about it - we have a
number of other pressing issues that are consuming lots of cycles.
--David
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 27, 2015, at 9:56 AM, Tony Stevenson <to...@pc-tony.com> wrote:
>
> On Tuesday, 27 January 2015, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>>
>>> On Jan 27, 2015, at 7:42 AM, Alan D. Cabrera <list@toolazydogs.com
>> <javascript:;>> wrote:
>>>
>>>> We are still playing with the
>>>> backend provider, and one of the options I am looking at is using
>>>> Apache Syncope - this already provides many of the things you might
>>>> expect to code up.
>>>> Once we have settled on the backend, only then should you think about
>>>> writing something up.
>>>
>>> Sure. Thanks for the heads up.
>>
>> BTW, what’s the ETA for this?
>>
>>
> This is weeks away. I'll revert as soon as anything solid comes out.
Hi Tony,
How are things going on this?
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by Tony Stevenson <to...@pc-tony.com>.
On Tuesday, 27 January 2015, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> > On Jan 27, 2015, at 7:42 AM, Alan D. Cabrera <list@toolazydogs.com
> <javascript:;>> wrote:
> >
> >> We are still playing with the
> >> backend provider, and one of the options I am looking at is using
> >> Apache Syncope - this already provides many of the things you might
> >> expect to code up.
> >> Once we have settled on the backend, only then should you think about
> >> writing something up.
> >
> > Sure. Thanks for the heads up.
>
> BTW, what’s the ETA for this?
>
>
This is weeks away. I'll revert as soon as anything solid comes out.
>
> Regards,
> Alan
>
>
--
Cheers,
Tony
----------------------------------
Tony Stevenson
tony@pc-tony.com
pctony@apache.org
http://www.pc-tony.com
GPG - 1024D/51047D66
----------------------------------
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 27, 2015, at 7:42 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>> We are still playing with the
>> backend provider, and one of the options I am looking at is using
>> Apache Syncope - this already provides many of the things you might
>> expect to code up.
>> Once we have settled on the backend, only then should you think about
>> writing something up.
>
> Sure. Thanks for the heads up.
BTW, what’s the ETA for this?
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 27, 2015, at 7:18 AM, Tony Stevenson <to...@pc-tony.com> wrote:
>
> On 27 January 2015 at 15:06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>> I’m going to assume that there’s lazy consensus on this and that the following steps are the way to go
>> architect a general REST API that captures foundation data
>> move processes to REST API
>> refactor disparate data sources behind REST API to where we want to be
>> I realize that some processes will necessarily need to work directly against data files/LDAP behind the REST API but I think the management of those sources should be done through the REST API so that all the interactions are performed in a standard, protected, audible, way.
>>
>> To that end I’m going to start collecting a catalog of processes that are in place. Please chime in if this is not the way to go or if someone else is already working on this.
>>
>>
>
> Alan,
>
> Can I please ask you to just hold off? We are still playing with the
> backend provider, and one of the options I am looking at is using
> Apache Syncope - this already provides many of the things you might
> expect to code up.
> Once we have settled on the backend, only then should you think about
> writing something up.
Sure. Thanks for the heads up.
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by Tony Stevenson <to...@pc-tony.com>.
On 27 January 2015 at 15:06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> I’m going to assume that there’s lazy consensus on this and that the following steps are the way to go
> architect a general REST API that captures foundation data
> move processes to REST API
> refactor disparate data sources behind REST API to where we want to be
> I realize that some processes will necessarily need to work directly against data files/LDAP behind the REST API but I think the management of those sources should be done through the REST API so that all the interactions are performed in a standard, protected, audible, way.
>
> To that end I’m going to start collecting a catalog of processes that are in place. Please chime in if this is not the way to go or if someone else is already working on this.
>
>
Alan,
Can I please ask you to just hold off? We are still playing with the
backend provider, and one of the options I am looking at is using
Apache Syncope - this already provides many of the things you might
expect to code up.
Once we have settled on the backend, only then should you think about
writing something up.
--
Cheers,
Tony
On behalf of the ASF Infrastructure Team
----------------------------------
Tony Stevenson
tony@pc-tony.com
pctony@apache.org
http://www.pc-tony.com
GPG - 1024D/51047D66
----------------------------------
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 23, 2015, at 11:57 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>
>> On Jan 23, 2015, at 9:56 AM, Bertrand Delacretaz <bd...@apache.org> wrote:
>>
>> On Fri, Jan 23, 2015 at 5:00 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>> ...At the moment, we have untold documented and undocumented processes that fiddle with
>>> the disparate and inconsistent set of metadata that represents the Apache Software Foundation....
>>
>> You're suggesting a REST API to replace that, IMO a set of structured
>> text files in a *single* svn folder combined with a validation script
>> that people can apply before committing would also do the job.
>>
>> That's reasonably http-friendly and you'd just need to write the
>> validation script.
>
> I did consider that. Keeping the consolidated, canonical, non-LDAP, data in Subversion does make sense. Having Subversion serve up the data directly poses problems.
>
> At my work we heavily use/used Subversion to manage our metadata for the same reasons you mention with pre-commit hooks performing validation. We are now in the process of ripping much of it out; some of the reasons apply to the domain we wish to solve here.
>
> My thinking is:
>
> The granularity of access is complex. We have to complex matrix of R/O and R/W permissions for public, committer, PMC, ASF member, Board, PPMC. Trying to fit that into Subversion files and folder bends and rips your data in strange ways as one denormalizes data to get specific permissions to work correctly. Since the data gets bent and ripped the requisite pre-commit logic gets split apart and so the security logic gets obfuscated.
>
> Invariably one needs to read/write to something else, e.g. LDAP, etc. and keep it consistent.
I’m going to assume that there’s lazy consensus on this and that the following steps are the way to go
architect a general REST API that captures foundation data
move processes to REST API
refactor disparate data sources behind REST API to where we want to be
I realize that some processes will necessarily need to work directly against data files/LDAP behind the REST API but I think the management of those sources should be done through the REST API so that all the interactions are performed in a standard, protected, audible, way.
To that end I’m going to start collecting a catalog of processes that are in place. Please chime in if this is not the way to go or if someone else is already working on this.
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 23, 2015, at 9:56 AM, Bertrand Delacretaz <bd...@apache.org> wrote:
>
> On Fri, Jan 23, 2015 at 5:00 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>> ...At the moment, we have untold documented and undocumented processes that fiddle with
>> the disparate and inconsistent set of metadata that represents the Apache Software Foundation....
>
> You're suggesting a REST API to replace that, IMO a set of structured
> text files in a *single* svn folder combined with a validation script
> that people can apply before committing would also do the job.
>
> That's reasonably http-friendly and you'd just need to write the
> validation script.
I did consider that. Keeping the consolidated, canonical, non-LDAP, data in Subversion does make sense. Having Subversion serve up the data directly poses problems.
At my work we heavily use/used Subversion to manage our metadata for the same reasons you mention with pre-commit hooks performing validation. We are now in the process of ripping much of it out; some of the reasons apply to the domain we wish to solve here.
My thinking is:
The granularity of access is complex. We have to complex matrix of R/O and R/W permissions for public, committer, PMC, ASF member, Board, PPMC. Trying to fit that into Subversion files and folder bends and rips your data in strange ways as one denormalizes data to get specific permissions to work correctly. Since the data gets bent and ripped the requisite pre-commit logic gets split apart and so the security logic gets obfuscated.
Invariably one needs to read/write to something else, e.g. LDAP, etc. and keep it consistent.
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Jan 23, 2015 at 5:00 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> ...At the moment, we have untold documented and undocumented processes that fiddle with
> the disparate and inconsistent set of metadata that represents the Apache Software Foundation....
You're suggesting a REST API to replace that, IMO a set of structured
text files in a *single* svn folder combined with a validation script
that people can apply before committing would also do the job.
That's reasonably http-friendly and you'd just need to write the
validation script.
-Bertrand
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 23, 2015, at 7:48 AM, David Nalley <da...@gnsa.us> wrote:
>
> On Fri, Jan 23, 2015 at 10:27 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>
>>> On Jan 22, 2015, at 3:11 PM, Tony Stevenson <pc...@apache.org> wrote:
>>>
>>> Please note that there are some significant technical consequences to this (depending upon the exact nature of the changes) - for example adding that to an ou that was a child ou of the incubator )whcih it probably should be) will cause some of the services that query ldap tp incorrectly classify them, and perhaps there misuse them etc.
>>> It's not all doom and gloom. I'd rather see effort into getting other data into LDAP first - as this has been around for a long time, and the PPMC additions seems like such a small win for such a huge effort investment, right now. One day it will all be in LDAP.
>>>
>>
>> And maybe the Incubator will be a thing of the past by that time. ;)
>>
>> Anyway, I’d still like to help unless someone else is already working on this.
>>
>
> So my opposition to this is three fold.
>
> Today, LDAP is an authorization mechanism. More and more people are
> wanting it to become a source of truth. This difference is subtle, but
> a substantial one. For instance, if you look at the list of members
> per LDAP, you'll see folks who aren't actually members. There is a lot
> of technical debt present around in that arena that will have to be
> paid before we can began treating LDAP as a source of truth.
>
> We also have a lot of infra tooling built around the current way of
> doing things, including how projects in the incubator are graduated,
> how we handle authentication to various things and all of those are
> potentially affected, and would need to be reworked. That's not a good
> reason for not making changes, but it makes me reluctant to add all of
> this additional work and the need to pay this specific chunk of debt
> off right now given our other priorities. Part of that is looking at
> the opportunity cost to the foundation for not doing this work; in my
> mind that cost is that LDAP isn't authoritative and people maintain
> text files. Compared to what is on our plate, it's not close to being
> a priority just now.
>
> If, someone wanted to tackle this, and figures out all of the touch
> points and gets those fixed and working in a test environment first,
> more power to them, but even setting up the test environment is a
> non-trivial amount of work. And FWIW, I don't ever see the level of
> karma needed to make LDAP changes being changed - especially if we
> move to LDAP being a source of truth, if anything that may trigger a
> requirement that it be more restrictive than it is today.
Thanks for the concise and lucid exposition. I totally understand where you’re coming from.
At the moment, we have untold documented and undocumented processes that fiddle with the disparate and inconsistent set of metadata that represents the Apache Software Foundation. There is no way to get from “here” to “there” without building some kind of “interface” that represents where we want to be, move all of our processes onto this new interface, then start cleaning the disparate and inconsistent set of metadata behind the scenes.
I think that this interface should be a simple REST API.
Once we have this REST API then all manner of tooling is possible and infra can start cleaning/refactoring things at their own pace.
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by David Nalley <da...@gnsa.us>.
On Fri, Jan 23, 2015 at 10:27 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>> On Jan 22, 2015, at 3:11 PM, Tony Stevenson <pc...@apache.org> wrote:
>>
>> Please note that there are some significant technical consequences to this (depending upon the exact nature of the changes) - for example adding that to an ou that was a child ou of the incubator )whcih it probably should be) will cause some of the services that query ldap tp incorrectly classify them, and perhaps there misuse them etc.
>> It's not all doom and gloom. I'd rather see effort into getting other data into LDAP first - as this has been around for a long time, and the PPMC additions seems like such a small win for such a huge effort investment, right now. One day it will all be in LDAP.
>>
>
> And maybe the Incubator will be a thing of the past by that time. ;)
>
> Anyway, I’d still like to help unless someone else is already working on this.
>
So my opposition to this is three fold.
Today, LDAP is an authorization mechanism. More and more people are
wanting it to become a source of truth. This difference is subtle, but
a substantial one. For instance, if you look at the list of members
per LDAP, you'll see folks who aren't actually members. There is a lot
of technical debt present around in that arena that will have to be
paid before we can began treating LDAP as a source of truth.
We also have a lot of infra tooling built around the current way of
doing things, including how projects in the incubator are graduated,
how we handle authentication to various things and all of those are
potentially affected, and would need to be reworked. That's not a good
reason for not making changes, but it makes me reluctant to add all of
this additional work and the need to pay this specific chunk of debt
off right now given our other priorities. Part of that is looking at
the opportunity cost to the foundation for not doing this work; in my
mind that cost is that LDAP isn't authoritative and people maintain
text files. Compared to what is on our plate, it's not close to being
a priority just now.
If, someone wanted to tackle this, and figures out all of the touch
points and gets those fixed and working in a test environment first,
more power to them, but even setting up the test environment is a
non-trivial amount of work. And FWIW, I don't ever see the level of
karma needed to make LDAP changes being changed - especially if we
move to LDAP being a source of truth, if anything that may trigger a
requirement that it be more restrictive than it is today.
--David
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 22, 2015, at 3:11 PM, Tony Stevenson <pc...@apache.org> wrote:
>
> Please note that there are some significant technical consequences to this (depending upon the exact nature of the changes) - for example adding that to an ou that was a child ou of the incubator )whcih it probably should be) will cause some of the services that query ldap tp incorrectly classify them, and perhaps there misuse them etc.
> It's not all doom and gloom. I'd rather see effort into getting other data into LDAP first - as this has been around for a long time, and the PPMC additions seems like such a small win for such a huge effort investment, right now. One day it will all be in LDAP.
>
And maybe the Incubator will be a thing of the past by that time. ;)
Anyway, I’d still like to help unless someone else is already working on this.
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by Tony Stevenson <pc...@apache.org>.
Alan D. Cabrera wrote:
>> On Jan 22, 2015, at 2:53 PM, Tony Stevenson<pc...@apache.org> wrote:
>>
>> Alan D. Cabrera wrote:
>>> The harmonization effort is exactly what I’m trying to do and I want to help. Is someone working on this? If not can I take a crack at it in a similar manner as this podling project?
>> Sorry, what is 'this' exactly? I haven't kept up with the thread TBH as it was going past so quickly and quite honestly, I lost interest quickly.
>
> Currently podling membership information is partially maintained in the Subversion authorization file, thus making it incomplete. PPMC membership is not captured at all.
>
> I want to write up a proposal for putting the information into LDAP under its own OU. I will write up the plan, conversion scripts, LDIF files, update documentation, and coordinate w/ podlings and the Incubator to get it done.
>
Please note that there are some significant technical consequences to this (depending upon the exact nature of the changes) - for example adding that to an ou that was a child ou of the incubator )whcih it probably should be) will cause some of the services that query ldap tp incorrectly classify them, and perhaps there misuse them etc.
It's not all doom and gloom. I'd rather see effort into getting other data into LDAP first - as this has been around for a long time, and the PPMC additions seems like such a small win for such a huge effort investment, right now. One day it will all be in LDAP.
>
> Regards,
> Alan
>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 22, 2015, at 2:53 PM, Tony Stevenson <pc...@apache.org> wrote:
>
> Alan D. Cabrera wrote:
>> The harmonization effort is exactly what I’m trying to do and I want to help. Is someone working on this? If not can I take a crack at it in a similar manner as this podling project?
>
> Sorry, what is 'this' exactly? I haven't kept up with the thread TBH as it was going past so quickly and quite honestly, I lost interest quickly.
Currently podling membership information is partially maintained in the Subversion authorization file, thus making it incomplete. PPMC membership is not captured at all.
I want to write up a proposal for putting the information into LDAP under its own OU. I will write up the plan, conversion scripts, LDIF files, update documentation, and coordinate w/ podlings and the Incubator to get it done.
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by Tony Stevenson <pc...@apache.org>.
Alan D. Cabrera wrote:
> The harmonization effort is exactly what I’m trying to do and I want to help. Is someone working on this? If not can I take a crack at it in a similar manner as this podling project?
Sorry, what is 'this' exactly? I haven't kept up with the thread TBH as
it was going past so quickly and quite honestly, I lost interest quickly.
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 22, 2015, at 2:35 PM, Tony Stevenson <pc...@apache.org> wrote:
>
> Alan D. Cabrera wrote:
>> I just want the infra rubber stamp that this is the ultimate way to go and that I have the go-ahead to start work on this
>
> In that case can I please ask that your formulate a clear proposal and bring it to the list, and seek support for it.
>
> However, please note that failure to meet any of these criteria is likely to mean that the Infra team will not be willing to accept it:
>
> 1) The work outputs have to be fully captured, and idempotent in configuration management
>
> 2) If this means there is another service that needs managing you will sadly find short shrift from us as we are already over-burdened with support of services
>
> 3) If the proposal requires long term (read >1 day of infra input you will need to liaise with David)
>
> You should also note that there is a current piece of work to resolve the underlying issues with our ldap service. There is also an open JIRA and a very longstanding request to harmonise a whole bunch of our data (members.txt, iclas.txt to name just two) into LDAP data.
>
> I dont mean to piss on your fire, but you need to understand that we are unlikely to be able to commit to any new pieces of work of any significant magnitude for some months (unless re-directed by David, or Ross etc) as we still trying to shake of a whole heap of technical debt and years of under-serviced infrastructure.
Thanks. I’m used to having my work wait, in some cases years, until things align with your infra schedules. ;)
The harmonization effort is exactly what I’m trying to do and I want to help. Is someone working on this? If not can I take a crack at it in a similar manner as this podling project?
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by Tony Stevenson <pc...@apache.org>.
Alan D. Cabrera wrote:
> I just want the infra rubber stamp that this is the ultimate way to go and that I have the go-ahead to start work on this
In that case can I please ask that your formulate a clear proposal and
bring it to the list, and seek support for it.
However, please note that failure to meet any of these criteria is
likely to mean that the Infra team will not be willing to accept it:
1) The work outputs have to be fully captured, and idempotent in
configuration management
2) If this means there is another service that needs managing you will
sadly find short shrift from us as we are already over-burdened with
support of services
3) If the proposal requires long term (read >1 day of infra input you
will need to liaise with David)
You should also note that there is a current piece of work to resolve
the underlying issues with our ldap service. There is also an open JIRA
and a very longstanding request to harmonise a whole bunch of our data
(members.txt, iclas.txt to name just two) into LDAP data.
I dont mean to piss on your fire, but you need to understand that we are
unlikely to be able to commit to any new pieces of work of any
significant magnitude for some months (unless re-directed by David, or
Ross etc) as we still trying to shake of a whole heap of technical debt
and years of under-serviced infrastructure.
--
Cheers,
Tony
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 22, 2015, at 10:07 AM, jan i <ja...@apache.org> wrote:
>
> On 22 January 2015 at 18:54, Alan D. Cabrera <adc@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>
>>
>>> On Jan 22, 2015, at 9:36 AM, jan i <jani@apache.org <ma...@apache.org>> wrote:
>>>
>>> On 22 January 2015 at 18:04, Alan D. Cabrera <adc@toolazydogs.com <ma...@toolazydogs.com>
>> <mailto:adc@toolazydogs.com <ma...@toolazydogs.com>>> wrote:
>>>
>>>>
>>>>> On Jan 22, 2015, at 8:14 AM, sebb <sebbaz@gmail.com <ma...@gmail.com>> wrote:
>>>>>
>>>>> On 22 January 2015 at 15:52, Alan D. Cabrera <adc@toolazydogs.com <ma...@toolazydogs.com>>
>>>> wrote:
>>>>>>
>>>>>>> On Jan 22, 2015, at 7:34 AM, sebb <se...@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.
You know, I already volunteered to do all this. I volunteered to write the plan, conversion scripts, LDIF files, and coordinate the incubator and podlings. I volunteered to do most of the work. I didn’t say drop what every your doing and do this now. I just wanted approval to get started work on this.
And your reply is “nah, let’s stuff organizational information into a Subversion authorization file even if the podlings don’t use Subversion. Can you not see why I am baffled and frustrated?
If your reply was instead, “Yeah, it’s not ideal. Go ahead and get going on this and I’ll review the plan and scripts and help out on my end” this conversation would have taken a decidedly different turn.
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by jan i <ja...@apache.org>.
On 22 January 2015 at 18:54, Alan D. Cabrera <ad...@toolazydogs.com> wrote:
>
> > On Jan 22, 2015, at 9:36 AM, jan i <ja...@apache.org> wrote:
> >
> > On 22 January 2015 at 18:04, Alan D. Cabrera <adc@toolazydogs.com
> <ma...@toolazydogs.com>> wrote:
> >
> >>
> >>> On Jan 22, 2015, at 8:14 AM, sebb <se...@gmail.com> wrote:
> >>>
> >>> On 22 January 2015 at 15:52, Alan D. Cabrera <ad...@toolazydogs.com>
> >> wrote:
> >>>>
> >>>>> On Jan 22, 2015, at 7:34 AM, sebb <se...@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
>
>
>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 22, 2015, at 10:55 AM, sebb <se...@gmail.com> wrote:
>
> On 22 January 2015 at 18:15, Alan D. Cabrera <list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>>
>>> On Jan 22, 2015, at 10:05 AM, sebb <se...@gmail.com> wrote:
>>>
>>> On 22 January 2015 at 17:54, Alan D. Cabrera <ad...@toolazydogs.com> wrote:
>>>>
>>>>> On Jan 22, 2015, at 9:36 AM, jan i <ja...@apache.org> wrote:
>>>>>
>>>>> On 22 January 2015 at 18:04, Alan D. Cabrera <adc@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>>>>>
>>>>>>
>>>>>>> On Jan 22, 2015, at 8:14 AM, sebb <se...@gmail.com> wrote:
>>>>>>>
>>>>>>> On 22 January 2015 at 15:52, Alan D. Cabrera <ad...@toolazydogs.com>
>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Jan 22, 2015, at 7:34 AM, sebb <se...@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.
>>>
>>> It is not *adding* to the technical debt.
>>>
>>> The asf-auth file is the correct place for defining SVN groups that
>>> are not in LDAP.
>>> The podlings that do use SVN *already* have the committer groups here.
>>>
>>> It so happens that the ppmc groups won't have any SVN folders that need auth.
>>> Likewise the podlings that use Git don't *need* committer entries.
>>
>> If you don’t see how that is not a poor practice, then there’s nothing else I can say. Let’s just drop it and agree to disagree.
>
> I did not say that it was ideal. But it is no worse than the status quo.
>
>>>> 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'm equally baffled why you seem unwilling to try this simple improvement.
>>
>> I apologize for my tone.
>
> OK, fine.
>
> But are you willing to consider something other than requiring
> everything to be in LDAP?
> At least as a short term solution?
I just want the infra rubber stamp that this is the ultimate way to go and that I have the go-ahead to start work on this. What you do tactically is up to you so long as it doesn’t block me; this won’t block me.
> ==
>
> Going back to the original subject of this thread, if you wish to see
> Brooklyn in the committers-by-project list, that can be done right
> now.
> Adding PPMC listings will take a bit longer.
Yes, it will work.
Since we don’t have PPMC listings let’s wait until the info is in LDAP. Then we can update the generation of those pages to pull their data from LDAP, more likely whimsy who in turn will consult LDAP.
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by sebb <se...@gmail.com>.
On 22 January 2015 at 18:15, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>> On Jan 22, 2015, at 10:05 AM, sebb <se...@gmail.com> wrote:
>>
>> On 22 January 2015 at 17:54, Alan D. Cabrera <ad...@toolazydogs.com> wrote:
>>>
>>>> On Jan 22, 2015, at 9:36 AM, jan i <ja...@apache.org> wrote:
>>>>
>>>> On 22 January 2015 at 18:04, Alan D. Cabrera <adc@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>>>>
>>>>>
>>>>>> On Jan 22, 2015, at 8:14 AM, sebb <se...@gmail.com> wrote:
>>>>>>
>>>>>> On 22 January 2015 at 15:52, Alan D. Cabrera <ad...@toolazydogs.com>
>>>>> wrote:
>>>>>>>
>>>>>>>> On Jan 22, 2015, at 7:34 AM, sebb <se...@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.
>>
>> It is not *adding* to the technical debt.
>>
>> The asf-auth file is the correct place for defining SVN groups that
>> are not in LDAP.
>> The podlings that do use SVN *already* have the committer groups here.
>>
>> It so happens that the ppmc groups won't have any SVN folders that need auth.
>> Likewise the podlings that use Git don't *need* committer entries.
>
> If you don’t see how that is not a poor practice, then there’s nothing else I can say. Let’s just drop it and agree to disagree.
I did not say that it was ideal. But it is no worse than the status quo.
>>> 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'm equally baffled why you seem unwilling to try this simple improvement.
>
> I apologize for my tone.
OK, fine.
But are you willing to consider something other than requiring
everything to be in LDAP?
At least as a short term solution?
==
Going back to the original subject of this thread, if you wish to see
Brooklyn in the committers-by-project list, that can be done right
now.
Adding PPMC listings will take a bit longer.
> Regards,
> Alan
>
>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 22, 2015, at 10:05 AM, sebb <se...@gmail.com> wrote:
>
> On 22 January 2015 at 17:54, Alan D. Cabrera <ad...@toolazydogs.com> wrote:
>>
>>> On Jan 22, 2015, at 9:36 AM, jan i <ja...@apache.org> wrote:
>>>
>>> On 22 January 2015 at 18:04, Alan D. Cabrera <adc@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>>>
>>>>
>>>>> On Jan 22, 2015, at 8:14 AM, sebb <se...@gmail.com> wrote:
>>>>>
>>>>> On 22 January 2015 at 15:52, Alan D. Cabrera <ad...@toolazydogs.com>
>>>> wrote:
>>>>>>
>>>>>>> On Jan 22, 2015, at 7:34 AM, sebb <se...@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.
>
> It is not *adding* to the technical debt.
>
> The asf-auth file is the correct place for defining SVN groups that
> are not in LDAP.
> The podlings that do use SVN *already* have the committer groups here.
>
> It so happens that the ppmc groups won't have any SVN folders that need auth.
> Likewise the podlings that use Git don't *need* committer entries.
If you don’t see how that is not a poor practice, then there’s nothing else I can say. Let’s just drop it and agree to disagree.
>> 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'm equally baffled why you seem unwilling to try this simple improvement.
I apologize for my tone.
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by sebb <se...@gmail.com>.
On 22 January 2015 at 17:54, Alan D. Cabrera <ad...@toolazydogs.com> wrote:
>
>> On Jan 22, 2015, at 9:36 AM, jan i <ja...@apache.org> wrote:
>>
>> On 22 January 2015 at 18:04, Alan D. Cabrera <adc@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>>
>>>
>>>> On Jan 22, 2015, at 8:14 AM, sebb <se...@gmail.com> wrote:
>>>>
>>>> On 22 January 2015 at 15:52, Alan D. Cabrera <ad...@toolazydogs.com>
>>> wrote:
>>>>>
>>>>>> On Jan 22, 2015, at 7:34 AM, sebb <se...@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.
It is not *adding* to the technical debt.
The asf-auth file is the correct place for defining SVN groups that
are not in LDAP.
The podlings that do use SVN *already* have the committer groups here.
It so happens that the ppmc groups won't have any SVN folders that need auth.
Likewise the podlings that use Git don't *need* committer entries.
> 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'm equally baffled why you seem unwilling to try this simple improvement.
>
> Regards,
> Alan
>
>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
> On Jan 22, 2015, at 9:36 AM, jan i <ja...@apache.org> wrote:
>
> On 22 January 2015 at 18:04, Alan D. Cabrera <adc@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>
>>
>>> On Jan 22, 2015, at 8:14 AM, sebb <se...@gmail.com> wrote:
>>>
>>> On 22 January 2015 at 15:52, Alan D. Cabrera <ad...@toolazydogs.com>
>> wrote:
>>>>
>>>>> On Jan 22, 2015, at 7:34 AM, sebb <se...@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.
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by jan i <ja...@apache.org>.
On 22 January 2015 at 18:04, Alan D. Cabrera <ad...@toolazydogs.com> wrote:
>
> > On Jan 22, 2015, at 8:14 AM, sebb <se...@gmail.com> wrote:
> >
> > On 22 January 2015 at 15:52, Alan D. Cabrera <ad...@toolazydogs.com>
> wrote:
> >>
> >>> On Jan 22, 2015, at 7:34 AM, sebb <se...@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
just my 2ct.
jan I.
>
>
> Regards,
> Alan
>
>
>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
> On Jan 22, 2015, at 8:14 AM, sebb <se...@gmail.com> wrote:
>
> On 22 January 2015 at 15:52, Alan D. Cabrera <ad...@toolazydogs.com> wrote:
>>
>>> On Jan 22, 2015, at 7:34 AM, sebb <se...@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.
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by sebb <se...@gmail.com>.
On 22 January 2015 at 15:52, Alan D. Cabrera <ad...@toolazydogs.com> wrote:
>
>> On Jan 22, 2015, at 7:34 AM, sebb <se...@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.
>> 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.
>> The podling status files can then be updated to point to the extracted
>> data on people.a.o or whimsy as appropriate.
>>
>> There will then be a single source of the data (the asf-auth file).
>>
>> That would (I think) be a worthwhile improvement on the current situation.
>>
>> 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.
>>
>> This would also be a useful test of the REST API.
>> Any teething problems would only affect non-critical applications.
>>
>>
>>> On 22 January 2015 at 15:04, Alan Cabrera <li...@toolazydogs.com> wrote:
>>>
>>>>> On Jan 22, 2015, at 6:57 AM, jan i <ja...@apache.org> wrote:
>>>>>
>>>>> On Thursday, January 22, 2015, Alan D. Cabrera <ad...@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).
>>>
>>> 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 rest API. This API can be accessed by a variety of tools including whimsy.
>>>
>>> My general efforts here are not simple busywork. Disparate sources of data, often wildly inconsistent, need to be consolidated. The consolidated, canonical, data sources need to be put behind rest APIs where they can be accessed by a variety of tooling, including whimsy. Once we get to this state all manner of automation is possible.
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
> On Jan 22, 2015, at 7:34 AM, sebb <se...@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.
> 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.
>
> There will then be a single source of the data (the asf-auth file).
>
> That would (I think) be a worthwhile improvement on the current situation.
>
> 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.
>
> This would also be a useful test of the REST API.
> Any teething problems would only affect non-critical applications.
>
>
>> On 22 January 2015 at 15:04, Alan Cabrera <li...@toolazydogs.com> wrote:
>>
>>>> On Jan 22, 2015, at 6:57 AM, jan i <ja...@apache.org> wrote:
>>>>
>>>> On Thursday, January 22, 2015, Alan D. Cabrera <ad...@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).
>>
>> 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 rest API. This API can be accessed by a variety of tools including whimsy.
>>
>> My general efforts here are not simple busywork. Disparate sources of data, often wildly inconsistent, need to be consolidated. The consolidated, canonical, data sources need to be put behind rest APIs where they can be accessed by a variety of tooling, including whimsy. Once we get to this state all manner of automation is possible.
>>
>>
>> Regards,
>> Alan
>>
>>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by sebb <se...@gmail.com>.
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.
However if my suggestion of adding -ppmc entries to asf-auth is
acceptable to Infra, then this can be implemented very quickly.
The podling status files can then be updated to point to the extracted
data on people.a.o or whimsy as appropriate.
There will then be a single source of the data (the asf-auth file).
That would (I think) be a worthwhile improvement on the current situation.
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.
This would also be a useful test of the REST API.
Any teething problems would only affect non-critical applications.
On 22 January 2015 at 15:04, Alan Cabrera <li...@toolazydogs.com> wrote:
>
>> On Jan 22, 2015, at 6:57 AM, jan i <ja...@apache.org> wrote:
>>
>>> On Thursday, January 22, 2015, Alan D. Cabrera <ad...@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).
>>
>
> 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 rest API. This API can be accessed by a variety of tools including whimsy.
>
> My general efforts here are not simple busywork. Disparate sources of data, often wildly inconsistent, need to be consolidated. The consolidated, canonical, data sources need to be put behind rest APIs where they can be accessed by a variety of tooling, including whimsy. Once we get to this state all manner of automation is possible.
>
>
> Regards,
> Alan
>
>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by Alan Cabrera <li...@toolazydogs.com>.
> On Jan 22, 2015, at 6:57 AM, jan i <ja...@apache.org> wrote:
>
>> On Thursday, January 22, 2015, Alan D. Cabrera <ad...@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).
>
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 rest API. This API can be accessed by a variety of tools including whimsy.
My general efforts here are not simple busywork. Disparate sources of data, often wildly inconsistent, need to be consolidated. The consolidated, canonical, data sources need to be put behind rest APIs where they can be accessed by a variety of tooling, including whimsy. Once we get to this state all manner of automation is possible.
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by jan i <ja...@apache.org>.
On Thursday, January 22, 2015, Alan D. Cabrera <ad...@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.
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
> On Jan 22, 2015, at 4:45 AM, sebb <se...@gmail.com> wrote:
>
> On 22 January 2015 at 12:20, jan i <jani@apache.org <ma...@apache.org>> wrote:
>> On Thursday, January 22, 2015, sebb <se...@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.
>
> 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.
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by sebb <se...@gmail.com>.
On 22 January 2015 at 12:20, jan i <ja...@apache.org> wrote:
> On Thursday, January 22, 2015, sebb <se...@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.
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.
> rgds
> jan i
>
>>
>> >
>> > Regards,
>> > Alan
>> >
>> >
>> >
>> >
>>
>
>
> --
> Sent from My iPad, sorry for any misspellings.
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by jan i <ja...@apache.org>.
On Thursday, January 22, 2015, sebb <se...@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.
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by sebb <se...@gmail.com>.
On 21 January 2015 at 17:42, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>> On Jan 21, 2015, at 1:54 AM, Daniel Gruno <hu...@apache.org> 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.
>
> Regards,
> Alan
>
>
>
>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 21, 2015, at 1:54 AM, Daniel Gruno <hu...@apache.org> 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?
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by Daniel Gruno <hu...@apache.org>.
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?
With regards,
Daniel.
>> I’m happy to scrape this information together and, if given the privs,
>> complete the work.
>>
>>
>> Regards,
>> Alan
>>
>>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by jan i <ja...@apache.org>.
On 21 January 2015 at 00:57, sebb <se...@gmail.com> wrote:
> On 20 January 2015 at 23:43, jan i <ja...@apache.org> wrote:
> > On 21 January 2015 at 00:23, sebb <se...@gmail.com> wrote:
> >
> >> On 20 January 2015 at 23:08, jan i <ja...@apache.org> wrote:
> >> > On 20 January 2015 at 23:48, sebb <se...@gmail.com> wrote:
> >> >
> >> >> On 20 January 2015 at 21:12, Alan D. Cabrera <li...@toolazydogs.com>
> >> wrote:
> >> >> >
> >> >> >> On Jan 20, 2015, at 1:00 PM, David Nalley <da...@gnsa.us> wrote:
> >> >> >>
> >> >> >> On Tue, Jan 20, 2015 at 3:14 PM, Alan D. Cabrera <
> >> list@toolazydogs.com
> >> >> <ma...@toolazydogs.com>> wrote:
> >> >> >>>
> >> >> >>>> On Jan 20, 2015, at 12:04 PM, David Nalley <da...@gnsa.us>
> wrote:
> >> >> >>>>
> >> >> >>>> On Tue, Jan 20, 2015 at 3:01 PM, Alan D. Cabrera <
> >> >> list@toolazydogs.com> wrote:
> >> >> >>>>>
> >> >> >>>>>> On Jan 20, 2015, at 11:56 AM, David Nalley <da...@gnsa.us>
> >> wrote:
> >> >> >>>>>>
> >> >> >>>>>> On Tue, Jan 20, 2015 at 2:50 PM, Alan D. Cabrera <
> >> >> list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
> >> >> >>>>>>>
> >> >> >>>>>>>> On Jan 20, 2015, at 11:31 AM, jan i <ja...@apache.org>
> wrote:
> >> >> >>>>>>>>
> >> >> >>>>>>>> On 20 January 2015 at 20:22, Alan D. Cabrera <
> >> >> list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
> >> >> >>>>>>>>
> >> >> >>>>>>>>>
> >> >> >>>>>>>>>> On Jan 20, 2015, at 11:19 AM, jan i <ja...@apache.org>
> wrote:
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>> On 20 January 2015 at 20:12, Alan D. Cabrera <
> >> >> list@toolazydogs.com>
> >> >> >>>>>>>>> wrote:
> >> >> >>>>>>>>>>
> >> >> >>>>>>>>>>>
> >> >> >>>>>>>>>>>> On Jan 20, 2015, at 11:08 AM, sebb <se...@gmail.com>
> >> wrote:
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> On 20 January 2015 at 18:12, Alan D. Cabrera <
> >> >> adc@toolazydogs.com>
> >> >> >>>>>>>>>>> wrote:
> >> >> >>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>> On Jan 20, 2015, at 10:08 AM, David Nalley <
> >> david@gnsa.us>
> >> >> wrote:
> >> >> >>>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>> Is there a reason it needs to be added?
> >> >> >>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>> That seems like an odd question and I would turn it
> around
> >> >> and ask, is
> >> >> >>>>>>>>>>> there a reason why it shouldn’t?
> >> >> >>>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>> IIRC that page is derived from the authorization file
> for
> >> >> SVN -
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> Yes
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>>>> Brooklyn doesn't use svn, so no listing.
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> It does not *need* an entry in asf-auth, but one can be
> >> >> provided.
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>>> Time to fix the tooling… :) Where’s the code that
> >> generates
> >> >> those
> >> >> >>>>>>>>>>> pages?
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> The tooling is not broken.
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> There is currently no readily accessible data defining
> the
> >> >> members 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
> >> >> <
> >> >>
> >>
> https://svn.apache.org/repos/infra/infrastructure/trunk/subversion/authorization/asf-authorization-template
> >> >> >
> >> >> >>>>>>>>
> >> >> >>>>>>>> Search for "bookkeeper=breed"
> >> >> >>>>>>>>
> >> >> >>>>>>>> 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’m not sure if
> >> >> 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’s all incubator committers, as Jan said in
> >> another
> >> >> 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
> >> >> for 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’m hearing a description of all the complicated things that occur
> >> >> because we don’t put podling membership information in LDAP.
> >> >>
> >> >> What complicated things?
> >> >>
> >> >> > We can simplify that, that’s a tooling issue.
> >> >> > there’s no requirement to have membership information in a website
> 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
> >> >> non-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
> >> >> podling membership is implicitly managed in an SVN auth file.
> >> >>
> >> >> The source is the SVN auth file.
> >> >>
> >> > Actually not ! the SVN auth file contains all committers for a
> podling,
> >> but
> >> > not who is PPMC.
> >>
> >> I was under the impression that the PPMC consisted of all the
> >> committers for the podling.
> >>
> >
> > Initial committers == initial PPMC.
>
> Agreed.
>
> > But committers added after the podling
> > entered incubator might, but need not be PPMC.
>
> That is news to me; I thought the idea was building community rather
> than acquiring developers but I could be wrong.
>
Since when is PMC (or PPMC) == community ?
Of course the idea is to build community, but we have a clear definition of
roles for committer and PMC (PPMC).
To me a community is contributors+committers+PMC in short everyone who is
active in the project.
Btw, committers is not only developers but all kind of people interested in
a subset of the project (e.g. Documentation) whiich I am sure you agree to.
rgds
jan I.
>
> >
> > the same goes for mentors, initial mentors == PPMC and commiter. Those
> who
> > are added later should be voted in.
> >
> > Some podlings have a rule committers == PPMC but not all.
> >
> >
> >>
> >> At graduation time, those committers who are no longer involved will
> >> generally not be included in the initial PMC.
> >>
> >
> > I have understood this differently. Those PPMC members who are no longer
> > involved will not be included in the initial PMC.
>
> It's only different if committers != PPMC.
> Since I assumed they were equal, when I wrote committers I could have
> written PPMC.
>
> > I had the impression that PPMC members are asked if they want to be PMC
> as
> > part of the graduation process (no voting just asking).
>
> So long as there is general consensus I don't think it matters whether
> there is a vote or not.
> But I would expect only active committers to become members of the
> initial PMC, because it is important that the PMC are fully engaged
> with the project going forward.
> For this reason mentors may not wish to join the initial PMC - their
> job is done (if not, the podling is not ready!)
>
> > rgds
> > jan i.
> >
> >
> >>
> >> >
> >> >> Frankly, I’m surprised that I’m getting pushback in putting 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
> >> >> group.
> >> >>
> >> > I agree on that, but that would currently only give committers not
> PPMC
> >> of
> >> > a podling.
> >> >
> >> > The only place PPMC is registred is in the podlings status file (xml).
> >>
> >> That assumes there is a difference between committers and PPMC for a
> >> podling.
> >> As I wrote above, that is not my understanding.
> >>
> >> > rgds
> >> > jan i
> >> >
> >> >
> >> >
> >> >>
> >> >> >
> >> >> > Regards,
> >> >> > Alan
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >>
>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 21, 2015, at 12:47 AM, jan i <ja...@apache.org> wrote:
>
> On Wednesday, January 21, 2015, Alan D. Cabrera <adc@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>
>>
>>> On Jan 20, 2015, at 4:03 PM, Marvin Humphrey <marvin@rectangular.com <ma...@rectangular.com>
>> <javascript:;>> wrote:
>>>
>>> On Tue, Jan 20, 2015 at 3:57 PM, sebb <sebbaz@gmail.com <ma...@gmail.com> <javascript:;>>
>> wrote:
>>>
>>>>> But committers added after the podling
>>>>> entered incubator might, but need not be PPMC.
>>>>
>>>> That is news to me; I thought the idea was building community rather
>>>> than acquiring developers but I could be wrong.
>>>
>>> It's up to the community. This is an old debate, and some people feel
>>> very strongly one way or the other. The Incubator accommodates both.
>>
>> This is why we need LDAP groups for PPMC members. I’m glad we’re on the
>> same page now.
>
>
>> 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 <ma...@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.
You describe a tooling problem, something that can easily be remedied in a straightforward, secure, manner.
Look, this is not a new problem that has not been solved elsewhere thousands of times before.
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by jan i <ja...@apache.org>.
On Wednesday, January 21, 2015, Alan D. Cabrera <ad...@toolazydogs.com> wrote:
>
> > On Jan 20, 2015, at 4:03 PM, Marvin Humphrey <marvin@rectangular.com
> <javascript:;>> wrote:
> >
> > On Tue, Jan 20, 2015 at 3:57 PM, sebb <sebbaz@gmail.com <javascript:;>>
> wrote:
> >
> >>> But committers added after the podling
> >>> entered incubator might, but need not be PPMC.
> >>
> >> That is news to me; I thought the idea was building community rather
> >> than acquiring developers but I could be wrong.
> >
> > It's up to the community. This is an old debate, and some people feel
> > very strongly one way or the other. The Incubator accommodates both.
>
> This is why we need LDAP groups for PPMC members. I’m glad we’re on the
> same page now.
> 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
>
> I’m happy to scrape this information together and, if given the privs,
> complete the work.
>
>
> Regards,
> Alan
>
>
--
Sent from My iPad, sorry for any misspellings.
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
> On Jan 20, 2015, at 4:03 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
>
> On Tue, Jan 20, 2015 at 3:57 PM, sebb <se...@gmail.com> wrote:
>
>>> But committers added after the podling
>>> entered incubator might, but need not be PPMC.
>>
>> That is news to me; I thought the idea was building community rather
>> than acquiring developers but I could be wrong.
>
> It's up to the community. This is an old debate, and some people feel
> very strongly one way or the other. The Incubator accommodates both.
This is why we need LDAP groups for PPMC members. I’m glad we’re on the same page now.
Can we all agree that we need to put this into LDAP?
I’m happy to scrape this information together and, if given the privs, complete the work.
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Jan 20, 2015 at 3:57 PM, sebb <se...@gmail.com> wrote:
>> But committers added after the podling
>> entered incubator might, but need not be PPMC.
>
> That is news to me; I thought the idea was building community rather
> than acquiring developers but I could be wrong.
It's up to the community. This is an old debate, and some people feel
very strongly one way or the other. The Incubator accommodates both.
Marvin Humphrey
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by sebb <se...@gmail.com>.
On 20 January 2015 at 23:43, jan i <ja...@apache.org> wrote:
> On 21 January 2015 at 00:23, sebb <se...@gmail.com> wrote:
>
>> On 20 January 2015 at 23:08, jan i <ja...@apache.org> wrote:
>> > On 20 January 2015 at 23:48, sebb <se...@gmail.com> wrote:
>> >
>> >> On 20 January 2015 at 21:12, Alan D. Cabrera <li...@toolazydogs.com>
>> wrote:
>> >> >
>> >> >> On Jan 20, 2015, at 1:00 PM, David Nalley <da...@gnsa.us> wrote:
>> >> >>
>> >> >> On Tue, Jan 20, 2015 at 3:14 PM, Alan D. Cabrera <
>> list@toolazydogs.com
>> >> <ma...@toolazydogs.com>> wrote:
>> >> >>>
>> >> >>>> On Jan 20, 2015, at 12:04 PM, David Nalley <da...@gnsa.us> wrote:
>> >> >>>>
>> >> >>>> On Tue, Jan 20, 2015 at 3:01 PM, Alan D. Cabrera <
>> >> list@toolazydogs.com> wrote:
>> >> >>>>>
>> >> >>>>>> On Jan 20, 2015, at 11:56 AM, David Nalley <da...@gnsa.us>
>> wrote:
>> >> >>>>>>
>> >> >>>>>> On Tue, Jan 20, 2015 at 2:50 PM, Alan D. Cabrera <
>> >> list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>> >> >>>>>>>
>> >> >>>>>>>> On Jan 20, 2015, at 11:31 AM, jan i <ja...@apache.org> wrote:
>> >> >>>>>>>>
>> >> >>>>>>>> On 20 January 2015 at 20:22, Alan D. Cabrera <
>> >> list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>> >> >>>>>>>>
>> >> >>>>>>>>>
>> >> >>>>>>>>>> On Jan 20, 2015, at 11:19 AM, jan i <ja...@apache.org> wrote:
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> On 20 January 2015 at 20:12, Alan D. Cabrera <
>> >> list@toolazydogs.com>
>> >> >>>>>>>>> wrote:
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>>> On Jan 20, 2015, at 11:08 AM, sebb <se...@gmail.com>
>> wrote:
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> On 20 January 2015 at 18:12, Alan D. Cabrera <
>> >> adc@toolazydogs.com>
>> >> >>>>>>>>>>> wrote:
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> On Jan 20, 2015, at 10:08 AM, David Nalley <
>> david@gnsa.us>
>> >> wrote:
>> >> >>>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> Is there a reason it needs to be added?
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>> That seems like an odd question and I would turn it around
>> >> and ask, is
>> >> >>>>>>>>>>> there a reason why it shouldn’t?
>> >> >>>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> IIRC that page is derived from the authorization file for
>> >> SVN -
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> Yes
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>>>> Brooklyn doesn't use svn, so no listing.
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> It does not *need* an entry in asf-auth, but one can be
>> >> provided.
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>>> Time to fix the tooling… :) Where’s the code that
>> generates
>> >> those
>> >> >>>>>>>>>>> pages?
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> The tooling is not broken.
>> >> >>>>>>>>>>>>
>> >> >>>>>>>>>>>> There is currently no readily accessible data defining the
>> >> members 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
>> >> <
>> >>
>> https://svn.apache.org/repos/infra/infrastructure/trunk/subversion/authorization/asf-authorization-template
>> >> >
>> >> >>>>>>>>
>> >> >>>>>>>> Search for "bookkeeper=breed"
>> >> >>>>>>>>
>> >> >>>>>>>> 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’m not sure if
>> >> 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’s all incubator committers, as Jan said in
>> another
>> >> 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
>> >> for 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’m hearing a description of all the complicated things that occur
>> >> because we don’t put podling membership information in LDAP.
>> >>
>> >> What complicated things?
>> >>
>> >> > We can simplify that, that’s a tooling issue.
>> >> > there’s no requirement to have membership information in a website 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
>> >> non-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
>> >> podling membership is implicitly managed in an SVN auth file.
>> >>
>> >> The source is the SVN auth file.
>> >>
>> > Actually not ! the SVN auth file contains all committers for a podling,
>> but
>> > not who is PPMC.
>>
>> I was under the impression that the PPMC consisted of all the
>> committers for the podling.
>>
>
> Initial committers == initial PPMC.
Agreed.
> But committers added after the podling
> entered incubator might, but need not be PPMC.
That is news to me; I thought the idea was building community rather
than acquiring developers but I could be wrong.
>
> the same goes for mentors, initial mentors == PPMC and commiter. Those who
> are added later should be voted in.
>
> Some podlings have a rule committers == PPMC but not all.
>
>
>>
>> At graduation time, those committers who are no longer involved will
>> generally not be included in the initial PMC.
>>
>
> I have understood this differently. Those PPMC members who are no longer
> involved will not be included in the initial PMC.
It's only different if committers != PPMC.
Since I assumed they were equal, when I wrote committers I could have
written PPMC.
> I had the impression that PPMC members are asked if they want to be PMC as
> part of the graduation process (no voting just asking).
So long as there is general consensus I don't think it matters whether
there is a vote or not.
But I would expect only active committers to become members of the
initial PMC, because it is important that the PMC are fully engaged
with the project going forward.
For this reason mentors may not wish to join the initial PMC - their
job is done (if not, the podling is not ready!)
> rgds
> jan i.
>
>
>>
>> >
>> >> Frankly, I’m surprised that I’m getting pushback in putting 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
>> >> group.
>> >>
>> > I agree on that, but that would currently only give committers not PPMC
>> of
>> > a podling.
>> >
>> > The only place PPMC is registred is in the podlings status file (xml).
>>
>> That assumes there is a difference between committers and PPMC for a
>> podling.
>> As I wrote above, that is not my understanding.
>>
>> > rgds
>> > jan i
>> >
>> >
>> >
>> >>
>> >> >
>> >> > Regards,
>> >> > Alan
>> >> >
>> >> >
>> >> >
>> >>
>>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by jan i <ja...@apache.org>.
On 21 January 2015 at 00:23, sebb <se...@gmail.com> wrote:
> On 20 January 2015 at 23:08, jan i <ja...@apache.org> wrote:
> > On 20 January 2015 at 23:48, sebb <se...@gmail.com> wrote:
> >
> >> On 20 January 2015 at 21:12, Alan D. Cabrera <li...@toolazydogs.com>
> wrote:
> >> >
> >> >> On Jan 20, 2015, at 1:00 PM, David Nalley <da...@gnsa.us> wrote:
> >> >>
> >> >> On Tue, Jan 20, 2015 at 3:14 PM, Alan D. Cabrera <
> list@toolazydogs.com
> >> <ma...@toolazydogs.com>> wrote:
> >> >>>
> >> >>>> On Jan 20, 2015, at 12:04 PM, David Nalley <da...@gnsa.us> wrote:
> >> >>>>
> >> >>>> On Tue, Jan 20, 2015 at 3:01 PM, Alan D. Cabrera <
> >> list@toolazydogs.com> wrote:
> >> >>>>>
> >> >>>>>> On Jan 20, 2015, at 11:56 AM, David Nalley <da...@gnsa.us>
> wrote:
> >> >>>>>>
> >> >>>>>> On Tue, Jan 20, 2015 at 2:50 PM, Alan D. Cabrera <
> >> list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
> >> >>>>>>>
> >> >>>>>>>> On Jan 20, 2015, at 11:31 AM, jan i <ja...@apache.org> wrote:
> >> >>>>>>>>
> >> >>>>>>>> On 20 January 2015 at 20:22, Alan D. Cabrera <
> >> list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
> >> >>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>> On Jan 20, 2015, at 11:19 AM, jan i <ja...@apache.org> wrote:
> >> >>>>>>>>>>
> >> >>>>>>>>>> On 20 January 2015 at 20:12, Alan D. Cabrera <
> >> list@toolazydogs.com>
> >> >>>>>>>>> wrote:
> >> >>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>> On Jan 20, 2015, at 11:08 AM, sebb <se...@gmail.com>
> wrote:
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> On 20 January 2015 at 18:12, Alan D. Cabrera <
> >> adc@toolazydogs.com>
> >> >>>>>>>>>>> wrote:
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> On Jan 20, 2015, at 10:08 AM, David Nalley <
> david@gnsa.us>
> >> wrote:
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> Is there a reason it needs to be added?
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> That seems like an odd question and I would turn it around
> >> and ask, is
> >> >>>>>>>>>>> there a reason why it shouldn’t?
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> IIRC that page is derived from the authorization file for
> >> SVN -
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> Yes
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>>> Brooklyn doesn't use svn, so no listing.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> It does not *need* an entry in asf-auth, but one can be
> >> provided.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>> Time to fix the tooling… :) Where’s the code that
> generates
> >> those
> >> >>>>>>>>>>> pages?
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> The tooling is not broken.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> There is currently no readily accessible data defining the
> >> members 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
> >> <
> >>
> https://svn.apache.org/repos/infra/infrastructure/trunk/subversion/authorization/asf-authorization-template
> >> >
> >> >>>>>>>>
> >> >>>>>>>> Search for "bookkeeper=breed"
> >> >>>>>>>>
> >> >>>>>>>> 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’m not sure if
> >> 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’s all incubator committers, as Jan said in
> another
> >> 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
> >> for 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’m hearing a description of all the complicated things that occur
> >> because we don’t put podling membership information in LDAP.
> >>
> >> What complicated things?
> >>
> >> > We can simplify that, that’s a tooling issue.
> >> > there’s no requirement to have membership information in a website 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
> >> non-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
> >> podling membership is implicitly managed in an SVN auth file.
> >>
> >> The source is the SVN auth file.
> >>
> > Actually not ! the SVN auth file contains all committers for a podling,
> but
> > not who is PPMC.
>
> I was under the impression that the PPMC consisted of all the
> committers for the podling.
>
Initial committers == initial PPMC. But committers added after the podling
entered incubator might, but need not be PPMC.
the same goes for mentors, initial mentors == PPMC and commiter. Those who
are added later should be voted in.
Some podlings have a rule committers == PPMC but not all.
>
> At graduation time, those committers who are no longer involved will
> generally not be included in the initial PMC.
>
I have understood this differently. Those PPMC members who are no longer
involved will not be included in the initial PMC.
I had the impression that PPMC members are asked if they want to be PMC as
part of the graduation process (no voting just asking).
rgds
jan i.
>
> >
> >> Frankly, I’m surprised that I’m getting pushback in putting 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
> >> group.
> >>
> > I agree on that, but that would currently only give committers not PPMC
> of
> > a podling.
> >
> > The only place PPMC is registred is in the podlings status file (xml).
>
> That assumes there is a difference between committers and PPMC for a
> podling.
> As I wrote above, that is not my understanding.
>
> > rgds
> > jan i
> >
> >
> >
> >>
> >> >
> >> > Regards,
> >> > Alan
> >> >
> >> >
> >> >
> >>
>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by sebb <se...@gmail.com>.
On 20 January 2015 at 23:08, jan i <ja...@apache.org> wrote:
> On 20 January 2015 at 23:48, sebb <se...@gmail.com> wrote:
>
>> On 20 January 2015 at 21:12, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>> >
>> >> On Jan 20, 2015, at 1:00 PM, David Nalley <da...@gnsa.us> wrote:
>> >>
>> >> On Tue, Jan 20, 2015 at 3:14 PM, Alan D. Cabrera <list@toolazydogs.com
>> <ma...@toolazydogs.com>> wrote:
>> >>>
>> >>>> On Jan 20, 2015, at 12:04 PM, David Nalley <da...@gnsa.us> wrote:
>> >>>>
>> >>>> On Tue, Jan 20, 2015 at 3:01 PM, Alan D. Cabrera <
>> list@toolazydogs.com> wrote:
>> >>>>>
>> >>>>>> On Jan 20, 2015, at 11:56 AM, David Nalley <da...@gnsa.us> wrote:
>> >>>>>>
>> >>>>>> On Tue, Jan 20, 2015 at 2:50 PM, Alan D. Cabrera <
>> list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>> >>>>>>>
>> >>>>>>>> On Jan 20, 2015, at 11:31 AM, jan i <ja...@apache.org> wrote:
>> >>>>>>>>
>> >>>>>>>> On 20 January 2015 at 20:22, Alan D. Cabrera <
>> list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>> On Jan 20, 2015, at 11:19 AM, jan i <ja...@apache.org> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> On 20 January 2015 at 20:12, Alan D. Cabrera <
>> list@toolazydogs.com>
>> >>>>>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>> On Jan 20, 2015, at 11:08 AM, sebb <se...@gmail.com> wrote:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> On 20 January 2015 at 18:12, Alan D. Cabrera <
>> adc@toolazydogs.com>
>> >>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> On Jan 20, 2015, at 10:08 AM, David Nalley <da...@gnsa.us>
>> wrote:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Is there a reason it needs to be added?
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> That seems like an odd question and I would turn it around
>> and ask, is
>> >>>>>>>>>>> there a reason why it shouldn’t?
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> IIRC that page is derived from the authorization file for
>> SVN -
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Yes
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>>> Brooklyn doesn't use svn, so no listing.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> It does not *need* an entry in asf-auth, but one can be
>> provided.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> Time to fix the tooling… :) Where’s the code that generates
>> those
>> >>>>>>>>>>> pages?
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> The tooling is not broken.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> There is currently no readily accessible data defining the
>> members 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
>> <
>> https://svn.apache.org/repos/infra/infrastructure/trunk/subversion/authorization/asf-authorization-template
>> >
>> >>>>>>>>
>> >>>>>>>> Search for "bookkeeper=breed"
>> >>>>>>>>
>> >>>>>>>> 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’m not sure if
>> 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’s all incubator committers, as Jan said in another
>> 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
>> for 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’m hearing a description of all the complicated things that occur
>> because we don’t put podling membership information in LDAP.
>>
>> What complicated things?
>>
>> > We can simplify that, that’s a tooling issue.
>> > there’s no requirement to have membership information in a website 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
>> non-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
>> podling membership is implicitly managed in an SVN auth file.
>>
>> The source is the SVN auth file.
>>
> Actually not ! the SVN auth file contains all committers for a podling, but
> not who is PPMC.
I was under the impression that the PPMC consisted of all the
committers for the podling.
At graduation time, those committers who are no longer involved will
generally not be included in the initial PMC.
>
>> Frankly, I’m surprised that I’m getting pushback in putting 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
>> group.
>>
> I agree on that, but that would currently only give committers not PPMC of
> a podling.
>
> The only place PPMC is registred is in the podlings status file (xml).
That assumes there is a difference between committers and PPMC for a podling.
As I wrote above, that is not my understanding.
> rgds
> jan i
>
>
>
>>
>> >
>> > Regards,
>> > Alan
>> >
>> >
>> >
>>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by jan i <ja...@apache.org>.
On 20 January 2015 at 23:48, sebb <se...@gmail.com> wrote:
> On 20 January 2015 at 21:12, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> >
> >> On Jan 20, 2015, at 1:00 PM, David Nalley <da...@gnsa.us> wrote:
> >>
> >> On Tue, Jan 20, 2015 at 3:14 PM, Alan D. Cabrera <list@toolazydogs.com
> <ma...@toolazydogs.com>> wrote:
> >>>
> >>>> On Jan 20, 2015, at 12:04 PM, David Nalley <da...@gnsa.us> wrote:
> >>>>
> >>>> On Tue, Jan 20, 2015 at 3:01 PM, Alan D. Cabrera <
> list@toolazydogs.com> wrote:
> >>>>>
> >>>>>> On Jan 20, 2015, at 11:56 AM, David Nalley <da...@gnsa.us> wrote:
> >>>>>>
> >>>>>> On Tue, Jan 20, 2015 at 2:50 PM, Alan D. Cabrera <
> list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
> >>>>>>>
> >>>>>>>> On Jan 20, 2015, at 11:31 AM, jan i <ja...@apache.org> wrote:
> >>>>>>>>
> >>>>>>>> On 20 January 2015 at 20:22, Alan D. Cabrera <
> list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> On Jan 20, 2015, at 11:19 AM, jan i <ja...@apache.org> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On 20 January 2015 at 20:12, Alan D. Cabrera <
> list@toolazydogs.com>
> >>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> On Jan 20, 2015, at 11:08 AM, sebb <se...@gmail.com> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 20 January 2015 at 18:12, Alan D. Cabrera <
> adc@toolazydogs.com>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Jan 20, 2015, at 10:08 AM, David Nalley <da...@gnsa.us>
> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Is there a reason it needs to be added?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> That seems like an odd question and I would turn it around
> and ask, is
> >>>>>>>>>>> there a reason why it shouldn’t?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> IIRC that page is derived from the authorization file for
> SVN -
> >>>>>>>>>>>>
> >>>>>>>>>>>> Yes
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> Brooklyn doesn't use svn, so no listing.
> >>>>>>>>>>>>
> >>>>>>>>>>>> It does not *need* an entry in asf-auth, but one can be
> provided.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Time to fix the tooling… :) Where’s the code that generates
> those
> >>>>>>>>>>> pages?
> >>>>>>>>>>>>
> >>>>>>>>>>>> The tooling is not broken.
> >>>>>>>>>>>>
> >>>>>>>>>>>> There is currently no readily accessible data defining the
> members 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
> <
> https://svn.apache.org/repos/infra/infrastructure/trunk/subversion/authorization/asf-authorization-template
> >
> >>>>>>>>
> >>>>>>>> Search for "bookkeeper=breed"
> >>>>>>>>
> >>>>>>>> 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’m not sure if
> 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’s all incubator committers, as Jan said in another
> 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
> for 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’m hearing a description of all the complicated things that occur
> because we don’t put podling membership information in LDAP.
>
> What complicated things?
>
> > We can simplify that, that’s a tooling issue.
> > there’s no requirement to have membership information in a website 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
> non-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
> podling membership is implicitly managed in an SVN auth file.
>
> The source is the SVN auth file.
>
Actually not ! the SVN auth file contains all committers for a podling, but
not who is PPMC.
> Frankly, I’m surprised that I’m getting pushback in putting 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
> group.
>
I agree on that, but that would currently only give committers not PPMC of
a podling.
The only place PPMC is registred is in the podlings status file (xml).
rgds
jan i
>
> >
> > Regards,
> > Alan
> >
> >
> >
>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by sebb <se...@gmail.com>.
On 20 January 2015 at 21:12, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>> On Jan 20, 2015, at 1:00 PM, David Nalley <da...@gnsa.us> wrote:
>>
>> On Tue, Jan 20, 2015 at 3:14 PM, Alan D. Cabrera <list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>>>
>>>> On Jan 20, 2015, at 12:04 PM, David Nalley <da...@gnsa.us> wrote:
>>>>
>>>> On Tue, Jan 20, 2015 at 3:01 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>>>>
>>>>>> On Jan 20, 2015, at 11:56 AM, David Nalley <da...@gnsa.us> wrote:
>>>>>>
>>>>>> On Tue, Jan 20, 2015 at 2:50 PM, Alan D. Cabrera <list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>>>>>>>
>>>>>>>> On Jan 20, 2015, at 11:31 AM, jan i <ja...@apache.org> wrote:
>>>>>>>>
>>>>>>>> On 20 January 2015 at 20:22, Alan D. Cabrera <list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Jan 20, 2015, at 11:19 AM, jan i <ja...@apache.org> wrote:
>>>>>>>>>>
>>>>>>>>>> On 20 January 2015 at 20:12, Alan D. Cabrera <li...@toolazydogs.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On Jan 20, 2015, at 11:08 AM, sebb <se...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 20 January 2015 at 18:12, Alan D. Cabrera <ad...@toolazydogs.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Jan 20, 2015, at 10:08 AM, David Nalley <da...@gnsa.us> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is there a reason it needs to be added?
>>>>>>>>>>>>>
>>>>>>>>>>>>> That seems like an odd question and I would turn it around and ask, is
>>>>>>>>>>> there a reason why it shouldn’t?
>>>>>>>>>>>>>
>>>>>>>>>>>>>> IIRC that page is derived from the authorization file for SVN -
>>>>>>>>>>>>
>>>>>>>>>>>> Yes
>>>>>>>>>>>>
>>>>>>>>>>>>>> Brooklyn doesn't use svn, so no listing.
>>>>>>>>>>>>
>>>>>>>>>>>> It does not *need* an entry in asf-auth, but one can be provided.
>>>>>>>>>>>>
>>>>>>>>>>>>> Time to fix the tooling… :) Where’s the code that generates those
>>>>>>>>>>> pages?
>>>>>>>>>>>>
>>>>>>>>>>>> The tooling is not broken.
>>>>>>>>>>>>
>>>>>>>>>>>> There is currently no readily accessible data defining the members 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 <https://svn.apache.org/repos/infra/infrastructure/trunk/subversion/authorization/asf-authorization-template>
>>>>>>>>
>>>>>>>> Search for "bookkeeper=breed"
>>>>>>>>
>>>>>>>> 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’m not sure if 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’s all incubator committers, as Jan said in another 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 for 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’m hearing a description of all the complicated things that occur because we don’t put podling membership information in LDAP.
What complicated things?
> We can simplify that, that’s a tooling issue.
> there’s no requirement to have membership information in a website 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 non-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 podling membership is implicitly managed in an SVN auth file.
The source is the SVN auth file.
> Frankly, I’m surprised that I’m getting pushback in putting 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 group.
>
> Regards,
> Alan
>
>
>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 20, 2015, at 1:00 PM, David Nalley <da...@gnsa.us> wrote:
>
> On Tue, Jan 20, 2015 at 3:14 PM, Alan D. Cabrera <list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>>
>>> On Jan 20, 2015, at 12:04 PM, David Nalley <da...@gnsa.us> wrote:
>>>
>>> On Tue, Jan 20, 2015 at 3:01 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>>>
>>>>> On Jan 20, 2015, at 11:56 AM, David Nalley <da...@gnsa.us> wrote:
>>>>>
>>>>> On Tue, Jan 20, 2015 at 2:50 PM, Alan D. Cabrera <list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>>>>>>
>>>>>>> On Jan 20, 2015, at 11:31 AM, jan i <ja...@apache.org> wrote:
>>>>>>>
>>>>>>> On 20 January 2015 at 20:22, Alan D. Cabrera <list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>> On Jan 20, 2015, at 11:19 AM, jan i <ja...@apache.org> wrote:
>>>>>>>>>
>>>>>>>>> On 20 January 2015 at 20:12, Alan D. Cabrera <li...@toolazydogs.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Jan 20, 2015, at 11:08 AM, sebb <se...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 20 January 2015 at 18:12, Alan D. Cabrera <ad...@toolazydogs.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Jan 20, 2015, at 10:08 AM, David Nalley <da...@gnsa.us> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is there a reason it needs to be added?
>>>>>>>>>>>>
>>>>>>>>>>>> That seems like an odd question and I would turn it around and ask, is
>>>>>>>>>> there a reason why it shouldn’t?
>>>>>>>>>>>>
>>>>>>>>>>>>> IIRC that page is derived from the authorization file for SVN -
>>>>>>>>>>>
>>>>>>>>>>> Yes
>>>>>>>>>>>
>>>>>>>>>>>>> Brooklyn doesn't use svn, so no listing.
>>>>>>>>>>>
>>>>>>>>>>> It does not *need* an entry in asf-auth, but one can be provided.
>>>>>>>>>>>
>>>>>>>>>>>> Time to fix the tooling… :) Where’s the code that generates those
>>>>>>>>>> pages?
>>>>>>>>>>>
>>>>>>>>>>> The tooling is not broken.
>>>>>>>>>>>
>>>>>>>>>>> There is currently no readily accessible data defining the members 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 <https://svn.apache.org/repos/infra/infrastructure/trunk/subversion/authorization/asf-authorization-template>
>>>>>>>
>>>>>>> Search for "bookkeeper=breed"
>>>>>>>
>>>>>>> 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’m not sure if 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’s all incubator committers, as Jan said in another 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 for 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’m hearing a description of all the complicated things that occur because we don’t put podling membership information in LDAP.
We can simplify that, that’s a tooling issue.
there’s no requirement to have membership information in a website 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 non-podlings
> Presumably if we added an LDAP group for the podling we'd also need to
> add a PPMC group for the podling as well.
Yes, and that would be a good thing.
> 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 podling membership is implicitly managed in an SVN auth file.
Frankly, I’m surprised that I’m getting pushback in putting podling group information in LDAP.
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by David Nalley <da...@gnsa.us>.
On Tue, Jan 20, 2015 at 3:14 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>> On Jan 20, 2015, at 12:04 PM, David Nalley <da...@gnsa.us> wrote:
>>
>> On Tue, Jan 20, 2015 at 3:01 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>>
>>>> On Jan 20, 2015, at 11:56 AM, David Nalley <da...@gnsa.us> wrote:
>>>>
>>>> On Tue, Jan 20, 2015 at 2:50 PM, Alan D. Cabrera <list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>>>>>
>>>>>> On Jan 20, 2015, at 11:31 AM, jan i <ja...@apache.org> wrote:
>>>>>>
>>>>>> On 20 January 2015 at 20:22, Alan D. Cabrera <list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>>>>>>
>>>>>>>
>>>>>>>> On Jan 20, 2015, at 11:19 AM, jan i <ja...@apache.org> wrote:
>>>>>>>>
>>>>>>>> On 20 January 2015 at 20:12, Alan D. Cabrera <li...@toolazydogs.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Jan 20, 2015, at 11:08 AM, sebb <se...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On 20 January 2015 at 18:12, Alan D. Cabrera <ad...@toolazydogs.com>
>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Jan 20, 2015, at 10:08 AM, David Nalley <da...@gnsa.us> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Is there a reason it needs to be added?
>>>>>>>>>>>
>>>>>>>>>>> That seems like an odd question and I would turn it around and ask, is
>>>>>>>>> there a reason why it shouldn’t?
>>>>>>>>>>>
>>>>>>>>>>>> IIRC that page is derived from the authorization file for SVN -
>>>>>>>>>>
>>>>>>>>>> Yes
>>>>>>>>>>
>>>>>>>>>>>> Brooklyn doesn't use svn, so no listing.
>>>>>>>>>>
>>>>>>>>>> It does not *need* an entry in asf-auth, but one can be provided.
>>>>>>>>>>
>>>>>>>>>>> Time to fix the tooling… :) Where’s the code that generates those
>>>>>>>>> pages?
>>>>>>>>>>
>>>>>>>>>> The tooling is not broken.
>>>>>>>>>>
>>>>>>>>>> There is currently no readily accessible data defining the members 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 <https://svn.apache.org/repos/infra/infrastructure/trunk/subversion/authorization/asf-authorization-template>
>>>>>>
>>>>>> Search for "bookkeeper=breed"
>>>>>>
>>>>>> 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’m not sure if 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’s all incubator committers, as Jan said in another 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 for 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.
Presumably if we added an LDAP group for the podling we'd also need to
add a PPMC group for the podling as well.
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?
--David
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 20, 2015, at 12:04 PM, David Nalley <da...@gnsa.us> wrote:
>
> On Tue, Jan 20, 2015 at 3:01 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>
>>> On Jan 20, 2015, at 11:56 AM, David Nalley <da...@gnsa.us> wrote:
>>>
>>> On Tue, Jan 20, 2015 at 2:50 PM, Alan D. Cabrera <list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>>>>
>>>>> On Jan 20, 2015, at 11:31 AM, jan i <ja...@apache.org> wrote:
>>>>>
>>>>> On 20 January 2015 at 20:22, Alan D. Cabrera <list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>>>>>
>>>>>>
>>>>>>> On Jan 20, 2015, at 11:19 AM, jan i <ja...@apache.org> wrote:
>>>>>>>
>>>>>>> On 20 January 2015 at 20:12, Alan D. Cabrera <li...@toolazydogs.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>> On Jan 20, 2015, at 11:08 AM, sebb <se...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> On 20 January 2015 at 18:12, Alan D. Cabrera <ad...@toolazydogs.com>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Jan 20, 2015, at 10:08 AM, David Nalley <da...@gnsa.us> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Is there a reason it needs to be added?
>>>>>>>>>>
>>>>>>>>>> That seems like an odd question and I would turn it around and ask, is
>>>>>>>> there a reason why it shouldn’t?
>>>>>>>>>>
>>>>>>>>>>> IIRC that page is derived from the authorization file for SVN -
>>>>>>>>>
>>>>>>>>> Yes
>>>>>>>>>
>>>>>>>>>>> Brooklyn doesn't use svn, so no listing.
>>>>>>>>>
>>>>>>>>> It does not *need* an entry in asf-auth, but one can be provided.
>>>>>>>>>
>>>>>>>>>> Time to fix the tooling… :) Where’s the code that generates those
>>>>>>>> pages?
>>>>>>>>>
>>>>>>>>> The tooling is not broken.
>>>>>>>>>
>>>>>>>>> There is currently no readily accessible data defining the members 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 <https://svn.apache.org/repos/infra/infrastructure/trunk/subversion/authorization/asf-authorization-template>
>>>>>
>>>>> Search for "bookkeeper=breed"
>>>>>
>>>>> 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’m not sure if 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’s all incubator committers, as Jan said in another email?
The podling committer membership and PPMC membership information seems to be spread around if at all. Does it make sense to create LDAP groups for them to provide a canonical source?
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by David Nalley <da...@gnsa.us>.
On Tue, Jan 20, 2015 at 3:01 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>> On Jan 20, 2015, at 11:56 AM, David Nalley <da...@gnsa.us> wrote:
>>
>> On Tue, Jan 20, 2015 at 2:50 PM, Alan D. Cabrera <list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>>>
>>>> On Jan 20, 2015, at 11:31 AM, jan i <ja...@apache.org> wrote:
>>>>
>>>> On 20 January 2015 at 20:22, Alan D. Cabrera <list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>>>>
>>>>>
>>>>>> On Jan 20, 2015, at 11:19 AM, jan i <ja...@apache.org> wrote:
>>>>>>
>>>>>> On 20 January 2015 at 20:12, Alan D. Cabrera <li...@toolazydogs.com>
>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>> On Jan 20, 2015, at 11:08 AM, sebb <se...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> On 20 January 2015 at 18:12, Alan D. Cabrera <ad...@toolazydogs.com>
>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Jan 20, 2015, at 10:08 AM, David Nalley <da...@gnsa.us> wrote:
>>>>>>>>>>
>>>>>>>>>> Is there a reason it needs to be added?
>>>>>>>>>
>>>>>>>>> That seems like an odd question and I would turn it around and ask, is
>>>>>>> there a reason why it shouldn’t?
>>>>>>>>>
>>>>>>>>>> IIRC that page is derived from the authorization file for SVN -
>>>>>>>>
>>>>>>>> Yes
>>>>>>>>
>>>>>>>>>> Brooklyn doesn't use svn, so no listing.
>>>>>>>>
>>>>>>>> It does not *need* an entry in asf-auth, but one can be provided.
>>>>>>>>
>>>>>>>>> Time to fix the tooling… :) Where’s the code that generates those
>>>>>>> pages?
>>>>>>>>
>>>>>>>> The tooling is not broken.
>>>>>>>>
>>>>>>>> There is currently no readily accessible data defining the members 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 <https://svn.apache.org/repos/infra/infrastructure/trunk/subversion/authorization/asf-authorization-template>
>>>>
>>>> Search for "bookkeeper=breed"
>>>>
>>>> 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’m not sure if podlings are in LDAP.
>
No.
I meant PMC
Podlings are not projects in the top level sense, and have no entry in LDAP.
--David
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 20, 2015, at 11:56 AM, David Nalley <da...@gnsa.us> wrote:
>
> On Tue, Jan 20, 2015 at 2:50 PM, Alan D. Cabrera <list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>>
>>> On Jan 20, 2015, at 11:31 AM, jan i <ja...@apache.org> wrote:
>>>
>>> On 20 January 2015 at 20:22, Alan D. Cabrera <list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>>>
>>>>
>>>>> On Jan 20, 2015, at 11:19 AM, jan i <ja...@apache.org> wrote:
>>>>>
>>>>> On 20 January 2015 at 20:12, Alan D. Cabrera <li...@toolazydogs.com>
>>>> wrote:
>>>>>
>>>>>>
>>>>>>> On Jan 20, 2015, at 11:08 AM, sebb <se...@gmail.com> wrote:
>>>>>>>
>>>>>>> On 20 January 2015 at 18:12, Alan D. Cabrera <ad...@toolazydogs.com>
>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Jan 20, 2015, at 10:08 AM, David Nalley <da...@gnsa.us> wrote:
>>>>>>>>>
>>>>>>>>> Is there a reason it needs to be added?
>>>>>>>>
>>>>>>>> That seems like an odd question and I would turn it around and ask, is
>>>>>> there a reason why it shouldn’t?
>>>>>>>>
>>>>>>>>> IIRC that page is derived from the authorization file for SVN -
>>>>>>>
>>>>>>> Yes
>>>>>>>
>>>>>>>>> Brooklyn doesn't use svn, so no listing.
>>>>>>>
>>>>>>> It does not *need* an entry in asf-auth, but one can be provided.
>>>>>>>
>>>>>>>> Time to fix the tooling… :) Where’s the code that generates those
>>>>>> pages?
>>>>>>>
>>>>>>> The tooling is not broken.
>>>>>>>
>>>>>>> There is currently no readily accessible data defining the members 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 <https://svn.apache.org/repos/infra/infrastructure/trunk/subversion/authorization/asf-authorization-template>
>>>
>>> Search for "bookkeeper=breed"
>>>
>>> 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’m not sure if podlings are in LDAP.
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by David Nalley <da...@gnsa.us>.
On Tue, Jan 20, 2015 at 2:50 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>> On Jan 20, 2015, at 11:31 AM, jan i <ja...@apache.org> wrote:
>>
>> On 20 January 2015 at 20:22, Alan D. Cabrera <list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>>
>>>
>>>> On Jan 20, 2015, at 11:19 AM, jan i <ja...@apache.org> wrote:
>>>>
>>>> On 20 January 2015 at 20:12, Alan D. Cabrera <li...@toolazydogs.com>
>>> wrote:
>>>>
>>>>>
>>>>>> On Jan 20, 2015, at 11:08 AM, sebb <se...@gmail.com> wrote:
>>>>>>
>>>>>> On 20 January 2015 at 18:12, Alan D. Cabrera <ad...@toolazydogs.com>
>>>>> wrote:
>>>>>>>
>>>>>>>> On Jan 20, 2015, at 10:08 AM, David Nalley <da...@gnsa.us> wrote:
>>>>>>>>
>>>>>>>> Is there a reason it needs to be added?
>>>>>>>
>>>>>>> That seems like an odd question and I would turn it around and ask, is
>>>>> there a reason why it shouldn’t?
>>>>>>>
>>>>>>>> IIRC that page is derived from the authorization file for SVN -
>>>>>>
>>>>>> Yes
>>>>>>
>>>>>>>> Brooklyn doesn't use svn, so no listing.
>>>>>>
>>>>>> It does not *need* an entry in asf-auth, but one can be provided.
>>>>>>
>>>>>>> Time to fix the tooling… :) Where’s the code that generates those
>>>>> pages?
>>>>>>
>>>>>> The tooling is not broken.
>>>>>>
>>>>>> There is currently no readily accessible data defining the members 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 <https://svn.apache.org/repos/infra/infrastructure/trunk/subversion/authorization/asf-authorization-template>
>>
>> Search for "bookkeeper=breed"
>>
>> 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.
--David
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 20, 2015, at 11:31 AM, jan i <ja...@apache.org> wrote:
>
> On 20 January 2015 at 20:22, Alan D. Cabrera <list@toolazydogs.com <ma...@toolazydogs.com>> wrote:
>
>>
>>> On Jan 20, 2015, at 11:19 AM, jan i <ja...@apache.org> wrote:
>>>
>>> On 20 January 2015 at 20:12, Alan D. Cabrera <li...@toolazydogs.com>
>> wrote:
>>>
>>>>
>>>>> On Jan 20, 2015, at 11:08 AM, sebb <se...@gmail.com> wrote:
>>>>>
>>>>> On 20 January 2015 at 18:12, Alan D. Cabrera <ad...@toolazydogs.com>
>>>> wrote:
>>>>>>
>>>>>>> On Jan 20, 2015, at 10:08 AM, David Nalley <da...@gnsa.us> wrote:
>>>>>>>
>>>>>>> Is there a reason it needs to be added?
>>>>>>
>>>>>> That seems like an odd question and I would turn it around and ask, is
>>>> there a reason why it shouldn’t?
>>>>>>
>>>>>>> IIRC that page is derived from the authorization file for SVN -
>>>>>
>>>>> Yes
>>>>>
>>>>>>> Brooklyn doesn't use svn, so no listing.
>>>>>
>>>>> It does not *need* an entry in asf-auth, but one can be provided.
>>>>>
>>>>>> Time to fix the tooling… :) Where’s the code that generates those
>>>> pages?
>>>>>
>>>>> The tooling is not broken.
>>>>>
>>>>> There is currently no readily accessible data defining the members 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 <https://svn.apache.org/repos/infra/infrastructure/trunk/subversion/authorization/asf-authorization-template>
>
> Search for "bookkeeper=breed"
>
> 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?
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by jan i <ja...@apache.org>.
On 20 January 2015 at 20:22, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> > On Jan 20, 2015, at 11:19 AM, jan i <ja...@apache.org> wrote:
> >
> > On 20 January 2015 at 20:12, Alan D. Cabrera <li...@toolazydogs.com>
> wrote:
> >
> >>
> >>> On Jan 20, 2015, at 11:08 AM, sebb <se...@gmail.com> wrote:
> >>>
> >>> On 20 January 2015 at 18:12, Alan D. Cabrera <ad...@toolazydogs.com>
> >> wrote:
> >>>>
> >>>>> On Jan 20, 2015, at 10:08 AM, David Nalley <da...@gnsa.us> wrote:
> >>>>>
> >>>>> Is there a reason it needs to be added?
> >>>>
> >>>> That seems like an odd question and I would turn it around and ask, is
> >> there a reason why it shouldn’t?
> >>>>
> >>>>> IIRC that page is derived from the authorization file for SVN -
> >>>
> >>> Yes
> >>>
> >>>>> Brooklyn doesn't use svn, so no listing.
> >>>
> >>> It does not *need* an entry in asf-auth, but one can be provided.
> >>>
> >>>> Time to fix the tooling… :) Where’s the code that generates those
> >> pages?
> >>>
> >>> The tooling is not broken.
> >>>
> >>> There is currently no readily accessible data defining the members 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=breed"
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).
rgds
jan i.
> > I really do not care whether I have to update the svn authz file or
> another
> > file, and we need to keep the information somewhere.
>
> Neither do I. Just trying to fix Brooklyn.
>
>
> Regards,
> Alan
>
>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 20, 2015, at 11:19 AM, jan i <ja...@apache.org> wrote:
>
> On 20 January 2015 at 20:12, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>>
>>> On Jan 20, 2015, at 11:08 AM, sebb <se...@gmail.com> wrote:
>>>
>>> On 20 January 2015 at 18:12, Alan D. Cabrera <ad...@toolazydogs.com>
>> wrote:
>>>>
>>>>> On Jan 20, 2015, at 10:08 AM, David Nalley <da...@gnsa.us> wrote:
>>>>>
>>>>> Is there a reason it needs to be added?
>>>>
>>>> That seems like an odd question and I would turn it around and ask, is
>> there a reason why it shouldn’t?
>>>>
>>>>> IIRC that page is derived from the authorization file for SVN -
>>>
>>> Yes
>>>
>>>>> Brooklyn doesn't use svn, so no listing.
>>>
>>> It does not *need* an entry in asf-auth, but one can be provided.
>>>
>>>> Time to fix the tooling… :) Where’s the code that generates those
>> pages?
>>>
>>> The tooling is not broken.
>>>
>>> There is currently no readily accessible data defining the members 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?
> I really do not care whether I have to update the svn authz file or another
> file, and we need to keep the information somewhere.
Neither do I. Just trying to fix Brooklyn.
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by jan i <ja...@apache.org>.
On 20 January 2015 at 20:12, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> > On Jan 20, 2015, at 11:08 AM, sebb <se...@gmail.com> wrote:
> >
> > On 20 January 2015 at 18:12, Alan D. Cabrera <ad...@toolazydogs.com>
> wrote:
> >>
> >>> On Jan 20, 2015, at 10:08 AM, David Nalley <da...@gnsa.us> wrote:
> >>>
> >>> Is there a reason it needs to be added?
> >>
> >> That seems like an odd question and I would turn it around and ask, is
> there a reason why it shouldn’t?
> >>
> >>> IIRC that page is derived from the authorization file for SVN -
> >
> > Yes
> >
> >>> Brooklyn doesn't use svn, so no listing.
> >
> > It does not *need* an entry in asf-auth, but one can be provided.
> >
> >> Time to fix the tooling… :) Where’s the code that generates those
> pages?
> >
> > The tooling is not broken.
> >
> > There is currently no readily accessible data defining the members 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.
I really do not care whether I have to update the svn authz file or another
file, and we need to keep the information somewhere.
rgds
jan I.
>
>
> Regards,
> Alan
>
>
>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 20, 2015, at 11:08 AM, sebb <se...@gmail.com> wrote:
>
> On 20 January 2015 at 18:12, Alan D. Cabrera <ad...@toolazydogs.com> wrote:
>>
>>> On Jan 20, 2015, at 10:08 AM, David Nalley <da...@gnsa.us> wrote:
>>>
>>> Is there a reason it needs to be added?
>>
>> That seems like an odd question and I would turn it around and ask, is there a reason why it shouldn’t?
>>
>>> IIRC that page is derived from the authorization file for SVN -
>
> Yes
>
>>> Brooklyn doesn't use svn, so no listing.
>
> It does not *need* an entry in asf-auth, but one can be provided.
>
>> Time to fix the tooling… :) Where’s the code that generates those pages?
>
> The tooling is not broken.
>
> There is currently no readily accessible data defining the members 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?
Regards,
Alan
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by sebb <se...@gmail.com>.
On 20 January 2015 at 18:12, Alan D. Cabrera <ad...@toolazydogs.com> wrote:
>
>> On Jan 20, 2015, at 10:08 AM, David Nalley <da...@gnsa.us> wrote:
>>
>> Is there a reason it needs to be added?
>
> That seems like an odd question and I would turn it around and ask, is there a reason why it shouldn’t?
>
>> IIRC that page is derived from the authorization file for SVN -
Yes
>> Brooklyn doesn't use svn, so no listing.
It does not *need* an entry in asf-auth, but one can be provided.
> Time to fix the tooling… :) Where’s the code that generates those pages?
The tooling is not broken.
There is currently no readily accessible data defining the members of
the Brooklyn podling.
Once a podling graduates, it will have an LDAP group.
>> On Tue, Jan 20, 2015 at 1:02 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>> What do we need to do to add it?
>>>
>>>
>>> Regards,
>>> Alan
>>>
>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
> On Jan 20, 2015, at 10:08 AM, David Nalley <da...@gnsa.us> wrote:
>
> Is there a reason it needs to be added?
That seems like an odd question and I would turn it around and ask, is there a reason why it shouldn’t?
> IIRC that page is derived from the authorization file for SVN -
> Brooklyn doesn't use svn, so no listing.
Time to fix the tooling… :) Where’s the code that generates those pages?
> On Tue, Jan 20, 2015 at 1:02 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>> What do we need to do to add it?
>>
>>
>> Regards,
>> Alan
>>
Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Posted by David Nalley <da...@gnsa.us>.
Is there a reason it needs to be added?
IIRC that page is derived from the authorization file for SVN -
Brooklyn doesn't use svn, so no listing.
On Tue, Jan 20, 2015 at 1:02 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> What do we need to do to add it?
>
>
> Regards,
> Alan
>