Finally want to leave "infrastructure work" to others from now on

[Thorsten Leemhuis]

On 09.07.2009 14:00, Xavier Bachelot wrote:
> 
> First, thanks a lot for all your past, current and futur work on
> Fedora/EPEL/Livna/RPM Fusion, you really deserve them.

Thx. While at it a short site note here: I'm not sure how long I'll
continue with that. I'm iirc contributing to Fedora and related project
since more then five years now and for different reasons I'm considering
to rather sooner then later lower my involvement to find some time for
other stuff I'd like to do/learn... And only some of those things will
be Fedora related as it looks right now. So a main goal for my work over
the next few months is: make myself obsolete ;-)

> Then, can you be a little more specific on what are the tasks and thus the
> skills involved in helping with both the RPM Fusion infrastructure work
> and also on the RPM Fusion for EPEL sub project.

The "easy" things first: RPM Fusion for EL / EPEL

>From my point of view everything I've written in

http://thread.gmane.org/gmane.linux.redhat.fedora.rpmfusion.devel/3872

still is the case. There have been some people that considered to become
the release manager, but nobody really said "yes, I will do it". Mabye I
could have talked someone into it, but that's not a good base for such a
position, so I didn't try to.

But having a *active* and release manager that is interested in the job
and driving things forward/makeing sure things work well 99,x percent of
the time imho is a must.


The more tricky part: infrastructure

I know that Xavier Lamien/SmootherFrOgZ, has a rough todo list that he
hopefully shares with the list sooner or later. Nevertheless I'll give a
rough list of what I think would be needed:

- we need a proper infra group with at least a few people -- right now
out "infrastructure group" is basically just SmootherFrOgZ and that is a
dangerous bottleneck/single point of failure in the long run

- a lot of things (read: nearly all) infra things in RPM Fusion are
undocumented; that needs to be fixed, otherwise it's impossible for new
people to get involved / to help

- we in general need to do a better job to make sure new people find
their way into the project/into the infra area. Mmcgrath is quite good
in that area afaics, as we does a good jobs to get new people involved
and making them do lot of work


Those three points are in the same area and more overall goals. Some
more concrete things:

- all the builders have local or nearby Fedora mirrors that are synced
from different sources; thus they are not in sync; that hasn't lead to
big problem up to now, but to some small ones that are more and more
annoying afaics

- some of the builder ran out of disk space in the past;

- I roughly heard a request to move the ppc builder (to which only I
have access to, which is also a problem) somewhere else

- making our infra more Fedora like (koji, bodhi, ...) would be nice,
but afaics more a long term goal

- I'm not sure if there is a good backup strategy; also it might be a
lot of time consuming work work to reinstall machines, as the setup is
not documented properly or puppet managed afaics

- delta rpm support is still incomplete/rough in some areas (which might
be not that hard to fix, but nevertheless on my todo list for weeks now;
the basic problem is: we need to keep old rpms around somewhere for
delta generation, which the push scripts support thx to mschwendt)

That list is from the top of my head; I guess I forgot a lot of things,
but it should be enough to get an impression...

> As a long time RHL/Fedora
> user and less longer time Fedora and EPEL contributor, and also as a
> Fedora/RHEL/CentOS sysadmin, I'm interested in both of them and would
> certainly like to help,

That great!

> but I don't want to commit to a bigger/harder task
> I would be able to cope with.

Mabye consider to become the release manager for the EL repo. It's not
that much work and I'd say you are in a good position to do it. It's not
that much work -- don't let the mail I mentioned above scare you...

> I guess the workload could certainly be
> shared over a team rather than exhaust a few individuals anyway.

Getting proper "teams" and making RPM Fusion a real and healthy
community effort IMHO is something we really need, otherwise RPM Fusion
will fail in the long run.

For example right now to many things highly depend on a few
individuals, which IMHO is a big problem/risky. OTOH one reasons for
that afaics is: It seems that there are not many people that are
interested in driving RPM Fusion (as a whole) forward and making it
better :-/

> Regards,
> Xavier (yet another one ;-))

That years ago confused me for some weeks or months before I started to
take a closer look at the surnames ;-)

CU
knurd