[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Plan for tomorrows EPEL meeting

I probably won't be able to attend.  I had a lunch meeting scheduled
today that will be difficult to get out of. I will try to attend if I
can.  I did update the communication plan [1], and spoke briefly with
quaid about the plan.

A big concern I have is how we plan to get along with the other repos
and contributors, both from a governance prospective and from a
communication plan prospective. I don't have exact issues thus far,
but we have seen a few concerns from major 3rd party repos and
downstream contributors.

Also,  I would like to see the QA and test cycle release process
documented.  I think this is a major selling point of EPEL to end EL

It also probably won't help with my elections for chairperson if I
can't make the meeting :)


[1]   http://fedoraproject.org/wiki/EPEL/CommunicationPlan

On 4/17/07, Jeff Sheltren <sheltren cs ucsb edu> wrote:
On Apr 17, 2007, at 2:01 PM, Thorsten Leemhuis wrote:

> Hi,
> I thought it might be a good idea to announce the major topics for
> tomorrows EPEL meeting beforehand.
> /topic EPEL Meeting -- RHEL5 on the builders -- dgilmore/mmcgrath
> /topic EPEL Meeting -- mass rebuild for RHEL5 -- thl
> /topic EPEL Meeting -- Elect chairmen and discuss responsibilities
> /topic EPEL Meeting -- Relations to 3rd party distro (ยน)
> The next two still need to be discussed on the list, so we'll likely
> skip this)
> /topic EPEL Meeting -- Final repolayout -- thl
> /topic EPEL Meeting -- Communication plan for enterprise
> customers/ISVs/IHVs -- stahnma, quaid
> The usual rules apply: if you want to get something discussed send a
> note and we'll try to visit in the meeting.
> CU
> thl

Hi thl, I won't be able to make the meeting tomorrow, so I'll chime
in on a couple things FWIW:

- mass rebuild -- I'm all for giving maintainers a few days (maybe
even a week?) to rebuild their packages once the build systems are
ready with RHEL 5 final.  After that, bump the release and rebuild
automatically for things that haven't been built.

- chairman(men?)  I think that the responsibilities in your other
email seem good.

- 3rd party repos -- Like I mentioned before, it is good to work with
other repos, but I also feel that EPEL should be pushed as a
"central" repo where all those that wish to contribute packages can
do so.  Users do not need the extra headache of trying to coordinate
the packages in multiple repos if it can be avoided.

I have something else which I'm not sure has been discussed before,
or else I am just blocking it out of my memory :)  Yesterday I had
EPEL branches created for fortune-mod (how can you run a server
without fortunes?), but now I realize that fortune-mod needs recode(-
devel), which is part of FE.  I do not maintain recode, and I'm not
sure that the person who does maintain it would like to do so for
EPEL.  How can we proceed in cases like this so that I can import my
package which has dependencies in FE?


epel-devel-list mailing list
epel-devel-list redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]