--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process
* spot is here
* abadger1999 watches from the bleachers
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
Hi everybody; who's around?
* nirik is here
* jeremy
tibbs here
warren here
notting is here
dgilmore is here
bpeppleok, we can probably get started.
--- bpepple has changed the topic to: FESCo meeting -- Any objection to this week's report from FPC at https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01717.html
* bpepple didn't have a problem with either proposal.
caillonmy only thought was it is cased as "JavaScript" not "Javascript"
dgilmoreill abstain from sugar activities since i proposed it
* nirik is ok with them
nottingseem reasonable
dgilmoreim ok with the static policy
bpepplecaillon: I think the Javascript guidelines are still being worked on.
nottingis there a general procedure for FPC redoing prior packages that do not match the paradigm?
tibbsI voted for both of these in the FPC meeting.
tibbsnotting: Not as far as I know, although spot has volunteered to do audits and fixups various times recently.
caillonbpepple, well they should be scrapped.  we need JavaScript guidelines.  there's no such thing as Javascript.  ;-)
bpepplecaillon: ;)
tibbsI take the blame for caring not one whit about casing.
I'm sure I'm not the only one.
nottingcaillon: that's JavaScript(tm) to you!
bpeppleok, I don't hear any objections to the proposal from the FPC.  So unless someone speaks up, I'll consider them approved.
bpepplealright, moving on.........
--- bpepple has changed the topic to: FESCo-Meeting -- Emacs Reversion - notting
tibbsBTW, c4chris acked both on-list.
bpepplenotting: you want to lead this?
for a very brief period of time, emacs-23 was in rawhide. it broke stuff.
f13 & chip (emacs maintainer) talked it over, and decided to untag it from rawhide, without doing a new build with an epoch, due to the epoch likely requiring rebuilds of multiple packages
tibbsNot brief enough that my rawhide boxes don't have it installed.
dgilmoretibbs: theres no epoch in 22.2
tibbsdgilmore: Well, yes, but I don't understand the relevance.
dgilmoretibbs: im going tojust fix it,  i have commented in the bug https://bugzilla.redhat.com/show_bug.cgi?id=443639
buggbotBug 443639: high, urgent, ---, Chip Coldwell, ASSIGNED , emacs-23 is not ready for prime time
tibbsI guess I'm confused.
spottibbs: they dont want to bump the epoch because they'd have to fix any packages that do a versioned requires
it was out there for nearly 5 days
tibbsWe all know we agreed we wouldn't do things like this and now we've done it.  I can accept having to figure out how to undo this on my boxes, but it really needs to be documented so that poor testers who were trying to help don't get boned.
spotfwiw, i agree with tibbs, we should bump the epoch and fix anything that breaks.
dgilmorespot: im going to bump the epoch
bpepplespot: do we have an idea of how many packages would be effected?
* notting looks
tibbsSo I wasn't just unlucky and happened to update during a five minute period where the wrong package was in the repos.
dgilmorespot: i noticed it when i was getting ready to apply a sparc64 patch i have for it
tibbs: i have emacs-common-23.0.60-2.fc9.x86_64 installed
* nirik noticed it on the commit...
nottingthere are 12 packages that have versioned requirements on emacs of some sort
nirikshould we get input from the maintainer and/or f13 before commiting things here?
tibbsf13 intended to defend the non-epoch here.
dgilmorenirik: i brought it up in the bug report
caillonnirik, that seems prudent
tibbsAt least that's what he said.
nottingtechnically, having to add an epoch to all of those won't be necessary until they rebuild against a newer version
but it's still a pain
bpeppleespecially this close to release.
tibbsBTW, why was -23 pushed out?
Was it mistakenly intended for post-F9 rawhide or something?
cailloni don't know in the emacs case, but that happened to hunspell
jeremyI don't see a tag request for it, but I might have accidentally deleted some rel-eng mail
bpeppletibbs: I'm not sure.  we would probably need to check w/ Chip.
nottingit fixed a blocker bug. 436767
not sure why the full new version was needed for that
jeremynot sure either... especially since the exact patch is in the bug
caillonbecause fedora is bleeding edge
jeremycaillon: thppt
nottingooh, and 'new version' == snapshot!
jeremyyeah.  there's apparently some lack of maintainer understanding of where we were in the release process
caillonmy guess is the tag request went something like: "this package fixes this blocker" and whoever tagged it may not have realized the version change
tibbsSo there are a couple of issues:
jeremycaillon: especially as there wasn't an explicit tag request, it was just in the bug :-/
tibbsHow do we prevent this cock-up from happening in the future?
Do we really want to break our agreed-upon rule that we wouldn't revert packages like this?
jeremyfor the first, continue trying to improve maintainer education about the meaning of the word "freeze"
bpepplejeremy: +1000
tibbsI personally don't have a problem reverting emacs on my boxes, but I think it needs to be documented well and announced loudly.
caillonwand second, making sure that the freeze process is followed.  we need two +1s, not one +1.
tibbsMaybe we need a yum-revert-screwups plugin.
* jeremy is trying to see how many days it was in rawhide. but slow.
nirikrawhide-updates-testing ? :) rawerhide? ;)
bpepplejeremy: I believe it was there 5 days or so.
caillontibbs, we just need to stop pretending ENVR is relevant and just go by build date ;-)
jeremynirik: we have that -- it's called static-repos
nirikit wasn't in the PR release, but pretty much anyone who installed PR probibly applied updates after installing...
jeremy5 days
caillonassuming they weren't using the liveCD
jeremyshowed up in rawhide on the 19th
well, and assuming they had emacs installed. but who wouldn't? ;-)
nottingjeremy: anyone who installed from the livecd!
cailloni don't think it's on the livecd, but i could be wrong?
jeremyit's not
much to my continual dismay ;-)
bpeppleok, so how do we want to handle this?
caillonjeremy, yeah, neither is zsh... :-(
jeremygiven our stated policy in teh past, I think we have to go with the epoch (although, hopefully someone will volunteer to help there)
and maybe the pain of going through that will help us to avoid the problem in the future
* spot thinks that dgilmore is volunteering
dgilmorespot: i will
jeremy(on the rel-eng side of ensuring that things have multiple +1s, etc)
dgilmorei need to touch the evil beast anyways
cailloni think we should really attempt to get the package owner to fix his own mess
dgilmorecaillon: well if he wont then I will
bpeppleProposal: Have emacs use epoch, instead of pulling package.
caillondoing things for people helps them forget how big of a pain it is and leads to them repeating mistakes
jeremycaillon: agreed
nottingbpepple: doing so will require changing the emacs package to output the epoch in its *pkg-config* file
jeremy(although, helpful oversight is probably also good)
caillondgilmore, i think you should be a big meanie until he does it himself.
dgilmorecaillon: :)
nottingbpepple: i don't know how trivial that is
bpepplenotting: hmm, that sorta sucks.
caillonso, if he says no, don't do it yourself.  just convince him better.  :)
dgilmorecaillon: ill point him at a picture of me and say he needs to do it
nottingbpepple: although, i suppose if we add the fix to the pkg-config file, we don't *need* to rebuild other things. unless we epoch ourselves back to an earlier-than-22.x version
bpepplenotting: but wouldn't we be carrying a patch to fix the pkg-config basically forever?
nottingbpepple: yup
cailloncan you really epoch yourself backward?  i thought the whole point is to go forward?  oh no, i've gone cross-eyed
nottingcaillon: hahaha
nottingbpepple: actually, the pkgconfig file is created inline in the spec file
bpepple: == trivial
bpeppleoh, I thought they shipped one in the tarball.  That makes it a lot easier.
jeremya gnu project couldn't ship a fdo related thing...
dgilmorenot invented here
bpeppleSo, where are we then?
nirikget maintainer + other affected packages maintainers to fix... ?
jeremyso, vote on adding an epoch (or more explicitly, voting to stick to our previously stated policy of keeping the upgrade path working)
* nirik notes that f13 will probibly chime in after the fact that we shouldn't require the Epoch.
jeremy(or not granting an exception to our policy; however you want to think of it :)
caillonalso, really really require the freeze process to be followed.
caillonit wouldn't have guaranteed this would have gotten caught if the process was followed, but it would have had a better chance of doing so.
bpeppleok, I see 5 '+1', and one '-1'.  anyone else want to weight in?
bpeppleok, that's seven '+1', and one '-1'.  FESCo has decided that the maintainer needs to add an epoch.
tibbsI kind of wish f13 could have chimed in; wasn't he going to try and be here?
bpeppletibbs:  I think he mentioned he wasn't able to make it,
caillonbpepple, for the record, it's still 6.  spot doesn't get a vote.  :-)
jeremytibbs: he's on a plane...
spotwhy don't I get a vote?
jeremyspot: for starting the sbin thread
warrenEpoch is evil but sometimes it is necessary =(
bpepplejeremy: :)
warrenand we *DID* agree that we would do this even during rawhide during the last cycle
otherwise testers wont auto-upgrade and they wont know
nottingwho's here that hasn't voted?
jeremyspot: :)
bpepplenotting: I think we're at eight '+1', and one '-1', and tibbs undecided.
bpeppleok, is there anything else, or should we move on?
nottingother than noting that 'adding the epoch' is more than just adding "Epoch: 1" to the package, no
bpepplenotting: right, I'll mention that in my summary.
niriknotting: can you add the list of packages that you found that require emacs to that bug/
dgilmorenotting: adding the Epoch  and fixing all that breaks as a result
nottingnirik: which one? the 'revert' bug? or the blocker regex bug?
caillonEpoch: 0%{?dist}
niriknotting: either... or both? ;)
nottingcaillon: epochs are numeric only ;)
tibbsEpoch: $(date +%s)
Or whatever the hideous syntax is.
caillontibbs, w00t.  +1  :)
warrenisn't epoch limited to 32bit numbers?
I recall there was some limit
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
nirikblocker list seems to be going up. ;( Hopefully progress can be made...
jeremynirik: that's to be expected really
lots of people testing out the PR
poelcatdo we have a policy about how components are added to bugzilla? (re: unison)
caillonnirik, blocker list is going up because we're getting more testing and/or people don't understand blocker criteria.
* nirik nods. Just noting.
jeremypoelcat: they are supposed to be getting added automatically.  that broke for a bit with the FAS2 transition, but should be working again now
nirikpoelcat: did you read why that mess is the way it is?
nottingpoelcat: unison came first. it was discovered all versions of it are horribly incompatible. so it was split into various unison<version> packages
caillonnirik, many people think that "this is a bad bug for my package" means blocker for the distro, when it's not necessarily the case
tibbsOK, I lagged out for some reason.
nirikcaillon: sure. Same people who change the priority to "urgent"
caillonnirik, yeah
jeremycaillon: I'd prefer that people who are unsure mark them and then they can be triaged from there
poelcatnotting: so incompatibilty is the driver for three separate components?
nirikpoelcat: yes. The various versions don't talk to each other.
caillonjeremy, much as i hate flags, they work well in this case.
nirikpoelcat: so you need the version you are using on client/server.
poelcatnirik: that's why i run the fc6 version :)
nirikthe unisonNNN versions can coexist with alternatives on the same machine.
* poelcat was more just trying to keep bugzilla component list sane
poelcatthough that is a losing battle :)
jeremycaillon: *nod*
poelcatnirik: oh, didn't realize that
nirikwe could look at removing the 'unison' component... but the maintainer reads those bugs, so it should be ok to file there.
bpepplealright. anything else or should we wrap up for this week?
dgilmorewrap er up
bpeppledgilmore: done.
* bpepple will end the meeting in 60
bpepple will end the meeting in 30
bpepple will end the meeting in 15
bpepple-- MARK -- Meeting End
Thanks, everyone!

Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!