=================================== #fedora-meeting: FESCO (2010-07-27) =================================== Meeting started by nirik at 19:30:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-07-27/fesco.2010-07-27-19.30.log.html .. Meeting summary --------------- * init process (nirik, 19:30:01) * #351 Create a policy for updates - status report on implementation (nirik, 19:33:38) * #382 Implementing Stable Release Vision (nirik, 19:35:45) * #438 F14Feature: Ruby_1.87 - https://fedoraproject.org/wiki/Features/Ruby_1.8.7 (nirik, 19:41:13) * AGREED: feature is approved. (nirik, 19:43:28) * #440 Improve updates process to avoid "windows of doom" (nirik, 19:43:48) * #442: Firefox and SELinux - bug 597858 (nirik, 20:14:34) * Python 2.7 (nirik, 20:32:53) * AGREED: merge python2.7 already (pjones, 20:51:40) * please fix your packages where required (notting, 20:51:59) * AGREED: merge of python 2.7 is approved (notting, 20:52:19) * FES tickets (notting, 20:53:46) * Open Floor (notting, 20:55:42) * mass branching, and conversion to git will occur at 0800 UTC tonight (notting, 21:05:23) * scm access and building will use the new 'fedpkg' commands (notting, 21:05:40) * please respond to your proposed and accepted blocker bugs (notting, 21:08:22) * IDEA: perhaps try and schedule FTBFS runs around landing of major ABI breaks (notting, 21:15:33) Meeting ended at 21:17:52 UTC. -- 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
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
