17:59:59 <notting> #startmeeting FESCO (2012-03-05)
17:59:59 <zodbot> Meeting started Mon Mar  5 17:59:59 2012 UTC.  The chair is notting. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:59 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:04 <notting> #meetingname fesco
18:00:04 <zodbot> The meeting name has been set to 'fesco'
18:00:12 <notting> #chair notting nirik mjg59 mmaslano t8m pjones sgallagh mitr limburgher
18:00:12 <zodbot> Current chairs: limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m
18:00:12 <notting> #topic init process
18:00:16 <notting> hey, who's around?
18:00:16 * nirik is here.
18:00:31 <mmaslano> hi
18:00:33 <mitr> Hello
18:00:37 * sgallagh assumes incorporeal form on the wire to be here
18:00:54 <mjg59> Hi
18:01:01 <pjones> hello.
18:01:06 <t8m> hi
18:01:13 <vallor> greets
18:01:47 <VICODAN2> hiya
18:01:52 * epienbro is here for the mingw subject
18:02:19 <notting> big crowd today
18:02:37 <VICODAN2> i missed the other meeting so making up with a different one :/
18:02:39 * ktietz is here for the mingw subject, too
18:02:40 <notting> ok, let's get started
18:02:49 <notting> #topic #812     Mass rename request for all mingw32-* packages because of new packaging guidelines
18:02:55 <notting> .fesco 812
18:02:58 <zodbot> notting: #812 (Mass rename request for all mingw32-* packages because of new packaging guidelines) – FESCo - https://fedorahosted.org/fesco/ticket/812
18:03:29 <nirik> so, my concern here is that it's really easy to screw up the Obsoletes/Provides... how can we check that they are good before just landing all these.
18:04:03 <sgallagh> nirik: In the ticket, they claim it's not changing the Provides for 32-bit packages
18:04:04 <epienbro> obsoletes/provides aren't needed for this rename
18:04:12 * t8m has no problem with this mass change for Rawhide
18:04:15 <epienbro> let me come up with an example diff
18:04:19 <mitr> It seems that FPC has been involved with the plan, is that so?
18:04:41 <nirik> yeah, so if we don't need them, it might be ok. as long as we block the old ones at the same time.
18:04:43 <epienbro> http://svn.openftd.org/viewvc/Fedora%20Cross%20Compiler%20Framework/mingw-cppunit/mingw-cppunit.spec?r1=322&r2=543
18:04:45 <t8m> It's questionable whether we want such change on F17 branch
18:06:12 <nirik> seems like a lot of change post alpha/feature freeze.
18:06:56 <notting> we'd still have to block all the prior-named packages
18:07:05 * nirik nods.
18:07:15 <epienbro> well, we planned to perform this change earlier, but as we were waiting for rh legal to approve the use of the mingw-w64 toolchain in fedora we couldn't do this earlier
18:07:29 <mitr> The "actual software" aspect seems easy enough (diff, automation, rpmdiff etc.), only the infrastructure might be a problem
18:07:43 <sgallagh> epienbro: Is there a technical or political reason that it can't wait until F18 at this point?
18:07:44 <nirik> we have also had a policy of no new packages without review, but this may be a corner case where it's ok.
18:08:08 <mitr> sgallagh: Is there a technical or political reason why it couldn't go into F17 at this point?  0 code change.
18:08:10 <notting> i'm certainly fine for rawhide, and can be convinced that it's useful for f17 as it's all behind the scenes, it shouldn't be changing anything for users/developers
18:08:11 <VICODAN2> maybe you can rename all the mingw packages and create an alias with the old name?
18:08:32 <nirik> VICODAN2: this is about renaming them. ;)
18:08:44 <sgallagh> mitr: Technically, it's a massive set of changed packages post feature freeze
18:09:12 <notting> epienbro: dumb question - what do you intend to do in the buildsystem if one of our secondary arches is made primary? port the cross-compiler to that arch too?
18:09:19 <sgallagh> mitr: Frankly, I'm on the fence, so I'm offering an opportunity to convince me
18:09:31 <epienbro> sgallagh, as we needed to wait for rh legal to give approval (for more than a year) it would be a shame if we would miss the f17 deadline..especially as everything has already been developed and tested in a separate repository
18:10:18 <t8m> epienbro, this does not really look like a convincing technical argument
18:10:19 <epienbro> notting, in that case only a bootstrap has to be performed of gcc
18:10:36 <VICODAN2> nirik: I understand, the idea was to somehow keep backwards compatibility, I mean theoretically this "shouldnt" break anything but what could it break?
18:10:36 <t8m> epienbro, although I can understand your point
18:10:51 <ktietz> well, technical argument for this rename is that 64-bit support can be added by it AFAIU
18:10:59 <mitr> sgallagh: I guess I'm not worried about the code change at all (there is none, and we routinely assume that rebuilding one moth later is safe), I'm not really worried about the packaging (many eyeballs are already focusing on this), so all that is left from my POV is whether the infrastructure / package retirement process can accomodate it.
18:11:12 <sgallagh> ktietz: Yes, but that sounds like a Feature coming in post-Feature Freeze to me.
18:11:17 <sgallagh> So I need a little justification
18:11:28 <t8m> mitr, yeah, that looks like reasonable argument
18:11:53 <sgallagh> true
18:11:59 <nirik> mitr: should be possible. Just create the 101 new packages, block the 101 old packages, let them import. For f17 the updates process may not be able to easily handle an update with 101 packages... so it would need to be split up or manually tagged into f17
18:12:07 <sgallagh> I'm not trying to be obstructionist, just cautious :)
18:12:07 <epienbro> sgallagh, that's correct, we actually already prepared a feature page for mingw-w64 support: https://fedoraproject.org/wiki/Features/Mingw-w64_cross_compiler
18:12:24 <pjones> nirik: eh, 101 packages most people don't have installed?
18:12:32 <nirik> right.
18:12:40 <ktietz> well, from my point it would be good to start on F17 already with the mass-rename, as it leads for RHEL 7 from beginning to the proper naming schema.  On the other hand, I can wait for this until F18, but it might be better for having it soon
18:12:47 <notting> nirik: would we even import? why not just copy the repos over?
18:12:59 <epienbro> but we didn't propose it at the feature submission deadline because of the pending legal issues I mentioned earlier and we weren't certain if the legal approval would arrive in time
18:13:24 <nirik> notting: well, they still have to update and the spec would need renaming, and it seems odd to have the old history there on a new package, IMHO
18:14:17 <mitr> notting: the old repo can be merged into the git history anyway
18:14:20 <notting> i'm sure the retirement process can handle it. blocking things is easy :)
18:14:40 <nirik> ok, I guess I am +1 to both 17/rawhide. Provided releng doesn't yell.
18:14:52 <pjones> (also for personal reasons I want this in as soon as possible.)
18:14:52 * nirik looks at dgilmore
18:15:20 <sgallagh> I'm +1 Rawhide, +0 Fedora 17
18:15:43 <pjones> I'm +1 to both
18:15:45 <t8m> OK +1 for both F17 and Rawhide
18:15:55 <mitr> I'm +1 to both
18:15:58 <mmaslano> +1 to both if dgilmore is ok with rename
18:16:55 <notting> +1 to both from me
18:17:02 <notting> dgilmore: opinions?
18:17:07 <pjones> nirik: I'd rather keep the old history FWIW; it's not like it's suddenly not true history or something.
18:17:21 <mjg59> +1
18:17:33 <dgilmore> what is the question?
18:17:36 * nirik shrugs. I don't know that I care, just seems odd in a 'new' package.
18:17:47 <VICODAN2> lol
18:18:06 <nirik> dgilmore: we are talking about blocking mingw32-* and making mingw-* and doing that in f17 and rawhide.
18:18:25 <dgilmore> nirik: i would say rawhide only
18:18:33 <pjones> why?
18:19:37 <nirik> it's post feature freeze churn, but it seems like it would be reasonably safe
18:19:43 <pjones> what we're really asking is: is there any technical problems releng would have with doign it for f17?
18:19:49 <dgilmore> because its a big change way past feature freeze
18:19:57 <dgilmore> pjones: who knows
18:19:59 <notting> it is merely a change in the name of the source package
18:20:19 <dgilmore> does it involve changes in comps?
18:20:22 <notting> no.
18:20:23 <dgilmore> andaconda?
18:20:25 <pjones> no.
18:20:47 <pjones> nirik's synopsis above really appears to be complete.
18:21:23 <dgilmore> grep mingw32 comps-f17.xml.in |wc -l
18:21:24 <dgilmore> 34
18:21:38 <dgilmore> i would think that really should all be changed
18:21:42 <notting> right, it doesn't change those
18:22:01 <dgilmore> seriously we should at this point be slowing the curn way down. its really too late for f17
18:22:04 <epienbro> dgilmore, the comps file only contains binary packages right? the naming of binary packages doesn't change..only the source packages change
18:22:45 <mjg59> dgilmore: What you're being asked isn't whether you think it's a good idea. It's whether it will cause rel-eng (and *only* rel-eng) technical difficulties.
18:23:05 <dgilmore> mjg59: thats unknown
18:23:17 <mjg59> Well if there's no known problems then let's do it
18:23:18 <dgilmore> mjg59: i found out about it a monute or two ago
18:23:20 <mitr> mjg59: well, "risk of technical difficulties" is interesting as well
18:23:32 <dgilmore> mjg59: so i would say rather than tempt fate no
18:23:46 <mjg59> dgilmore: Yes, but that's not what you're being asked
18:24:01 <dgilmore> mjg59: it may cause technical difficulties
18:24:15 <mjg59> But you're not aware of any specific cases in which it would?
18:24:17 <mitr> dgilmore: any particular area, or just "too much change"?
18:24:17 <notting> it's a process we do now on an individual basis. not seeing why it would break when scripted
18:24:21 <t8m> OK why not doing it in two steps? First doing rawhide as soon as possible. Then if there are no serious difficulties proceed with F17.
18:24:45 <pjones> t8m: with a very short timeframe for determining if there were serious difficulties?  like a day or two max?
18:24:46 <dgilmore> mitr: its completely unknown what will. wont or may break.
18:25:02 <mitr> t8m: looks reasonable
18:25:07 <t8m> pjones, yep,
18:25:22 <pjones> t8m: I could get behind that
18:25:25 <drago01> dgilmore: so do it and find out?
18:25:26 <dgilmore> notting: we do not ever rename git repos
18:25:40 <dgilmore> drago01: not at this point of the release cycle
18:25:54 <dgilmore> notting: we create new repos for renames
18:25:55 <nirik> well, if they went and did re-review of the packages, then it would be allowed?
18:26:04 <t8m> Renaming git repos is optional and if rel-eng objects to it it does not have to be done
18:26:09 <dgilmore> we eol the old package aand block it in koji
18:26:15 <dgilmore> and add the new packages
18:26:30 <nirik> we don't want to rename.
18:26:32 <mjg59> So far what I'm continuing to hear is "There are no technical issues that would result from this"
18:26:39 <mitr> While a package rename was requested, I think the most important part of the request was an exception from the re-review request.
18:26:41 <pjones> mjg59: sounds like it.
18:26:50 <dgilmore> nirik: the packages being re-reviewsed is the steps needed for a rename, we treat them as new packages
18:26:55 <pjones> I'm +1 to going ahead with it, though I could be persuaded by t8m's plan.
18:27:00 <t8m> mitr, I think the exception from rereview was clearly granted
18:27:05 <mitr> It seems there's no controversy about the lack of re-review
18:27:11 <mjg59> I have no problem with it being briefly staged in rawhide
18:27:14 <nirik> dgilmore: right. in this case they are asking us to skip the review part.
18:27:31 <sgallagh> We probably should have voted on the re-review skip. +1 to it in my case
18:27:51 <dgilmore> nirik: that should be a big fat no
18:28:15 <nirik> well, the reason for re-review is to make sure obsoletes/provides is right. In this case there are none needed.
18:28:22 <pjones> I don't think anybody on fesco is currently arguing that we should re-review.
18:28:40 <mitr> dgilmore: You mean that the re-review bug is necessary as a part of the process, or that the human review is necessary?
18:28:56 <dgilmore> mitr: both
18:28:57 * nirik nods. I'm ok with giving them a pass on re-review. The f17 thing is more up in the air.
18:29:24 <mjg59> dgilmore: Again, you're being asked a technical question, not a policy one.
18:30:04 <nirik> proposal: no re-review, land in rawhide. Revisit next week about f17 status?
18:30:11 <mjg59> dgilmore: Policy-wise, fesco is fine with these packages not being re-reviewed. If there are technical reasons that this causes a problem for rel-eng then we'd love to hear about them.
18:30:17 <mitr> So, if no renaming is done in infrastructure, and this is treated like an ordinary re-review with a bug filed, tickets etc., except that nobody will actually do a full re-review, is there any problem?
18:30:45 <mitr> nirik: I'd rather approve this right now, and only require 1 non-broken compose in the mean time
18:31:08 <nirik> non broken compose?
18:31:12 <mitr> dgilmore: Would doing f18 and f17 separately double load on a person, or is new package import automated enough?
18:31:20 <pjones> nirik: I'm okay with the people doing the work just moving ahead on f17 if nothing breaks in rawhide.
18:31:25 <mitr> nirik: Well, what kind of a failure are we expecting really?
18:32:03 <nirik> epienbro: are there any changes to the packages aside from the subpackage adding/spec file name? ie, are you also adding other changes?
18:32:10 <dgilmore> mitr: the load on a person doing it for f17 and f18 would be the same as adding any other package
18:32:21 <sgallagh> dgilmore: This is 101 packages
18:32:36 <mitr> dgilmore: "do you care whether there are 101 or 202 tickets, or do you not care?"
18:32:52 <sgallagh> mitr: There should only be 101 tickets
18:32:59 <notting> mitr: tbh, it would go through bugzilla and wouldn't hit releng until the old packages needed blocked
18:33:00 <dgilmore> mitr: adding the repos on the server is scripted
18:33:03 <mitr> sgallagh: Not if f17 is done several days later
18:33:11 <mitr> dgilmore: thanks
18:33:25 <notting> really, it would be one ticket. "plz block these 101 packages"
18:33:26 * nirik notes there should be 1 ticket really.
18:33:30 <dgilmore> mitr: the script is run, each package is checked for a complete review
18:33:46 <dgilmore> and then acked or naked by the person doing the processing
18:33:46 <notting> nirik: JINX.
18:33:58 <epienbro> nirik, for now, the only things we plan to do are to bootstrap the win64 compiler and to perform the package renames (which we expect to complete this week)..after that we can port the individual packages to the new mingw packaging guidelines (thus adding win64 support), but this isn't time limited
18:34:04 <dgilmore> nirik: there cant be one ticket
18:34:27 <dgilmore> nirik: the scripts to process new git branches expect one package per bug report
18:34:43 <mitr> epienbro: the packaging guildeines update would be F18 only?
18:34:51 <dgilmore> but there should be 1 ticket to block the old ones
18:34:56 <nirik> dgilmore: yes, if we require a bugzilla bug for each rename.
18:35:29 <epienbro> mitr, well they can be enabled from f17 on as all the pieces are already in place (all rpm macros are backwards compatible)
18:36:02 <t8m> dgilmore, cannot this be handled with a different script automatically, not requiring bugzilla for each package?
18:36:03 <mitr> epienbro: I'm fine with doing the rename for f17; larger changes in f17 are... something to discuss separately?
18:36:13 <mitr> t8m: Why bother?  Let epienbro write a bugzilla script.
18:36:23 <t8m> mitr, OK that's another possibility
18:36:35 <notting> is this boiling down to "is someone from releng volunteering to do the work of handling the request?
18:36:36 <epienbro> I'm okay with that
18:37:04 <dgilmore> t8m: no. we dont have anything like that because thats not how things are done
18:37:08 <mitr> notting: I think we've covered most known ways why this couldn't work, and it seems to me that it could work after all.
18:37:39 <nirik> so where are we here?
18:38:13 <mitr> So, proposal: 1) manual re-review is not required for this rename; 2) if the rename happens in f18 and doesn't break a compose or anything else, 2 days later the rename can be done in f17
18:38:16 <t8m> epienbro, OK I suppose you'll have to create all the bugzillas with some script. I suppose that you can grant the review flag automatically by another script run with mentioning the FESCo grant
18:38:47 <notting> mitr: nothing prevents #2 from being done in any case.
18:38:49 <epienbro> t8m, sure, I can give that a shot
18:39:10 <mitr> Oh, and 3) rel-eng is not asked to create special processes for thi
18:39:20 <mitr> this
18:39:51 <mitr> epienbro: Would that work for you?
18:40:05 <nirik> the one problem is the bodhi update for f17... but I suppose you could break them into 10-20 package chunks
18:40:23 <dgilmore> nirik: i have created an update with over 100 packages before
18:40:32 <epienbro> mitr, I'm okay with that
18:40:34 <dgilmore> but thats about its limit
18:40:39 <nirik> dgilmore: and it worked? cool.
18:40:42 <sgallagh> The longer this discussion goes on, the more I'm inclined to vote -1 for F17
18:40:59 <sgallagh> But I'm sure I'm going to be outvoted.
18:41:05 <notting> i'm still +1 to doing this for both
18:41:09 <pjones> sgallagh: why?  even dgilmore seems to be saying it should work.
18:41:24 <pjones> (though he clearly dislikes the idea)
18:41:35 <dgilmore> pjones: it shoudl work, will it break things who knows
18:41:46 <mjg59> dgilmore: Well, ideally rel-eng would know
18:41:51 <mitr> I'm undecided, slightly negative, on adding win64 support in f17, but that's something else.
18:42:18 * nirik is fine with the above proposal. (note that item 1 really isn't the case anymore if we are filing bugs and having someone approve the reviews)... but sure.
18:42:23 <dgilmore> mjg59: without looking at it in detail and doing some testing we dont know, we can only speculate
18:42:24 <sgallagh> pjones: We've gotten to "it should work" by walking through a half-dozen things that could each fall apart.
18:42:24 <pjones> mitr: agreed.
18:42:30 <sgallagh> This doesn't engender confidence in me.
18:42:37 <mjg59> dgilmore: Informed speculation is useful
18:42:49 <dgilmore> mjg59: and i cant look at it in detail when ive only known about it for the length of this discussion
18:42:57 <nirik> dgilmore: you don't have your tarot cards handy? or is that crystal ball?
18:42:59 <pjones> sgallagh: sounds the only way to arrive at any conclusion to me...
18:43:06 <t8m> nirik, note that the review approval would be just formal flag in BZ not a real review
18:43:14 <mmaslano> we are discussing simple rename for 40 minutes, so it's not so easy as it looked like
18:43:21 <mitr> dgilmore: So a deferral by a week would be useful?
18:43:25 <nirik> t8m: sure, but it could also be a quick look over of the diff. Anyway.
18:43:27 <dgilmore> nirik: its a magic fairy these days ;)
18:43:28 <mitr> Does it make sense within the schedule?
18:43:30 <t8m> nirik, just so that releng scripts would work
18:43:36 <pjones> yeah, I think we're way past our 15 minutes on this.  Can we just vote on mitr's proposal and move on?
18:43:45 <notting> +1 to jfdi
18:43:48 <nirik> +1 to mitr's proposal, move on.
18:43:52 <pjones> +1 as well
18:43:55 <t8m> nirik, but normally a re-review should be a full rereview with running rpmlint etc
18:43:58 <mjg59> +1
18:43:58 <drago01> mmaslano: well the only difference to a "normal" rename is 1) no reviews 2) lots of packages
18:44:07 <dgilmore> TC1 for beta is due today
18:44:10 <pjones> obviously mitr is +1 for it, right?  that's 5.
18:44:11 <dgilmore> or tomorrow
18:44:12 <t8m> +1 to both mitr's proposal and moving on
18:44:18 <pjones> 6
18:44:28 <sgallagh> I remain -1 to F17, but +1 for 1) and 2) of mitr's proposal
18:44:32 <drago01> 1) shouldn't be a problem due to fesco's ack 2) well if ti works for single packages there is no reason it can't work for 2, 10 or 1000
18:44:49 <mitr> Yes, I'm +1;  I don't think deferral is reasonable, given that we are 15 days before beta change deadline
18:45:00 <notting> #agreed rename w/o re-review will be done in rawhide and merged for f17 if there are no problems
18:45:04 <pjones> dgilmore: if it doesn't make TC1, that's fine.
18:45:18 <notting> next topic...
18:45:22 <notting> #topic #815     abrt bugzilla deduplicator
18:45:26 <notting> .fesco 815
18:45:28 <zodbot> notting: #815 (abrt bugzilla deduplicator) – FESCo - https://fedorahosted.org/fesco/ticket/815
18:45:36 <epienbro> thank you for the approval!
18:45:44 <pjones> this probably should have been a requirement for deploying abrt in the first place.
18:45:55 <notting> this was more or less approved in the ticket. mentioning here for completeness.
18:46:08 <notting> any comments before we move on? strenuous objections?
18:46:11 <drago01> pjones: yeah
18:46:25 <sgallagh> pjones: If we waited for a project to complete every feature, we'd never ship anything
18:46:26 <nirik> they need to file a infra ticket to get the account setup with perms, etc
18:46:36 <nirik> but hope it closes a ton of bugs. ;)
18:46:39 <mjg59> Yeah I'm +1 for this
18:46:48 * sgallagh was +1 in the ticket and remains so here
18:46:57 <mmaslano> +1 in the ticket
18:47:02 * t8m as well
18:47:05 <mitr> +1 in the ticket, for the record
18:47:13 <pjones> sgallagh: dude, quit it with the useless aphorisms. I'm not making any assertion anything like "we should wait for every project to complete every feature".
18:47:20 <drago01> sgallagh: that's not about being complete but avoid useless noise and thus save maintainers times (and keep there mailboxes sane ;) )
18:47:30 <notting> #agreed abrt bugzilla deduplicator is approved. go forth and do it
18:47:35 <notting> moving on
18:47:38 <notting> #topic FES tickets
18:47:40 <notting> any news?
18:47:50 <nirik> nope.
18:48:03 <nirik> I can try and find someone to run things... but haven't yet.
18:48:03 <notting> ok
18:48:26 <notting> #topic Open Floor
18:48:29 <notting> i've got one item
18:48:45 <nirik> notting: there was also a late ticket if we want to look at it
18:48:46 <notting> #topic #609 Live CD's and Install Media's arch inconsistent
18:48:53 <notting> .fesco 609
18:48:53 <nirik> ah yes.
18:48:54 <zodbot> notting: #609 (F16Feature: Boost 1.47 - http://fedoraproject.org/wiki/Features/F16Boost147) – FESCo - https://fedorahosted.org/fesco/ticket/609
18:49:05 <notting> whoops
18:49:06 <nirik> thats a rel-eng ticket?
18:49:08 <notting> #undo
18:49:08 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x322a9d10>
18:49:10 <notting> .fesco 602
18:49:14 <zodbot> notting: #602 (meeting topic: Live CD's and Install Media's arch inconsistent) – FESCo - https://fedorahosted.org/fesco/ticket/602
18:49:38 <notting> fesco approved changing the live media. this got dropped for a while, moved to releng last week
18:49:41 <nirik> yeah, we wanted to do this a while back and it got dropped on the floor. ;(
18:50:04 <notting> the releng ticket was closed->wontfix
18:50:19 <notting> with a suggestion to re-evaluate for f18
18:50:51 * nirik is fine with doing this for f18, but perhaps we should have a ticket or other note to actually do it?
18:51:15 <notting> agreed. releng ticket? fesco ticket? Feature?
18:51:24 <drago01> can't we just call it x86
18:51:30 <drago01> makes more sense
18:51:33 <mjg59> We could paint it blue, too
18:51:34 <drago01> but well
18:51:42 <mjg59> But it's going to be called i386
18:51:46 <pjones> mjg59: or chromakey green?
18:52:02 <pjones> then whoever's looking at it can just pick what they want it to look like
18:52:11 <pjones> (We're talking about our rusty old bikeshed, right?)
18:52:32 <sgallagh> pjones: Don't they use magenta for chromakey nowadays?
18:52:34 <nirik> notting: not sure. rel-eng might make most sense, but how can we keep it from being forgotten there too.
18:52:46 <mjg59> We could reopen the ticket?
18:52:56 <pjones> sgallagh: paint available at b&h would suggest not.
18:53:05 * nirik wonders if by the time we remember to do this we just retire 32bit. ;)
18:53:13 <pjones> nirik: +1
18:53:18 <sgallagh> Proposal: Retire 32-bit for Fedora 18
18:53:26 * mitr notes that there are 5 fesco tickets that seem to have fell through the cracks; can we... not spend 10 minutes joking instead?
18:53:27 <nirik> ha
18:53:39 <sgallagh> (Thank you for giving me a segue to make that suggestion. I've been sitting on it for months)
18:53:45 <nirik> proposal: re-open releng ticket, target f18?
18:53:49 <mjg59> +1
18:53:53 <pjones> sure, +1
18:53:54 <mmaslano> nirik: +1
18:53:59 <sgallagh> I wasn't actually joking about the retirement
18:54:03 <sgallagh> But yes, +1 to nirik
18:54:18 <mmaslano> sgallagh: do you have numbers how many i686 were downloaded?
18:54:24 <mjg59> We probably can't retire 32-bit userspace
18:54:34 <mjg59> So while we could retire 32-bit install media, it doesn't seem like a huge win
18:54:37 <t8m> nirik, +1
18:54:44 <notting> -1 , for OLPC if nothing else
18:55:12 <mmaslano> notting: -1 on re-opening the ticket? ;-)
18:55:15 <notting> proposal: reopen the rel-eng ticket to target f18. check back later.
18:55:20 <notting> whoops
18:55:32 <notting> too many proposals in flight :)
18:55:35 <notting> +1
18:55:37 <sgallagh> OLPC can get its own secondary arch :)
18:55:39 <mjg59> Seems like 5 for that, then
18:55:47 <notting> #agreed reopen rel-eng ticket, target f-18
18:55:54 <mitr> rel-eng wants i686 instead of i386; I assume this is entirely up to rel-eng?  If so, +1 to filing for f18
18:56:12 <sgallagh> Seriously, though, is it such a bad idea to kill off a decade-old architecture at this point?
18:56:23 <mjg59> sgallagh: Yes
18:56:34 <mjg59> sgallagh: There's still plenty of 32-bit only binary code in use
18:56:34 <pjones> 3 decades old, and it seems to actually be used quite a bit.
18:56:38 * nirik thinks it's another discussion, feel free to bring it up next week with rationale?
18:56:47 <pjones> nirik: agreed.
18:56:50 <sgallagh> I'll do so
18:56:53 <notting> #topic Open Floor
18:57:09 <sgallagh> I meant decade-old since it was reasonably replaced by x86_64
18:57:10 <notting> there's a late-breaking fesco ticket on security policy & polkit configuration. want to discuss now, or move to next week?
18:57:12 <mjg59> There was somthing brought up on -devel re: security
18:57:18 <mjg59> Ah yeah that
18:57:36 <nirik> notting: I'd like to see the folks who made that decision weigh in on the ticket, then discuss next week after we have their input...
18:57:41 <nirik> do we know who that would be?
18:57:53 <vallor> hello, thanks for adding the item to the agenda -- but as always, please scrutinize what I'm saying, as I'm running a few degrees of fever (not joking)
18:58:11 <vallor> it can wait until next week, of course -- just a minor insecurity
18:58:23 * vallor is Scott Doty -- hello
18:58:43 <notting> ok
18:58:56 <notting> #agreed defer #816 to next week
18:58:58 <t8m> I'm actually not sure this is really FESCo bussiness at all - I do not think there is real conflict for FESCo to resolve here
18:59:13 <mitr> My POV: 1) Linux is still supposed to be a multi-user system; blindly removing authentication is unacceptable 2) having things easier (perhaps much easier) for "wheel" (and presumably "wheel" being used on single-user machines) is fine 3) improvements in UI, workflows etc. within the boundaries of 1) are always welcome, but not really a FESCo matter.
18:59:34 <t8m> mitr, +1
18:59:46 <vallor> t8m: it's a request for review of asking for passwords for routine sysadmin tasks
18:59:55 <vallor> the bug on -devel is just an example
19:00:09 <mitr> vallor: What are you asking FESCo to do exactly?
19:00:09 <vallor> sometimes, asking for a password makes the situation less secure
19:00:31 <vallor> t8m: ask the security SIG to review packages for this problem
19:00:34 <nirik> well, I think there's a conflict between what some people want and what maintainers have decided. perhaps we can mediate and come up with a solution, or perhaps some rationale would make us want to ask them to change.
19:00:39 <vallor> t8m: or whoever would do the review
19:00:40 <mitr> vallor: "root password could be captured, so let's just do it without authenticating as root" is a really bad tradeoff
19:01:00 * nirik notes there's not any kind of active security sig.
19:01:05 <notting> can we take this to the list, please?
19:01:16 <vallor> there is a security@ list, but that's more of an incident response
19:01:27 <sgallagh> nirik: There's a new security group at Red Hat run by Josh Bressers that is becoming more active
19:01:32 <sgallagh> I'd suggest starting there
19:01:45 <sgallagh> That's application security rather than CVE response
19:01:51 <nirik> sgallagh: sure... but thats not really fedora specific. I'd be happy for that group to weigh in tho
19:01:56 <mitr> proposal: close ticket, pending a specific proposal/question; let's discuss on fedora-devel for now
19:02:04 <sgallagh> mitr: +1
19:02:17 <sgallagh> nirik: Right, I meant to direct that at vallor
19:02:17 <vallor> the proposal was to review, not the ticket
19:02:19 <vallor> but okay
19:02:20 <nirik> proposal: leave ticket, gather more info and visit next week when we have had time to review it.
19:02:38 <notting> +1 to nirik . when i said 'take this to the list', i meant the current in-channel discussion :)
19:03:04 <mitr> nirik: what kind of info?
19:03:10 <vallor> mitr: meet me over in #fedora-qa pls? :)
19:03:32 <notting> anything else for open floor?
19:03:37 <nirik> mitr: rationale on how desktop folks set auth needed and which auth?
19:03:44 <mitr> #800, #05, #808, #811
19:03:55 <mitr> notting: ^^^
19:04:03 <sgallagh> #05?
19:04:04 <mitr> the second one is #805
19:04:06 <sgallagh> ah
19:04:51 <mitr> In particular #805 applies to F17 and seems to need a decision, the others can be deferred easier I think
19:04:59 <nirik> .fesco 805
19:05:01 <zodbot> nirik: #805 (Freeze break request for firewalld) – FESCo - https://fedorahosted.org/fesco/ticket/805
19:05:23 <notting> #topic #805 Freeze break request for firewalld
19:05:53 <notting> mitr: honestly 808 and 811 can likely be closed
19:05:56 <notting> but to this ticket...
19:06:25 <mmaslano> I discussed #805 with qa and rel-eng. It didnt have Test Day yet
19:06:43 <mitr> The ticket says March 15
19:07:20 <mmaslano> great
19:08:02 <notting> so, the options are:
19:08:09 <notting> - postpone any decision until after test day
19:08:21 <notting> - allow inclusion if successful test day
19:08:26 <notting> - not allow inclusion at all
19:08:26 <notting> ?
19:08:31 <mitr> The original ticket is +1-5 if I count correctly
19:08:50 <mitr> Do we have any idea how many users test alpha vs. beta?
19:09:01 <nirik> and the change being discussed is changing comps only?
19:09:17 <dgilmore> mitr: many more test beta,
19:09:21 <mitr> nirik: "only" changing the method the firewall is controlled
19:09:56 <mmaslano> but we agreed on changing default to firewalld
19:09:59 <mitr> or was that already enabled by default on alpha?
19:10:00 * nirik is -1 for f17 still... but f18 comps is open and ready for changes. ;)
19:10:05 <mmaslano> the change in comps "only" switch it on
19:11:00 <dgilmore> mitr: the issues is that the change was not made in comps prior to alpha
19:11:07 <dgilmore> mitr: so by default its not enabled
19:11:52 <notting> my suggestion would be - if we think we can allow it based on a successful test day, we should be able to say so now. if we don't think we will allow it regardless of test day status, we can also say that now and close out the ticket.
19:12:02 <mitr> notting: +1
19:12:33 <notting> so... proposal: allow switch of default firewall based on successful test day feedback
19:12:36 <nirik> if we say it's ok with test day, we should note what "successful" test day means. ;)
19:12:52 <mitr> Hm.  On one hand, I'm not too worried about a comps change, and if alpha is not tested very widely, a pre-beta-freeze test day should be enough; on the other hand, if a pre-beta-freeze test day is a good enough substitue for alpha, why do we require features testable by alpha?
19:13:46 <notting> i think going down the rathole of the existing feature process is unlikely to add to this discussion
19:14:18 <nirik> shall we vote? a) allow if test day goes well, b) ask to retarget for f18 ?
19:14:40 <mmaslano> a/ +1, but how we define well
19:14:47 <mitr> b)
19:14:49 <sgallagh> b: +1
19:14:54 <nirik> b) here as well.
19:15:12 <notting> a) for me.
19:15:22 <notting> mjg59: pjones: t8m: ?
19:15:25 <t8m> nirik, a) +1
19:15:46 <nirik> 3 vs 3
19:17:14 <pjones> sorry, got pulled away.  lemme read some.
19:17:58 <pjones> I'm +1 for "a"
19:18:10 <pjones> mjg59's currently talking in a conference call, so I bet he's not paying attention.
19:19:02 <notting> hooray, limbo.
19:19:30 <nirik> thats 7 votes and mjg59... who's the last no vote?
19:19:40 <notting> limburgher isn't here today.
19:19:52 <nirik> ah right.
19:20:03 <sgallagh> In the interim, I suppose we could ask them to schedule the test day anyway
19:20:12 <sgallagh> They can do a custom live spin with a comps change for that.
19:20:15 <notting> it's already scheduled. revisit next week?
19:20:25 <nirik> sure.
19:20:29 <mmaslano> could we vote in ticket?
19:20:32 <sgallagh> Whether we decide to let it ship or not, it makes sense to have the test day, I guess
19:20:42 <notting> #agreed defer decsion to next week, or to votes in ticket
19:20:59 <pjones> yeah, we could certainly still have a useful test day
19:21:02 <nirik> basically we need votes from limb or mjg59 to decide.
19:21:33 <notting> ok, back to...
19:21:38 <notting> #topic Open Floor
19:22:24 <notting> anything else?
19:22:45 <nirik> chair for next week?
19:22:52 <t8m> I can do it
19:23:09 <notting> #info t8m will chair next week's meeting
19:23:47 <notting> if there's nothing else, will close meeting in 2 mins
19:25:48 <notting> #endmeeting