19:30:01 <nirik> #startmeeting FESCO (2010-08-24)
19:30:01 <zodbot> Meeting started Tue Aug 24 19:30:01 2010 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:30:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:30:02 <nirik> #meetingname fesco
19:30:02 <zodbot> The meeting name has been set to 'fesco'
19:30:02 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59
19:30:02 <nirik> #topic init process
19:30:02 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones
19:30:37 * cwickert is here
19:30:50 <mjg59> Afternoon
19:30:55 * SMParrish here... made it just in time
19:30:56 * mclasen here
19:31:35 <pjones> yo
19:32:03 <nirik> morning everyone.
19:32:56 <ajax> i think so, brain, but why would anyone want to see snow white and the seven samurai?
19:32:57 <SMParrish> afternoon here )
19:33:20 <pjones> ajax: I would totally pay for that.
19:33:47 <nirik> ok, we have all updates all the time today... ;) (ie, thats all thats on the main agenda)
19:33:55 * nirik would also pay to see that. ;)
19:34:01 <nirik> #topic #351 Create a policy for updates - status report on implementation
19:34:02 <nirik> .fesco 351
19:34:03 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351
19:34:10 <ajax> https://fedoraproject.org/wiki/User:Ajax/Stable_Release_Policy
19:34:10 <mjg59> Oh, just to say I'll be missing next week for vacation
19:34:21 <mjg59> I'll email as well
19:34:26 <ajax> someone tell me how that's terrible so i can fix it
19:34:26 * notting has a hard stop around 4:30 today, FYI.
19:34:36 <nirik> ok, till had some questions for us in https://fedorahosted.org/fesco/ticket/351#comment:49 on this.
19:35:12 <nirik> ajax: cool. ;) Lets discuss that under the other ticket about implementing the board vision thing...
19:35:59 <ajax> k
19:37:25 <notting> point #1 he makes is easy
19:37:48 <nirik> yeah, point 1 is fine... lets change that to critical path everwhere.
19:38:33 <nirik> any objections to that?
19:38:40 <mclasen> none here
19:38:41 <cwickert> nope
19:38:49 <SMParrish> Nope
19:38:52 <ajax> doooo eeeet
19:39:13 <nirik> #agreed we should just use critical path and remove references to 'important packages'
19:39:26 <mclasen> a similar rewording thing I noticed the other day is that we seem to have at least one reference to 'section 2'
19:39:30 <mclasen> but the sections are not numbered...
19:39:33 <nirik> is anyone willing to rework https://fedoraproject.org/wiki/Package_update_acceptance_criteria based on that?
19:39:40 <nirik> mclasen: yeah, I think they used to be... ;(
19:40:05 <notting> i don't necessarily agree with his second point. if the submitter wants to require +4 karma, the system should honor that
19:40:17 <mclasen> I can take on the editing job for important -> critpath
19:40:40 <notting> or does he mean that the auto-karmatism is not allowing the submitter to submit to stable even though the requirements have been reached?
19:40:55 <nirik> mclasen: thanks.
19:41:06 <nirik> #action mclasen to update https://fedoraproject.org/wiki/Package_update_acceptance_criteria
19:41:11 <SMParrish> I do have a concern with point 2, in that a net karma of +1 can be reached but the package might still have some -1s, and I agree with notting it should be up to the maintainer to set the threshold
19:41:34 <notting> but yea, i think what he's saying is:
19:41:42 <nirik> perhaps you guys could ask him for clarification on it? I'm not sure either.
19:41:49 <notting> - submitter set autokarma at +3
19:41:57 <notting> - package has the policy-required +1 karma
19:42:10 <notting> - bodhi does not allow a push to stable until the autokarma threshold is reached
19:42:15 <notting> if that's the case, we should fix that
19:42:36 <nirik> well, the policy says "the positive Bodhi karma threshold specified by the updates submitter"
19:42:50 <nirik> but they could set it to +1, they just didn't?
19:43:11 <mclasen> so bodhi doesn't implement that, then ? but insists on 3 ?
19:43:25 * mclasen not sure what bodhi does
19:43:30 <notting> yeah, i think we need him to clarify
19:44:07 <gholms> Try it:  set autokarma = +3, then try to push at +1 since the policy allows for that.
19:44:16 <cwickert> I don't understand what till means ether
19:44:31 <nirik> gholms: can you set the autokarma to +1 and then push it?
19:44:48 <gholms> Never tried; can you?
19:45:00 <gholms> It seems like an unnecessary step, IMO.
19:45:18 * nirik notes the policy doesn't say "at least +1 karma"
19:45:33 <cebbert> bodhi does weird things with autokarma if you try to edit it
19:45:43 <notting> the policy says 'positive karma of +2, with +1 from proventester'
19:45:57 <nirik> or "the positive Bodhi karma threshold specified by the updates submitter"
19:46:09 <nirik> (if it's not critpath)
19:46:44 <nirik> so I guess we should see if it could allow pushing anytime it's at least +1 and not critpath?
19:46:54 <nirik> but then we should adjust the policy.
19:47:23 <cebbert> i'm pretty sure you can push it anytime after the "critical path update approved" message shows up
19:47:34 <notting> i'm not seeing anything that needs changing, but i'm also not sure what the issue is he's seeing
19:47:35 <nirik> for critial path, yes.
19:47:36 <cebbert> it just won't happen automatically
19:47:50 <pjones> we definitely need him to clarify
19:47:51 <nirik> I think he's talking about non critpath
19:48:29 <nirik> ok, can someone take the action to ask for clarification?
19:48:42 <notting> sure, will do
19:49:23 <nirik> thanks
19:49:34 <nirik> #action notting to ask for more clarification on question 2.
19:49:46 <nirik> lmacken: you around?
19:50:11 <nirik> for item 3 we need to confirm with lmacken I think.
19:50:45 <nirik> Does it need just +1 proventester, +1 other, or does it need to be +1 proventester, +1 other and the total must be +2.
19:51:26 * nirik looks forward to revamping the karma system, I just hope it will become simpiler instead of more complex.
19:52:46 <nirik> anyone know? shall we just clarify with lmacken and update the page accordingly?
19:53:19 <lmacken> nirik: total karma of at least 2, with at least 1 provenpackager
19:53:43 <nirik> lmacken: thanks.
19:54:14 <lmacken> proventester, rather
19:54:37 <nirik> any questions or changes wanted on that? Or shall we just move on since till updated the page correctly there?
19:55:00 * gholms notes that 20 minutes have passed
19:55:00 <ajax> move on sounds fine
19:55:02 <SMParrish> move on
19:55:19 <nirik> ok.
19:55:25 <nirik> #topic #382 Implementing Stable Release Vision
19:55:25 <nirik> .fesco 382
19:55:27 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382
19:55:39 <nirik> so, ajax worked on some docs here?
19:55:55 * nirik reads.
19:56:01 <nirik> https://fedoraproject.org/wiki/User:Ajax/Stable_Release_Policy
19:56:23 <ajax> plan is to link them from the packager landing page from the wiki and on devel@ (for all the good that'll do)
19:56:34 <ajax> does it need more, or less, or what?
19:56:50 * mclasen likes the examples, good stuff
19:57:16 <cwickert> ajax: I have a question about your fourth example
19:57:16 * pjones didn't see that link earlier, is reading now
19:57:48 <cwickert> what if the update fixes bugs, e.g. crashed, BUT changes the user experience?
19:57:56 <notting> ajax: 'We have rawhide <and the next release> for that' ?
19:58:05 * cwickert had this case today
19:58:51 <notting> cwickert: backport the fix, or don't push it, in general. or ask for an exception.
19:59:03 <ajax> cwickert: fuzzy.  depends on whether it's reasonable to pull out just the fix as a backport.
19:59:06 <mclasen> cwickert: I think it is a judgement call
19:59:14 <nirik> I think we might want to add "new hardware enablement"?
19:59:20 <nirik> or do we?
19:59:34 <mclasen> if it adds a new menuitem or something of that scale, the user exerience change is probably negligable
19:59:46 <notting> nirik: non-disruptive hardware enablement, sure
20:00:00 <notting> nirik: but KMS had hardware enablement in it
20:00:02 <mclasen> nirik: I think 'interoperability' is meant to cover that
20:00:13 <mclasen> but might be clearer to list it as a separate category
20:00:17 <nirik> for example, my corner case package... calibre.
20:00:23 <cwickert> mclasen: it removed a menu entry that many people used, in this case it was the bookmark entry in the midori webbrowser
20:00:44 <mclasen> cwickert: that might be a more troublesome change of experience
20:00:50 <cwickert> therefore I haven't pushed it to F13 yet
20:01:20 <notting> ajax: i feel that there should probably more loud entries somewhere in that list about "don't change library ABI. do. not. do. it."
20:01:21 <nirik> cwickert: FYI, I have been trying to get a hold of peter, want to take over or help with midori. I didn't push it yet because I wanted to talk to him about it...
20:01:38 <ajax> notting: indeed.
20:01:40 <pjones> notting: definitely
20:01:48 <cebbert> i don't see anything in there about kernel updates
20:02:10 <ajax> cebbert: i left many things out
20:02:28 <ajax> i was hoping to avoid over-prescribing behaviour in the hopes that i wouldn't have to legislate taste
20:02:40 <SMParrish> What about the case I have where kpackagekit is about to release a new build which fixes many bugs, but also introduces some major UI changes.  The bug fixes are needed in F13 and because of the way the maintainer works backporting the fixes would be close to impossible
20:02:59 <mclasen> ajax: might be good to add the kernel in the examples section...
20:03:01 <notting> cebbert: i think the kernel policy is "don't make us change userspace"
20:03:12 <ajax> cebbert: if you have suggestions for a kernel policy that you're comfortable with i'm happy to hear them
20:03:33 <ajax> SMParrish: i gently suggest the maintainer is a jerk.
20:03:37 <ajax> SMParrish: but, that aside.
20:03:53 <pjones> notting: that's the policy I'd like - it's certainly not been the case in the past though
20:04:08 <notting> pjones: sure. but it's better than it used to be, i think?
20:04:13 <pjones> yeah
20:04:32 <ajax> SMParrish: to the extent that the update is still functional, and not disorientingly different, i can see that kind of update being okay
20:04:52 <nirik> I think that we might want a 'Upstreams don't match fedora release cycles or have a seperate stable/bugfix stream' section. In that we could ask that people try and quantify changes in experence vs bugs fixed when asking for exceptions. Then, it comes down to a judgement call.
20:04:54 <ajax> but to the extent that it's trading one set of bugs for another... less awesome.
20:05:00 <SMParrish> ajax not a jerk but maybe too much on his plate
20:05:00 <pjones> then again, I might just think it's gotten better because I don't have to maintain mkinitrd any more ;)
20:05:11 <cebbert> we have worked with affected userspace packagers in the past to coordinate releases with a new kernel
20:05:32 <ajax> nirik: that's a good suggestion.
20:05:39 <ajax> much as i loathe the practice.
20:05:51 <ajax> (but then, i work on rhel, i'm a backportin' machine)
20:05:52 <nirik> yeah, but there are such projects...
20:06:23 <ajax> any other parting shots? i'll work this into an update for next week.
20:06:26 <nirik> again calibre... weekly releases with new features, bugfixes and new hardware enablement. Wheee...
20:06:57 <notting> nirik: obviously, the only solution is to orphan it ;)
20:07:14 <nirik> but it's so shiny! :)
20:07:59 <nirik> ajax: do we want to revist this next week? or would you like to add stuff from today and ask for comments from the devel list. :)
20:08:30 <ajax> one other thing i haven't captured there that still need to meditate on is how to state "F12 slower than F13 slower than rawhide"
20:09:04 <mclasen> isn't that happening naturally ?
20:09:15 <ajax> nirik: i don't have a strong preference, besides that posting it to devel will assuredly be seen as an act of war by the usual suspects.
20:09:19 <mclasen> might want to mention something about not pushing major updates a week before eol
20:09:30 <nirik> one of the suggestions recently on the advisory board list was to make all 'enhancement' updates need proventester/get more scrutiny.
20:10:06 <nirik> ajax: yeah.
20:10:19 <pjones> nirik: I worry that that'll have the same effect as "regression" does in rhel - lots of little lies.
20:10:27 <ajax> let's come back in a week then.
20:10:43 <ajax> (and we're at 15)
20:10:54 <nirik> ok. Perhaps if you have updates over the week, update the fesco ticket and everyone cc'ed there can look and provide more feedback?
20:11:04 <ajax> you got it.
20:11:12 <nirik> thanks.
20:11:26 <nirik> #action ajax to update docs. Will revisit over the week and next meeting.
20:11:41 <nirik> #topic FES tickets roundup
20:11:45 <nirik> https://fedorahosted.org/fedora-engineering-services/report/6
20:11:51 <nirik> mmcgrath: what news from engineering?
20:12:14 <mmcgrath> well, we had lots of good inqueries from the shout I sent to devel-list.
20:12:25 <mmcgrath> most of the tickets have been assigned
20:12:31 * jsmith even went and looked at the unassigned ticket list
20:12:53 <mmcgrath> I'm not totally sure what all work has been done on those tickets yet but I'll be following up this week and find out
20:13:12 <nirik> I meant to create some new tickets, but I didn't.
20:13:30 <nirik> anyone have ideas for new tickets? what kinds of things could we really get someone to fix for us?
20:14:11 <ajax> i kind of want to direct more of that energy towards autoqa tests
20:14:39 <mclasen> nirik: there's some janitorial package cleanup stuff, like drop gtk-doc dependencies
20:14:45 <mclasen> some 50 open bugs for that
20:14:55 <mclasen> with fairly mechanical changes in each spec
20:15:01 <mclasen> would that be suitable ?
20:15:01 <nirik> perhaps we could ask one or two FES folks to add an autoqa test, then blog about the process. ;)
20:15:17 <jsmith> nirik: I think that's a splendid idea
20:15:19 <nirik> mclasen: yeah, we have a ticket already for that. I don't know if it's assigned yet since it was waiting for guidelines.
20:15:26 <ajax> i remember seeing a bug earlier about packages coming out of koji with files owned by mockbuild, which is just bogus and should be something we can reject builds for up front.
20:15:45 <nirik> mclasen: https://fedorahosted.org/fedora-engineering-services/ticket/34
20:15:45 <jsmith> nirik: There's some introductory stuff on the wiki, but not enough "here's how I did it from soup to nuts" documentation
20:16:03 <nirik> mclasen: if you can add info to that we could get some folks working on it.
20:16:10 <nirik> jsmith: agreed.
20:16:16 <mclasen> nirik: I think there's enough info in the tracker bug, actually
20:16:30 <nirik> mclasen: yeah, probibly so. I fixed mine the other day.
20:16:44 <mclasen> and fpc has spoken on it, so should be good to go
20:16:49 <nirik> ajax: good idea. Should that reject builds? or should rpm just not do that?
20:17:21 <ajax> nirik: probably the former; i don't think rpm should necessarily make decisions about default file ownership.
20:17:27 <ajax> seems like something you should be explicit about
20:17:37 <nirik> perhaps it could be another autoqa test?
20:17:47 <ajax> that was what i was hoping for, yes ;)
20:18:04 <nirik> cool. I can file some of those... and update the gtk-doc one.
20:18:12 <nirik> Anything else anyone can think of off hand?
20:18:36 <mclasen> test updates, and apply karma :-)
20:18:37 * mmcgrath has nothing else :)
20:18:45 * jsmith has nothing to add
20:18:58 <ajax> all from me for now
20:19:03 <nirik> #topic Open Floor
20:19:08 <nirik> ok, anything for open floor?
20:19:26 * mclasen wanted to float a question on update criteria for pre-release updates
20:19:31 <nirik> I'd like to note that this is the less busy time for fesco with no features coming in yet... so we should look at doing things we can't find time for the rest of the cycle.
20:19:41 <nirik> mclasen: shoot.
20:19:54 <mclasen> I wonder if it would make sense to have different criteria for updates that are against the branch, but before release
20:20:09 <mclasen> the criteria we've put in place for post-release updates are fine
20:20:29 <mclasen> but may not be ideal for the post-alpha phase when we are still heavily bug fixing
20:21:36 <mclasen> the other thing I'd love to see is reduced latency between commiting and update and having it move to -testing
20:22:18 * mclasen done
20:22:24 <notting> mclasen: is daily not good enough?
20:22:41 <ajax> it's not daily.  it's the days when someone kicks it.
20:22:44 <ajax> (right?)
20:22:53 <ajax> admittedly, that's most.
20:23:03 <mclasen> it would be nice to have it be automatic, once autoqa says the build is ok, move it to -testing
20:23:20 * mclasen constantly pulls builds out of koji...
20:23:35 <notting> mclasen: that requires significant rewriting of the update composition process
20:23:49 <pjones> mclasen: yeah, I've been wondering about that too actually
20:24:06 <pjones> (both of those things, actually)
20:24:10 <mclasen> notting: yeah, thats what I feared
20:24:26 <notting> ajax: correct, the days when someone kicks it
20:24:55 * nirik would be happy to start doing them on weekends if setup to.
20:25:08 <nirik> but then it's still only daily for the main branched compose.
20:25:30 <pjones> mclasen: (and I note we're still only +1 on https://admin.fedoraproject.org/updates/F14/FEDORA-2010-13284 )
20:25:52 <mclasen> pjones: I only succeeded in building a livecd with it today
20:26:09 <dgilmore> ajax: some days we do multiple pushes
20:26:13 <nirik> pjones: I was going to test that today... ;)
20:26:23 <dgilmore> only time pushes are not likely to happen is weekends
20:26:31 <pjones> so, point being, the change between -2 and -3 there is entirely in the packaging
20:26:41 <mclasen> pjones: unfortunately for me, anaconda grew another (indirect) perl dep in the meantim
20:26:47 <pjones> mclasen: :/
20:27:39 <nirik> the other case that came up with branched is pushing for broken deps...
20:27:47 <pjones> anyway, I'm wondering if maybe "needs 3 acks" is too strict for this time period
20:27:52 <ajax> i think because someone fixed the dep generator to translate #!/usr/bin/env perl into /usr/bin/perl
20:27:52 <pjones> nirik: yeah
20:27:53 <nirik> ie, is it ok to push to stable when the thing there now is already uninstallable. ;)
20:28:14 <pjones> ajax: so it didn't really grow the dep, we just didn't know before.
20:28:25 <mclasen> nirik: thats the position I was in for a lot of the gnome updates, recently
20:28:37 <mclasen> ideally of course, we'd enter branched in a nonbroken situation
20:28:44 <nirik> yeah.
20:28:47 <mclasen> and autoqa would then help us to keep things from breaking
20:29:11 <pjones> that sounds like a nice future ;)
20:30:06 <mclasen> maybe we also want to reduce the mandatory waiting time from a week to, say 4 days or so ?
20:30:32 <pjones> I'm not sure it even needs to be that long earlyish in the branch
20:31:27 <ajax> yeah, shorter mandatory wait in branched seems reasonable
20:31:41 <mclasen> should I write up a concrete proposal for next week ?
20:31:50 <cwickert> please do
20:31:54 <mclasen> and maybe interview lmacken as to the feasibility of different criteria
20:32:13 <pjones> yeah, I'd like that
20:32:18 <mclasen> ok, will do
20:32:21 <nirik> yeah, sounds good.
20:32:33 <nirik> #action mclasen to write up ideas for branched releases update criteria
20:32:39 <nirik> Anything else anyone has for open floor?
20:33:02 <pjones> nirik: yeah, I've got a question about the yum config in fedora-release &c
20:33:11 <skvidal> yes?
20:33:13 <pjones> or rather a statement
20:33:23 <nirik> ok.
20:34:11 <pjones> it seems weird to me that while f14 is branched, if I've got fedora-release-14 and fedora-release-rawhide-14 installed, the former points to f13 and the latter points to f15
20:34:26 <skvidal> the former points to f13?
20:34:26 <pjones> is that really supposed to be that way, or am I seeing some relic of upgrading over and over on my machines?
20:34:36 <notting> yes, that's not right
20:34:48 <skvidal> what does your $releasever end up being?
20:35:02 <mclasen> what does /etc/fedora-release say ?
20:35:19 <pjones> okay, so if you think it's not supposed to be that way, I'll go check and see if I've got something unexpected going on on the machine I was seeing that on.
20:35:23 <skvidal> pjones: rpm -q --whatprovides redhat-release --qf %{version}
20:35:28 <pjones> (and bother you later if there's a real problem)
20:35:43 <skvidal> mclasen: /etc/fedora-release is not read or accessed by yum
20:35:54 <pjones> I'm not in front of that machine right now and ssh is being finicky
20:35:55 <mclasen> I don't know where you get $releasever from, I guess
20:36:05 <skvidal> mclasen: rpm -q --whatprovides redhat-release --qf %{version}
20:36:08 <pjones> mclasen: comes from the version of the package
20:36:15 <mclasen> I see
20:36:21 <pjones> (this has been the hard rule since ~rhl6)
20:36:41 <pjones> skvidal: okay, thanks for confirming my expectation that that's weird.
20:36:49 <mclasen> I have one more point for open floor
20:36:56 <pjones> we can move on and I'll come find you if there's a real problem and it's not something stupid I've done on my workstation at the office.
20:37:15 <mclasen> the systemd acceptance criteria that are being discussed on fedora-devel currently
20:37:28 <mclasen> should we wait for that to run out and discuss it next week ?
20:37:43 <pjones> probably?
20:38:07 <nirik> me thought was that we should decide if we need to enact the contingency plan before beta change freeze...
20:38:09 <pjones> I'm really unthrilled with systemd so far :/  it still seems really premature.  But I'm willing to let that thread come to some conclusions before discussing it.
20:38:10 <ajax> particularly since notting wrote a ton of them and we're past his hard stop.
20:38:14 * nirik lost a / there
20:38:59 <ajax> (without stating my personal opinion on systemd)
20:39:10 <ajax> next week then?
20:39:11 <mclasen> nirik: might be good to figure out the criteria to judge it by earlier, so that give lennart  a chance to meet them
20:39:20 <nirik> mclasen: yeah, notting posted a pretty good list.
20:39:26 <nirik> yeah, next week sounds good.
20:39:39 <gholms> If it comes time to revert it then rawhide can still keep it anyway, right?
20:39:48 <ajax> gholms: yes.
20:39:49 <pjones> gholms: yes
20:40:26 <notting> in fact, i'd argue that if we revert it, we block it from f-14 and leave it only in rawhide. the f-14 version would just bitrot, imo
20:40:33 <pjones> yep
20:40:35 <nirik> yeah.
20:40:43 <nirik> ok, if nothing else, lets call it a meeting.
20:40:48 <nirik> Thanks for coming everyone.
20:40:50 <pjones> yeah, it's time.
20:40:56 <ajax> *gavel*
20:41:07 <nirik> #endmeeting