meetings and some issues

[Stephen John Smoogen]

On Mon, Feb 9, 2009 at 6:50 PM, Michael Stahnke <mastahnke at gmail.com> wrote:
>>> 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.

I think for a global group we have to do as much on the list and then
have a meeting as a catchup but in truth.. if its not on the list, it
didn't happen/doesn't matter.

>>> - 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.

I agree.

>>> - 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.

I know that I am using it here.. but I haven't used any of them to see
what it would mean.


>>> - 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).

Hmmm I wonder if we could have an email sent to the list for each one
opened. It would help me know when new ones are open.

>> 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.

That is what I get for listening to Echoes and typing at the same time.

>> 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.

Agreed. Most of the time.. I need something like a rawhide for EPEL..
I am not expecting it to be stable for anyone just to see if it will
work.. Then there are the packages I need to be very stable and those
I try to help maintain.

>> 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.

In some ways, it is pretty much what people have to do. I am having to
find how to get Python-2.5 to work with RHEL-3 because project
requires both. Its one of those things that I know a number of people
do... but we just don't like to talk about it.

> 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
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list
>



-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"