12:41 p.m.
Hi all!
The idea to build Fedora (Extras) Packages for RHEL and compatible
distros like CentOS in the scope of the Fedora Project is over half a
year old now, but didn't really take of yet. This mail (and some other
work in other places like the wiki) tries to actually get the idea
running a bit more faster now in the hope that the project actually
takes of soon.
So what needs to be done:
- actually discuss the way forward with contributors and get some
feedback of potential users and contributors -- done in parts now that
you read the mail, as this is one of the purposes why it was written ;-)
- find the final name -- done already, there was (still|once again) some
discussion to use a different name for the Project. It was agreed
(agreed=no one did yell until now) on by certain EPEL SIG members that
we use a slightly variant of what was used until now -- e.g. instead of
"Extras Packages for Enterprise Linux" we'll use "(Fedora) Extra
Packages for Enterprise Linux" (note: Extra and not Extra*s*) and will
stick to EPEL as FLA (four letter acronym).
- update the wiki and put some useful and crucial informations into it
-- done mostly already. See http://fedoraproject.org/wiki/EPEL for the
current state. Some stuff will probably be added depending on what this
discussion brings up. Note that there are quite more informations in
the wiki (including a FAQ) then this mail contains. Also note that
everything in the wiki is still under discussion and might change.
- create a fully functional SIG (see
http://fedoraproject.org/wiki/EPEL/SIG ) that takes care of EPEL, meets
on IRC regularly and make sure things are moving forward. In progress
already. Want to join? Simply add your name to the SIG list in the wiki.
- create a "EPEL Release Manager group", that together with the package
owners is actually responsible for the EL repo. They step up if
maintainers don't react in time to fix stuff like security fixes, broken
deps and similar issues that create problems for our userbase.
- allow all Extras contributors to maintain their packages in EPEL, if
they want to and are aware of the consequences; means:
-- the package needs to be supported until the End Of Life (EOL) of the
Distributions they were build for -- round about seven years. Sure,
nobody of us knows if he still be around then. But you should not build
packages for EPEL if you plan to moe oer to other stuff soon or find
packaging really annoying
-- realize that the rules in EPEL are stricter -- if you don't keep
track of you package properly someone from the "EPEL Release Manager
group" might just fix your package. If that happens multiple times the
package might get hand over to somebody else, if that the best for the
repo as a whole
- find a kind of update and release policy. See
http://www.fedoraproject.org/wiki/EnterpriseExtras/FAQ#head-e5ac329823844...
; proposed is to have a kind of rolling release, but with a careful and
strict update policy where only stuff that really needs a update for a
good reasons gets done. Updating to the latest and greatest version is
not possible quite often in any case, as a lot of newer packages will
depend on new versions of certain core-libs (say gtk, qt, and a lot of
others), which we in quite a lot of cases simply won't have available
when the distribution we support is 12 months or older. So why update
parts to the latest and greatest while keeping other parts on older
ersions and having a distro as a base that people are paying for because
it doesn't change
- actually start building the repo up with packages people want to
maintain and the most important packages from Fedora Extras. Maybe we
get some very rough stats from the Fedora Extras repository servers to
actually have a rough idea of which packages are popular, so we get them
build for EPEL soon and from the beginning. Ask the Fedora package
maintainers if they want to maintain them in EPEL -- if not try to find
another maintainer for EPEL quickly (the people interested in EPEL
probably might have to take care of a lot of packages in the beginning).
- get the inital batch of important and popular packages online into a
testing channel until end of march
- Make sure we have a group of people watching the usual security lists
and file bugs for open issues.
- and move them to a proper channel after some weeks if everything seems
to work.
- In parallel try to the second batch try to get all the other Fedora
packages into EPEL, but leave the "obscure" stuff out of it.
- EL-4 branches will get created from the FE-3 branch, EL-5 packages
from the FC-6 branch
I probably missed a lot of stuff. But that's why I wrote this mail, so
you can tell me and the other members of the EPEL Sig what we missed so
we can actually take care of it.
Your interested to help? Then join the SIG by adding your name to the
EPEL-SIG page in the wiki and join us in the first meeting -- that's
scheduled for Sunday, the 25th at 16:00 UTC in #fedora-meeting on the
freenode network. The mailing list for further discussions around EPEL
will be fedora-devel-list (this list); please use the tag [EPEL] in the
subject so people that are not interested in the other stuff from
fedora-devel-list can filter for it. Thanks in advance.
Cu
thl
10:47 a.m.
On Wed, 2007-02-21 at 19:41 +0100, Thorsten Leemhuis wrote:
Hi all!
The idea to build Fedora (Extras) Packages for RHEL and compatible
distros like CentOS in the scope of the Fedora Project is over half a
year old now, but didn't really take of yet. This mail (and some other
work in other places like the wiki) tries to actually get the idea
running a bit more faster now in the hope that the project actually
takes of soon.
Thanks for stepping up and organizing us this far. It's really helping
make EPEL happen.
-- the package needs to be supported until the End Of Life (EOL) of
the
Distributions they were build for -- round about seven years. Sure,
nobody of us knows if he still be around then. But you should not build
packages for EPEL if you plan to moe oer to other stuff soon or find
packaging really annoying
One idea we want to promote is making the packaging into a job role
instead of a personal side-project. This is possible and useful where
your employer or other outside organization benefits from your package
in EPEL. For example, your infrastructure requires package Foo be
rebuilt in EPEL. If you make package maintenance part of your job role,
you gain:
* The ability to pass on package maintenance when you move job roles or
leave the organization
* Protection of the longevity of the package
* More institutional knowledge of why it is a Good Thing to maintain
packages in Fedora
* A small portion of your compensation now covers working on Fedora (!)
To that end, I have this first draft of a 'job description'. It is
designed to be generic enough that it can be adjusted to fit into other,
existing job descriptions. We need your help to make sure the job
duties are complete and accurate:
http://fedoraproject.org/wiki/EPEL/PackageMaintainer/GenericJobDescription
When it has improved some, I'm going to run this by folks who deal in
job descriptions for a living. This should help make it easier to use
it in your organization.
- Karsten
--
Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project
Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject
quaid.108.redhat.com | gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
10:51 a.m.
On Fri, 2007-02-23 at 08:47 -0800, Karsten Wade wrote:
On Wed, 2007-02-21 at 19:41 +0100, Thorsten Leemhuis wrote:
> Hi all!
>
> The idea to build Fedora (Extras) Packages for RHEL and compatible
> distros like CentOS in the scope of the Fedora Project is over half a
> year old now, but didn't really take of yet. This mail (and some other
> work in other places like the wiki) tries to actually get the idea
> running a bit more faster now in the hope that the project actually
> takes of soon.
Thanks for stepping up and organizing us this far. It's really helping
make EPEL happen.
> -- the package needs to be supported until the End Of Life (EOL) of the
> Distributions they were build for -- round about seven years. Sure,
> nobody of us knows if he still be around then. But you should not build
> packages for EPEL if you plan to moe oer to other stuff soon or find
> packaging really annoying
One idea we want to promote is making the packaging into a job role
instead of a personal side-project. This is possible and useful where
your employer or other outside organization benefits from your package
in EPEL. For example, your infrastructure requires package Foo be
rebuilt in EPEL. If you make package maintenance part of your job role,
you gain:
Is your intention to preclude people that _are_ doing it as a side
project?
josh
10:58 a.m.
Josh Boyer wrote:
On Fri, 2007-02-23 at 08:47 -0800, Karsten Wade wrote:
> One idea we want to promote is making the packaging into a job role
> instead of a personal side-project. This is possible and useful where
> your employer or other outside organization benefits from your package
> in EPEL. For example, your infrastructure requires package Foo be
> rebuilt in EPEL. If you make package maintenance part of your job role,
> you gain:
>
Is your intention to preclude people that _are_ doing it as a side
project?
not preclude but join them together. I suspect the climate for EPEL
will be a lot different from Extras. It'll be interesting to see if
someone like IBM comes in and starts working with Joe Blow on package B
because IBM needs to roll it out to 20,000 customers.
-Mike
11:55 a.m.
On 2/23/07, Mike McGrath <mmcgrath(a)redhat.com> wrote:
Josh Boyer wrote:
> On Fri, 2007-02-23 at 08:47 -0800, Karsten Wade wrote:
>
>> One idea we want to promote is making the packaging into a job role
>> instead of a personal side-project. This is possible and useful where
>> your employer or other outside organization benefits from your package
>> in EPEL. For example, your infrastructure requires package Foo be
>> rebuilt in EPEL. If you make package maintenance part of your job role,
>> you gain:
>>
>
> Is your intention to preclude people that _are_ doing it as a side
> project?
>
not preclude but join them together. I suspect the climate for EPEL
will be a lot different from Extras. It'll be interesting to see if
someone like IBM comes in and starts working with Joe Blow on package B
because IBM needs to roll it out to 20,000 customers.
One of the things I have run into for needs for Extras for Enterprise
at various sites is that there are three different camps you need to
be able to satisfy.
Camp1 wants the same release for the lifetime of the product until it
can no longer be patched. So if clamav-0.88.1 was what was released
then they want patches backported until the end of the 7 years of
support for say RHEL-4. So when 4.5.1 comes out, they want only things
updated that have security updates and not API/ABI changes. Currently
they will take FCL-3 for say RHEL-4 and use whatever is in that repo
til time ends.
Camp2 wants general updates to match the quarterly release cycle. They
dont want to upgrade every 4 days to the latest, but they want
technology upgrades at regular times. So say clamav is the same for
RHEL-4.5.0 but want 4.6.0 to have whatever is considered stable at
that time. Currently they are taking a src.rpm from say FCL-5 and when
FCL-6 comes out upgrading to what was in there. They will upgrade
other stuff when it is needed.
Camp3 wants to get the latest stuff when it is available. They need it
for whatever project and are basically wanting a 'barely-qa'd
rawhide'. Currently they are taking Fedora rawhide and compiling it to
meet daily/weekly needs.
One thing we need to figure out what we can afford to do. I think
Camp3 is the easiest for volunteers to do.. and Camp2 has the largest
number of people. Camp1 should be left to people who are going to be
paid for it. It takes the most work and has the least 'reward'.
--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
12:07 p.m.
On 2/23/07, Stephen John Smoogen <smooge(a)gmail.com> wrote:
On 2/23/07, Mike McGrath <mmcgrath(a)redhat.com> wrote:
> Josh Boyer wrote:
> > On Fri, 2007-02-23 at 08:47 -0800, Karsten Wade wrote:
> >
> >> One idea we want to promote is making the packaging into a job role
> >> instead of a personal side-project. This is possible and useful where
> >> your employer or other outside organization benefits from your package
> >> in EPEL. For example, your infrastructure requires package Foo be
> >> rebuilt in EPEL. If you make package maintenance part of your job role,
> >> you gain:
> >>
> >
> > Is your intention to preclude people that _are_ doing it as a side
> > project?
> >
If a company has need for package foo that requires 15 other packages,
would you like that company to be responsable for the 15 dependencies
also?
> not preclude but join them together. I suspect the climate for
EPEL
> will be a lot different from Extras. It'll be interesting to see if
> someone like IBM comes in and starts working with Joe Blow on package B
> because IBM needs to roll it out to 20,000 customers.
>
One of the things I have run into for needs for Extras for Enterprise
at various sites is that there are three different camps you need to
be able to satisfy.
Camp1 wants the same release for the lifetime of the product until it
can no longer be patched. So if clamav-0.88.1 was what was released
then they want patches backported until the end of the 7 years of
support for say RHEL-4. So when 4.5.1 comes out, they want only things
updated that have security updates and not API/ABI changes. Currently
they will take FCL-3 for say RHEL-4 and use whatever is in that repo
til time ends.
Camp2 wants general updates to match the quarterly release cycle. They
dont want to upgrade every 4 days to the latest, but they want
technology upgrades at regular times. So say clamav is the same for
RHEL-4.5.0 but want 4.6.0 to have whatever is considered stable at
that time. Currently they are taking a src.rpm from say FCL-5 and when
FCL-6 comes out upgrading to what was in there. They will upgrade
other stuff when it is needed.
Camp3 wants to get the latest stuff when it is available. They need it
for whatever project and are basically wanting a 'barely-qa'd
rawhide'. Currently they are taking Fedora rawhide and compiling it to
meet daily/weekly needs.
One thing we need to figure out what we can afford to do. I think
Camp3 is the easiest for volunteers to do.. and Camp2 has the largest
number of people. Camp1 should be left to people who are going to be
paid for it. It takes the most work and has the least 'reward'.
Couldn't have said this better myself. This has been where most of
questions about EPEL have stemmed from.
--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
2:01 p.m.
Stephen John Smoogen schrieb:
One of the things I have run into for needs for Extras for Enterprise
at various sites is that there are three different camps you need to
be able to satisfy.
Camp1 wants the same release for the lifetime of the product until it
can no longer be patched. So if clamav-0.88.1 was what was released
then they want patches backported until the end of the 7 years of
support for say RHEL-4. So when 4.5.1 comes out, they want only things
updated that have security updates and not API/ABI changes. Currently
they will take FCL-3 for say RHEL-4 and use whatever is in that repo
til time ends.
Camp2 wants general updates to match the quarterly release cycle. They
dont want to upgrade every 4 days to the latest, but they want
technology upgrades at regular times. So say clamav is the same for
RHEL-4.5.0 but want 4.6.0 to have whatever is considered stable at
that time. Currently they are taking a src.rpm from say FCL-5 and when
FCL-6 comes out upgrading to what was in there. They will upgrade
other stuff when it is needed.
Camp3 wants to get the latest stuff when it is available. They need it
for whatever project and are basically wanting a 'barely-qa'd
rawhide'. Currently they are taking Fedora rawhide and compiling it to
meet daily/weekly needs.
One thing we need to figure out what we can afford to do. I think
Camp3 is the easiest for volunteers to do.. and Camp2 has the largest
number of people. Camp1 should be left to people who are going to be
paid for it. It takes the most work and has the least 'reward'.
My 2 cent:
Agreed for Camp1 -- it should be left to people who are going to be paid
for it.
For the other stuff: I'm targeting something like a mix in the middle
between Camp2 and Camp3 (with some bits of Camp1 maybe) for EPEL (maybe
a bit more closer to Camp2 than Camp3). Always the latest stuff IMHO is
what we have Fedora for; I also think that's its unrealistic to even try
to always ship the latest apps: Just try now to build a certain apps
from Extras for RHEL4 -- you will run into trouble now and then, as
RHEL4 ships with gtk2-2.4, but there are quite a few apps these days
that require gtk2-2.6.
Cu
thl
2:08 p.m.
On 2/23/07, Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
Stephen John Smoogen schrieb:
>
> One of the things I have run into for needs for Extras for Enterprise
> at various sites is that there are three different camps you need to
> be able to satisfy.
>
> Camp1 wants the same release for the lifetime of the product until it
> can no longer be patched. So if clamav-0.88.1 was what was released
> then they want patches backported until the end of the 7 years of
> support for say RHEL-4. So when 4.5.1 comes out, they want only things
> updated that have security updates and not API/ABI changes. Currently
> they will take FCL-3 for say RHEL-4 and use whatever is in that repo
> til time ends.
>
> Camp2 wants general updates to match the quarterly release cycle. They
> dont want to upgrade every 4 days to the latest, but they want
> technology upgrades at regular times. So say clamav is the same for
> RHEL-4.5.0 but want 4.6.0 to have whatever is considered stable at
> that time. Currently they are taking a src.rpm from say FCL-5 and when
> FCL-6 comes out upgrading to what was in there. They will upgrade
> other stuff when it is needed.
>
> Camp3 wants to get the latest stuff when it is available. They need it
> for whatever project and are basically wanting a 'barely-qa'd
> rawhide'. Currently they are taking Fedora rawhide and compiling it to
> meet daily/weekly needs.
>
> One thing we need to figure out what we can afford to do. I think
> Camp3 is the easiest for volunteers to do.. and Camp2 has the largest
> number of people. Camp1 should be left to people who are going to be
> paid for it. It takes the most work and has the least 'reward'.
My 2 cent:
Agreed for Camp1 -- it should be left to people who are going to be paid
for it.
For the other stuff: I'm targeting something like a mix in the middle
between Camp2 and Camp3 (with some bits of Camp1 maybe) for EPEL (maybe
a bit more closer to Camp2 than Camp3). Always the latest stuff IMHO is
what we have Fedora for; I also think that's its unrealistic to even try
to always ship the latest apps: Just try now to build a certain apps
from Extras for RHEL4 -- you will run into trouble now and then, as
RHEL4 ships with gtk2-2.4, but there are quite a few apps these days
that require gtk2-2.6.
Cu
thl
Has the demand for one particular type of application been higher than
another? For example, most shops I see with RHEL/CentOS are in
runlevel 3, so QT/GTK applications are minimal. Is anyone seeing
things that are different? Also, will things like Tremulous be
allwoed in EPEL? It's not that I want it in there, I am just curious.
I would love to show real value of EPEL to my employer as it matures.
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
2:41 p.m.
Michael Stahnke schrieb:
On 2/23/07, Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
> Stephen John Smoogen schrieb:
> My 2 cent:
> Agreed for Camp1 -- it should be left to people who are going to be paid
> for it.
> For the other stuff: I'm targeting something like a mix in the middle
> between Camp2 and Camp3 (with some bits of Camp1 maybe) for EPEL (maybe
> a bit more closer to Camp2 than Camp3). Always the latest stuff IMHO is
> what we have Fedora for; I also think that's its unrealistic to even try
> to always ship the latest apps: Just try now to build a certain apps
> from Extras for RHEL4 -- you will run into trouble now and then, as
> RHEL4 ships with gtk2-2.4, but there are quite a few apps these days
> that require gtk2-2.6.
Has the demand for one particular type of application been higher than
another? For example, most shops I see with RHEL/CentOS are in
runlevel 3, so QT/GTK applications are minimal. Is anyone seeing
things that are different?
Well, I assume that besides those that run RHEL/CentOS on Servers in
runlevel 3 there are a lot of people out there that run it on their
workstation; Fedora afaics moves to fast for a lot of people that prefer
to have a "stable" desktop -- they afaics prefer to only upgrade their
machine all 18-24 months (or even more seldom) to a new release.
Also, will things like Tremulous be
allwoed in EPEL?
/me looks up what tremulous -- ohh, a "First Person Shooter game based
on the Quake 3 engine", that why I don't know about it.
Well, I didn't build the games I maintain for EPEL yet, but I suppose
some people expect them to find in EPEL. I think we should ship them, if
the maintainer wants, but games IMHO have not a high priority.
CU
thl
4:43 p.m.
On Fri, 2007-02-23 at 10:51 -0600, Josh Boyer wrote:
Is your intention to preclude people that _are_ doing it as a side
project?
Certainly not! Yeek! Thanks for the question, I didn't see that
interpretation.
The purpose of the job description is to make it easier for people who
maintain packages to get at least some of the work "guaranteed" by their
employer. Obviously it is not a guarantee or a contract to support the
package. This is where the wording matters. It is just about extending
the personal responsibility to the organization. For example, an
individual can orphan a package for any reason, and their responsibility
is just to announce the orphaning. The same should hold true for an
organization.
I'll make some changes in the page[1] for that.
- Karsten
[1] ref.
http://fedoraproject.org/wiki/EPEL/PackageMaintainer/GenericJobDescription
--
Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project
Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject
quaid.108.redhat.com | gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
5:03 p.m.
On 2/23/07, Karsten Wade <kwade(a)redhat.com> wrote:
The purpose of the job description is to make it easier for people
who
maintain packages to get at least some of the work "guaranteed" by their
employer. Obviously it is not a guarantee or a contract to support the
package. This is where the wording matters. It is just about extending
the personal responsibility to the organization. For example, an
individual can orphan a package for any reason, and their responsibility
is just to announce the orphaning. The same should hold true for an
organization.
Do you have buy-in or feedback from organizations at the
organizational level on this approach? From manager-like entities who
would be making this commitment on behalf of their organization or
company?
Not to name names or anything..but after FudCon I was on the same
flight back with dgilmore, and we had a little chat about EPEL and the
contributor landscape for it. It was obvious to both of us that IT
people in smaller organizations would very much be interested
consumers of this material, but it wasn't clear that they would have
organizational support to maintain this material as part of their job.
I think some rather valid observations were made concerning the
possible reluctance of IT people in a corporate setting to be involved
in a maintainership role, exactly because it would appear to be an
additional worktime commitment, not supported by their organizations.
-jef
5:56 p.m.
On Fri, 2007-02-23 at 14:03 -0900, Jeff Spaleta wrote:
On 2/23/07, Karsten Wade <kwade(a)redhat.com> wrote:
> The purpose of the job description is to make it easier for people who
> maintain packages to get at least some of the work "guaranteed" by their
> employer. Obviously it is not a guarantee or a contract to support the
> package. This is where the wording matters. It is just about extending
> the personal responsibility to the organization. For example, an
> individual can orphan a package for any reason, and their responsibility
> is just to announce the orphaning. The same should hold true for an
> organization.
Do you have buy-in or feedback from organizations at the
organizational level on this approach? From manager-like entities who
would be making this commitment on behalf of their organization or
company?
I would think this is something that should be approached at the hiring
manager level, that is, the level where the manager is directly involved
in deciding/defining job descriptions.
Not to name names or anything..but after FudCon I was on the same
flight back with dgilmore, and we had a little chat about EPEL and the
contributor landscape for it. It was obvious to both of us that IT
people in smaller organizations would very much be interested
consumers of this material, but it wasn't clear that they would have
organizational support to maintain this material as part of their job.
I think some rather valid observations were made concerning the
possible reluctance of IT people in a corporate setting to be involved
in a maintainership role, exactly because it would appear to be an
additional worktime commitment, not supported by their organizations.
If I read you correctly, you are bringing up the exact reasoning I had
for putting together a generic job description people can use. My
approach is a first stab; obviously many more of you are experienced
with this. I may not get paid for my Fedora work, but I have an easier
time justifying my time spent. :)
What approach would you take? Is this the right one?
Whatever approach this community recommends is probably exactly what
I'll recommend to Red Hat to incorporate. To make it clear, I think it
is the job of the EL distributor (Red Hat, or CentOS, or whoever) to
help promote joining the EPEL community. To that end, my goal at Red
Hat is to have a set of materials that "make sense" for ISVs, IHVs, and
customers; then make sure those materials are in the hands of the
marketing, support, and service organizations who have direct contact
with the target audience. Any help in that direction is (likely) Good
For All.
- Karsten
--
Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project
Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject
quaid.108.redhat.com | gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
10:55 a.m.
Thorsten Leemhuis wrote:
- get the inital batch of important and popular packages online into
a
testing channel until end of march
I still haven't heard back from Stacy on this, I'll send a follow up.
I probably missed a lot of stuff. But that's why I wrote this
mail, so
you can tell me and the other members of the EPEL Sig what we missed so
we can actually take care of it.
Emphasis on co-maintainership.
-Mike
12:13 p.m.
On Friday 23 February 2007 10:55:29 am Mike McGrath wrote:
Thorsten Leemhuis wrote:
> - get the inital batch of important and popular packages online into a
> testing channel until end of march
I still haven't heard back from Stacy on this, I'll send a follow up.
we
have space now i need to work out how to get packages there.
http://download.fedora.redhat.com/pub/epel/
> I probably missed a lot of stuff. But that's why I wrote
this mail, so
> you can tell me and the other members of the EPEL Sig what we missed so
> we can actually take care of it.
Emphasis on co-maintainership.
-Mike
--
Dennis Gilmore, RHCE
6261
days inactive
6267
days old
13 comments
8 participants
participants (8)
-
Dennis Gilmore -
Jef Spaleta -
Josh Boyer -
Karsten Wade -
Michael Stahnke -
Mike McGrath -
Stephen John Smoogen -
Thorsten Leemhuis