=================================== #fedora-meeting: FESCO (2010-08-24) ===================================
Meeting started by nirik at 19:30:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-08-24/fesco.2010-08-24-19.30.log.html .. Meeting summary --------------- * init process (nirik, 19:30:02) * #351 Create a policy for updates - status report on implementation (nirik, 19:34:01) * LINK: https://fedoraproject.org/wiki/User:Ajax/Stable_Release_Policy (ajax, 19:34:10) * AGREED: we should just use critical path and remove references to 'important packages' (nirik, 19:39:13) * ACTION: mclasen to update https://fedoraproject.org/wiki/Package_update_acceptance_criteria (nirik, 19:41:06) * ACTION: notting to ask for more clarification on question 2. (nirik, 19:49:34) * #382 Implementing Stable Release Vision (nirik, 19:55:25) * LINK: https://fedoraproject.org/wiki/User:Ajax/Stable_Release_Policy (nirik, 19:56:01) * ACTION: ajax to update docs. Will revisit over the week and next meeting. (nirik, 20:11:26) * FES tickets roundup (nirik, 20:11:41) * LINK: https://fedorahosted.org/fedora-engineering-services/report/6 (nirik, 20:11:45) * Open Floor (nirik, 20:19:03) * ACTION: mclasen to write up ideas for branched releases update criteria (nirik, 20:32:33) Meeting ended at 20:41:07 UTC. Action Items ------------ * mclasen to update https://fedoraproject.org/wiki/Package_update_acceptance_criteria * notting to ask for more clarification on question 2. * ajax to update docs. Will revisit over the week and next meeting. * mclasen to write up ideas for branched releases update criteria -- 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
signature.asc
Description: PGP signature
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
