[gentoo-dev] council manifesto for ferringb

[gentoo-dev] council manifesto for ferringb

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 5044 bytes --]

Pardon the delay in sending this folks- been playing w/ the wording a 
bit more than I should've.

Feel free to ask whatever question's you'd like answered- I'll keep a 
copy of the manifesto at 
http://pkgcore.org/~ferringb/council-manifesto-2010.txt which will be 
updated as needed for typo's and point clarifications.

Manifesto follows-


For those who don't know me, these days I work as a Distro Engineer, although
over the last decade I've ran the gamut from basic embedded to web monkey to
running OPs.  Been a bit varied.

For gentoo specifically, I've been active since mid 2003- same thing, my work
has been a bit all over the map- split the first prefix branch, created EAPI,
wrote the distfiles mirror content manager, founded/wrote pkgcore, and done a
fair amount of portage work.  Intermixed with that is a similar all over the
map involvement in the tree, although these days my main interest/focus on
the tree is QA.

The point of this brag sheet is twofold;

1) I've got a pretty wide amount of technical experience to bring to the
council (ranging from infra to imaging to simple ebuilds to explicit knowledge
of package manager internals)

2) When something isn't getting done, I jump in and *get it done* rather than
letting it sit.  Simplest example, I want the git migration plan finished-
since robin was overloaded and no one was doing it, I chipped in the work
I could do (optimization of the conversion so it wasn't a full day outage).

My purpose in running for the council is to apply the same approach- with due
respect to the previous councils, there has been very little real activity
that has come from the council.  Requests pushed up to them have been ignored
at the last minute (or without explanation), things have been voted on with
questionable understanding of the actual proposal, and generally, they've not
been incredibly useful.  Finally, things have passed through the council with
very little relation to reality.

What I expect of the council, and will push w/in the council if elected is
simply the principles of accountability and getting things done.

Some examples of changes I'd like to see within the council-

1) Staggered elections- 2 elections a year, for example 3 council members in
the summer, 4 in winter.  The purpose of this is purely accountability- if the
current council is abdicating their responsibilities, we aren't waiting a
year, the council's feet are continually held to the fire.  This additionally
provides stability instead of the jarring once a year swap of the full
council.  Finally note that if this were accepted, to make it easier to get
implemented I'd willingly go through an early election (would just need 2 other
council members for it to be pulled off in that case).

2) While hard to enforce (let alone define rules for), sanctions/early
election proceedings for members who repeatedly don't read the reference
materials for what they're going to be discussing that month.  It wastes
everyones time, and it stalls decisions yet another month.  Pretty much
I believe that if you want to be a council member you better be willing to do
the work.  If you won't/can't, then don't run, simple as that.

Please also note that #1 and #2 require community vote to actually accomplish
also- I'm listing them since these are changes I'd like to see (and quite
likely the process of getting that vote has to go through the council also).

3) Figuring out a way to get the council meeting and making decisions more 
frequently then once a month, for a single hour.  We should strive to do more
than just the mininum specified in glep39.

4) Proposals brought forth to the council need an actual plan of
implementation- by opensources nature, the council cannot just say "go
implement EAPI4"- we're all volunteers.  Via requiring people to have at least
the semblence of a plan (including patches/devs attached to it), this will
allow things to go faster, decisions made by the council to actually become
reality within the year.

5) On the flipside, the council should be actively trying to help w/ the
things it thinks should go through- if the council thinks the web redesign
should go through, actively searching for folk to help, tracing down what
has been done, what needs doing, etc.  In this respect the council should be
active rather than passive- if the ball is being dropped, they should be
trying to track it and get it back on course.


Now I wish I could promise voters that if I were elected, all of these things
would be accomplished- I won't blindly promise things that I cannot gurantee.
I can only promise to bring this approach to the council if elected.


Finally please understand that while I am critical of preceeding councils, 
I don't wish to completely tear down what they have accomplished.  To improve
and move forward requires taking a hard but realistic look at what has led to
this point- hopefully I've managed just that in my manifesto.


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] council manifesto for ferringb

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

On 6/24/10 3:42 AM, Brian Harring wrote:
> Simplest example, I want the git migration plan finished- since robin
> was overloaded and no one was doing it, I chipped in the work I could
> do (optimization of the conversion so it wasn't a full day outage).

I respect your work on this, and really hope the git migration will go
just great. However, I'm wondering why we're delaying the migration to
minimize the outage instead of doing the migration earlier?

I'd rather have git soon with longer, but acceptable outage, than in the
future, with a very small outage. On the other hand, I'm not familiar
with the technical side and possibly other reasons that may prevent us
from "closing the tree" for a long period of time.

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] council manifesto for ferringb

[Jeroen Roovers]

On Thu, 24 Jun 2010 07:31:07 +0200
"Paweł Hajdan, Jr." <phajdan.jr@gentoo.org> wrote:

> I'd rather have git soon with longer, but acceptable outage, than in
> the future, with a very small outage.

I'd like some documentation to be finished before the switch is made. I
have no idea how to commit patches using git yet, let alone how to
change my workflow or how sources.g.o is going to display these or
how packages.g.o is going to be adapted for git use. I could go on. :)


     jer

Re: [gentoo-dev] council manifesto for ferringb

[Domen Kožar]

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

Clear reference for usnig git http://gitref.org/

On Thu, 2010-06-24 at 07:56 +0200, Jeroen Roovers wrote:
> On Thu, 24 Jun 2010 07:31:07 +0200
> "Paweł Hajdan, Jr." <phajdan.jr@gentoo.org> wrote:
> 
> > I'd rather have git soon with longer, but acceptable outage, than in
> > the future, with a very small outage.
> 
> I'd like some documentation to be finished before the switch is made. I
> have no idea how to commit patches using git yet, let alone how to
> change my workflow or how sources.g.o is going to display these or
> how packages.g.o is going to be adapted for git use. I could go on. :)
> 
> 
>      jer
> 


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] council manifesto for ferringb

[Robin H. Johnson]

On Thu, Jun 24, 2010 at 07:56:12AM +0200, Jeroen Roovers wrote:
> On Thu, 24 Jun 2010 07:31:07 +0200
> "Paweł Hajdan, Jr." <phajdan.jr@gentoo.org> wrote:
> 
> > I'd rather have git soon with longer, but acceptable outage, than in
> > the future, with a very small outage.
> 
> I'd like some documentation to be finished before the switch is made. I
> have no idea how to commit patches using git yet, let alone how to
> change my workflow or 

> how sources.g.o is going to display these 
gitweb or cgit.

> how packages.g.o is going to be adapted for git use.
packages.g.o is completely VCS agnostic. It gets data from rsync on the
same update.

Lists like the above do have value in making sure that all the bases are
covered.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85