| --- 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 | ||
| bpepple | FESCo 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 | ||
| bpepple | ok, 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. | ||
| caillon | my only thought was it is cased as "JavaScript" not "Javascript" | |
| dgilmore | ill abstain from sugar activities since i proposed it | |
| * nirik is ok with them | ||
| notting | seem reasonable | |
| dgilmore | im ok with the static policy | |
| bpepple | caillon: I think the Javascript guidelines are still being worked on. | |
| notting | is there a general procedure for FPC redoing prior packages that do not match the paradigm? | |
| tibbs | I voted for both of these in the FPC meeting. | |
| tibbs | notting: Not as far as I know, although spot has volunteered to do audits and fixups various times recently. | |
| caillon | bpepple, well they should be scrapped. we need JavaScript guidelines. there's no such thing as Javascript. ;-) | |
| bpepple | caillon: ;) | |
| tibbs | I take the blame for caring not one whit about casing. | |
| I'm sure I'm not the only one. | ||
| notting | caillon: that's JavaScript(tm) to you! | |
| bpepple | ok, I don't hear any objections to the proposal from the FPC. So unless someone speaks up, I'll consider them approved. | |
| s/proposal/proposals/ | ||
| bpepple | alright, moving on......... | |
| --- bpepple has changed the topic to: FESCo-Meeting -- Emacs Reversion - notting | ||
| tibbs | BTW, c4chris acked both on-list. | |
| bpepple | notting: you want to lead this? | |
| notting | sure! | |
| 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 | ||
| tibbs | Not brief enough that my rawhide boxes don't have it installed. | |
| emacs-23.0.60-2.fc9.i386 | ||
| dgilmore | tibbs: theres no epoch in 22.2 | |
| tibbs | dgilmore: Well, yes, but I don't understand the relevance. | |
| dgilmore | tibbs: im going tojust fix it, i have commented in the bug https://bugzilla.redhat.com/show_bug.cgi?id=443639 | |
| buggbot | Bug 443639: high, urgent, ---, Chip Coldwell, ASSIGNED , emacs-23 is not ready for prime time | |
| tibbs | I guess I'm confused. | |
| spot | tibbs: they dont want to bump the epoch because they'd have to fix any packages that do a versioned requires | |
| dgilmore | http://koji.fedoraproject.org/koji/packageinfo?packageID=560 | |
| it was out there for nearly 5 days | ||
| tibbs | We 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. | |
| spot | fwiw, i agree with tibbs, we should bump the epoch and fix anything that breaks. | |
| dgilmore | spot: im going to bump the epoch | |
| bpepple | spot: do we have an idea of how many packages would be effected? | |
| * notting looks | ||
| tibbs | So I wasn't just unlucky and happened to update during a five minute period where the wrong package was in the repos. | |
| dgilmore | spot: 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... | ||
| notting | there are 12 packages that have versioned requirements on emacs of some sort | |
| nirik | should we get input from the maintainer and/or f13 before commiting things here? | |
| tibbs | f13 intended to defend the non-epoch here. | |
| dgilmore | nirik: i brought it up in the bug report | |
| caillon | nirik, that seems prudent | |
| tibbs | At least that's what he said. | |
| notting | technically, 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 | ||
| bpepple | especially this close to release. | |
| tibbs | BTW, why was -23 pushed out? | |
| Was it mistakenly intended for post-F9 rawhide or something? | ||
| caillon | i don't know in the emacs case, but that happened to hunspell | |
| jeremy | I don't see a tag request for it, but I might have accidentally deleted some rel-eng mail | |
| bpepple | tibbs: I'm not sure. we would probably need to check w/ Chip. | |
| notting | it fixed a blocker bug. 436767 | |
| erm | ||
| 435767 | ||
| not sure why the full new version was needed for that | ||
| jeremy | not sure either... especially since the exact patch is in the bug | |
| caillon | because fedora is bleeding edge | |
| jeremy | caillon: thppt | |
| notting | ooh, and 'new version' == snapshot! | |
| jeremy | yeah. there's apparently some lack of maintainer understanding of where we were in the release process | |
| caillon | my guess is the tag request went something like: "this package fixes this blocker" and whoever tagged it may not have realized the version change | |
| tibbs | So there are a couple of issues: | |
| jeremy | caillon: especially as there wasn't an explicit tag request, it was just in the bug :-/ | |
| tibbs | How 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? | ||
| jeremy | for the first, continue trying to improve maintainer education about the meaning of the word "freeze" | |
| bpepple | jeremy: +1000 | |
| tibbs | I personally don't have a problem reverting emacs on my boxes, but I think it needs to be documented well and announced loudly. | |
| caillon | wand second, making sure that the freeze process is followed. we need two +1s, not one +1. | |
| tibbs | Maybe we need a yum-revert-screwups plugin. | |
| * jeremy is trying to see how many days it was in rawhide. but slow. | ||
| nirik | rawhide-updates-testing ? :) rawerhide? ;) | |
| bpepple | jeremy: I believe it was there 5 days or so. | |
| caillon | tibbs, we just need to stop pretending ENVR is relevant and just go by build date ;-) | |
| jeremy | nirik: we have that -- it's called static-repos | |
| nirik | it wasn't in the PR release, but pretty much anyone who installed PR probibly applied updates after installing... | |
| jeremy | 5 days | |
| caillon | assuming they weren't using the liveCD | |
| jeremy | showed up in rawhide on the 19th | |
| well, and assuming they had emacs installed. but who wouldn't? ;-) | ||
| notting | jeremy: anyone who installed from the livecd! | |
| caillon | i don't think it's on the livecd, but i could be wrong? | |
| jeremy | it's not | |
| much to my continual dismay ;-) | ||
| bpepple | ok, so how do we want to handle this? | |
| caillon | jeremy, yeah, neither is zsh... :-( | |
| jeremy | given 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 | ||
| dgilmore | spot: i will | |
| jeremy | (on the rel-eng side of ensuring that things have multiple +1s, etc) | |
| dgilmore | i need to touch the evil beast anyways | |
| caillon | i think we should really attempt to get the package owner to fix his own mess | |
| dgilmore | caillon: well if he wont then I will | |
| bpepple | Proposal: Have emacs use epoch, instead of pulling package. | |
| caillon | doing things for people helps them forget how big of a pain it is and leads to them repeating mistakes | |
| jeremy | caillon: agreed | |
| notting | bpepple: 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) | |
| caillon | dgilmore, i think you should be a big meanie until he does it himself. | |
| dgilmore | caillon: :) | |
| notting | bpepple: i don't know how trivial that is | |
| bpepple | notting: hmm, that sorta sucks. | |
| caillon | so, if he says no, don't do it yourself. just convince him better. :) | |
| dgilmore | caillon: ill point him at a picture of me and say he needs to do it | |
| caillon | rock | |
| notting | bpepple: 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 | |
| bpepple | notting: but wouldn't we be carrying a patch to fix the pkg-config basically forever? | |
| notting | bpepple: yup | |
| caillon | can you really epoch yourself backward? i thought the whole point is to go forward? oh no, i've gone cross-eyed | |
| notting | caillon: hahaha | |
| notting | bpepple: actually, the pkgconfig file is created inline in the spec file | |
| bpepple: == trivial | ||
| bpepple | oh, I thought they shipped one in the tarball. That makes it a lot easier. | |
| jeremy | a gnu project couldn't ship a fdo related thing... | |
| dgilmore | not invented here | |
| bpepple | So, where are we then? | |
| nirik | get maintainer + other affected packages maintainers to fix... ? | |
| jeremy | so, vote on adding an epoch (or more explicitly, voting to stick to our previously stated policy of keeping the upgrade path working) | |
| notting | +1 | |
| jeremy | +1 | |
| bpepple | +1 | |
| caillon | +1 | |
| * nirik notes that f13 will probibly chime in after the fact that we shouldn't require the Epoch. | ||
| nirik | +1 | |
| jeremy | (or not granting an exception to our policy; however you want to think of it :) | |
| caillon | also, really really require the freeze process to be followed. | |
| nirik | http://www.redhat.com/archives/fedora-devel-list/2008-April/msg01785.html | |
| caillon | it 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. | |
| bpepple | ok, I see 5 '+1', and one '-1'. anyone else want to weight in? | |
| spot | +1 | |
| dgilmore | +1 | |
| bpepple | ok, that's seven '+1', and one '-1'. FESCo has decided that the maintainer needs to add an epoch. | |
| tibbs | I kind of wish f13 could have chimed in; wasn't he going to try and be here? | |
| bpepple | tibbs: I think he mentioned he wasn't able to make it, | |
| caillon | bpepple, for the record, it's still 6. spot doesn't get a vote. :-) | |
| jeremy | tibbs: he's on a plane... | |
| spot | why don't I get a vote? | |
| warren | +1 | |
| jeremy | spot: for starting the sbin thread | |
| warren | Epoch is evil but sometimes it is necessary =( | |
| bpepple | jeremy: :) | |
| warren | and we *DID* agree that we would do this even during rawhide during the last cycle | |
| otherwise testers wont auto-upgrade and they wont know | ||
| notting | who's here that hasn't voted? | |
| tibbs | Me. | |
| jeremy | spot: :) | |
| bpepple | notting: I think we're at eight '+1', and one '-1', and tibbs undecided. | |
| tibbs | +1 | |
| bpepple | ok, is there anything else, or should we move on? | |
| notting | other than noting that 'adding the epoch' is more than just adding "Epoch: 1" to the package, no | |
| bpepple | notting: right, I'll mention that in my summary. | |
| nirik | notting: can you add the list of packages that you found that require emacs to that bug/ | |
| dgilmore | notting: adding the Epoch and fixing all that breaks as a result | |
| notting | nirik: which one? the 'revert' bug? or the blocker regex bug? | |
| caillon | Epoch: 0%{?dist} | |
| nirik | notting: either... or both? ;) | |
| notting | caillon: epochs are numeric only ;) | |
| caillon | boo | |
| tibbs | Epoch: $(date +%s) | |
| Or whatever the hideous syntax is. | ||
| caillon | tibbs, w00t. +1 :) | |
| warren | isn't epoch limited to 32bit numbers? | |
| I recall there was some limit | ||
| --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora | ||
| nirik | blocker list seems to be going up. ;( Hopefully progress can be made... | |
| jeremy | nirik: that's to be expected really | |
| lots of people testing out the PR | ||
| poelcat | do we have a policy about how components are added to bugzilla? (re: unison) | |
| caillon | nirik, blocker list is going up because we're getting more testing and/or people don't understand blocker criteria. | |
| * nirik nods. Just noting. | ||
| jeremy | poelcat: they are supposed to be getting added automatically. that broke for a bit with the FAS2 transition, but should be working again now | |
| nirik | poelcat: did you read why that mess is the way it is? | |
| notting | poelcat: unison came first. it was discovered all versions of it are horribly incompatible. so it was split into various unison<version> packages | |
| caillon | nirik, many people think that "this is a bad bug for my package" means blocker for the distro, when it's not necessarily the case | |
| tibbs | OK, I lagged out for some reason. | |
| nirik | caillon: sure. Same people who change the priority to "urgent" | |
| caillon | nirik, yeah | |
| jeremy | caillon: I'd prefer that people who are unsure mark them and then they can be triaged from there | |
| poelcat | notting: so incompatibilty is the driver for three separate components? | |
| nirik | poelcat: yes. The various versions don't talk to each other. | |
| caillon | jeremy, much as i hate flags, they work well in this case. | |
| nirik | poelcat: so you need the version you are using on client/server. | |
| poelcat | nirik: that's why i run the fc6 version :) | |
| nirik | the unisonNNN versions can coexist with alternatives on the same machine. | |
| * poelcat was more just trying to keep bugzilla component list sane | ||
| poelcat | though that is a losing battle :) | |
| jeremy | caillon: *nod* | |
| poelcat | nirik: oh, didn't realize that | |
| nirik | we could look at removing the 'unison' component... but the maintainer reads those bugs, so it should be ok to file there. | |
| bpepple | alright. anything else or should we wrap up for this week? | |
| dgilmore | yep | |
| dgilmore | wrap er up | |
| bpepple | dgilmore: 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!