meetings and some issues

[Michael Stahnke]

>> Since we haven't had an epel meeting in quite a while, I would like to
>> revisit the idea of a new meeting time. Perhaps we could setup a table
>> in the wiki for people to fill in and choose the best time that way?
>> Or perhaps someone would like to suggest a time?
The best time for me is late afternoon in the US.  I know that's a
pain to our European friends.  In the morning I commonly am dealing
with issues from work.


>> - Did we ever decide to make a epel-announce list? I think this might
>>  be good still to send important announcements about packages or other
>>  changes that end epel users should be notified of. I am not sure, but
>>  we could also send the package update announcements there (might be
>>  too much traffic tho, perhaps just the stable ones?)
+1 for the list.  It's a good idea, but I hate to be on more lists.
However, epel users would probably like it.

>> - Orphans. We have the following orphan packages. Some of them are more
>>  'retired', but we should look at trying to find owners for the ones
>>  that can still be maintained.
>>

>> cvs2cl
>> cvsps
>> svn2cl

As much as we (maintainers) probably don't like CVS anymore, it's
still used all over the place in companies.  We should probably try to
find somebody to keep those alive.  I'd be happy to be a co-maintainer
on the cvs packages, but I'd like help.

>> - Bugs. We are now just over 100 epel bugs. This is no good, IMHO.
>> Would it be possible to get some interested folks to dig through these
>> and see about fixing easy ones/poking maintainers/doing something to
>> move them along. Especially in the case where it's a missing dep.
>
Ouch.  And I haven't filed any (that I remember).

> 1) We need to get the build system to koji. David Gilmore says thats
> real soon now (like this month).
Maybe Dennis Gilmore?  David Gilmore is of Pink Floyd fame.  I mean,
if he is working on Koji, more power to him, but if not, I'll let him
keep playing guitar.

> 2) We need to have a branch where we will build 'everything' against
> the BETA when it comes out. That way we can keep track of where things
> break and see if we can get some loving to EL-6 sooner versus later.

I agree.  My biggest issues with EPEL are normally a package I *need*
is missing.

> 3) We need a TAM at Red Hat to keep us in contact with what is going
> on with EL{4,5,6} so that we have better communication about changes.

++ a lot.  I really like this idea.  Karsten, any thoughts on your
end?   This would be most excellent.  I'll see about bringing it up to
my sales rep, to see if maybe we can get traction on two fronts.  I am
sure my sales reps will somehow see $$$ from $DAYJOB, but whatever,
I'll deal with it.

>> - How can we get more packages branched for EPEL? Perhaps we could
>>  approach some of the sigs, like the perl-sig and ask them to consider
>>  their packages that work/make sense on EPEL (I have seen a bunch of
>>  new perl packages in fedora that were not branched for EPEL).
The ruby-sig (like all 5 of us) are working pretty hard to get a lot
of the packages into EL5.  EL4 is pretty much a lost cause since
rubygems can't really be installed.  At $DAYJOB I have ripped out the
entire ruby stack on RHEL4 and replaced it with a newer one.  That's
probably not recommended.

I was working with the perl sig a while back on at least generating a
report of what perl modules where in EPEL and what was missing.  I
forgot who I was working with, but it's in the archives and I'll look
again when I get back to it.  Anybody is welcome to help there.  I can
tell you that about 60% of the 'missing' packages in EPEL from my
server team's perspective is perl modules.

Thanks,
stahnma