Revisiting the mass rebuild plans for EPEL5
by Thorsten Leemhuis
Hi,
FESCo today nacked the rebuild plan from voting "1" in
https://www.redhat.com/archives/epel-devel-list/2007-April/msg00055.html
See the end of this mail for details. In short: FESCo afaics didn't like
to leave release unchanged.
So I'd like to propose we switch back to the alternate plan (should
still be in the wiki at
http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting
but the wiki is down currently aaics :-( ) that I proposed in the vote.
That would mean: We announce when RHEL5 is on the builders to the public
and give people round about 72 (?) hours to rebuild their EPEL5 packages
manually on their own (in case they want to do it themselves).
Everything that didn't get rebuild gets a ".1" added to release in cvs;
that change gets committed, tagged and build -- we afaik have a script
that should be able to do that and I can take care of running it if
that's okay for everyone.
Does that sounds sane to everyone?
CU
thl
P.S.:here is the relevant part from the FESCo meeting:
19:42 --- | bpepple has changed the topic to: FESCO-Meeting
-- EPEL
19:42 < bpepple> | anything in regard to EPEL need to be discussed?
19:42 < jwb> | yes
19:42 * | thl send some notes from this week to the list
19:43 < thl> | one hour or so ago
19:43 < tibbs> | notting: If you do have any ideas about that,
please let us know.
19:43 < jwb> | there was the buildroot issue Axel wanted acked
by FESCo
19:43 < notting> | tibbs: get out baseball bats and beat upstream? :)
19:43 * | bpepple hasn't had a chance to read his e-mail
today. :(
19:44 < thl> | bpepple, it's about the "mass-rebuild of EPEL5
now that we soon have RHEL5 final on the builders"
19:44 < thl> | bpepple, it was voted to delete everything and
just rebuild
19:44 < bpepple> | thl: ok.
19:44 < jwb> | -1
19:44 < thl> | everything, without chaning ENVR
19:44 < f13> | er..
19:44 < jwb> | yeah, -1
19:44 < f13> | that may not bode well for clients whom already
ahve stuff installed
19:45 < nirik> | (note: only EPEL-5... not 4)
19:45 < thl> | f13, tell those that voted like that
19:45 < f13> | as noted many times before, packages changing
checksums and such get messy
19:45 < jwb> | f13, it was noted in their discussion.
apparently it didn't seem that big of a deal
19:45 * | thl disliked that plan, too
19:45 < jwb> | are we voting on this yet?
19:45 < f13> | *shrug* I don't run rhel5 so I won't get
effected by it.
19:45 < jwb> | f13, more than rhel5
19:45 < bpepple> | jwb: Yeah, we should do a quick vote.
19:46 < tibbs> | I'm still not understanding why you wouldn't want
to bump, and I read the IRC logs.
19:46 < jwb> | tibbs, me either
19:46 < dgilmore> | tibbs: becaue people did not want to fork the spec
19:46 < jwb> | that is just lazy
19:46 < thl> | jwb, +1
19:46 < jwb> | you're pissing on your users because you don't
want to make a 2 character change
19:46 < dgilmore> | i wanted to add a .1 and rebuild
19:46 < tibbs> | Ah, that is a point, but I don't think it's a
terribly good point.
19:46 < jwb> | dgilmore, that would be very acceptable
19:46 < c4chris> | yea, .1 and rebuild
19:46 < rdieter> | dgilmore: +1
19:46 < tibbs> | The spec will diverge pretty much immediately anyway.
19:47 < jwb> | right
19:47 < thl> | dgilmore, why did you vote for deleting the
packges then?
19:47 * | thl is confused
19:47 < notting> | ? you don't need to fork the spec. just b/c the
release changes, doesn't mean you have to build and push for older releases
19:47 < jwb> | notting, fork it vs. the fedora spec
19:47 <-- | sankarshan has quit (Connection timed out)
19:47 < f13> | notting: er, they have to bump the spec there,
but nowhere else, so now the specs are diverged
19:48 < notting> | *horrors*
19:48 < tibbs> | As I understand things, EPEL has no reason to
attempt to keep any kind of release ordering with Fedora.
19:48 < dgilmore> | thl: i was confused by then.
19:48 < f13> | not that I find anything _wrong_ with that.
19:48 < tibbs> | So it's not even appending ".1"; just bump the
release.
19:48 < f13> | nod
19:48 < thl> | dgilmore, np, I was just confused now
19:48 < notting> | thl: well, two issues. i'd be all for 'rebuild
and delete all old packages', but with a release bump
19:48 < thl> | tibbs, some people prefer to appending ".1" ovefr
bumpin the release
19:48 < f13> | is there a call for fesco vote?
19:48 < thl> | I think they have a point
19:49 < jwb> | f13, axel requested one
19:49 < f13> | or a point 1
19:49 < f13> | (:
19:49 < thl> | notting, sounds fine for me
19:49 < c4chris> | :-)
19:49 < tibbs> | OTOH, not rebuilding at all seems to be working
for Fedora at this point. What's the reason they absolutely must be
rebuilt?
19:49 < abadger1999> | tibbs: If they want to use the vanilla spec
later, using .1 lets them come back on the next Fedora Release rather
than the next upstream bump
19:49 < nirik> | tibbs: they were build against beta1
19:49 < tibbs> | abadger1999: Extremely good point.
19:49 < f13> | abadger1999: but that actually overwrites history
19:50 < f13> | unless they merge that .1 somewhere into the
history of hte FEdora spec
19:50 < nirik> | abadger1999: yeah, changelog is lost then if you
merge
19:50 < tibbs> | nirik: And we have .fc6 packages in F7; surely F7
diverges from FC6 more than rhel5b1 diverges from rhel5release.
19:50 < thl> | f13, is that really a big problem if it was just
a "rebuild" in the chanelog?
19:50 < notting> | dgilmore, this is only rebuilding things actually
built for EPEL, not everything in EPEL cvs, right?
19:50 < thl> | notting, yes, only what has been build up to now
19:51 < f13> | thl: it's not a really big problem, but I
generally don't like to see history get stomped
19:51 < nirik> | tibbs: yeah, you would think so... dunno for sure.
19:51 < thl> | f13, agreed; I think in this case it's still not
nice, but acceptable
19:51 < f13> | and who k nows what happens with the rebuild,
something may end up needing changed to build again against RHEL5 GA
19:51 < f13> | tibbs: you'd be surprised what all changed from
B1 to GOLD
19:52 * | rdieter thinks we're not here to (re)make epel's
decision for them (or not?), just ack or nack it.
19:52 < f13> | -1
19:52 < f13> | (for their current plan)
19:52 < jwb> | -1
19:52 < c4chris> | (plan == rebuild and no bump, right)
19:52 < jwb> | rdieter, but we can nack with a suggested improvement
19:52 < thl> | c4chris, yes
19:52 < f13> | c4chris: yep
19:53 < bpepple> | c4chris: correct.
19:53 < c4chris> | k, -1 then
19:53 < notting> | -1
19:53 < bpepple> | -1 here also.
19:53 < tibbs> | Yeah, I hate to be an obstruction, but -1 to
rebuilding with no bump.
19:53 < abadger1999> | -1
19:53 < thl> | jwb, I can take care of that if you want; i was
against this in any case ;-)
19:53 < bpepple> | so it looks like we against EPEL suggested plan.
19:53 < jwb> | thl, great
19:54 <-- | gregdek has quit (Read error: 104 (Connection
reset by peer))
19:54 < thl> | bpepple, I'll get that out to epel and will take
care of it
19:54 < dgilmore> | notting: yeah just whats built
19:54 < bpepple> | thl: great, thanks.
17 years, 1 month
Summary of EPEL Steering Committee meeting 20070412
by Thorsten Leemhuis
= Meeting 20070412 =
[[TableOfContents]]
== Attending ==
>From the Steering Committee:
* dgilmore
* mmcgrath
* nirik
* quaid
* stahnma
* thl
Active on the rabble seats:
* entr0py
* wolfy
== Summary ==
* wiki votings -- some people on the list complained about hardcoding
releasever in the repofile. stahnma will look into the issue closer and
ask the infrasturcute guys if a symlink could be set in place
* votings via the wiki -- might need a bit more coordination in the
future; reminders ("vote now") probably also; "we need more info on some
of the issues"; all things of course can get revisited if we want, but
we should probably take a issue as solved for the near future when it
got voted upon; stahnma asked 'should I be voting "on behalf of epel
consumers" or as a fedora developer? '; thl answered that it's probably
a mix;
* the idea to have a chairmen that coordinates was liked by some people
(quiad: "I thought it was a requirement of a steering committee (or I
think it should be) ") ; dgilmore brought this to the list for public
discussion.
* RHEL5 on the builders - legal problems got solved and should happen
real soon now; dgilmore will look after the mass-rebuild as voted and
then thl will announce the "Go" signal afterwards to those Fedora
packages that are still waiting for it
* pushing scripts/repo layout: thl will bring this to the list for
further discussion
* stahnma will help quiad with his "Communication plan for enterprise
customers/ISVs/IHVs"
http://fedoraproject.org/wiki/EPEL/CommunicationPlan ; will get send to
the list for further discussion, too.
== MISC ==
There were three votings by the EPEL steering committee done via the
wiki; see
https://www.redhat.com/archives/epel-devel-list/2007-April/msg00055.html
for details. In short: no repotags, fedora-usermgmt does not get
forbidden and the mass-rebuild will happen in a "delete repo and just
rebuild everything again with RHEL5 final on the builders now"-style.
== Full Log ==
{{{
00:01 --- | thl has changed the topic to: EPEL Meeting
00:01 < thl> | hi everyone
00:01 * | entr0py grabs first set of rocks to volley into
the group :)
00:01 < thl> | ping dgilmore mmcgrath_ stahnma quaid nirik
00:02 < stahnma> | ack
00:03 < nirik> | I'm mostly here.
00:03 < thl> | that makes 2,5 people afaics
00:03 < quaid> | howdy
00:04 < thl> | 3,5
00:04 < stahnma> | almost a quarum
00:04 < quaid> | depends on your def. of a quorum; "enough to be
the majority of the vote if the consensus is 100%" is good enough for me :)
00:04 < quaid> | also, thimm said he'd be ... late? half way
through, right?
00:05 < thl> | quaid, yes, that's what he said
00:05 < stahnma> | do we have topics?
00:05 * | thl really would like to know what the status of
RHEL5 final on the builders is; but we need mmcgrath_ and dgilmore for that
00:05 < thl> | stahnma, well, we have a schedule
00:05 < stahnma> | I know dgilmore was working on it the other night
when i was chatting with him
00:06 < stahnma> | good enough :)
00:06 < thl> | afaics we should talk about these topics:
00:06 < nirik> | is centos5 out yet? I think I saw something about
it starting to mirror..
00:06 < stahnma> | oooh
00:06 < stahnma> | haven't seen it
00:06 < thl> | RHEL5 final on the builders
00:06 < thl> | did we like the wiki votings
00:06 < thl> | anything to further discuss about the wiki votings
00:06 < entr0py> | c5 still mirroring
00:07 < thl> | revisit the hardcoding of releasever in the repo
file
00:07 < nirik> | it's not hit my mirror yet, oh well.
00:07 < stahnma> | I guess since our votings are quite public, I
think we should be able to say why we vote the way we do
00:07 < stahnma> | currently the release is harded in epel-release
00:07 < stahnma> | it can change if the repo changes
00:07 < thl> | stahnma, yeah, I know; but some people complained
on the list
00:07 < stahnma> | and that's an infrastructure call
00:08 < stahnma> | yeah, I can go either way
00:08 < stahnma> | I normally wouldn't recommend an upgrade from EL
n to EL n+1
00:08 < stahnma> | via yum
00:08 < thl> | yeah, but we need dgilmore and mmcgrath_ for
that, as those two could create the proper links on the server
00:08 < stahnma> | or up2date
00:08 < stahnma> | but whatever
00:08 < nirik> | I've had 3->4 work with centos yum updates anyhow...
00:09 < nirik> | but yeah, not something supported, but nice to
have the option for people if they want to try.
00:09 < stahnma> | well, they can edit the repo files also...
00:09 < stahnma> | isn't that how you have to start an upgrade?
00:09 < stahnma> | change what repo you point at?
00:10 < thl> | stahnma, installing a new fedora-release in
enough in fedora
00:10 < stahnma> | in which case, the repo files being hard-coded or
not doesn't matter correct?
00:10 < nirik> | upgrade the release file... no changing of the
files.
00:10 < stahnma> | oh ok
00:10 < thl> | I suspect it will be similar in RHEL/Centos
00:10 < stahnma> | been a long time since I have done an upgrade
like that
00:10 < stahnma> | as I said, i will happily change it
00:10 < stahnma> | if it will work
00:10 < stahnma> | I changed to hard-coding after it didn't work on
RHEL
00:10 < thl> | stahnma, could you work on getting the whole
issue solved?
00:10 < stahnma> | thl: sure
00:10 < thl> | stahnma, e.g. ask dgilmore and mmcgrath_ for
their opinion
00:11 < stahnma> | no problem
00:11 < stahnma> | I speak with dgilmore daily
00:11 < thl> | and get is discussed on the mailig list if needed
00:11 < thl> | stahnma, k, sounds good
00:11 < stahnma> | yup, next item
00:11 --- | thl has changed the topic to: EPEL meeting --
votings via the wiki
00:11 * | rdieter is lurking in the shadows...
00:11 < thl> | so, did we like it?
00:11 < thl> | I'd say we need more coordination
00:11 <-- | llaumgui has quit (Read error: 110 (Connection
timed out))
00:11 * | quaid is pretty sure that updating redhat-release
is similar
00:11 < nirik> | well, it was ok, but we need more info on some of
the issues I think.
00:12 < thl> | otherwise each and everyone might issue votings
00:12 < stahnma> | reminders sent va email would be cool
00:12 < thl> | and that could lead to chaos
00:12 * | entr0py agrees with nirik
00:12 < quaid> | I explained my problems in my comment field of my
vote
00:12 < thl> | it was a hard discussion this time already
00:12 --> | llaumgui (LLaumgui) has joined #fedora-meeting
00:12 < thl> | quaid, that's okay; but I think it's nevertheless
good to have you here
00:12 < quaid> | I had to abstain because of ignorance, and I
couldn't tell if I was ignorant because the issues were too complex, or
because this was a molehill being made into a mountain.
00:12 --> | kital (Joerg Simon) has joined #fedora-meeting
00:13 < thl> | nirik, agreed to "more info"
00:13 < GeroldKa> | hello kital
00:13 < thl> | nirik, that what I mean with more "coordination",
too
00:13 < nirik> | it's also unclear... does this mean those issues
are decided forever? (I hope not) or just for "a while"
00:13 < stahnma> | I question my voting: should I be voting "on
behalf of epel consumers" or as a fedora developer?
00:13 < quaid> | thl: so, I had to have faith that a vote was
useful in this case
00:13 < kital> | hi GeroldKa
00:13 < quaid> | stahnma: good question
00:13 < thl> | nirik, I'd say wiki votings are similar to
votings here
00:13 < thl> | e.g. we can always revisit stuff if we like to
00:14 --> | wolfy (Manuel Wolfshant) has joined #fedora-meeting
00:14 < nirik> | good, althought not every week I hope. ;)
00:14 < thl> | nirik, agreed :)
00:14 < stahnma> | maybe we say a vote cast drops an item for 60
days or something?
00:14 < stahnma> | or maybe need a policy that formal
00:14 < thl> | stahnma, no rules, for details like that IMHO
00:14 < nirik> | hopefully folks will push a replacement for
fedora-usermgmt in fedora and we can just do the same thing when they do.
00:14 < thl> | stahnma, that makes it just hard
00:14 < stahnma> | s/need/don't\ need
00:15 < thl> | s/hard/complicated/
00:15 < stahnma> | ok
00:15 * | dgilmore is here
00:15 < thl> | stahnma, and I'd say you should vote as someone
that wants the best for epel (which in parts is "on behalf of epel
consumers" and as "fedora developer" IMHO)
00:16 * | thl welcomes dgilmore
00:16 < thl> | dgilmore, will you stick around for the rest of
the meeting?
00:16 < dgilmore> | nirik: fedora-usermgmt from FC-3 will work fine
on RHEL4
00:16 < dgilmore> | thl: ill be here
00:16 < nirik> | right. and it's already in, so thats the way it
will be for now.
00:17 < dgilmore> | yep
00:17 * | nirik needs to look at branching munin at some
point now.
00:17 < stahnma> | thl: sometimes those are conflicting though
00:17 < thl> | stahnma, that's life ;-)
00:17 < stahnma> | thl: from a consumer prospective, I want a
repo-tag, from a developer prospective, I understand not wanting it
00:17 < stahnma> | thl: true
00:17 < dgilmore> | nirik: im going to branch mysql-gui-tools it has
some other things it needs
00:18 < thl> | so, how do we get more coordination into the wiki
votes in the future?
00:18 < thl> | do we need a chair that coordinates this and
other stuff?
00:18 < nirik> | I don't think so...
00:18 < thl> | or do we want rules like "at least two Steering
committee members are needed to start a voting"?
00:19 < nirik> | I would like to see 2 people setup a vote... one
"for" and one "against" the item, so they could each write the pros and
cons.
00:19 < stahnma> | I didn't think it was too bad. I think reminder
emails to vote are good. And, I agree that starting the vote needs to
be looked at
00:19 < dgilmore> | nirik: if everyone agrees then we will never vote
00:19 < stahnma> | nirik: +1
00:19 < nirik> | having input from people on both sides would help.
00:19 < quaid> | seems like the question of "to chair or not to
chair" is maybe not ours to make; I thought it was a requirement of a
steering committee (or I think it should be)
00:19 < nirik> | dgilmore: don't want them to agree on the issue,
just agree to summarize it for a vote...
00:20 < entr0py> | nirik, i agree, which is what i was pointing out
to thimm. without opposing views, what is the vote really worth
00:20 < quaid> | once a project reaches the size or scope to need
a *SCo ...
00:20 < thl> | quaid, well, we never discussed it; but yes, I
also tend to say a steering committee normally should have a chairmen
00:20 < dgilmore> | i think that we need a chair person and that
they put up the votes
00:20 < quaid> | it needs an identified single person that all the
rst of the world recognizes as "in charge" and "person to go to"
00:20 < quaid> | it can be nominal, etc., but it helps
00:21 < thl> | quaid, +1
00:21 < stahnma> | quaid +1
00:22 < dgilmore> | anyone want to nominate themselves as the chair
person
00:22 < stahnma> | so do we need to figure out a chairperson for
vote postings?
00:22 < stahnma> | I'd do it
00:22 < mmcgrath_> | crizap
00:22 * | mmcgrath_ here
00:22 < quaid> | we could discuss on list, too, since all aren't
here right now. :)
00:22 * | thl could do the chair as well
00:23 < thl> | quaid, well, we should at least wait one week
before lecting a chairmen
00:23 < quaid> | +1
00:23 * | stahnma votes for thl since he has experince and
withdraws earlier statement
00:23 < dgilmore> | stahnma: too late
00:23 < stahnma> | haha
00:23 < quaid> | stahnma: well, how do you think he got the
experience?
00:23 < stahnma> | good point
00:23 < quaid> | stahnma: have to start somewhere :D
00:23 < stahnma> | yeah, I have the time to put into it for the most
part, so that's a plus
00:24 * | dgilmore feels he would not be able to be a good
chair person.
00:24 < nirik> | I think it should get discussed on the list...
00:24 < stahnma> | +
00:24 < dgilmore> | ok so we have two nominees lets take it to the list
00:24 * | nirik would be happy with thl or stahnma
00:25 < stahnma> | ok, back to RHEL 5 on the builders? (now that
infrastructure folk are here)
00:25 < thl> | so, shall we mention it in the summary or shall
someone open a seperate discusion?
00:25 < thl> | seperate discussion +1
00:25 < stahnma> | either way is fine with me
00:25 < dgilmore> | thl: ill start a seperate discussion
00:25 < thl> | dgilmore, k, thx
00:25 < thl> | and I'll write the summary
00:25 --- | thl has changed the topic to: RHEL5 on the builders
00:26 < thl> | mmcgrath_, dgilmore, any news?
00:26 < mmcgrath_> | Yeah, we finally have approval.
00:26 --- | thl has changed the topic to: EPEL meeting --
RHEL5 on the builders
00:26 < thl> | hurray!
00:26 < mmcgrath_> | so we can put it up whenever we're ready.
00:26 < thl> | mmcgrath_, when are we ready?
00:26 < mmcgrath_> | we can do it now
00:26 < thl> | now sounds really good to me :-)
00:27 < thl> | I'd really like to start, and we need RHEL5 final
for that
00:27 < dgilmore> | mmcgrath_: want me to do it tonight?
00:27 < mmcgrath_> | dgilmore: sounds good to me.
00:27 < thl> | dgilmore, thx
00:28 < thl> | who can kick off the rebuild after RHEL5 is
installed?
00:28 < thl> | and when?
00:28 < mmcgrath_> | when, any time.
00:29 < thl> | can we get that done until Sunday maybe?
00:29 < thl> | then I could send out a "now start for realy
guys" mail out on sunday evening/Monday
00:29 < mmcgrath_> | I think anyone can request a rebuild, I've been
late on catching up on EPEL traffic. Did we decide exactly how we're
going to do it?
00:29 < dgilmore> | mmcgrath_: rm -rf
00:30 < thl> | mmcgrath_, the wiki-voting was "delete and just
rebuild"
00:30 < thl> | s/was/agreed on/
00:30 < mmcgrath_> | excellent.
00:30 < thl> | but that requires that either you or dgilmore do
it afaics
00:31 < thl> | I can help if you tell me what to do
00:31 < thl> | but I think there are scripts that automate
everything?
00:32 < mmcgrath_> | not that I know of.
00:32 < dgilmore> | thl: ill work out an easy way to get it done
00:32 < thl> | dgilmore, thx
00:32 < dgilmore> | the scripts we have do a bump and build
00:32 < thl> | k
00:33 --- | thl has changed the topic to: EPEL meeting --
what else?
00:33 < thl> | anything else to discuss?
00:33 < stahnma> | thl: will this "for real now guys" message ask
people to get their packages into EPEL?
00:33 * | dgilmore has nothing right now
00:33 < dgilmore> | stahnma: yes
00:33 < entr0py> | is there any target date for announcement of the
repos?
00:34 < thl> | stahnma, well, it more a "if you waited for the
signal to start then this is it" mail
00:34 < dgilmore> | along with if you dont want to and someone else
does we will let them
00:34 < nirik> | so do we have all the pushing scripts set? what
about with the testing repo?
00:34 < stahnma> | thl: that's fine.
00:34 < thl> | entr0py, not yet
00:34 < stahnma> | what about mirrors?
00:34 < thl> | entr0py, I#d say we need to test a bit more
00:34 < dgilmore> | nirik: that will be in the next week
00:34 < thl> | and we need the final repo layout
00:34 < dgilmore> | we need boshi for that
00:34 < dgilmore> | bodhi
00:35 < dgilmore> | lmacken: where you at?
00:35 < nirik> | how do developers push from testing to release?
ah... bodhi will be available?
00:35 * | thl for a moment thought he got confused with all
those codenames
00:35 * | dgilmore needs to help lmacken
00:35 < lmacken> | dgilmore: i'm here
00:35 < entr0py> | will the rebuild push everything to testing?
00:35 * | nirik is eager to break^H^H^H^H^Htry out bodhi.
00:35 < dgilmore> | lmacken:everything other than the bit i said i
would do in place
00:36 < thl> | entr0py, everything should be in testing IMHO,
but isn't :-/
00:36 < lmacken> | dgilmore: yeah. I have yet to make sure my
updates stage matches the EPEL layout that you guys voted on
00:37 < dgilmore> | ok
00:37 < stahnma> | do we have a process to move from testing to proper?
00:37 < lmacken> | there is a "Mark as stable" button in bodhi
00:37 < thl> | lmacken, the layout can be adjusted if we need
to, but I think the current proposal should make most people happy
00:37 < lmacken> | which will request that it be mvoed from
testing=>final
00:37 < dgilmore> | stahnma: i thought we were going to do votes or 2
weeks
00:37 < lmacken> | thl: ok
00:37 < stahnma> | dgilmore: that's fine, I was just curious if we
had a method. (I didn't remember)
00:38 < thl> | stahnma, most stuff normally should go to testing
anyway
00:38 < thl> | and stay there until the next quarterly update
00:38 < dgilmore> | security updates can bypass testing thats it
00:38 < thl> | only security or other bad bugs should go to
stable directly
00:38 < stahnma> | thl: I agree , just want to make sure I
understand how things work
00:39 < entr0py> | thl: agree, weren't we working on formalizing an
approach for epel?
00:39 < thl> | stahnma, I'd say we should take a closer look at
it when we know how bodhi works
00:39 < stahnma> | maybe make that a future topic
00:39 <-- | kital has quit (Read error: 110 (Connection timed
out))
00:39 < stahnma> | for discussion
00:39 < wwoods> | The method is evolving but should involve some
testing by a QA-type person
00:39 < stahnma> | seems fair
00:39 < nirik> | yeah, testing ++
00:39 < thl> | wwoods, for epel there was actually a three stage
mechanism under discussion
00:40 < wwoods> | we want to start writing how-to-test docs for
each package, but basically the short version will be that some QA
person needs to actually install the package and make sure it actually
works
00:40 --> | kital (Joerg Simon) has joined #fedora-meeting
00:40 < wwoods> | what are the three stages?
00:40 < nirik> |
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies
00:40 < thl> | wwoods, kind of "testing-testing" (new builds),
"testing" (becomes stable with the next quearterly update and "stable"
(only serios bugfixes)
00:41 <-- | kital has quit (Remote closed the connection)
00:41 < nirik> | oh wait, that wasn't the right link...
00:41 < wwoods> | In my mind there's quite a few possible stages -
automated package sanity testing, manual functional verification by a QA
dude, automated regression tests
00:42 < lmacken> | wwoods: as well as updates-testing community testing
00:42 < wwoods> | the updates-testing repo is basically a work
queue for QA
00:42 < thl> | we probably should discuss this on the list
00:42 < nirik> | wwoods: the diffrence between fedora and epel
here is that epel would be considered to be in "freeze" all the time...
only bugfixes to the release... new functionality/versions only happen
at new minor RHEL releases.
00:42 < thl> | that might make things a bit easier
00:42 < mmcgrath_> | thl: +1
00:42 < wwoods> | well, when I say "QA dude", that's kind of a
vague handwave for "Either an official QA guy or, until we have a big
enough QA team, community folks"
00:43 < wwoods> | but yeah
00:43 <-- | bpepple has left #fedora-meeting ( "Ex-Chat")
00:43 < wwoods> | we can take this to the list, but I'd like to sit
down and define a QA process for stuff in updates-testing
00:43 < thl> | mmcgrath_, I'll write everything up and send it
to the list over the next week
00:43 < lmacken> | wwoods:
https://hosted.fedoraproject.org/projects/bodhi/wiki/DesignTesting
00:43 < lmacken> | poelstra helped get that ball rolling
00:44 < wwoods> | awesome
00:44 < lmacken> | wwoods: the actual files are in the bodhi code..
feel free to modify
00:44 < thl> | k, so anything else regarding EPEL?
00:45 < stahnma> | I still would like to see us work on something
encouraging involvment from companies
00:45 < stahnma> | I don't know exactly how/what
00:45 < stahnma> | but I think first step is to have EPEL in existance
00:45 < stahnma> | so maybe not today
00:45 < dgilmore> | stahnma: as would i quaid is best to do that
00:45 < thl> | stahnma, didn't quaid work on something in that
area?
00:45 * | dgilmore needs to go get food soon
00:45 < thl> | stahnma, "Communication plan for enterprise
customers/ISVs/IHVs" is on the schedule
00:45 < nirik> | having a functioning setup will help with
community and company involvement.
00:46 < thl> | and it's assigned to quaid
00:46 < thl> | stahnma, there is a wiki page
00:46 < thl> | stahnma, maybe you can help him with that a bit?
00:46 * | stahnma apparently can't read and forgets what he
reads after the fact :)
00:46 < stahnma> | yeah, i will help with that
00:46 < nirik> | lmacken: that chart is great. Just what I was
thinking the process would be. ;)
00:46 < quaid> | there is a page
00:46 * | quaid looks for URL
00:46 < lmacken> | nirik: nice
00:47 < thl> | quaid,
http://fedoraproject.org/wiki/EPEL/CommunicationPlan
00:47 < quaid> | ah, that one yes
00:47 < quaid> | right
00:47 < stahnma> | quaid: ah , I remember that
00:47 < quaid> | the help I need is the part i don't have in my
head, the rebuild developers/packagers
00:47 < stahnma> | quaid: great start :)
00:47 < quaid> | and the rebuild users
00:47 < quaid> | stahnma: thanks :)
00:48 < quaid> | I'll either write or coordinate the RHEL
Customers section, since I do somewhat understand that audience :)
00:48 < quaid> | same with the isv/ihv part
00:48 < stahnma> | great
00:48 * | stahnma is out of random topics
00:48 < thl> | quaid, maybe sending what you have to the list
and asking for opinions and feedback might help to evolve it further
00:48 < quaid> | we could take this to the list for discussion,
whenever we are ready
00:48 < quaid> | heh, jinx!
00:48 < quaid> | thl: right-O, will do
00:49 < thl> | k, anything else?
00:49 < dgilmore> | thl: nope
00:49 * | thl will close the meeting in 60
00:49 < stahnma> | later all, lunch time here...
00:50 * | thl will close the meeting in 30
00:50 * | thl will close the meeting in 15
00:50 < thl> | -- MARK -- Meeting end
00:50 < thl> | thx everyone
00:50 < wolfy> | thank you, guys
00:51 < nirik> | thanks all
00:51 * | wolfy waiting eagerly for the countdown till real
launch of EPEL :)
00:51 --- | 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:51 < quaid> | do we have a timeline set for that then?
00:52 < thl> | quaid, no, we haven't yet
00:52 < quaid> | ok, just checking :)
00:52 < thl> | and I don#t really feel compfortable setting one yet
00:52 * | quaid misses things, at times
00:52 < quaid> | thl: yes, seems a little premature
00:52 < thl> | let's see how it works out after we open the
flood gates
00:52 < thl> | now that we have RHEL5 on the builders soon
00:53 < thl> | then we need the proper layout
00:53 < thl> | and well, if the repo is in a good shape then we
can announce quickly
00:53 < thl> | good shape and big enough
00:53 < wolfy> | ... and QA policy
00:53 < entr0py> | will integration of bodhi be soon?
00:53 < entr0py> | or is it even finished?
00:53 < thl> | but it seem there are a lot of packages in EPEL
already
00:54 < thl> | entr0py, "soon" afaik
00:54 < entr0py> | nice
00:54 < thl> | wolfy, are you volunteering for writing a QA policy?
00:54 < thl> | wolfy, we didn#t talk about such a policy yet
00:54 < thl> | s/yet/much &/
00:55 < wolfy> | thl: I would if I knew how. Unfortunately I am
much closer to sysadm then to policy design
00:55 < thl> | wolfy, well, keep it in mind and bring it up
again when we get closer to the final annoucement
00:55 < wolfy> | roger that
00:56 <-- | giallu has quit (Read error: 110 (Connection
timed out))
00:57 < entr0py> | thanks thl
}}}
17 years, 1 month
EPEL Chairperson
by Dennis Gilmore
So now that we have our own steering committee we should elect a chairperson
to keep things in line and running smoothly.
We have two nominees for Chair Person they are Michael Stahnke and Thorsten
Leemhuis
So now we need to decide on who it should be. As well as a time line to elect
a new chairperson so that one does not get burnt out. I would like the
chairperson to be there for 6 months.
--
Dennis Gilmore, RHCE
17 years, 1 month
Outcome of first EPEL votes: Rebuild, Repotag and fedora-usermgmt
by Axel Thimm
This is the report on the outcome of the EPEL votings to date. The
one that passed needs a ratification by fesco (details are on
http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting):
1) Rebuild of EPEL5
Topic: The packages currently in EPEL5 got build against RHEL5beta1; the plan
is to rebuild them against RHEL5. The question is: how?
Winning option: Simply delete the current repo and rebuild all packages
2) Introduction of a repotag
Topic: Should EPEL carry a repotag? If yes, the technical details
will be delegated to the Packaging Committee.
Vote turned down
3) Vetoing fedora-usermgmt until FPC makes a decision
Topic: Packages should not use fedora-usermgmt or other
non-standard useradd replacements.
Vote turned down
fesco needs to ratify the outcome of vote 1) above, the turned down
votes don't need any ratification of course.
--
Axel.Thimm at ATrpms.net
17 years, 1 month
Meeting today
by Axel Thimm
Hi,
I will not be able to make it to (the first half of) the meeting
today.
--
Axel.Thimm at ATrpms.net
17 years, 1 month
Packaging question (new packager)
by Ray Van Dolson
Hello all. Have been wanting to get involved with Fedora/CentOS for
some time, and though helping package up a few programs which I use
frequently would be a good way to get my feet wet.
I've built an RPM for 'remind', which is a pretty cool little
scheduling utility that I use in place of a GUI Calendar.
I have a few questions on the "proper" (Fedora) way that this utility
should be packaged up however.
remind includes a couple scripts: rem2ps, tkremind, cm2rem.tcl to name
a few that obviously would depend on TCL/TK being present on the
system. Is the proper way to handle this to make a subpackage for
these few scripts (remind-extras or remind-gui, etc)? Or, since remind
itself works fine without them, just to exclude them completely from
the RPM? Or perhaps throw them in /usr/share/doc ...
Also, remind distributes their source with a source tarball name as
follows:
remind-03.00.24.tar.gz
This corresponds with v3.00.24 of the program. I've left this version
number intact in my spec file, but perhaps I should tuncate it to
3.00.24? The naming guidelines don't seem to cover a scenario like
this. I left it at 03.00.24 because it made my %prep and %setup steps
simpler. :)
Thanks in advance for any guidance.
Ray
17 years, 1 month
Fedora EPEL Package Build Report 2007-04-09
by Fedora Koji Build System
Packages built and released for Fedora EPEL 5: 4
conmux-0.0-6.493svn.el5
firmware-addon-dell-1.2.11-1.el5
rrdtool-1.2.19-1.el5
NEW websec-1.9.0-3.5
Packages built and released for Fedora EPEL 4: 5
firmware-addon-dell-1.2.11-1.el4
nas-1.9-1.el4
rrdtool-1.2.19-1.el4
tmda-1.1.11-3.el4
NEW websec-1.9.0-3.4
For more information about the built packages please see the repository
or the Fedora Info Feed: http://fedoraproject.org/infofeed/
17 years, 1 month
Deleted minutes
by Axel Thimm
Hi Thorsten,
you're deleting the minutes in the wiki replacing with a link to the
mailing list. Keeping the minutes in the wiki is making life easier
for using the wiki's search engine to check what had been said in a
meeting.
--
Axel.Thimm at ATrpms.net
17 years, 1 month
