19:30:01 <nirik> #startmeeting FESCO (2010-07-27)
19:30:01 <zodbot> Meeting started Tue Jul 27 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:01 <nirik> #meetingname fesco
19:30:01 <zodbot> The meeting name has been set to 'fesco'
19:30:01 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59
19:30:01 <nirik> #topic init process
19:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones
19:30:13 <ajax> oh no, not again
19:30:27 <nirik> yeah, it's like almost every week it happens. ;(
19:30:33 <pjones> ajax: quick, make a run for it before they notice we're here
19:30:58 * dmalcolm is lurking
19:31:07 * abadger1999 is lurking if you need to ping me.
19:31:18 <mjg59> Afternoon
19:31:25 <nirik> cwickert is gonna be here, but said he would be a few minutes late.
19:31:46 <nirik> also, I have to leave in about an hour to head to an appointment, so someone will have to take over running things then. ;)
19:32:08 <mjg59> Let's just get everything done in an hour
19:32:11 <mjg59> That sounds easier
19:32:23 <pjones> yes, let's run with that.
19:32:29 <nirik> yeah, that would be nice.
19:32:47 * nirik doesn't see us having quorum currently...
19:33:03 <nirik> notting, SMParrish ? you guys around?
19:33:11 <notting> yes, i'm here. sorry.
19:33:29 <nirik> ok, thats enough to get started I guess...
19:33:38 <nirik> #topic #351 Create a policy for updates - status report on implementation
19:33:39 <nirik> .fesco 351
19:33:42 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351
19:33:46 <nirik> Our fav ticket in the entire world. ;)
19:34:02 <nirik> I think lmacken was working on adding the one week thing, but not sure the status.
19:34:28 <nirik> autoqa is hoping to have something for f14alpha hopefully?
19:34:44 <nirik> those are the last 2 things on this I think...
19:35:19 <nirik> anyone have anything else here? I can try and find more concrete info on those items for next time...
19:35:41 <ajax> not i.
19:35:42 * nirik moves on then.
19:35:45 <nirik> #topic #382 Implementing Stable Release Vision
19:35:45 <nirik> .fesco 382
19:35:46 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382
19:35:57 <nirik> Anyone have anything to report from the tasks we parceled out?
19:36:29 <nirik> I added some more things to: https://fedoraproject.org/wiki/Updates_Lessons and asked for the test list to add anything folks have seen.
19:36:43 <notting> nope, still behind
19:37:38 <nirik> I also asked the Board to clarify the "and only fix bugs and security issues." but so far, not one of the Board has replied. ;)
19:37:47 <ajax> in general i'm not going to have updates this week, since i've been out of the country
19:37:48 <pjones> nirik: shocking.
19:38:56 <nirik> so, I fear we made not much progress this week... perhaps next will be better? Or is there any way folks can think of in how to move this along more?
19:40:22 <nirik> ok, I guess we try and do better and move on...
19:41:13 <nirik> #topic #438 F14Feature: Ruby_1.87 - https://fedoraproject.org/wiki/Features/Ruby_1.8.7
19:41:13 <nirik> .fesco 438
19:41:14 <zodbot> nirik: #438 (F14Feature: Ruby_1.87 - https://fedoraproject.org/wiki/Features/Ruby_1.8.7) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/438
19:41:46 <nirik> we had some questions on this one...
19:41:53 <nirik> and it looks like they were answered on the talk page.
19:42:23 <notting> um, sure why not. +1
19:42:39 <nirik> so, I am +1
19:42:43 <pjones> yeah, +1
19:42:52 <notting> although touting somethng that was released in mid-2008 doesn't make us look that rapid. but ruby's known to have been a bit unloved in fedora
19:42:53 <nirik> it's already in and doesn't need a mass rebuild (thank goodness)
19:42:58 <ajax> +1
19:43:08 <mjg59> +1
19:43:09 <nirik> notting: yeah, 1.9.x apparently is very much like python3
19:43:17 <nirik> ie, not much works with it yet, etc.
19:43:28 <nirik> #agreed feature is approved.
19:43:48 <nirik> #topic #440 Improve updates process to avoid "windows of doom"
19:43:48 <nirik> .fesco 440
19:43:49 <zodbot> nirik: #440 (Improve updates process to avoid "windows of doom") - FESCo - Trac - https://fedorahosted.org/fesco/ticket/440
19:43:57 <nirik> ok, so this issue is a lot worse than I thought it was. ;(
19:44:02 <notting> that was the only feature?
19:44:34 <nirik> notting: yep. The other two bumped to f15.
19:44:50 <nirik> gold wanted more time to work on things.
19:44:59 <nirik> dnssec-conf wanted more time to work with NM folks.
19:45:32 <ajax> aaw.
19:45:36 <ajax> i was kinda rooting for gold
19:46:00 <mjg59> We should just declare F13 EOL now
19:46:01 <nirik> we might suggest to them landing it in rawhide after the branch to allow lots of time for it.
19:46:40 <nirik> anyhow, back to this topic... I think we need: a) an announcement about it, and b) ask proventesters to make sure they have selinux setup when testing.
19:47:33 <ajax> b definitely.
19:47:40 <notting> yes. also, packagers.
19:47:57 <nirik> so perhaps to devel-announce and test-announce?
19:48:01 <pjones> yes.
19:48:03 <mjg59> If you're developing Fedora and you aren't running selinux, you're doing it wrong
19:48:14 <adamw> i've already done b
19:48:19 <adamw> it's in the proventesters instructions, now
19:48:26 <drago01> there is another non selinux problem here
19:48:27 <mjg59> In future...
19:48:34 <nirik> adamw: oh? cool... might still be good to announce tho.
19:48:37 <adamw> the issue which doesn't involve selinux is actually the more important one
19:48:44 <mjg59> It's difficult to do things like test functionality that only triggers when something out of your control happens
19:48:56 * cwickert rushes in late
19:49:26 <nirik> ok, whats the non selinux issue?
19:49:36 <drago01> I have added a comment to the ticket
19:49:49 <drago01> was a different bug caused by updating PackageKit before updating gnome-packagekit
19:50:01 <drago01> which exposed a bug that has always been there
19:50:08 <drago01> which ends up in .... no update notifications
19:50:18 <nirik> oh, sorry, kept looking at the inital info.
19:50:33 <cwickert> wait, can we first look at the one bug, which is the selinux issue?
19:51:08 <drago01> sure was just saying that it does not only affect people who had selinux on
19:51:17 <cwickert> I think in order to prevent such things from happening again we need to find out what went wrong here
19:51:50 <cwickert> I think one is a communication problem, the same packager already did the "install packages without root password" thing
19:52:06 <drago01> that is completly unrelated
19:52:20 <cwickert> the second is testing, how comes that nobody found the problem?
19:52:44 <cwickert> drago01: I know it is unrelated from a technical POV, but not from a social one I think
19:52:53 <drago01> the point here is that when breaking the update tool we are pretty much screwed ... as it is not to easy fix it afterwards
19:53:34 <adamw> cwickert: the problem is kinda intrinsic to update checking functionality
19:53:41 <adamw> cwickert: you usually test right after you install updates, right?
19:53:45 <nirik> yes. The update tool should get extra scrutiny.
19:54:00 <adamw> cwickert: so you'll never notice if there's no update notifications...because there wouldn't be one anyway, because you just installed all the updates
19:54:08 <adamw> cwickert: we have the same problem testing it before release...
19:54:14 <nirik> does anyone wish to step up to draft/send a general announcement? or should we ask jsmith to do so? or ?
19:54:31 <cwickert> wait, about which update are we talking now? 0.6.6-1?
19:55:17 <adamw> on the selinux issue, people did notice the problem that was caused, but it wasn't immediately obvious that the root cause was the packagekit update (the selinux alerts identified other things)
19:55:18 <nirik> I was talking about both.
19:55:46 <adamw> see the example bug i linked to in the ticket
19:56:13 <cwickert> so we are talking about https://admin.fedoraproject.org/updates/PackageKit-0.6.6-1.fc13
19:56:23 <cwickert> I wonder why it is not critpath
19:56:29 <adamw> huh. i didn't comment on the ticket. thought I did.
19:56:32 <nirik> ie, "Hey Fedora end users. Two issues happened lately that may result in you no longer getting updates. Open up a terminal and 'su -c 'yum update PackageKit gnome-packagekit selinux-policy-targeted'' to get the fixed versions so you can get updates with the gui tool moving forward. Sorry for the screw up. Thanks.
19:57:04 <mjg59> Right, we need to publicise this somehow
19:57:05 <cwickert> and I wonder why it was only in testing for a 3 1/2 days
19:57:22 <drago01> because poeple jumped in "works for me"
19:57:23 <pjones> cwickert: because we let people do that :/
19:57:24 <adamw> it might have been just too early for the proventester process
19:57:37 <adamw> my email archive shows i sent out an email about proven testers starting on 29th june
19:57:42 <notting> cwickert: PK is critpath... for F-14 where we've expanded the list
19:58:33 <nirik> we should probibly extend that in eariler releases as well.
19:58:51 <notting> changing the updating rules out from under them?
19:59:10 <nirik> well, we already have for all the other critical path packages?
19:59:12 <cwickert> ok, I have to correct myself, it was in testing for ~6 days
19:59:45 <notting> nirik: ? we never redefined *what* was critical path for earlier releases
19:59:46 <jsmith> nirik: (Sorry for the slow response -- I'm happy to draft/send an announcement, as soon I know enough details not to make a fool of myself)
19:59:57 <notting> nirik: we just applied the same critpath handling from branched to the final
20:00:00 <nirik> notting: no, but we enabled/disabled it.
20:00:22 <drago01> so wait ... isn't PK crithpath already?
20:00:31 <nirik> ie, there was not a critical path for f12 ever, and now there is.
20:00:44 <nirik> and there was not one after it was released for a while until we re-enabled it.
20:01:09 <notting> nirik: sure, but that's using the f13 definition
20:02:12 <nirik> well, do we think that proventesters would have helped/caught these issues?
20:03:50 <nirik> do we want to see if PackageKit maintainers object to them being added to critpath in stable releases now?
20:04:07 <mjg59> I think proventesters /should/ have caught this
20:04:13 <mjg59> Whether they would is another question
20:04:15 <notting> my concern is that backporting the f14 critpath expands the list greatly
20:04:18 <cwickert> +1 to mjg59and nirik
20:04:19 <adamw> mjg59: i suspect with current procedures we wouldn't
20:04:22 <mjg59> The failure to provide update notifications is a problem
20:04:33 <drago01> adamw: which means the need to be fixed
20:04:36 <nirik> can we just add PackageKit and it's deps?
20:04:36 <mjg59> Because if someone's just installed all their updates, they *shouldn't* get one
20:04:36 <notting> bringing in apps, browsers, kde, etc.
20:04:37 <adamw> we have discussed the idea of having specific procedures for certain packages (kernel was the previous example), packagekit would be appropriate for that
20:04:49 <mjg59> In this case I think packagekit needs some sort of unit testing
20:05:07 * nirik notes 25min until he has to leave. ;)
20:05:13 <mjg59> And I think we do need to hold it to a higher standard than most of the distribution, given that without it people can't get bugfixes
20:05:15 <drago01> mjg59: well "yum downgrade $randompackage"
20:05:20 <adamw> mjg59: right, as I said earlier, that's the issue. i think hughsie has mentioned a command to me before that you can use to test if it's working to some extent. the other thing you can do is have a fake update repo you can toggle which will *always* show an update available, for testing
20:05:58 <mjg59> The precise details are, I think, out of scope
20:06:00 <adamw> we could put a fedora-release-9999 in a fake repo, or something, and to test pk update notification you could turn that repo on and see if you got a notification
20:06:06 <adamw> fair enough, sorry.
20:06:24 <mjg59> But it should be *impossible* to push a packagekit update to stable without it (a) starting and (b) providing update notification
20:06:31 <drago01> jsmith: what details are missing?
20:06:33 <adamw> agreed
20:06:46 <adamw> i'll certainly try and do whatever's necessary on the proventester/qa side to help with that
20:06:46 <nirik> right, so we need to announce to a) end users, b) devel/testers about this, and c) try and improve our testing of PK in any way that would help catch these kinds of issues.
20:06:50 <mjg59> And I don't think there's a generic way we can handle that in infrastructure
20:06:55 <mjg59> It's something that needs to happen in the package
20:06:56 * abadger1999 notes that Oxf13asked dmalcolm and I to get FESCo signoff to move the python-2.7 rebuild into rawhide.
20:07:13 <nirik> abadger1999: we can go to that topic in a few?
20:07:14 <abadger1999> in case people have to leave early
20:07:25 <jsmith> drago01: Last time I looked at the trac ticket (early this morning) it wasn't clear if there were one or two causes of the problem, if the updates to fix the problem(s) had been pushed, etc.
20:08:18 <nirik> drago01 / jsmith: how about we work out of band/meeting on an announcement and checking to make sure all is ready for it?
20:08:18 <notting> yes, they're all pushed
20:08:23 <notting> afaict
20:08:32 <drago01> nirik: wfm
20:08:44 <drago01> yes they are and are working fine
20:08:52 <nirik> drago01: we could drop draft announcement info into the ticket?
20:09:08 <drago01> nirik: yeah
20:10:00 <nirik> cool. adamw: would you be willing to send out a devel/test announce about testing with selinux?
20:11:15 <jsmith> nirik: Sounds great -- let's communicate on the ticket
20:11:38 <adamw> nirik: sure
20:11:57 <nirik> any other thoughts or action items on this ?
20:12:11 <cwickert> slap the maintainer?
20:12:15 <drago01> no
20:12:36 <drago01> playing blame games isn't helpfull
20:12:36 <nirik> in what way?
20:13:07 <cwickert> it's not about blaming someone in public but telling him to be more careful next time
20:13:30 <mjg59> It's not about being more careful
20:13:33 <mjg59> It's about making it impossible
20:13:47 <mjg59> There's no practical way we can expect humans to be infalliable here
20:14:06 <nirik> we need to catch issues like this before they go out. ;(
20:14:16 <mjg59> I think the most appropriate thing for a package of this significance is to make sure that it actually tests its own functionality in this respect
20:14:33 <nirik> yeah.
20:14:34 <nirik> #topic #442: Firefox and SELinux - bug 597858
20:14:34 <nirik> .fesco 442
20:14:36 <zodbot> nirik: #442 (Firefox and SELinux - bug 597858) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/442
20:15:21 <drago01> again
20:15:25 <ajax> let's just call it redbaron already
20:15:47 * notting is not sure why this is a huge issue. the same policy tweak for rawhide has been done in *many* prior fedora releases, to be turned off for the actual release
20:16:26 <drago01> seems there is atleast one benefit for mozilla not shipping the JIT for x86_64 yet
20:17:17 <notting> the execmem check was also breaking the JIT for webkit-based apps
20:17:23 <notting> at least, the last time we had it on
20:17:49 <nirik> Not sure what we can do here currently, aside from asking for more attention on it and see if we can get folks to help get it upstreamed.
20:17:49 <nirik> anyone have any other thoughts on input on this one?
20:18:59 <ajax> i'm with notting; we'll flip it back eventually unless mozilla says something
20:22:08 <notting> should we move on?
20:23:03 <cwickert> +1 for ajax and notthing and then more
20:24:30 <notting> well, that explains the quiet
20:25:13 <cwickert> ouch
20:25:26 <ajax> *yawn*
20:25:27 * cyberpear thought the silence weird
20:27:23 <cwickert> all fesco members back in here?
20:27:53 <drago01> ...
20:28:46 <ajax> possibly
20:30:01 <ajax> it's like an irc network, only, not.
20:31:14 <cwickert> oops
20:31:14 <cwickert> drago01: you stopped it ;)
20:31:23 * dmalcolm wonders if the meeting is still on
20:31:51 <cwickert> all fesco members in an voiced?
20:31:53 <notting> presumably, if freenode can keep itself in order.
20:32:30 <ajax> honestly.
20:32:53 <nirik> ok.
20:32:53 <nirik> #topic Python 2.7
20:32:53 * nirik looks for zodbot
20:32:53 * jsmith continues to lurk
20:32:58 <nirik> hurray.
20:33:03 <nirik> abadger1999 / dmalcolm: whats the status?
20:33:46 <abadger1999> nirik: We would like to move the dist-f14-py27-rebuild packages back into the dist-f14 tag
20:34:10 <dmalcolm> nirik: 99 failures from original run; have found about 35 further rpms that missed my original script
20:34:32 <dmalcolm> much of this is due to FTBFS in other packages e.g. gtk2 vs gtk3 breakage
20:34:50 <nirik> based on what I know, +1 from me.
20:34:54 <dmalcolm> adamw: how's your testing going?
20:34:58 <abadger1999> adamw has looked at the list of still ftbfs packages and doesn't think anything is on the critpath list.
20:35:56 <cwickert> +1
20:36:10 <cwickert> most of the things that failed already failed before
20:36:19 <notting> abadger1999: you were working on neutering python-fedora into something that builds enough functionality for f-easy-karma, etc.?
20:36:26 * nirik has to depart... can someone take over running things from here? The only thing left on the regular agenda is FES tickets roundup and open floor.
20:36:32 <pjones> I definitely think +1 on doing this ASAP
20:36:54 <dmalcolm> cwickert: I believe Oxf13's concern is that things that don't FTBFS at least install and run as is, whereas if we do this, they won't
20:37:11 <dmalcolm> s/don't//
20:37:34 <cwickert> good point indeed
20:37:56 <adamw> dmalcolm: testing i'm stalled on as I can't make any live images boot due to other bugs
20:38:09 <abadger1999> notting: Yes -- I've neutered both python-fedora and bodhi so that they build the clientside necessary for easy-karma, etc.
20:38:19 <notting> adamw: can you yum upgrade something?
20:38:52 <adamw> notting: hmm, i guess i could do an f13 live cd and yum update it, indeed, didn't think of that - thanks
20:39:04 <notting> the corollary here is that if we merge it, stuff's gon break. and if we lock cvs for branching, and dist-git... hard to fix things in the interim
20:39:26 <adamw> do we have even a vague eta on the downtime?
20:39:41 <adamw> so we'll know how much fixin' time will be left after it comes back up and before we get very frozen for alpha?
20:39:53 <abadger1999> adamw: IIRC dgilmore or Oxf13 said two-three days.
20:40:04 <abadger1999> Oxf13: ^
20:40:17 <Oxf13> I'm hoping to cut down that time by splitting the conversion across a couple hosts
20:40:21 <adamw> alpha change deadline is 08-03
20:40:30 <adamw> after which i believe we won't take changes to non-critpath packages into alpha, right oxf13?
20:40:39 <Oxf13> but I'm also getting a later start because I'm trying to give the python and boost folks as much time today to get builds done
20:40:40 <mjg59> I'm still missing a reasonably written description of the problem
20:40:48 <notting> alpha's not blocking, is it?
20:40:49 <Oxf13> adamw: only if we're in RC phase
20:40:50 <adamw> or is it the other way around, critpath is frozen but we'll accept non-critpath changes? i forgert
20:41:01 <Oxf13> notting: "kinda"
20:41:04 <adamw> Oxf13: i'm looking at http://poelstra.fedorapeople.org/schedules/f-14/f-14-quality-tasks.html
20:41:18 <Oxf13> once we have a cleared blocker list and enter RC phase, we won't be doing any pushes to stable unless it's to fix a blocker issue
20:41:18 <notting> mjg59: 'approximately 90 things that have a dependeny on python-2.6 did not rebuild. this means that if we merge the rebuild, they will have broken dependencies'
20:41:23 <Oxf13> we'll still do pushes to updates-testing though
20:41:23 <adamw> it has 'alpha change deadline' at 08-03, first alpha rc on 08-05
20:41:42 * Oxf13 wonders where the alpha change deadline came from...
20:41:48 <adamw> Oxf13: yeah, me too, that's something new.
20:41:51 <Oxf13> probably me
20:41:54 <adamw> maybe it's there to give you time to spin the rc?
20:41:58 <Oxf13> could be
20:41:59 <adamw> it seems about the right time
20:42:18 <mjg59> notting: Ok, thanks
20:42:18 <notting> istr poelcat pushing for a defined date for taking final changes
20:43:26 <adamw> so if we take 08-03 as the deadline
20:43:31 <adamw> say the conversion gets done in 3 days
20:43:32 <Oxf13> ok, so that's the target date for not doing any more stable pushes
20:43:46 <adamw> that gives...3-4 days for people to fix their python packages
20:44:06 <Oxf13> they can be worked on locally during the outage too
20:44:10 <adamw> right
20:44:15 <Oxf13> if we land the python mess and allow a compose to happen tomorrow
20:44:19 <adamw> and a lot of this stuff doesn't go into the live compose or default install
20:45:06 <poelcat> notting: lol... it came from you and fesco and replaced the "freezes"
20:45:11 <adamw> the py27 target is already at a point where i can do an almost unmodified live spin, though i can't see how well it WORKS because it won't boot (unrelated bugs)
20:45:22 <poelcat> notting: though i still think it is a good idea
20:45:26 <notting> poelcat: hah. so much for my faulty memory
20:46:42 <abadger1999> Okay -- so are we good to land the packages in the tag?
20:46:43 <notting> realistically, we are voting on 'do we accept the feature for f-14', no?
20:46:51 <adamw> i should be able to give a rough idea of how a system installed with f13 live, updated to py27 tag goes in about half an hour, if it goes smoothly
20:47:04 <notting> because either we accept it, merge it now, and deal with it, or we postpone it for a) post-alpha, as an exception b) the release
20:47:28 <abadger1999> notting: Well -- you could also issue an exception to say, we'll allow the packages to be merged after the alpha.
20:48:03 <abadger1999> I talked with adamw this morning and if it came down to bad options to choose from he'd rather we slip alpha than merge after alpha.
20:48:06 <pjones> notting: yeah, I think that's the reality of the situation
20:48:09 <adamw> fwiw, from a qa perspective, i personally would rather merge for the alpha and deal with it at this point, i think we can fix enough packages that the alpha won't be horribly broken. note i haven't discussed with the rest of qa, though.
20:48:21 <pjones> but I think we're better served merging it sooner rather than later.
20:48:50 <abadger1999> <nod>
20:49:25 <adamw> the biggest worry is anaconda, but pjones seems reasonably confident that if we run into problems they should be fixable quite quickly...right?
20:49:27 <notting> so, yeah. +1 to merge, although i can't help but think we're gonna slip.
20:50:01 <pjones> yeah, I'm reasonably confident.  the biggest issue there will probably be the timing coinciding with the dist-git outage, but, well, that's life.
20:50:27 <pjones> so that's me, cwickert, and notting all +1
20:50:40 <cwickert> jepp, anybody else?
20:50:55 <pjones> ajax: mjg59: psst, you around?
20:51:19 <notting> pjones: nirik as well
20:51:22 <abadger1999> nirik was +1 earlier.
20:51:25 <pjones> ah, okay
20:51:32 <mjg59> Ok, +1
20:51:40 <pjones> #agreed merge python2.7 already
20:51:59 <notting> #info please fix your packages where required
20:52:02 <pjones> (I don't think the bot is listening to me)
20:52:19 <notting> #agreed merge of python 2.7 is approved
20:53:36 <ajax> yeah, merge it
20:53:46 <notting> #topic FES tickets
20:54:06 <notting> any updates?
20:54:16 <abadger1999> mmcgrath: ^
20:54:31 <mmcgrath> abadger1999: no updates on that this week, haven't put my hours in yet :-/
20:54:41 <mmcgrath> let me know if there's anything we should be doing for python2.7
20:55:04 <notting> mmcgrath: fix FTBFS broken deps. but i can't imagine that's not already covered tangentially in existing tickets
20:55:14 <mmcgrath> <nod>
20:55:39 <notting> ok, if there's nothing on that...
20:55:42 <notting> #topic Open Floor
20:55:53 <notting> any questions, concerns, comments, flamings?
20:56:31 <notting> Oxf13: want to talk a bit about the dist-git migration?
20:56:50 <Oxf13> sure
20:56:54 <jsmith> Yeah, it would be good to have a quick update
20:57:06 <Oxf13> Things are going smoothly on getting the production pkgs.fedoraproject.org fully config managed.
20:57:24 <Oxf13> I've done another test conversion using our "final" branching structure and tested fedpkg against it
20:57:30 <Oxf13> a new build of fedpkg will be coming up today
20:57:40 <Oxf13> I have a game plan for the outage too
20:57:55 <Oxf13> and I plan to reduce outage time by splitting the repo conversions across two hosts
20:58:19 <Oxf13> while it won't be a 2x speed increase, it should make things faster overall
20:58:27 <Oxf13> and perhaps faster than 2 days
20:58:59 <Oxf13> so far, we're still looking good on this, the big missing part is getting documentation in place
20:59:10 <notting> Oxf13: for reference... outage starts when, and people can help with docs where?
20:59:40 <Oxf13> the outage will start late tonight, after the python / boost folks are "done" throwing builds at the system
21:00:31 <Oxf13> I suspect it'll be close to the rawhide compose start time, which is 0800 UTC
21:00:48 <Oxf13> so in about 10 hours.
21:01:26 <jsmith> Oxf13: If there's anything I can help with tonight, let me know.  I'm happy to help write docs, if that's what it takes to help get things going
21:02:18 <Oxf13> as for docs help, the surface can be scratched by starting with https://fedoraproject.org/wiki/Using_Fedora_CVS and making a Using_Fedora_GIT page and start translating stuff
21:02:41 <Oxf13> admittedly many of the things referenced are still being setup
21:02:53 <Oxf13> so I suspect it'll be a lot of people asking me questions about how it's supposed to work
21:03:50 <jsmith> OK.
21:04:29 <Oxf13> also my time estimation on conversion was based on our stage host, and then our production host with hardware constraints.  So it could go faster, I really don't know
21:05:23 <notting> #info mass branching, and conversion to git will occur at 0800 UTC tonight
21:05:40 <notting> #info scm access and building will use the new 'fedpkg' commands
21:06:08 * poelcat wanted to draw attention to the blocker bug reminder emails I've started sending... we may need assistance from FESCo if we do not start receiving more timely response to some of the open proposed and approved blockers
21:07:08 <poelcat> we've gone through two alpha blocker bug meetings and a good majority of the time is trying to track down information and fill in gaps that we have because the bugs don't have a clear response from the maintainerr
21:07:47 <poelcat> I'd like to think/hope we can avoid some of the marathon meetings that fedora 13 saw
21:07:55 <poelcat> <end of soapbox>
21:08:01 <notting> all blocker review meetings must be eternal. it is in their charter.
21:08:22 <notting> #info please respond to your proposed and accepted blocker bugs
21:10:04 <notting> anything else?
21:10:11 <ndim> Idea for the future: Regular mass rebuilds could be a good idea, to avoid the FTBFSs from piling up. The py27 rebuild dug up many FTBFS issues unrelated to py27.
21:10:42 <notting> mdomsch does do them occasionally. i think he did the last f14 one before gtk2/gtk3 landed
21:12:08 <ndim> notting: So the issue is just a case of people not fixing FTBFS in time? Well, then that might be something to watch.
21:12:20 <notting> ndim: no, it's things changing after the last mass rebuild test
21:12:42 <Oxf13> notting: I'd say it's a combo of both
21:13:01 <abadger1999> Maybe see if we can coordinate landing big changes with mdomsch's mass rebuilds?
21:13:22 <Oxf13> I have in the past asked him to test with something that is proposed to land
21:13:29 <Oxf13> so that we can see ahead of time what kind of havoc it would wreak
21:13:42 <Oxf13> that really just takes coordination with the feature overviewers
21:13:56 <abadger1999> <nod>
21:14:09 <Oxf13> in the past I kept an eye out for that, but this release I have not been able to
21:15:21 <notting> #info perhaps try and schedule FTBFS runs around landing of major ABI breaks
21:15:28 <notting> #undo
21:15:28 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x1e362e10>
21:15:33 <notting> #idea perhaps try and schedule FTBFS runs around landing of major ABI breaks
21:16:09 <notting> anything else?
21:17:49 <notting> ok then.
21:17:52 <notting> #endmeeting