You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@whimsical.apache.org by Sam Ruby <ru...@intertwingly.net> on 2016/05/17 22:51:16 UTC
Rethinking TLP creation/migration
Statement of the problem (by Chris Lambertus):
Our process for tlp creation is to run the script, figure out why half
the steps failed, re-run it a few times until it works, then go do all
the manual mailing list creations and jira and conflience etc. etc.
General outline of the solution being explored (by Sam Ruby):
The goal is to make it so that asf-secretary and pmc-chair people can do
most of the work themselves. The first step will be to have me do the
the tlp requests manually this month (I'm in both groups) with the
infrastructure contractors (primarily @fluxo and @pono) providing
guidance and adjusting the authorizations as required. As soon as it
becomes possible for the secretary and pmc chairs to execute these
tasks, focus will turn to automation and providing a web interface.
Current code base:
https://svn.apache.org/repos/infra/infrastructure/trunk/tlpreq
Secretarial tasks will likely be merged into the board agenda tool, pmc
chair tasks will like be merged into the roster tool.
- Sam Ruby
Re: Rethinking TLP creation/migration
Posted by Henri Yandell <ba...@apache.org>.
Makes lots of sense - I love the idea.
Hen
On Sun, May 22, 2016 at 6:00 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> As I am working my way through this code, it occurs to me that much of
> what I am finding could apply to termination of projects. For
> example, if the secretary adds the PMC to LDAP for 'Establish'
> resolutions at the end of the board meeting it might make equal sense
> for the secretary to remove the PMC (and committers) for 'Terminate'
> resolutions.
>
> Thoughts?
>
> - Sam Ruby
>
> On Tue, May 17, 2016 at 6:51 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> > Statement of the problem (by Chris Lambertus):
> >
> > Our process for tlp creation is to run the script, figure out why half
> the
> > steps failed, re-run it a few times until it works, then go do all the
> > manual mailing list creations and jira and conflience etc. etc.
> >
> > General outline of the solution being explored (by Sam Ruby):
> >
> > The goal is to make it so that asf-secretary and pmc-chair people can do
> > most of the work themselves. The first step will be to have me do the
> the
> > tlp requests manually this month (I'm in both groups) with the
> > infrastructure contractors (primarily @fluxo and @pono) providing
> guidance
> > and adjusting the authorizations as required. As soon as it becomes
> > possible for the secretary and pmc chairs to execute these tasks, focus
> will
> > turn to automation and providing a web interface.
> >
> > Current code base:
> >
> > https://svn.apache.org/repos/infra/infrastructure/trunk/tlpreq
> >
> > Secretarial tasks will likely be merged into the board agenda tool, pmc
> > chair tasks will like be merged into the roster tool.
> >
> > - Sam Ruby
>
Re: Rethinking TLP creation/migration
Posted by Sam Ruby <ru...@intertwingly.net>.
On Mon, May 23, 2016 at 3:30 AM, Henk P. Penning <pe...@uu.nl> wrote:
> On Mon, 23 May 2016, Sam Ruby wrote:
>
>> Date: Mon, 23 May 2016 03:00:51 +0200
>> From: Sam Ruby <ru...@intertwingly.net>
>> To: general@attic.apache.org
>> Cc: dev@whimsical.apache.org
>> Subject: Re: Rethinking TLP creation/migration
>> Sender: sa3ruby@gmail.com
>>
>> As I am working my way through this code, it occurs to me that much of
>> what I am finding could apply to termination of projects. For
>> example, if the secretary adds the PMC to LDAP for 'Establish'
>> resolutions at the end of the board meeting it might make equal sense
>> for the secretary to remove the PMC (and committers) for 'Terminate'
>> resolutions.
>>
>> Thoughts?
>
>
> My thoughts ; looking at the ASF bylaws ...
>
> -- the ASF has many PMCs
> -- each PMC has 0, 1 or more projects ;
> PMC Attic is like PMC Incubator ; both have many projects
> -- graduation :
> -- a new PMC is established ;
> -- the projects moves from PMC Incubator to the new PMC
> -- project retirement :
> -- the project moves to PMC Attic
> -- PMC retirement :
> -- the PMC's projects are retired (moved to PMC Attic)
> -- the PMC is terminated
>
> IMHO, PMCs and projects must be treated as distict entities ;
> where each project has a parent (PMC) pointer.
>
> The board (secretary) can
> -- create and terminate PMCs
> -- create projects and move projects between PMCs
We seem to be talking at different meta-levels.
In general, the agenda for a board meeting may contain a number of
Establish and a number of Terminate resolutions. And the end of the
meeting, the Secretary is presented with a list of Establish
resolutions and is given an opportunity to select those that pass.
With the current version of the board agenda tool, this list is then
placed into svn which is used by the tlpreq tool.
What I am working on is to change that code from notifying the
infrastructure team that changes need to be made to actually making
the changes. Instead of only creating one file in svn, it will update
a small number of files in svn, git, or other places (including LDAP).
These files will be used by puppet and/or cron jobs to perform the
needed actions.
So... old process was secretary pushes a button and at a later time a
member of the infrastructure team would log into Minotaur and run a
script once per new project and things like LDAP would be set up. The
new process is that the secretary pushes a button and LDAP is set up.
The same thing is possible for Terminate resolutions. The secretary
could see a list of such resolutions, select those that pass, and push
a button and (for example) the LDAP definitions of the PMC list and
committer list could be removed. Committee-info.txt could be updated,
etc.
- Sam Ruby
> Regards,
>
> Henk Penning
>
>> On Tue, May 17, 2016 at 6:51 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>>>
>>> Statement of the problem (by Chris Lambertus):
>>>
>>> Our process for tlp creation is to run the script, figure out why half
>>> the
>>> steps failed, re-run it a few times until it works, then go do all the
>>> manual mailing list creations and jira and conflience etc. etc.
>>>
>>> General outline of the solution being explored (by Sam Ruby):
>>>
>>> The goal is to make it so that asf-secretary and pmc-chair people can do
>>> most of the work themselves. The first step will be to have me do the
>>> the
>>> tlp requests manually this month (I'm in both groups) with the
>>> infrastructure contractors (primarily @fluxo and @pono) providing
>>> guidance
>>> and adjusting the authorizations as required. As soon as it becomes
>>> possible for the secretary and pmc chairs to execute these tasks, focus
>>> will
>>> turn to automation and providing a web interface.
>>>
>>> Current code base:
>>>
>>> https://svn.apache.org/repos/infra/infrastructure/trunk/tlpreq
>>>
>>> Secretarial tasks will likely be merged into the board agenda tool, pmc
>>> chair tasks will like be merged into the roster tool.
>>>
>>> - Sam Ruby
>>
>>
>
> ------------------------------------------------------------ _
> Henk P. Penning, ICT-beta R Uithof HFG-406 _/ \_
> Faculty of Science, Utrecht University T +31 30 253 4106 / \_/ \
> Budapestlaan 6, 3584CD Utrecht, NL F +31 30 253 4553 \_/ \_/
> http://www.staff.science.uu.nl/~penni101/ M penning@uu.nl \_/
Re: Rethinking TLP creation/migration
Posted by Sam Ruby <ru...@intertwingly.net>.
On Mon, May 23, 2016 at 3:30 AM, Henk P. Penning <pe...@uu.nl> wrote:
> On Mon, 23 May 2016, Sam Ruby wrote:
>
>> Date: Mon, 23 May 2016 03:00:51 +0200
>> From: Sam Ruby <ru...@intertwingly.net>
>> To: general@attic.apache.org
>> Cc: dev@whimsical.apache.org
>> Subject: Re: Rethinking TLP creation/migration
>> Sender: sa3ruby@gmail.com
>>
>> As I am working my way through this code, it occurs to me that much of
>> what I am finding could apply to termination of projects. For
>> example, if the secretary adds the PMC to LDAP for 'Establish'
>> resolutions at the end of the board meeting it might make equal sense
>> for the secretary to remove the PMC (and committers) for 'Terminate'
>> resolutions.
>>
>> Thoughts?
>
>
> My thoughts ; looking at the ASF bylaws ...
>
> -- the ASF has many PMCs
> -- each PMC has 0, 1 or more projects ;
> PMC Attic is like PMC Incubator ; both have many projects
> -- graduation :
> -- a new PMC is established ;
> -- the projects moves from PMC Incubator to the new PMC
> -- project retirement :
> -- the project moves to PMC Attic
> -- PMC retirement :
> -- the PMC's projects are retired (moved to PMC Attic)
> -- the PMC is terminated
>
> IMHO, PMCs and projects must be treated as distict entities ;
> where each project has a parent (PMC) pointer.
>
> The board (secretary) can
> -- create and terminate PMCs
> -- create projects and move projects between PMCs
We seem to be talking at different meta-levels.
In general, the agenda for a board meeting may contain a number of
Establish and a number of Terminate resolutions. And the end of the
meeting, the Secretary is presented with a list of Establish
resolutions and is given an opportunity to select those that pass.
With the current version of the board agenda tool, this list is then
placed into svn which is used by the tlpreq tool.
What I am working on is to change that code from notifying the
infrastructure team that changes need to be made to actually making
the changes. Instead of only creating one file in svn, it will update
a small number of files in svn, git, or other places (including LDAP).
These files will be used by puppet and/or cron jobs to perform the
needed actions.
So... old process was secretary pushes a button and at a later time a
member of the infrastructure team would log into Minotaur and run a
script once per new project and things like LDAP would be set up. The
new process is that the secretary pushes a button and LDAP is set up.
The same thing is possible for Terminate resolutions. The secretary
could see a list of such resolutions, select those that pass, and push
a button and (for example) the LDAP definitions of the PMC list and
committer list could be removed. Committee-info.txt could be updated,
etc.
- Sam Ruby
> Regards,
>
> Henk Penning
>
>> On Tue, May 17, 2016 at 6:51 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>>>
>>> Statement of the problem (by Chris Lambertus):
>>>
>>> Our process for tlp creation is to run the script, figure out why half
>>> the
>>> steps failed, re-run it a few times until it works, then go do all the
>>> manual mailing list creations and jira and conflience etc. etc.
>>>
>>> General outline of the solution being explored (by Sam Ruby):
>>>
>>> The goal is to make it so that asf-secretary and pmc-chair people can do
>>> most of the work themselves. The first step will be to have me do the
>>> the
>>> tlp requests manually this month (I'm in both groups) with the
>>> infrastructure contractors (primarily @fluxo and @pono) providing
>>> guidance
>>> and adjusting the authorizations as required. As soon as it becomes
>>> possible for the secretary and pmc chairs to execute these tasks, focus
>>> will
>>> turn to automation and providing a web interface.
>>>
>>> Current code base:
>>>
>>> https://svn.apache.org/repos/infra/infrastructure/trunk/tlpreq
>>>
>>> Secretarial tasks will likely be merged into the board agenda tool, pmc
>>> chair tasks will like be merged into the roster tool.
>>>
>>> - Sam Ruby
>>
>>
>
> ------------------------------------------------------------ _
> Henk P. Penning, ICT-beta R Uithof HFG-406 _/ \_
> Faculty of Science, Utrecht University T +31 30 253 4106 / \_/ \
> Budapestlaan 6, 3584CD Utrecht, NL F +31 30 253 4553 \_/ \_/
> http://www.staff.science.uu.nl/~penni101/ M penning@uu.nl \_/
Re: Rethinking TLP creation/migration
Posted by "Henk P. Penning" <pe...@uu.nl>.
On Mon, 23 May 2016, Sam Ruby wrote:
> Date: Mon, 23 May 2016 03:00:51 +0200
> From: Sam Ruby <ru...@intertwingly.net>
> To: general@attic.apache.org
> Cc: dev@whimsical.apache.org
> Subject: Re: Rethinking TLP creation/migration
> Sender: sa3ruby@gmail.com
>
> As I am working my way through this code, it occurs to me that much of
> what I am finding could apply to termination of projects. For
> example, if the secretary adds the PMC to LDAP for 'Establish'
> resolutions at the end of the board meeting it might make equal sense
> for the secretary to remove the PMC (and committers) for 'Terminate'
> resolutions.
>
> Thoughts?
My thoughts ; looking at the ASF bylaws ...
-- the ASF has many PMCs
-- each PMC has 0, 1 or more projects ;
PMC Attic is like PMC Incubator ; both have many projects
-- graduation :
-- a new PMC is established ;
-- the projects moves from PMC Incubator to the new PMC
-- project retirement :
-- the project moves to PMC Attic
-- PMC retirement :
-- the PMC's projects are retired (moved to PMC Attic)
-- the PMC is terminated
IMHO, PMCs and projects must be treated as distict entities ;
where each project has a parent (PMC) pointer.
The board (secretary) can
-- create and terminate PMCs
-- create projects and move projects between PMCs
> - Sam Ruby
Regards,
Henk Penning
> On Tue, May 17, 2016 at 6:51 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>> Statement of the problem (by Chris Lambertus):
>>
>> Our process for tlp creation is to run the script, figure out why half the
>> steps failed, re-run it a few times until it works, then go do all the
>> manual mailing list creations and jira and conflience etc. etc.
>>
>> General outline of the solution being explored (by Sam Ruby):
>>
>> The goal is to make it so that asf-secretary and pmc-chair people can do
>> most of the work themselves. The first step will be to have me do the the
>> tlp requests manually this month (I'm in both groups) with the
>> infrastructure contractors (primarily @fluxo and @pono) providing guidance
>> and adjusting the authorizations as required. As soon as it becomes
>> possible for the secretary and pmc chairs to execute these tasks, focus will
>> turn to automation and providing a web interface.
>>
>> Current code base:
>>
>> https://svn.apache.org/repos/infra/infrastructure/trunk/tlpreq
>>
>> Secretarial tasks will likely be merged into the board agenda tool, pmc
>> chair tasks will like be merged into the roster tool.
>>
>> - Sam Ruby
>
------------------------------------------------------------ _
Henk P. Penning, ICT-beta R Uithof HFG-406 _/ \_
Faculty of Science, Utrecht University T +31 30 253 4106 / \_/ \
Budapestlaan 6, 3584CD Utrecht, NL F +31 30 253 4553 \_/ \_/
http://www.staff.science.uu.nl/~penni101/ M penning@uu.nl \_/
Re: Rethinking TLP creation/migration
Posted by "Henk P. Penning" <pe...@uu.nl>.
On Mon, 23 May 2016, Sam Ruby wrote:
> Date: Mon, 23 May 2016 03:00:51 +0200
> From: Sam Ruby <ru...@intertwingly.net>
> To: general@attic.apache.org
> Cc: dev@whimsical.apache.org
> Subject: Re: Rethinking TLP creation/migration
> Sender: sa3ruby@gmail.com
>
> As I am working my way through this code, it occurs to me that much of
> what I am finding could apply to termination of projects. For
> example, if the secretary adds the PMC to LDAP for 'Establish'
> resolutions at the end of the board meeting it might make equal sense
> for the secretary to remove the PMC (and committers) for 'Terminate'
> resolutions.
>
> Thoughts?
My thoughts ; looking at the ASF bylaws ...
-- the ASF has many PMCs
-- each PMC has 0, 1 or more projects ;
PMC Attic is like PMC Incubator ; both have many projects
-- graduation :
-- a new PMC is established ;
-- the projects moves from PMC Incubator to the new PMC
-- project retirement :
-- the project moves to PMC Attic
-- PMC retirement :
-- the PMC's projects are retired (moved to PMC Attic)
-- the PMC is terminated
IMHO, PMCs and projects must be treated as distict entities ;
where each project has a parent (PMC) pointer.
The board (secretary) can
-- create and terminate PMCs
-- create projects and move projects between PMCs
> - Sam Ruby
Regards,
Henk Penning
> On Tue, May 17, 2016 at 6:51 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>> Statement of the problem (by Chris Lambertus):
>>
>> Our process for tlp creation is to run the script, figure out why half the
>> steps failed, re-run it a few times until it works, then go do all the
>> manual mailing list creations and jira and conflience etc. etc.
>>
>> General outline of the solution being explored (by Sam Ruby):
>>
>> The goal is to make it so that asf-secretary and pmc-chair people can do
>> most of the work themselves. The first step will be to have me do the the
>> tlp requests manually this month (I'm in both groups) with the
>> infrastructure contractors (primarily @fluxo and @pono) providing guidance
>> and adjusting the authorizations as required. As soon as it becomes
>> possible for the secretary and pmc chairs to execute these tasks, focus will
>> turn to automation and providing a web interface.
>>
>> Current code base:
>>
>> https://svn.apache.org/repos/infra/infrastructure/trunk/tlpreq
>>
>> Secretarial tasks will likely be merged into the board agenda tool, pmc
>> chair tasks will like be merged into the roster tool.
>>
>> - Sam Ruby
>
------------------------------------------------------------ _
Henk P. Penning, ICT-beta R Uithof HFG-406 _/ \_
Faculty of Science, Utrecht University T +31 30 253 4106 / \_/ \
Budapestlaan 6, 3584CD Utrecht, NL F +31 30 253 4553 \_/ \_/
http://www.staff.science.uu.nl/~penni101/ M penning@uu.nl \_/
Re: Rethinking TLP creation/migration
Posted by Henri Yandell <ba...@apache.org>.
Makes lots of sense - I love the idea.
Hen
On Sun, May 22, 2016 at 6:00 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> As I am working my way through this code, it occurs to me that much of
> what I am finding could apply to termination of projects. For
> example, if the secretary adds the PMC to LDAP for 'Establish'
> resolutions at the end of the board meeting it might make equal sense
> for the secretary to remove the PMC (and committers) for 'Terminate'
> resolutions.
>
> Thoughts?
>
> - Sam Ruby
>
> On Tue, May 17, 2016 at 6:51 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> > Statement of the problem (by Chris Lambertus):
> >
> > Our process for tlp creation is to run the script, figure out why half
> the
> > steps failed, re-run it a few times until it works, then go do all the
> > manual mailing list creations and jira and conflience etc. etc.
> >
> > General outline of the solution being explored (by Sam Ruby):
> >
> > The goal is to make it so that asf-secretary and pmc-chair people can do
> > most of the work themselves. The first step will be to have me do the
> the
> > tlp requests manually this month (I'm in both groups) with the
> > infrastructure contractors (primarily @fluxo and @pono) providing
> guidance
> > and adjusting the authorizations as required. As soon as it becomes
> > possible for the secretary and pmc chairs to execute these tasks, focus
> will
> > turn to automation and providing a web interface.
> >
> > Current code base:
> >
> > https://svn.apache.org/repos/infra/infrastructure/trunk/tlpreq
> >
> > Secretarial tasks will likely be merged into the board agenda tool, pmc
> > chair tasks will like be merged into the roster tool.
> >
> > - Sam Ruby
>
Re: Rethinking TLP creation/migration
Posted by Sam Ruby <ru...@intertwingly.net>.
As I am working my way through this code, it occurs to me that much of
what I am finding could apply to termination of projects. For
example, if the secretary adds the PMC to LDAP for 'Establish'
resolutions at the end of the board meeting it might make equal sense
for the secretary to remove the PMC (and committers) for 'Terminate'
resolutions.
Thoughts?
- Sam Ruby
On Tue, May 17, 2016 at 6:51 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> Statement of the problem (by Chris Lambertus):
>
> Our process for tlp creation is to run the script, figure out why half the
> steps failed, re-run it a few times until it works, then go do all the
> manual mailing list creations and jira and conflience etc. etc.
>
> General outline of the solution being explored (by Sam Ruby):
>
> The goal is to make it so that asf-secretary and pmc-chair people can do
> most of the work themselves. The first step will be to have me do the the
> tlp requests manually this month (I'm in both groups) with the
> infrastructure contractors (primarily @fluxo and @pono) providing guidance
> and adjusting the authorizations as required. As soon as it becomes
> possible for the secretary and pmc chairs to execute these tasks, focus will
> turn to automation and providing a web interface.
>
> Current code base:
>
> https://svn.apache.org/repos/infra/infrastructure/trunk/tlpreq
>
> Secretarial tasks will likely be merged into the board agenda tool, pmc
> chair tasks will like be merged into the roster tool.
>
> - Sam Ruby
Re: Rethinking TLP creation/migration
Posted by Sam Ruby <ru...@intertwingly.net>.
As I am working my way through this code, it occurs to me that much of
what I am finding could apply to termination of projects. For
example, if the secretary adds the PMC to LDAP for 'Establish'
resolutions at the end of the board meeting it might make equal sense
for the secretary to remove the PMC (and committers) for 'Terminate'
resolutions.
Thoughts?
- Sam Ruby
On Tue, May 17, 2016 at 6:51 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> Statement of the problem (by Chris Lambertus):
>
> Our process for tlp creation is to run the script, figure out why half the
> steps failed, re-run it a few times until it works, then go do all the
> manual mailing list creations and jira and conflience etc. etc.
>
> General outline of the solution being explored (by Sam Ruby):
>
> The goal is to make it so that asf-secretary and pmc-chair people can do
> most of the work themselves. The first step will be to have me do the the
> tlp requests manually this month (I'm in both groups) with the
> infrastructure contractors (primarily @fluxo and @pono) providing guidance
> and adjusting the authorizations as required. As soon as it becomes
> possible for the secretary and pmc chairs to execute these tasks, focus will
> turn to automation and providing a web interface.
>
> Current code base:
>
> https://svn.apache.org/repos/infra/infrastructure/trunk/tlpreq
>
> Secretarial tasks will likely be merged into the board agenda tool, pmc
> chair tasks will like be merged into the roster tool.
>
> - Sam Ruby
Re: Rethinking TLP creation/migration
Posted by Sam Ruby <ru...@intertwingly.net>.
On Tue, May 17, 2016 at 6:51 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> Statement of the problem (by Chris Lambertus):
>
> Our process for tlp creation is to run the script, figure out why half the
> steps failed, re-run it a few times until it works, then go do all the
> manual mailing list creations and jira and conflience etc. etc.
>
> General outline of the solution being explored (by Sam Ruby):
>
> The goal is to make it so that asf-secretary and pmc-chair people can do
> most of the work themselves. The first step will be to have me do the the
> tlp requests manually this month (I'm in both groups) with the
> infrastructure contractors (primarily @fluxo and @pono) providing guidance
> and adjusting the authorizations as required. As soon as it becomes
> possible for the secretary and pmc chairs to execute these tasks, focus will
> turn to automation and providing a web interface.
>
> Current code base:
>
> https://svn.apache.org/repos/infra/infrastructure/trunk/tlpreq
>
> Secretarial tasks will likely be merged into the board agenda tool, pmc
> chair tasks will like be merged into the roster tool.
I've come to the conclusion that it isn't practical to debugg and
rewrite a script that I don't have the authority to run. After
talking to Ross about this, I'm suspending working on this item.
- Sam Ruby