Repotag
by Dag Wieers
Hi,
Could you please add a repotag to your EPEL packages ?
I know you guys think you have enough authority to not require a repotag.
And you generally do not care because the default policy will be to tell
people other packages than EPEL are dangerous. (look at the release to
identify a package)
But by not tagging your packages, you take advantage of the fact that
other repositories play nice and *do* tag their packages.
But what will happen if I (and other repositories) start doing the same
thing and drop the repotag ?
I don't know if I have to start threaten to make you see the light, but I
strongly consider dropping the repotag if Fedora and Red Hat cannot play
nice.
Thanks for taking notice.
-- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]
17 years
RHEL5 builder content?
by Axel Thimm
Hi,
this may have been documented somewhere, or perhaps discussed here,
but I can't find it: What "repo" is used for the RHEL5 builds? Server,
client or the sum or both? If it's the sum are you using *two*
licenses for creating the repo? If it's open for debate I would argue
that we should have the sum, e.g. the complete RHEL5 as a base.
For reference: packages (as of today) that only exist in the server:
Cluster_Administration-5.0.0-5 clustermon-0.8-27.el5
compat-gcc-295-2.95.3-85 conga-0.8-30.el5 elilo-3.6-2
gfs-kmod-0.1.16-5.2.6.18_8.1.1.el5 gfs-kmod-0.1.16-5.2.6.18_8.el5
gfs-utils-0.1.11-1.el5 Global_File_System-5.0.0-4 gnbd-1.1.5-1.el5
gnbd-kmod-0.1.3-4.2.6.18_8.1.1.el5 gnbd-kmod-0.1.3-4.2.6.18_8.el5
iprutils-2.1.5-3 ipvsadm-1.24-8.1 libica-1.3.7-5.el5
librtas-1.2.4-3.el5 libunwind-0.98.5-3 lvm2-cluster-2.02.16-3.el5
openssl-ibmca-1.0.0.rc2-1.el5.3 piranha-0.8.4-7.el5 ppc64-utils-0.11-2
prctl-1.4-5.2.1 redhat-release-5Server-5.0.0.9
redhat-release-notes-5Server-5 rgmanager-2.0.23-1
s390utils-1.5.3-10.el5.6 salinfo-1.1-2.el5
system-config-cluster-1.0.39-1.0 yaboot-1.3.13-3.el5
and such only existing for the client:
compiz-0.0.13-0.36.20060817git.el5 ekiga-2.0.2-7
evolution-2.8.0-33.el5 evolution-connector-2.8.0-3.fc6
evolution-webcal-2.7.1-6 fribidi-0.10.7-5.1 gaim-2.0.0-0.28.beta5.el5
gnome-games-2.16.0-1.fc6 gnome-pilot-2.0.13-16
gnome-pilot-conduits-2.0.13-7.el5 gnome-spell-1.0.7-3.1
gnome-user-share-0.10-6.el5 hsqldb-1.8.0.4-3jpp.4 jpilot-0.99.8-7.1
k3b-0.12.17-1.el5 kdeaddons-3.5.4-1.fc6 kdegames-3.5.4-1.fc6
kdegraphics-3.5.4-1.fc6 kdemultimedia-3.5.4-2.fc6 kdepim-3.5.4-4.fc6
launchmail-4.0.0-1.el5 libgpod-0.4.0-1.el5 libsilc-1.0.2-2.fc6
libwpd-0.8.6-1 nautilus-sendto-0.7-5.fc6 opal-2.2.2-1.1
openoffice.org-2.0.4-5.4.17 perl-Archive-Zip-1.16-1.2.1
pilot-link-0.11.8-16 planner-0.14-3 pwlib-1.10.1-7.el5
python-imaging-1.1.5-5.el5 redhat-release-5Client-5.0.0.9
redhat-release-notes-5Client-5 rhythmbox-0.9.5-8.el5
scribus-1.3.3.2-3.el5 taskjuggler-2.2.0-3 thunderbird-1.5.0.9-6.el5
--
Axel.Thimm at ATrpms.net
17 years
Fedora EPEL Package Build Report 2007-03-16
by Fedora Koji Build System
Packages built and released for Fedora EPEL 5: 8
NEW dclib-0.3.8-1.el5
NEW firmware-addon-dell-1.2.2-1.el5
NEW firmware-tools-1.2.3-1.el5
NEW naim-0.11.8.3-1.el5
NEW nethack-3.4.3-12.el5
NEW pork-0.99.8.1-6.el5
NEW python-cherrypy-2.2.1-6.el5
NEW xprobe2-0.3-8.el5
Packages built and released for Fedora EPEL 4: 5
NEW firmware-addon-dell-1.2.2-1.el4
NEW firmware-tools-1.2.3-1.el4
nas-1.8-13.el4
NEW perl-YAML-0.62-3.el4
qt4-4.2.3-3.el4
For more information about the built packages please see the repository
or the Fedora Info Feed: http://fedoraproject.org/infofeed/
17 years
RFC: Package maintenance and update policy for EPEL -- take 1
by Thorsten Leemhuis
Hi everyone,
find below my take for a "Package maintenance and update policy for
EPEL". You an find it in the wiki at:
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenan...
If you spot typos (there are probably still some...) please fix them in
the wiki directly -- that's why the document is there ;-)
Did I miss anything? Do people like the general direction?
CU
thl
= Package maintenance and update policy =
EPEL wants to provide a common "look and feel" to the users of our
repository. Thus the EPEL SIG wrote this policy that describes the
regulations for package maintenance and updates in EPEL, that are a bit
more stronger regulated then they are in Fedora now.
[[TableOfContents]]
== Digest ==
The goal is to have packages in EPEL that enhances the Enterprise Linux
distributions the packages were build against without disturbing or
replacing packages from that distribution. The Packages in the
Repository should if possible get maintained in similar ways like the
packages get maintained in the Enterprise Linux Distribution they get
build against. In other words: have a mostly stable set of packages that
normally does not change at all and only changes if there are good
reasons for it -- so no "hey, there is a new version, it builds, let's
ship it" mentality.
== Policy ==
EPEL packages should only enhance and never disturb the Enterprise Linux
distributions the packages were build for. Thus packages from EPEL
should never replace packages from the base distribution they get build
against; kernel-modules further are not allowed, as they can disturb the
base kernel easily.
The Packages in the Repository should if possible get maintained in
similar ways like the packages get maintained in the Enterprise Linux
Distribution they get build against. In other words: have a mostly
stable set of packages that normally does not change at all and only
changes if there are good reasons for changes.
The changes that cant be avoided get routed into different release
trees. Only updates that fix important bugs (say: data-corruption,
security problems, really annoying bugs) go to a testing branch for a
short time period and then build a second time for the stable branch;
those people that sign and push the EPEL packages to the public repo
will skim over the list of updated packages for the stable repo to make
sure that sure the goal "only important updates for the stable branch"
is fulfilled.
Other updates get queued up in a testing repository over time. That
repository becomes the new stable branch in parallel with the quarterly
update that get released by the Linux Distributor that creates the
Enterprise Linux the packages gets build against. There will be a short
freeze time period before the quarterly update happens to make sure the
repo and its packages are in a good shape. But even this updates should
be limited to fixes only as far as possible and should be tested in
Fedora beforehand if possible. Updated Packages that change the ABI or
require config file adjustments must be avoided if somehow possible.
Compat- Packages that provide the old ABI need to be provided in the
repo if there is no way around a package update that changes the ABI.
== Guidelines and Backgrounds for this policy ==
=== Some examples of what package updates that are fine or not ===
Examples hopefully help to outline how to actually apply above policy in
practise.
==== Minor version updates ====
Let's assume package foo is shipped in EPEL 5.0 as version 1.0.1;
upstream developers now ship 1.0.2
* build for the stable branch only if it fixes serious bugs
* build for the testing branch (which will be 5.1 later) is acceptable
if the upstream release is mostly a bugfix release without new features
and the package got run-time testing
==== A little bit bigger minor version updates ====
Let's assume package foo is shipped in EPEL 5.0 as version 1.0.1;
upstream developers now ship 1.2.0; the ABI is compatible to 1.0.1 and
the existing config files continue to work
* build for the stable branch only if it fixes a really serious bug
* build for the testing branch (which will be 5.1 later) is acceptable
if it fixes serious bugs
==== A yet again little bit bigger minor version updates ====
Let's assume package foo is shipped in EPEL 5.0 as version 1.0.1;
upstream developers now ship 1.4.0; the ABI is compatible to 1.0.1, but
the config files need manual adjustments
* build for the stable branch is normally not acceptable; a backport
should be strongly considered if there are any serious bugs that must be
fixed
* build for the testing branch (which will be 5.1 later) is also
disliked; but it is acceptable if there is no other easy way out to
solve serious bugs; but the update and the config file adjustments need
to be announced to the users properly -- say in form of release notes
that get published together with the quarterly announcement.
==== A major version update ====
Let's assume package foo is shipped in EPEL 5.0 as version 1.0.1;
upstream developers now ship 2.0.0; the ABI changes or the config files
need manual adjustments
* this update should be avoided if possible at all. If there really is
no other way out to fix a serious bug then it rare cases it might be
acceptable to build the new version for the testing branch and mention
the update and the needed adjustments in the release notes for the next
update. An additional compat- packages with the old libs is necessary if
the ABI changed.
==== Add more examples as they show up ====
If to many show up put them into a separate document.
=== Why not a rolling release with up2date packages like Extras? ===
Why should we? That would be what Fedora (Extras) did and worked and
works well for it -- but that's mainly because Fedora (Core) has lots of
updates and a nearly rolling-release scheme/quick release cycle, too.
But the Enterprise Linux we build against is much more careful with
updates and has longer life-cycle; thus we should do the same for EPEL,
as most users will properly prefer it that way, as they chose a stable
distro for some reasons -- if they want bleeding edge they might have
chosen Fedora.
Sure, there are lots of areas where having a mix of a stable base and a
set of quite new packages on top of it is wanted. *Maybe* the EPEL
project will provide a solution (in parallel to the carefully updated
repository!) for those cases in the long term, but not for the start.
BTW, there are already repositories out there that provide something in
this direction, so users might be served by them already.
Further: A rolling release scheme like Fedora (Extras) did/does is not
possible for many EPEL packages for another reason, too. New Packages
often require new versions of certain core libraries, too. But we we
can't provide them in EPEL, as they would replace/disturb stuff from the
base distribution.
Example: This document was written round about when RHEL5 got released;
many packages that get build for RHEL5 can't be build for RHEL4 at this
point of time already, as the RHEL4-gtk2-Package is much two years old
and way to old for many current applications, as they depend on a newer
gtk2. So if even if we would try to have a rolling scheme with with
quite new package we'd fail, as we can't build a bunch of package due to
this dependencies on libs; in the end we would have a repo with some
quite new packages while others are still quite old. That mix wouldn't
make either of the "latest versions" or "careful updates only" sides
happy; so we try to target the "careful updates only" sides.
=== How will the repo actually look like ===
Similar to what [ http://ftp-stud.fht-esslingen.de/pub/Mirrors/centos/
layout] CentOS uses. Rough example:
{{{
* epel/ # topdir
* 4/ # topdir for EPEL4
* 4 -> 4.5 # symbolic link to latest version
* 4.1/ # this tree of course will never
exists, as this is history, and is here just to show the example
.... # 4.2, 4.3, 4.4; those won't ever
exists, too
* 4.5/ # 4.5, latest version, build target:
fedora-epel-4-stable
* 4.6 # not yet
* .... # time will come
* testing/ # testing repo, that together with the
old packages that didn't get update becomes 4.6 when RHEL 4.6
# releases; build target:
fedora-epel-5; gets frozen for a week or two before the quarterly update is
# issued; new packages land here for a
while, too
* 5/ # topdir for EPEL4
* 5 -> 5.0 # symbolic link to latest version
* 5.0/ # 5.0, latest version, build target:
fedora-epel-5-stable
* 5.1 # not yet
* .... # time will come
* testing/ # testing repo, that together with the
old packages that didn't get update becomes 4.6 when RHEL 4.6
# releases; build target:
fedora-epel-5; gets frozen for a week or two before the quarterly update is
# issued; new packages land here for a
while, too
}}}
This layout may looks complicated, but has one major benefit: Users can
stick to a EPEL repo for a not up2date EL release while a newer EL
quarterly update is already out (some users do that on purpose, others
have no chance as for example the CentOS update gets normally released
up to four weeks after RHEL released a quarterly update). The above
layout can makes it possible to prevent that users run into dependency
issues that might arise otherwise if packages in the new EPEL release
depend on new packages in the new EL release. The EPEL quarterly update
further isn't forced on users before they switch to the quarterly update.
Each repo always has all the packages in it; hardlinks will be used to
keep the space requirements on the server-side limited, as most packages
won't change.
17 years
IRC Meetings: New meeting time?
by Thorsten Leemhuis
Hi all!
The EPEL SIG currently meets each Sunday at 16:00 UTC -- this was the
time and date that matched most of the most active EPEL drivers when the
EPEL SIG was quite small.
Well, we have grown a bit, so we should probably re-discuss the meeting
time again. So what date and time would you guys people prefer?
My 2 cent: A meeting time between 16:00 and 20:30 local german time(¹)
would be the best for me(²). I'm nearly always afk later and at
work/shopping/in the garden/cleaning the house earlier then 16:00.
Cu
thl
(¹) -- that's 15:00 to 19:30 UTC currently, and 14:00 to 18:30 UTC in
two weeks from now, when Europe switches to DST
(²) -- early mornings (6:40 till ~ 9:00) wound be fine for me Monday to
Friday, too
17 years
Time to go live?
by Mike McGrath
We still have mentions of test only and "not meant for public
consumption" Should I send an official announcement to the
announce-list and get this party started?
-Mike
17 years
Can I play?
by Konstantin Ryabitsev
Hello, everyone:
I'd like to participate in the EPEL process, since I'm responsible for
a bunch of RHEL4 servers and figure that since I already rebuild a
bunch of stuff from extras, I might as well share my efforts. :)
I'll follow the discussions for a few days, just to get a hang of
things, since the wiki is a little short on details at the moment.
Cheers,
--
Konstantin Ryabitsev
Montréal, Québec
17 years
EPEL acceptance policy
by Tim Burke
Hi,
I was just checking out the acceptance policy listed here:
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenan...
There's a few acceptance criteria that I think it would help to
blatantly spell out there. Perhaps this is really nit points and could
be safely assumed, but I think it doesn't hurt to spell things out.
I think the intention is to not ship in EPEL stuff which RH already
ships. Specifically this is stated as: "Thus packages from EPEL should
never replace packages from the target base distribution"
I'm wondering if people may misinterpret that to think that things not
on the base RHEL isos are fair game for replacement. Layered products
from RH which are delivered separately from the OS come to mind.
Another example would be packages which are only intended for certain
release variants. For example, the GFS cluster components are not
available to desktop / client configurations - server only.
Tying to think of an alternative recommended wording:
"thus packages from EPEL should never replace packages delivered by Red
Hat - including those on the base distribution as well as layered products."
17 years
Fedora EPEL Package Build Report 2007-03-14
by Fedora Koji Build System
Packages built and released for Fedora EPEL 5: 5
NEW cfengine-2.1.22-1.el5
eggdrop-1.6.18-7.el5
NEW libsmbios-0.13.4-1.el5.1
NEW pastebin-0.50-3.el5
rpmlint-0.79-1.el5
Packages built and released for Fedora EPEL 4: 13
NEW cfengine-2.1.22-1.el4
eggdrop-1.6.18-7.el4
NEW libsmbios-0.13.4-1.el4.1
NEW nagios-plugins-1.4.6-3.el4
nfswatch-4.99.8-1.el4
NEW nrg2iso-0.4-2.el4
NEW pastebin-0.50-3.el4
NEW perl-Algorithm-Diff-1.1902-2.el4
perl-SOAP-Lite-0.68-5.el4
NEW perl-Text-Diff-0.35-3.el4
rpmlint-0.79-1.el4
NEW ssmtp-2.61-11.1.el4
NEW tcpxtract-1.0.1-7.el4
For more information about the built packages please see the repository
or the Fedora Info Feed: http://fedoraproject.org/infofeed/
17 years
Summary from yesterdays EPEL meeting
by Thorsten Leemhuis
Also in the wiki at
http://fedoraproject.org/wiki/EPEL/Meetings/20070311
= Meeting 20070311 =
[[TableOfContents]]
== Attending ==
* dgilmore
* mmcgrath (first part only)
* nirik
* quaid
* thl
== Summary ==
* getting RHEL5 on the builders is a priority now as we should use it
before we actually tell contributors to "really start now"; dgilmore and
mmcgrath will look into this; CentOS5 beta should hopefully be out soon
for testing by users, too.
* thl reworked the schedule a bit to reflect the current status a bit
better
* a shortcut for people wanting to branch lots of packages for EPEL
might be helpful. Is anybody interested in writing two scripts? Maybe
something like this:
* a short script that parses owners.list for all your packages by
e-mail and writes the list out on a single line (like
"random(a)host.somewhere foo bar foobar")
* another script then can be run on the branching machine that takes a
string like "EL-4,EL-5 random(a)host.somewhere foo bar foobar" and then
creates owners.epel.list entries for those packages (if they don't
exists already; needs to get the description from owners.list) and
creates the branches (the cvs admins would need to fill this part)
Then we could use a wiki page and a branch method similar to the old
Extras method for the EPEL start phase
* quaid worked on http://fedoraproject.org/wiki/EPEL/CommunicationPlan
; "what I'm hoping is ... anyone here who knows something that should be
in there, just pile it into the page if we get enough info, we'll spin
off a stand-alone page for that topic; otherwise it can be covered in
short there."
* we'll probably remove all those "PLEASE READ: This is currently a
being worked on and not yet finished -- consider it a draft and as not
yet official" warning from the wiki at end of march. Guys, please review
(and fix) what is written there!
* some discussion about steering issues that got discussed on the list
this week; seems people would like to prefer to stick to the current
scheme as long as problems that need to be solved can get solved with an
consensus on the list and in the meetings
* discuss the meeting time on the list again (discussion kicked off
already)
Note: there are some takes on the schedule at
http://fedoraproject.org/wiki/EPEL/Schedule
that could need some help. Anybody for example interested in setting up
a epel-release package, that people can install by "rpm -ivh
foo.src.rpm" and contains key and repo files for EPEL so it is
automatically used by up2date in RHEL 4, yum in RHEL 5 and yum on CentOS
4 + 5?
== Full log ==
{{{
00:00 * | thl looks around
00:00 < thl> | according to my clock it's EPEL meeting time
00:00 * | quaid kicks daylight savings in the shins
00:00 < thl> | ping dgilmore mmcgrath
00:00 < mmcgrath> | thl: pong
00:00 < thl> | hah
00:01 < thl> | quaid, yeah, we didn't change yet
00:01 < mmcgrath> | we had dst last night so it may be odd for people
to get in.
00:01 < thl> | we'll change in two weeks from now
00:01 < thl> | I'm fine moing the meeting time so the effective
meeting time stay the same
00:01 * | nirik is here, but also sick and on the phone. ;)_
00:01 --> | jmbuser (John Babich) has joined #fedora-meeting
00:01 * | thl has some food in the oven that will be read
in 15 minutes
00:01 < mmcgrath> | I've got an alarm clock that changes
automatically but its at least 7 years old. I woner what will happen
this year.
00:03 * | thl wonder if we should start the meeting or wait
another hour
00:03 < mmcgrath> | hmm
00:03 < EvilBob> | waiting and hour would be bad
00:04 * | thl wonders if waiting an hour would be the wrong
direction
00:04 < thl> | stupid dst changes
00:04 < jmbuser> | EvilBob: so you want to wait an hour? :-)
00:05 < EvilBob> | thl: FDSCo is waiting for the room
00:05 < thl> | EvilBob, k, noted, thx :)
00:05 < thl> | EvilBob, is that a regular meeting? then add it
to http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel ;-)
00:06 < thl> | well, then let's start
00:06 < dgilmore> | pong
00:06 < thl> | I updated the schedule a bit
00:06 < thl> | hi dgilmore
00:06 < thl> | the two most important things afaics are:
00:06 < thl> | get RHEL5 onto the builders
00:07 < thl> | so people can actually start
00:07 < thl> | and find some kind oft shortbut for branching for
people that have a lot of pacakges
00:07 < thl> | mmcgrath, quaid, do you have access to RHEL5 already?
00:07 < thl> | could you get it onto the builders?
00:07 < thl> | dgilmore, seems quite busy already afaics
00:08 < mmcgrath> | thl: Possibly, I'm waiting to hear back from the
cusotmer service people.
00:08 < dgilmore> | thl: there is supposed to be a way using up2date
to pull all teh packages i need to work it out.
00:08 < mmcgrath> | Just so the people here know for the future, our
licenses have to go through Red Hat's customer service.
00:08 < quaid> | mmcgrath has much better theoretical chance than I do
00:08 * | dgilmore has not used up2date in many years
00:09 < mmcgrath> | and be extra careful about saying you need RHEL
entitlements for Fedora not "Fedora Entitlements" Someone about killed me.
00:09 < nirik> | thl: is the centos 5 beta out yet? last time I
checked it was not...
00:09 * | dgilmore really wants to just be able to rsync it
00:09 < dgilmore> | nirik: soon
00:09 < thl> | nirik, not yet; it was supposed to be out some
days ago but then they delayed it "to fix some more bugs"
00:09 < quaid> | mmcgrath: are you forming an internal group
through CS for all Fedora machines?
00:09 < nirik> | also, I think we should require all EL-4 branches
to also branch EL-5... we don't want to drop packages in upgrade, do we?
00:09 < thl> | mmcgrath, for now it would be enough to get RHEL5
00:09 < thl> | building against the beta1 sucks
00:10 < thl> | I don't want to tell people to actually start
before we have RHEL5 in the buildroots
00:10 < mmcgrath> | quaid: We actually have 150 RHEL licenses (I
didn't realize that)
00:10 < thl> | nirik, well, there are some people that moved to
core (and thus to RHEL5); we don#t want branches for those
00:10 < nirik> | well, it's also hard to start when you don't have
any way of testing it (at least I prefer to be able to test builds on a
new release)
00:10 < dgilmore> | mmcgrath: i noticed that the other day
00:11 < mmcgrath> | I'm still trying to get in touch with the right
people to see what we can do with them and how to renew, they expire in
May currently.
00:11 < thl> | nirik, I think it's okay to build blindly atm
00:11 < thl> | as stuff goes into a testing branch
00:11 < dgilmore> | RHEL 5 rhgb is ugly
00:11 < thl> | and hopefully CentOS5 will be out soon
00:11 < quaid> | mmcgrath: I recently set up a new group for the
online services, I'll find the details and fwd. to you
00:11 < mmcgrath> | quaid: danke
00:11 < dgilmore> | thl: hopefully before the end of march
00:12 < thl> | dgilmore, I hope so
00:12 * | dgilmore installed beta2 as a kvm guest last night
00:12 < thl> | so, who takes over the RHEL5 on the builders
task? mmcgrath?
00:12 < dgilmore> | thl: im fine with doing it
00:12 < thl> | is it possible to get RHEL5 until next week?
00:13 < mmcgrath> | I'll get the content (rpms) then dgilmore or I
will set up the configs.
00:13 < thl> | dgilmore, k, also fine for me :)
00:13 < dgilmore> | i just need to work out the best way to do so and
maintain them
00:13 < mmcgrath> | I wonder if we have a TAM or something :-D
00:13 < thl> | dgilmore, mmcgrath, well, is there any chance to
get RHEL5 stuff onto the builders by next week?
00:13 < thl> | s/by/during/
00:14 <-- | FrancescoUgolini has quit ("Quit")
00:14 * | thl looks after his food in the oven
00:14 < dgilmore> | thl: :) it is doable in one way or another
00:15 < mmcgrath> | thl: I think that should be doable, I've been
having trouble finding the right email address to contact.
00:15 < thl> | dgilmore, mmcgrath that would be great; thx for
your help
00:16 * | thl will leave soon for a while to eat the stuff
that cooking
00:16 * | mmcgrath too might have a small interuption this
morning
00:17 < thl> | sorry for the trouble
00:17 < mmcgrath> | and there it is, br
00:17 < mmcgrath> | b
00:17 < thl> | the schedule is at
http://fedoraproject.org/wiki/EPEL/Schedule
00:17 < thl> | maybe you guys want to talk about other things?
00:17 < thl> | or we stop and meet again next week
00:18 < thl> | what about the steering issues thimm brought up?
00:18 < thl> | should we discuss them now?
00:18 < dgilmore> | there are alot of people not here
00:18 * | thl now afk for a while; sorry
00:18 < dgilmore> | quaid: how goes your work?
00:19 < quaid> | dgilmore: heh, which? for the most part, pretty good
00:19 < dgilmore> | quaid: :) cool anything to report in regards to EPEL
00:20 < quaid> | ah, you mean, on this topic :)
00:21 < quaid> | I haven't found the right people to propose
subscriptions for EPEL maintainers
00:21 < dgilmore> | cool
00:21 < nirik> | dgilmore: I see there isn't a epel el5 version in
bugzilla... should there be along with el4? or not until we get
buildroots, etc spun up and happy?
00:21 < quaid> | I may want to coordinate with mmcgrath and have
those added as aspecial subs to the Fedora group
00:22 < dgilmore> | nirik: i asked for it when it was setup and he
didint do it
00:22 < nirik> | bummer
00:22 < dgilmore> | i figured ill bug him when RHEL 5 is released as
final
00:22 * | quaid had several Firefox crashes while writing
up CommunicationPlan, but there is at least a start there now
00:22 < dgilmore> | quaid: possibly
00:23 < quaid> | http://fedoraproject.org/wiki/EPEL/CommunicationPlan
00:23 < quaid> | what I'm hoping is ...
00:23 < quaid> | anyone here who knows something that should be in
there, just pile it into the page
00:23 < quaid> | if we get enough info, we'll spin off a
stand-alone page for that topic;
00:24 < quaid> | otherwise it can be covered in short there.
00:24 < dgilmore> | sounds good
00:24 * | thl back at the keyboard, with some food besides him
00:25 * | thl will take a closer look at
http://fedoraproject.org/wiki/EPEL/CommunicationPlan later
00:25 < quaid> | thl's food is on the keyboard!
00:26 < thl> | btw, when do we plan to remove all those "PLEASE
READ: This is currently a being worked on and not yet finished --
consider it a draft and as not yet official" warning from the wiki?
00:26 < dgilmore> | thl: what do you have to eat?
00:26 < nirik> | I would say we could do that when we offically
announce and move things from testing to a main repo?
00:27 < quaid> | personally, I need to spend a few hours going
over the language clarity, etc., before I want to remove draft warnings :)
00:27 < quaid> | but I'm always wanting to do that, so don't let
that hold us back
00:28 < thl> | dgilmore, some pasta
00:28 < dgilmore> | thl: :
00:28 < dgilmore> | ;) yum
00:29 < thl> | quaid, I'd say we should plan to remove those in
two or three weeks
00:29 < thl> | quaid, so there is still some time to fix all
those stupid typos and grammatical mistakes thl made ;-)
00:29 < quaid> | :)
00:30 < thl> | shall we plan 20070401 as target date for remoal
of those warnings?
00:30 < dgilmore> | wy is rhn down again
00:30 < f13> | dgilmore: RHEL5 syncup
00:30 < dgilmore> | thl: sounds good
00:30 < thl> | I can send a mail to the list asking people to
look over it
00:30 < dgilmore> | f13: ahh
00:31 < quaid> | new code, too
00:31 < dgilmore> | f13: do you know of anyone we could bug that
would let us be able to rsync trees from cvs-int
00:32 < mmcgrath> | Sorry guys I have to scoot, an out of town friend
just dropped by :-/
00:32 < dgilmore> | mmcgrath: have fun
00:32 < thl> | mmcgrath, yeah, have fun!
00:33 < thl> | btw, is anybody willig to work out two small scripts?
00:33 < thl> | so make it a bit easier for dgilmore to branch
packages for EPEL?
00:34 < thl> | one script that looks at owners.list for all
packages owned by foo
00:34 < thl> | and another script that creates owners.eple.list
entries and the branches from a string like "EL-4 foo@bar baz foobar ..."
00:35 < thl> | quaid, btw, what's your take on the steering issues?
00:35 < thl> | should we have a steering committee soon?
00:35 < quaid> | thl: sorry, which?
00:35 < quaid> | oh
00:36 < quaid> | are we prepared to have an election for it?
00:36 < thl> | quaid, I'd say FESCo should appoint people
00:36 < thl> | and then we target for a election three months later
00:37 < nirik> | so all thats just so we can vote on
fedora-usermanagement?
00:37 < dgilmore> | thl: if we have one thats how i would say we do it
00:37 < thl> | nirik, well, I think it's a general problem
00:37 < quaid> | thl: that's interesting, in that I don't think FP
has a process for that
00:37 < thl> | the question "who decides" in not regulated afaics
00:38 < thl> | I can ask FESCo what they would prefer
00:38 < quaid> | http://fedoraproject.org/wiki/DefiningProjects
00:39 < quaid> | it's the last section
00:39 < thl> | quaid, I'd say we should not make a official
project yet
00:39 * | thl takes a look
00:39 < quaid> | right, so to have a steering committee implies
formal project
00:40 * | thl wonders why can't we have a SIG that has a
steering committee without being a official project
00:40 * | quaid adds anchors and toC to that page
00:40 < quaid> | thl: maybe we can
00:40 < quaid> | thl: in which case, appointment is the form, i guess
00:41 < thl> | quaid, FESCo should be able to regulate it
00:41 < thl> | the question still is if we want one...
00:41 < quaid> | maybe wait until the SIG is too big?
00:42 < thl> | quaid, or until problems that need to be solved
can't get solved without an real consensus
00:42 < quaid> | yeah
00:43 < thl> | other opinions? dgilmore, nirik ?
00:43 < nirik> | well, I hate to add a bunch of overhead just to
solve one contentious issue...
00:44 < dgilmore> | nirik: indeed
00:44 < nirik> | didn't ensc say fedora-user-mgmt won't work on
EL4? we could then remove it for now and let fedora come up with a
solution down the road?
00:44 < thl> | nirik, well, having a steering committee might
makes things easier sometimes, too
00:44 < dgilmore> | i think if we have a steering committe we are
likely to diverge from fedora
00:44 < thl> | nirik, the lates version doesn#t work on EL4
00:44 < thl> | nirik, older ones do
00:44 < dgilmore> | id like to do whatever we can to make sure we dont
00:45 < nirik> | dgilmore: +1
00:45 < dgilmore> | thl: the version in EL-4 should be FC-3's
00:45 < dgilmore> | so it should work
00:46 < thl> | yeah, it should
00:47 < thl> | so we leave this open as see how it envolves over
time?
00:48 < nirik> | I think it should be possible to come to some
technical consensus... not easily, but it should be possible
00:49 < nirik> | I do see ensc has been putting up ideas for what
should be addressed in a replacement, which is good.
00:49 < thl> | k
00:49 < thl> | so anything else?
00:50 < thl> | or shall we adjourn and meet again next week?
00:50 < nirik> | do we want to look at a new meeting time where
more of the people from the list can make it?
00:51 < nirik> | might help solve some of the issues if we can get
everyone talking...
00:51 < nirik> | s/talking/typing/
00:51 < thl> | nirik, I asked once on the mailing list if people
would like a new meeting time
00:51 < thl> | one or two weeks ago
00:51 < thl> | I got no replay
00:51 < thl> | reply
00:51 < quaid> | we should discuss it on list :)
00:51 < thl> | but I agree, we should ask once again on the list
00:51 < quaid> | now that we all experienced DST pain, it will be
back on people's minds
00:52 < nirik> | huh... not sure I ever say it... ok.
00:52 < nirik> | ever saw it. Sorry, cold meds must be affecting
my typing. ;)
00:53 < thl> | nirik, I think it was in a meeting summary
00:53 < thl> | so anything else?
00:53 < thl> | or close for today?
00:53 < nirik> | ok, we should post again now about it in it's own
post. Can you do that thl ? or would you like me to?
00:53 < dgilmore> | i have nothing else
00:54 < dgilmore> | my time available for meetings is limited
00:54 < dgilmore> | i cant do it during work time
00:54 < thl> | nirik, I'll do
00:54 * | thl will close the meeting in 30
00:54 * | thl will close the meeting in 15
00:55 <-- | jmbuser has left #fedora-meeting ( "Leaving")
00:55 < thl> | -- MARK -- Meeting end
00:55 < thl> | thx guys
00:55 < nirik> | dgilmore: yeah, but after business hours some
weeknight might work?
00:56 < nirik> | thanks thl
00:57 < thl> | nirik, thx in the middle of the night for me....
00:57 < thl> | s/thx/that's/
00:57 < nirik> | whats your TZ offset? if it's late enough here
wouldn't it be your morning?
00:57 * | quaid notes that FDSCo is meeting currently in
#fedora-docs
00:57 < thl> | everything later in the evening than FESCo is
problematic for me
00:57 < thl> | nirik, UTC-1
00:58 < thl> | nirik, UTC-2 when in two weeks, when we get DST
00:58 < thl> | I'm on the yeboard at round about 6:40 local time
in the mornings
00:58 < nirik> | quaid: might suggest switching to here? it's nice
to have all the meetings in one place so people can lurk and hear about
things they normally don't know about...
00:58 < dgilmore> | nirik: yep but i think its to late for europe
00:58 < quaid> | nirik: it's an ongoing discussion at the moment,
actually
00:59 * | thl really likes #fedora-meeting -- that way one
gets a chance to look what the others are discussing
00:59 < dgilmore> | thl: :) yep i like it to
}}}
17 years