rename fedora-usermgmt?
by Rahul Sundaram
Hi
I see fedora-usermgmt has been made available for EPEL. That is probably
going to cause some confusion. Maybe rename it into system-usermgmt or
something more distribution neutral. The other packages except for
fedora-ds-base are all indeed specific to Fedora.
Rahul
17 years, 1 month
RFP: octave and octave-forge for EL5
by Phil Schaffner
Apparently Octave has been orphaned for EL5 , although it is still in
Fedora Extras. Seems like octave and octave-forge are excellent
candidates for EPEL. They do successfully build from FC6/7 src.rpm
packages under the CentOS5 beta that is currently undergoing QA testing,
albeit with a few additional requirements...
octave SRPMS:
fftw-3.1.2-3.fc6.src.rpm
glpk-4.13-1.fc6.src.rpm
hdf5-1.6.5-7.fc7.src.rpm
octave-2.9.9-1.fc6.src.rpm
rpmdevtools-5.3-1.fc6.src.rpm
ufsparse-2.1.1-1.fc6.src.rpm
octave RPMS:
fftw-3.1.2-3.el5.i386.rpm
fftw-debuginfo-3.1.2-3.el5.i386.rpm
fftw-devel-3.1.2-3.el5.i386.rpm
glpk-debuginfo-4.13-1.el5.i386.rpm
glpk-devel-4.13-1.el5.i386.rpm
glpk-utils-4.13-1.el5.i386.rpm
hdf5-1.6.5-7.el5.i386.rpm
hdf5-debuginfo-1.6.5-7.el5.i386.rpm
hdf5-devel-1.6.5-7.el5.i386.rpm
octave-2.9.9-1.el5.i386.rpm
octave-debuginfo-2.9.9-1.el5.i386.rpm
octave-devel-2.9.9-1.el5.i386.rpm
rpmdevtools-5.3-1.el5.noarch.rpm
ufsparse-2.1.1-1.el5.i386.rpm
ufsparse-debuginfo-2.1.1-1.el5.i386.rpm
ufsparse-devel-2.1.1-1.el5.i386.rpm
For octave-forge:
octave-forge SRPMS:
cln-1.1.13-2.fc6.src.rpm
ginac-1.3.6-1.fc7.src.rpm
gsl-1.8-2.fc7.src.rpm
libdap-3.7.2-3.fc7.src.rpm
libnc-dap-3.6.2-5.fc7.src.rpm
octave-forge-2006.07.09-7.fc6.src.rpm
qhull-2003.1-6.fc6.src.rpm
octave-forge RPMS:
cln-1.1.13-2.el5.i386.rpm
cln-debuginfo-1.1.13-2.el5.i386.rpm
cln-devel-1.1.13-2.el5.i386.rpm
ginac-1.3.6-1.el5.i386.rpm
ginac-debuginfo-1.3.6-1.el5.i386.rpm
ginac-devel-1.3.6-1.el5.i386.rpm
ginac-utils-1.3.6-1.el5.i386.rpm
libdap-3.7.2-3.el5.i386.rpm
libdap-debuginfo-3.7.2-3.el5.i386.rpm
libdap-devel-3.7.2-3.el5.i386.rpm
libnc-dap-3.6.2-5.el5.i386.rpm
libnc-dap-debuginfo-3.6.2-5.el5.i386.rpm
libnc-dap-devel-3.6.2-5.el5.i386.rpm
octave-forge-2006.07.09-7.el5.i386.rpm
octave-forge-debuginfo-2006.07.09-7.el5.i386.rpm
qhull-2003.1-6.el5.i386.rpm
qhull-debuginfo-2003.1-6.el5.i386.rpm
qhull-devel-2003.1-6.el5.i386.rpm
This is not necessarily the exact set of packages that might be selected
to address the goals of enterprise-level stability that have been
discussed in recent posts, just what worked for me in a test-of-concept
build. (e.g. not my "best effort" :-)
Phil
P.S. Could someone please fix the spelling in the Reply-to string?
EPEL development disccusion <epel-devel-list(a)redhat.com>
17 years, 1 month
Request for voting SIG
by Axel Thimm
Hi,
we need to get a voting body set up asap. Nominate a bunch of folks,
maybe the ones in the wiki plus a couple more and give them fesco to
ratify (by vote) and to formulate our mandate.
--
Axel.Thimm at ATrpms.net
17 years, 1 month
package stability
by Patrice Dumas
Hello,
Do we want to keep API/ABI stable over the corresponding RHEL release?
I think yes, but then we should really make sure that some libs don't
go to EPEL (for an example of a lib I maintain there is libdap which
changes API every 6 months or so).
Is there something similar for apps, for example that searching paths
command-line options, config files, file formats, are backward
compatible?
If we impose such constraints, maybe there could be a discussion before
a package enters EPEL. Not a formal review because there should be no
packaging/usability issues, but a verification that the package is
stable enough and there are enough people/firms interested such that
if the maintainer stops maintaining a package that needs work it won't
be really unmaintained.
--
Pat
17 years, 1 month
Release and update procedure for EPEL
by Matthias Saou
FP! :-)
Joke aside, I'd like to see which views we have on the release and
update procedure to apply to EPEL.
- Do we want a moving (and potentially breaking) set of packages which
is constantly being updated?
- De we want a fixed set of packages when a RHEL release is made and
focus on major bugfixes and security updates from there on?
Or maybe something in between, or even both at the same time in
separate repositories... all is possible, as long as we have enough man
power to make it happen.
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6
Load : 1.10 1.28 1.18
17 years, 1 month
EPEL vs Fedora main
by Axel Thimm
The current discussion about fedora-usermgr is an example of most
probably a bad choice in Fedora which stalls EPEL.
What will the general consensus be in this and further conflicting
situations? Bringing this upstream, e.g. to Fedora main, is a noble
thing, but waiting for such things to resolve in Fedora-land takes a
long time, and in Fedora many people are more willing to compromise on
stuff they consider sub-optimal than in RHEL.
So will we be able to decide on anything deviating from Fedora or will
everything that comes up in RHEL land need to go through the Fedora
machinery? Of course, the highest commandment remains to be compatible
to Fedora, but only as much as is really possible, and not blindly
inherit everything that's being semi-tolerated in Fedora.
If we can stand on our own feet, then we should start by voting on
whether we want fedora-usermgmt to be part of RHEL or not. We can then
move on to other important things as EPEL sig, and hope that the issue
will be ironed out on Fedora someday.
--
Axel.Thimm at ATrpms.net
17 years, 1 month
noticing the list for new packages?
by Patrice Dumas
Hello,
I think that it would be nice if people doing branches in EPEL noticed
the list such that it can be seen, and maybe discussed. This is not
relevant for all packages, for example it is not interesting for an
old stable utility package or a deprecated lib nobody uses anymore
anyway, or some graphical apps that cannot have issues of compatibility
or perl and python modules that haven't been changed in years.
But for most libs, some modules and apps that are to be used by other
apps for example compilers, doc apps translators, etc. I think it would
be interesting that people wanting to maintain them post a short notice
describing:
* how stable is the software upstream
* what kind of updating is intended (use latest versions, backport with
explanation on what will be backported and even how...)
* whether comaintainers are wanted
* other?
That way there could be a discussion, I am a bit scared that packages
enter EPEL without discussion. I don't want this kind of stuff to
become bureaucratic either.
--
Pat
17 years, 1 month
Re: Release and update procedure for EPEL
by Greg Swallow
Axel Thimm wrote:
> Compare
>
> http://isoredirect.centos.org/centos/4/isos/i386/
>
> to
>
> https://www.scientificlinux.org/download/
>
> E.g. the range of 4.x versions. SL follows RH in maintaining each
> point release, while CentOS kind of EOLs the previous point releases.
(Sorry if this doesn't follow up to the previous messages properly, I
wasn't subscribed to the list when this was posted)
I think you missed that CentOS EOL's the previous point releases to
http://vault.centos.org - 4.0, 4.1, 4.2, etc are all there if you want
to stick to 4.3 for whatever reason. I think they just want to make
mirroring their main repository less of a storage burden - And I think
it works for them - there are a lot more CentOS mirrors that Scientific
Linux mirrors.
Greg
17 years, 1 month
Meeting Summary for yesterdays meeting
by Thorsten Leemhuis
http://fedoraproject.org/wiki/EPEL/Meetings/20070304
= Meeting 20070304 =
[[TableOfContents]]
== Attending ==
* dgilmore
* Jeff_S
* mmcgrath
* nirik
* quaid
* stahnma
* thl
== Summary ==
* thl created a status page in the wiki to track which Fedora
contributors are interested in EPEL; see
http://www.fedoraproject.org/wiki/EPEL/ContributorStatus got a bit
enhanced by him after some feedback he received during the meeting; he
will announce this to fedora-maintainers during the wiki after he added
some more questions and answers to the FAQ that especially Fedora
Contributors might have
* one thing should be agreed on soon: rolling release, latest and
greatest or a more carefull update approach? Answering that question is
quite important before the mass of Fedora contributors starts to build
packages for EPEL. The plan is to actually work out a solution during
the next week (thl will try to write something up) on the list and
ratify it in the next meeting on 20070311. Some highlights from the
meeting log regarding this topic are between 00:16 and round about 00:32
* who is allowed to participate in EPEL -> the plan is to allow all
Fedora contributors for EPEL. If you dislike that speak up now.
* dgilmore created a gpg key for signing RPMS
* dgilmore created the upload location and uploaded the first bunch of
packages http://download.fedora.redhat.com/pub/epel/
* branching: EPEL5 currenly branches from devel, but and will soon be
branched from FC-6 as devel might be to new for EL5. EPEL4 gets branched
from FC-3. If one or both of those is not existent then the EPEL branch
will get created from the Fedora devel branch
== Full log ==
{{{
00:00 < stahnma> | hello
00:00 --- | thl has changed the topic to: EPEL meeting!
00:00 < thl> | hy stahnma
00:00 < thl> | hi een
00:00 < thl> | even
00:00 --> | jwb_gone (Josh Boyer) has joined #fedora-meeting
00:00 --> | jwb_gone (Josh Boyer) has joined #fedora-meeting
00:00 --> | quaid (Karsten Wade) has joined #fedora-meeting
00:00 --> | quaid (Karsten Wade) has joined #fedora-meeting
00:00 < thl> | sorry, the "v" on my keyboard has some problems
and works only half of the time :-/
00:01 < stahnma> | thl needs a new keyboard
00:01 < thl> | stahnma, a new notebook
00:01 < thl> | laptop
00:01 < stahnma> | ah
00:01 < nirik> | sorry I'm late... here now. ;)
00:01 * | nirik just switched over to using his new d820
last night... so far so good.
00:02 < thl> | nirik, welcome, you din#t miss anything yet :)
00:02 --> | jmbuser (John Babich) has joined #fedora-meeting
00:03 < thl> | I#d say that was enough time to wait for people
to show up
00:03 * | quaid finally got the regular alert programmed
into his cellphone, so made it this time
00:03 < thl> | so let's get slowly started
00:03 < thl> | I just created a new page in the wiki
00:03 < thl> | see
http://www.fedoraproject.org/wiki/EPEL/ContributorStatus
00:04 < thl> | the stuff in the head explains the background for
that page
00:04 < nirik> | is that everyone from the fedora owners.list?
00:04 < thl> | if people like the idea I'd like to send out a
mail to arious fedora lists asking people to update their status
00:04 < thl> | nirik, all from cvsextras in the Accounts system
00:05 < thl> | the number of packages is from owners.list
00:05 < thl> | but it's not exact, as some people use different
e-mail adresses
00:05 * | thl waits for people to read the page
00:05 < nirik> | humm... what does "interested" mean here... that
they want to maintain packages? or that they will someday? or that they
don't mind if others do?
00:06 < thl> | good question
00:06 < quaid> | thl: recommend the /!\ be swapped to be at the
top, and set it up so people can just read that and go on (some people
don't read :)
00:06 < thl> | should probably be "interested in maintain
packages..."
00:07 < thl> | quaid, okay, will do
00:07 < nirik> | I guess we could use 'yes' (ready to branch and
maintain), 'no' don't want to branch and maintain, or 'perhaps' willing
to help, but not now, or how no packages that should go into epel?
00:07 < stahnma> | if it is a 'no' are we going to add a co-maintainer?
00:08 < thl> | stahnma, no, only if there is a co-maintainer
that actually wants to do the job
00:09 < stahnma> | I suppose that is dependant on the packages that
person has or doe snot have
00:09 < nirik> | yeah...
00:09 < quaid> | this page is contributor focused ...
00:09 < quaid> | could it be package focused?
00:09 < quaid> | or isthat too hard ?
00:09 < quaid> | that is, hard to do on a Wiki
00:09 < thl> | quaid, much to hard
00:10 < thl> | we have oer 2500 packages
00:10 < thl> | some people have more then hundret packages
00:10 < thl> | your don#t want to flip yes/no for all of them
00:10 < thl> | this way people see that the status of the
contributor is
00:10 < thl> | and can ask him, if a particular page is missing
00:10 < thl> | that should be good enough
00:11 < thl> | sure, a package based approach with a DB might
have some adantages, but would be hard to set up
00:11 < nirik> | yeah, I think this is usefull in that someone
might have been asked before... we don't want to keep bugging someone if
they don't want to deal with it.
00:11 < thl> | this should do it afaics
00:11 < thl> | nirik, +1
00:12 --> | aa33d (entr0py) has joined #fedora-meeting
00:12 < thl> | nirik, btw, regarding "I guess we could use 'yes'
(ready to branch and maintain)," -- I'll put a more detailed section in
the document that decribes what the different values mean
00:12 < nirik> | ok, sounds good.
00:13 < thl> | is it okay for you guys if I bug the mailig lists
with it later?
00:13 < quaid> | +1
00:14 < Jeff_S> | sounds good to me
00:14 < nirik> | +1 from me
00:14 < stahnma> | +1
00:15 < thl> | k, thx guys
00:15 < thl> | I further plan to add a "EPEL for Fedora
contributors" section to the FAQ
00:15 < thl> | so people know how eerything is currently
expected to work
00:15 < thl> | but one thing should be agreed on soon:
00:16 < thl> | rolling release, latest and greatest, more
carefull update approach?
00:16 < thl> | people might be wondering what they should build
for RHEL4
00:16 < thl> | (for RHEL5 is obvious: build what's currently in
the FC-6 branch)
00:17 < nirik> | I think it should be: release stable things, if
there is a version update it only pushes out on minor release updates,
ie, 4.4 to 4.5...
00:17 < stahnma> | from a maintainer view, if the the current FC6
stuff will build against RHEL4, I would think they want to do that
00:17 < stahnma> | perl modules for example
00:17 < thl> | stahnma, well, there is a problem: a lot of
current stuff won't build for RHEL4 as GTK2 for example is quite old
00:18 < stahnma> | right
00:18 < nirik> | in some cases it will... GUI still will not be as
easy
00:18 < thl> | and having a repo where some stuff is quite new,
and others old, makes not that much sense
00:18 <-- | entr0py has quit (Read error: 110 (Connection
timed out))
00:18 < stahnma> | well, I agree with that
00:18 < thl> | for perl-modules having "latest" might be okay
and possinble most of the time
00:18 < stahnma> | will we be asking quite a lot of our maintainers
though?
00:18 < nirik> | well, part of the problem is that "stable"
depends on the upstream project.
00:19 --- | BobJensen-Away is now known as BobJensen
00:19 < stahnma> | have any people asked to do EPEL in RHEL 5 only
and nor 4?
00:19 < stahnma> | s/nor/not
00:19 < nirik> | Perhaps instead of saying that people must
backport everything, or always upgrade we should just have a "Goal:
stable software. Backport if you can/need to, update if the new version
is very stable"
00:19 < thl> | stahnma, scop (Ville) indicated he's more
interested in RHEL5 than RHEL4
00:19 < thl> | s/RH//
00:20 < thl> | nirik, +1
00:20 < thl> | nirik, I'll try to put that into the faq before
sending the mail out
00:20 < stahnma> | defining "very stable" will be rough
00:20 < stahnma> | unless we have some type of test suite
00:20 < Jeff_S> | I think that's something best left to the
contributor(s) to decide for each package
00:21 < nirik> | yeah. There is upstream stable, and what the
maintainer thinks is stable, and what the end user thinks is stable.
00:21 < stahnma> | probably
00:21 < thl> | Jeff_S, well, we should have a mostly common look
and feel
00:21 --> | trondd (Trond Danielsen) has joined #fedora-meeting
00:21 < Jeff_S> | I think most people will not be willing to
backport patches for very long, since it becomes quite a chore once you
drop too far behind the current upstream release
00:21 < thl> | a repo that in parts has quite old software while
other parts are quite new is a bit confusing IMHO
00:21 < quaid> | what if people want to update the dependencies by
e.g. updating GTK2 for EL4? etc.
00:22 < thl> | Jeff_S, well, the thing IMHO is: update only if
there is a good reason
00:22 < quaid> | pretty soon we're going to be looking at a stable
and unstable branch
00:22 < stahnma> | I think the rolling release when minor updates
are released make the most sense to e
00:22 < thl> | quaid, well, that would be replacing, and we
don#t want that afaics
00:23 < stahnma> | seems like if you want to start replacing EL
components or core, you should run Fedora
00:23 < thl> | quaid, one could come up with a GTK2 pacakge that
lives in /opt and is used by rpaths -- but I doubt we really want that
00:23 < thl> | stahnma, +1 to "I think the rolling release when
minor updates are released make the most sense to me"
00:23 * | nirik shudders. No.
00:23 < nirik> | replacing rhel stuff sounds like a bad idea to me. ;)
00:24 < nirik> | I do like doing non security/bug updates only on
minor version upgrades tho.
00:24 < thl> | +1 for "I do like doing non security/bug updates
only on minor version upgrades"
00:24 < stahnma> | so should we commit a statement of direction then?
00:24 * | thl wonders where nirik got the impression we
want to replace stuff from rhel
00:25 < stahnma> | this will help each contributor decide if they
are interested in EPEL
00:25 < thl> | stahnma, that's why I brought the topic up
00:25 < nirik> | well, there was talk about it on the list... not
sure people were serious tho, or just didn't understand what it was...
00:25 < quaid> | thl: it was my comment and your reply
00:25 < mmcgrath> | Sorry guys,
00:25 < quaid> | oh, ok
00:25 * | mmcgrath is here now.
00:25 < stahnma> | thl, yeah, I mean, like, are we agreed on this?
00:25 * | mmcgrath reads up
00:25 < nirik> | thl: yeah, I think we should get some consensus
on the list before we push it out to the world tho.
00:26 < thl> | nirik, I in parts agree, but that might take
weeks :-((
00:26 < quaid> | +1 to work it out on list, make a decision here
in 7 days
00:26 < thl> | +1 for quaid
00:26 < stahnma> | +1 quaid
00:26 < nirik> | one still unknown is if we push updates on minor
release upgrades, is there any criteria for those updates? anything
goes? or try and maintain stability, but new features/upgrades are ok?
00:26 < nirik> | +1 quaid
00:27 < thl> | nirik, +1 for "try and maintain stability, but
new features/upgrades are ok" (maybe with the add-on "if there is a good
reasons for them)"
00:27 < stahnma> | nirik I think we try to move with upstream. This
is easiest for the maintainer and the admin running EPEL can look into
the release before moving. All the shops I know don't just go from
update 4 to update 5 wtihout research and testing
00:28 < nirik> | yeah, agreed.
00:28 < thl> | stahnma, well, but the base we build for doesn#t
move -- so why should we without a reasons?
00:28 < stahnma> | thl trumps me with his logic
00:28 < thl> | people use RHEL because it nearly doesn't move; I
think EPEL should be similar
00:29 < stahnma> | well, if look at EL each update normally *does*
include movement from upstream, they just don't change hte version number
00:29 < nirik> | so when rhel goes from X.N to X.N+1, would we
want to start building and testing then? or would we want to have a
testing repo ready with the updates?
00:29 < stahnma> | for example, 3.6p1 of OpenSSH on RHEL3 has many
features of 4.0 and greather
00:29 < thl> | stahnma, some movement yes, but not much afaics
00:30 * | mmcgrath agrees with thl.
00:30 < thl> | nirik, I'd say we should have a testing repo in
parallel, that becomes stable in parallel with the update
00:30 < thl> | & of RHEL
00:31 < nirik> | yeah, although if the new rhel minor bumps some
things, it could break things that previously compiled in testing...
00:31 < mmcgrath> | RHEL's just a rolling release with snapshots in time.
00:31 < stahnma> | in theory a new RHEL minor shouldn't break
anything (100% api/abi compat) :)
00:31 < mmcgrath> | There's minor exceptions.
00:31 < thl> | nirik, should be seldom afaics (and isnn't this a
bug in RHEL then?)
00:32 < quaid> | the way things are now, are EPEL maintainers
going to be able to get access to the EL bits early enough?
00:32 < thl> | quaid, no, I don't think so
00:32 < nirik> | ok, just wanted to bring that up... ;) WOuld be
fine if it didn't break anything.
00:32 < quaid> | i.e., do we need to arrange some kind of beta
channel for EPEL maintainers
00:32 < thl> | they will get it when CentOS shipps them, and
that some days/weeks after HEL
00:32 < stahnma> | quaid: that would be ideal
00:32 < thl> | quaid, I don't think that is needed
00:33 < thl> | quaid, and we can do that later if we really need it
00:33 < quaid> | ok
00:33 < mmcgrath> | hmm
00:33 < stahnma> | probably not a priority
00:33 <-- | aa33d has quit (Read error: 110 (Connection timed
out))
00:33 < thl> | quaid, would RHEL be willing to have such a
channel for EPEL maintainers?
00:33 < quaid> | it's likely we can do something, but it may
require (just guessing) an NDA or something; OTOH, maybe the CLA is good
enough there, we'd have to Seek Legal Advice
00:33 < thl> | quaid, remember, some EPEL maintainers might not
have RHEL at all
00:33 < mmcgrath> | thl: What will be more likely is a xen instance
people can 'reserve'
00:34 < quaid> | thl: well, it's done for customers; can't see why
it wouldn't work, but ...
00:34 < thl> | mmcgrath, ohh, hmm, yes, that could work; I like
the idea
00:34 < stahnma> | mmcgrath: that would probably ok
00:34 < quaid> | mmcgrath +1
00:34 < thl> | mmcgrath, but nevertheless: probably not a priority
00:34 < mmcgrath> | That just seams like less red tape.
00:35 <-- | kital has quit (Remote closed the connection)
00:35 < thl> | so, who brings the discussion about the "packge
upgrade guidelines" to the list?
00:36 * | thl probably has to do it
00:37 < thl> | I'm not sure if I find time for it in the next
two or three days, but I'll try
00:38 * | thl brought up the topics he wanted to see
discuessed today
00:38 < nirik> | yeah, I could try, but I need to try and catch up
with core reviews soon. ;)
00:38 < stahnma> | quaid: any progress on the Communication plans?
00:38 < thl> | nirik, it's okay, I'll do it
00:38 * | thl simply ignores the merge reviews most of the time
00:39 * | stahnma tries to do one merge review a night
00:39 * | thl doesn't even read the fedora lists in that
detail as in the past
00:39 < nirik> | I was trying to do that, but got swamped at work
and now new laptop fun. ;)
00:39 < thl> | the benefits of not being in FESCO anymore
00:39 < quaid> | stahnma: not yet; some of it is wanting to have
our details make sense first
00:39 < nirik> | anyhow, back to epel... anything else we want to
discuss?
00:40 * | thl hasn't anything
00:40 < mmcgrath> | I have one, branching.
00:40 < stahnma> | quaid: agreed.
00:40 < mmcgrath> | I swear this was discussed but I can't find it,
who's allowed to request branches right now?
00:40 < quaid> | stahnma: but I'll start to stub out a page today,
and we can throw our pieces into it to stitch together later
00:40 < nirik> | last I heard it was: sponsors and anyone with
more than 5 packages...
00:40 < stahnma> | dgilmore told me it wsa something about 5 packages
00:40 < mmcgrath> | nirik: Is that written down somewhere?
00:41 < thl> | mmcgrath, I think everyone is now
00:41 < dgilmore> | sorry guys i slept in
00:41 < thl> | we'll set up the release team soon to make sure
that everything is properly maintained, even if the maintainers vanishes
-- we afaics have to do this anyhow
00:41 < thl> | hi dgilmore !
00:42 < dgilmore> | hey thl
00:42 < thl> | dgilmore, gpg-key? new rhel5 buildroot? did
pushing work?
00:42 < nirik> | mmcgrath: not that I know of. Perhaps we want to
revisit it now?
00:42 < dgilmore> | thl: gpg key is done
00:42 < dgilmore> | what was built is pushed
00:42 < thl> | dgilmore, great :)
00:42 < dgilmore> | I havent been able to get the build root updated yet
00:43 < thl> | mmcgrath, "Is that written down somewhere?" ->
should be in a FESCo meeting log somewhere
00:43 < thl> | mmcgrath, but I'd say we should allow everyone now
00:44 < thl> | dgilmore, thx for your work
00:44 < quaid> | +1 we don't want it to be too difficult to get in
new EPEL maintainers
00:44 < nirik> | +1 for allowing any maintainer to branch.
00:44 < stahnma> | +1
00:44 * | thl takes that as accepted, and will add it to
the wiki somewhere
00:44 < dgilmore> | im ok with that
00:44 < quaid> | esp. as we're advocating for customer-types to do
it, standard Fedora process seems fine
00:44 < nirik> | hopefully we won't get too many new folks who
want to push a new game or something.
00:45 * | thl will at least write about it once to the
list, before he adds it to the wiki
00:45 < stahnma> | well initially not having dependencies will
probably hinder game packages and several other larger packages
00:45 < dgilmore> | thl: EL-5 is being branched from devel not FC-6
00:45 < thl> | dgilmore, shoudn#t that be FC-6 now?
00:45 < nirik> | stahnma: true.
00:45 < dgilmore> | thl: i dont think so
00:46 < dgilmore> | maybe it should be
00:46 < nirik> | I haven't built any of my branched packages for
el5... I have no way of test building or testing them yet.
00:46 < thl> | devel might have quite new stuff (see bittorent)
00:46 < dgilmore> | EL-4 is FC-3 if it exists if not devel
00:46 * | thl votes to create EL-5 branches for FC-6
00:46 < thl> | dgilmore, that's fine afaics
00:47 < thl> | s/for/from/
00:47 < dgilmore> | i can make it so EL-5 does FC-6 if it exists
devel if not
00:47 < thl> | dgilmore, +1
00:47 < thl> | other opinions?
00:48 < nirik> | sounds fine to me.
00:48 < nirik> | I don't think it much matters... maintainer can
adjust as needed.
00:48 < thl> | nirik, but FC-6 is better as safe default IMHO
00:49 < nirik> | sure.
00:50 < thl> | anything else to discuss?
00:50 * | thl takes that as "no"
00:50 < mmcgrath> | nope :-)
00:51 < thl> | shaltt we close the meeting ?
00:51 < thl> | shall
00:51 < nirik> | dgilmore: with the push, do we have mirrored
repos yet?
00:51 < dgilmore> | nirik: im not sure
00:51 < nirik> | ie, is there yum.repos.d files that we can
install and test with now?
00:51 < nirik> | yeah, I don't have anything else, so closing down
is fine with me.
00:51 < dgilmore> | nirik: i need to create a epel-release package
that can be installed and set everything up
00:52 < nirik> | yeah. ok.
00:52 < dgilmore> | along with mirrorlist stuff
00:52 < thl> | dgilmore, +1 (but dgilmore has enough to do
already afaics -- maybe somebody wants to leant a helping hand to dgilmore?)
00:53 * | thl does even more stupid typos today than he
does usually already :-/
00:54 < thl> | shall we close the meeting for today?
00:54 < stahnma> | ok, thanks everyone
00:54 < thl> | yeah, thx everyone!
00:54 < nirik> | thanks thl
00:55 --- | thl has changed the topic to:
http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel --
Meetings often get logged -- see schedule in the wiki for next meeting
00:55 < thl> | nirik, I'm just doing this a bit like I did the
meetings when I was FESCo chair
00:55 < thl> | is that okay for everybody?
00:55 < quaid> | +1 from me, works great
00:56 < nirik> | yep. Works fine for me... we might want to ping
the listg again and make sure this is a ok time... but seems to work for
several of us at least.
00:56 < jwb_gone> | there's a meeting going on?
00:56 < nirik> | there was...
00:56 < jwb_gone> | for?
00:57 < thl> | epel
00:57 < nirik> | EPEL...
00:57 < jwb_gone> | oh, sorry. wasn't paying attention
00:57 < jwb_gone> | :)
00:57 < nirik> | http://www.fedoraproject.org/wiki/EPEL/
00:58 < dgilmore> | http://download.fedora.redhat.com/pub/epel/
00:58 < dgilmore> | everything is there
01:01 < nirik> | cool!
01:01 < quaid> | dgilmore++
01:01 * | quaid says, "In your face, nay-sayers!"
01:01 < Jeff_S> | dgilmore: cool :)
}}}
17 years, 1 month
Meeting log from last week
by Thorsten Leemhuis
Hi,
just FYI, I uploaded the meeting log from last week to the wiki:
http://www.fedoraproject.org/wiki/EPEL/Meetings/20070225
I wanted to write a summary, but stopped soon -- it was more a general
chat about different things without much order in it, and that was to
hard to summarize.
Next meeting is tomorrow, at 16:00 UTC in #fedora-meeting on freenode; I
hope to update the schedule with some details beforehand. Hope to see
you guys there tomorrow.
BTW, we probably should revisit the meeting time again soon, to make
sure that most of the people EPEL that are interested in EPEL can
participate.
Cu
thl
17 years, 1 month
