fesco
LOGS
17:01:35 <notting> #startmeeting FESCO (2012-09-05)
17:01:35 <zodbot> Meeting started Wed Sep  5 17:01:35 2012 UTC.  The chair is notting. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:35 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:42 <notting> #meetingname fesco
17:01:42 <zodbot> The meeting name has been set to 'fesco'
17:01:48 <notting> #chair notting nirik mjg59 mmaslano t8m pjones mitr limburgher jwb
17:01:48 <zodbot> Current chairs: jwb limburgher mitr mjg59 mmaslano nirik notting pjones t8m
17:01:49 <notting> #topic init process
17:02:02 <mjg59> Hello
17:02:03 <notting> welcome to our new Wednesday reality.
17:02:05 <mmaslano> hi
17:02:07 <pjones> helo.
17:02:09 <nirik> Present.
17:02:10 * limburgher is here
17:02:26 <mitr> Hello
17:03:09 <t8m> hello
17:04:08 <notting> that leaves jwb...?
17:04:10 <jwb> here
17:04:12 <jwb> sorry
17:04:53 <mjg59> Non-standard reality
17:05:13 <notting> well, that's everyone
17:05:21 <notting> first, ye olde business
17:05:26 <notting> #topic #932 F18 Features - progress at Feature Freeze
17:05:26 <notting> .fesco 932
17:05:28 <zodbot> notting: #932 (F18 Features - progress at Feature Freeze) – FESCo - https://fedorahosted.org/fesco/ticket/932
17:05:55 <mjg59> Is MATE the only new one people are concerned about?
17:06:11 <nirik> http://fedoraproject.org/wiki/Releases/18/FeatureList
17:06:32 <nirik> Sugar is still at 0%
17:06:40 <mitr> mjg59: There's anaconda, but that's for later I suppose
17:06:47 <limburgher> right
17:07:29 <mjg59> MATE, at least, doesn't impact anything else, right?
17:07:37 <notting> other than the CWG, no.
17:07:42 <t8m> initial experience at 33% worries me
17:07:45 <mjg59> In that the contingency plan there is just "Don't talk about MATE"
17:07:53 <limburgher> mjg59: +1
17:07:56 <nirik> mjg59: nothing I know of.
17:08:02 <drago01_> t8m: that's not happening for f18 iirc
17:08:13 <mitr> t8m: I've seen some indication that it has been rescheduled to f19, no link I'm afraid
17:08:16 <notting> drago01_: if so, someone should explicitly say so.
17:08:17 <nirik> drago01_: it should get dropped from features then. ;)
17:08:32 <mjg59> What's the latest reasonable point that we can get a feature dropped from the docs?
17:08:42 <notting> for sugar... hm, haven't seen peter in a bit
17:09:00 <jwb> pbrobinson ?
17:09:04 <drago01_> <drago01_> mclasen: inital setup not happening for f18 right?
17:09:05 <drago01_> <mclasen> too late to get it all together
17:09:05 <drago01_> <drago01_> ok
17:09:08 <nirik> FWIW, various press stories have already carried "MATE to be in F18" type stories...
17:09:24 <jwb> nirik, i care not what the press has said about an unfinished release
17:09:26 <nirik> mjg59: good question though... at beta?
17:09:31 <pjones> nirik: press stories have been wrong before, they can deal with it?
17:09:33 <notting> jwb: yeah, sugar is/was his feature
17:09:42 <nirik> sure, just pointing it out...
17:09:45 <jwb> notting, pbrobinson is around.  he was posting about arm stuff today
17:09:54 <mitr> mjg59: translation deadline seems to be 10-01 (http://jreznik.fedorapeople.org/schedules/f-18/f-18-docs-and-trans-tasks.html)
17:09:56 <jwb> which might explain lack of time for sugar
17:10:36 <mitr> Or is that 9-19? ("POT coming"?)
17:10:41 <notting> mjg59: mitr: "Prepare GA Release Notes" is 09-25. we should probably have a deadline of 9-19, then
17:10:46 <mjg59> notting: Seems fair
17:11:11 <mjg59> notting: I'm still not optimistic, but there doesn't seem to be any reason to drop it when there's no practical harm in not doing so
17:11:19 <nirik> BTW: side tip... on http://fedoraproject.org/wiki/Releases/18/FeatureList you can click in the % complete heading to sort by that field in the table
17:11:27 <mjg59> nirik: Magic
17:11:38 <pjones> the "sort by convenient fiction" option
17:11:44 * nirik nods.
17:11:58 <notting> #info inital setup moved to F-19, feature page to be updated
17:12:02 <mitr> notting: I see different (later) dates on http://jreznik.fedorapeople.org/schedules/f-18/f-18-docs-and-trans-tasks.html , and this milestone is _following_ the "translate release notes" dates.
17:12:40 <mitr> Anyway, 9-19 works for me
17:12:47 <notting> hm, true. don't think being early hurts us
17:13:02 <mitr> Well... that depends on how much we slip for anaconda
17:13:09 <mitr> actually
17:13:10 <notting> proposal: do final feature checkpoint at 09-19 meeting
17:13:12 <t8m> isn't the Features 100% Complete Deadline the real relevaint point
17:13:15 <mjg59> Maybe we should set a date based on a milestone
17:13:21 <mjg59> Rather than an absolute
17:13:47 <notting> t8m: at that point, the relnotes are already handed off for translation
17:13:56 <t8m> at that point what isn't at 100% is automatically (well I suppose jreznik does it) dropped
17:13:56 <nirik> Beta Freeze--all features should be 100% complete. If necessary, the feature page adjusted to reflect everything completed (so as to reflect 100% completion).
17:14:22 <mitr> notting: so "features 100% complete" - 1 week?
17:14:40 <notting> sure
17:14:50 <t8m> notting, but the dropped feature just means dropped relnote point - it does not add anything new to translate
17:15:04 <notting> proposal: do final feature status review at '100% complete date' - 1 week. this currently means the 09-26 meeting
17:15:10 <mitr> +1
17:15:13 <t8m> notting, +1
17:15:24 <limburgher> +1
17:15:28 <nirik> +1 from me... given the ones in danger now are pretty isolated.
17:15:45 <mmaslano> +1
17:16:00 <jwb> +1
17:16:01 <mjg59> +1
17:16:01 <mitr> I suppose we don't expect regular reviews of the ticket in the mean time unless a specific concern is raised, or do we?
17:16:03 <nirik> if they were not, we would want more time for the revert or backout plans. ;)
17:16:56 <notting> mitr: i think for large concerns (a la anaconda) separate tickets work. for self-contianed things like m ate, not sure we need them
17:17:19 <mitr> exactly
17:17:54 <pjones> +1 to notting's proposal
17:18:17 <notting> #agreed FESCo will do final review of feature progress (including dropping of any features) one week before the "100% Feature Complete" date. this is currently scheduled for the 2012-09-26 meeting.
17:18:41 <notting> #topic #936 Clarify non-persistent service permission grant
17:18:41 <notting> .fesco 936
17:18:43 <zodbot> notting: #936 (Clarify non-persistent service permission grant) – FESCo - https://fedorahosted.org/fesco/ticket/936
17:19:09 <notting> is there anything more to do here?
17:19:23 <mjg59> Wait for kay or lennart to respond?
17:19:29 <mjg59> I don't think we can do anything more without that information
17:19:37 <t8m> well we should ratify the clarification if any is needed
17:19:37 * jreznik will provide updated ticket for fesco re-review week before...
17:19:43 <nirik> yeah, I'd love to know how better to work with presets. ;(
17:20:04 <t8m> the original topic is not really related to presets
17:20:22 <nirik> right, I think we agreed on the change/grant last time?
17:20:31 <mitr> 1) we agreed to modify the permission grant, but that didn't happen AFAICT
17:21:05 <mitr> 2) The presets feature seems to be missing the design/conventions for spins - which is another issue entirely
17:21:12 * nirik nods.
17:21:21 <notting> ok, so for the first one, it just needs done in the wiki after the meeting?
17:21:33 <pjones> yeah, think so
17:21:49 <notting> ok, i can do that today or tomorrow
17:21:58 <notting> #action notting to update the wiki with prior-agreed clarification
17:22:12 <notting> and we can table the preset issue for a different conversation?
17:22:22 <limburgher> nod
17:22:34 <t8m> yep
17:23:54 * gholms is here
17:23:57 <mitr> So do we retitle the ticket, or close it and duplicate, or delegate to fedora-spins@, or something else?
17:24:15 <nirik> personally, I would say close it.
17:24:23 <notting> close and potentially duplicate for preset issue
17:24:30 <nirik> and as soon as presets are documented/figured, start using that
17:25:07 <mitr> sure
17:25:21 <notting> ok
17:25:25 <t8m> fine
17:25:57 <notting> moving on to new business...
17:26:04 <notting> #topic #940 The tmp-on-tmpfs feature should be disabled by default
17:26:04 <notting> .fesco 940
17:26:08 <zodbot> notting: #940 (The tmp-on-tmpfs feature should be disabled by default) – FESCo - https://fedorahosted.org/fesco/ticket/940
17:26:22 <mitr> Would you mind taking anaconda first?  Both can take a long time, and anaconda is rather more important
17:26:38 <notting> sure
17:26:39 <notting> #undo
17:26:39 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x1884cdd0>
17:26:59 <notting> #topic #941 Support for installation from live images will not be ready on F18 Alpha schedule: what to do?
17:26:59 <notting> .fesco 941
17:27:02 <zodbot> notting: #941 (Support for installation from live images will not be ready on F18 Alpha schedule: what to do?) – FESCo - https://fedorahosted.org/fesco/ticket/941
17:27:19 <mjg59> Maybe we should do the "Revert to F17 Anaconda" one first?
17:27:19 <notting> note that ticket #944 is essentially a Proposal for resolution of this ticket. can be handled more or less together
17:27:25 <nirik> so, hoping for some more info from wwoods here.
17:27:28 <mjg59> Anyway, -1 to reversion.
17:27:33 <pjones> To be perfectly honest, I think the right thing to do here is to move live to be a beta blocker for this release only.
17:27:38 <gholms> .fesco 944
17:27:39 <mitr> Per http://fedoraproject.org/wiki/Features/NewInstallerUI#Contingency_Plan , reversion was never planned
17:27:39 <zodbot> gholms: #944 (Revert to old anaconda for F18) – FESCo - https://fedorahosted.org/fesco/ticket/944
17:27:43 <pjones> And I'm absolutely -1 to reversion.
17:27:59 <drago01> pjones: what about upgrades?
17:28:01 * limburgher is with pjones
17:28:11 <mjg59> Well, right. We can block everything on live support, or we can block the release on live support
17:28:13 <drago01> the roadmap says "f19 beta"
17:28:15 <jwb> afaik, live is working.  live install and upgrades are not, correct?
17:28:16 <mitr> Live is the least of our problems - upgrades being targeted to F19 beta are much worse
17:28:17 <mjg59> Blocking everything seems kind of pointless
17:28:33 <pjones> jwb: right
17:28:34 * nirik is also not thinking reverting is a good option here, however, I would like to know if we are going to slip more... because if we are, I would prefer to unfreeze, slip a block to allow everything to get implemented then go back on a schedule.
17:28:50 <pjones> the gigantic prank that has always been liveinst is one issue, upgrades are the other.
17:29:05 <pjones> nirik: I'm not at all convinced reverting is a /viable/ option, much less a good one
17:29:18 <t8m> nirik, +1
17:29:25 <notting> pjones: are you able to represent the anaconda collective here, or should we try and grab more people?
17:29:30 <nirik> I don't mind upgrades only being available for beta, but I want to know the code is actually written, or needs more time. I don't want us to one week slip along waiting for that.
17:29:36 <mitr> pjones: Naively speaking, the rest of the system should be compatible enough that reverting should be possible :)  [yeah, comps, secureboot, ...]
17:29:42 <jreznik> pjones: live is not a problem anymore
17:29:51 <nirik> pjones: right.
17:29:52 <pjones> jreznik: fair enough
17:30:00 <wwoods> what info do you want?
17:30:01 <jreznik> live + live installation
17:30:04 <jwb> mitr, that is fairly naive, yes
17:30:25 <t8m> wwoods, what is a realistic target for upgrades being supported?
17:30:30 <wwoods> a time?
17:30:33 <t8m> yep
17:30:36 <nirik> s/supported/written/
17:30:41 <pjones> mitr: right - a fairly naive approach that doesn't involve the ability to boot on new PCs on release day.
17:30:44 <notting> i am also -1 for 'reverting', fwiw. the way out is through, for better or worse.
17:30:47 <jreznik> it's now more about beta and what anaconda team can deliver - especially updates not to repeat alpha situation with live installer
17:31:35 <wwoods> Beta seems reasonable. Yum upgrades still work the same as they always do
17:32:05 <limburgher> wwoods:  <happydance>
17:32:06 <wwoods> was someone asking about live upgrades? because that's never existed AFAIK
17:32:08 <t8m> wwoods, that's good
17:32:12 <jreznik> wwoods: and for the dedicated upgrade tool? whatever it will be?
17:32:14 <drago01> wwoods: the question was about anaconda / preupgrade not yum
17:32:19 <wwoods> oh
17:32:19 <tflink> but we don't support yum upgrades
17:32:23 <wwoods> wait, what?
17:32:28 <pjones> tflink: but almost everybody uses them anyway
17:32:36 <wwoods> the funny thing about yum upgrades is that they work just about as well as regular upgrades
17:32:42 <limburgher> tflink:  Right, but we don't want to break them.
17:32:45 <notting> for certain overloaded variantions on the word 'support'
17:32:45 <pjones> except when they don't :/
17:32:45 <tflink> sure, but yum upgrade issues can't block release
17:32:55 <mjg59> "Can't"
17:33:00 <pjones> tflink: why not?
17:33:01 <limburgher> tflink: absolutely
17:33:07 <tflink> can't/don't
17:33:16 * nirik thinks this is going into the weeds.
17:33:18 <limburgher> pjones:  We'd have to officially support them.
17:33:18 <wwoods> the plan is to deliver a preupgrade-ish tool (which might just be an updated preupgrade and might be a wholly rewritten thing)
17:33:23 <notting> is a more precise statement "we try to ensure we have documented any release-specific caveats with yum upgrades"?
17:33:24 <nirik> can we avoid the yum upgrade discussion?
17:33:26 <limburgher> nirik: <nods>
17:33:30 <pjones> limburgher: that's fully circular.
17:33:38 <wwoods> upgrades will *not* use anaconda
17:33:42 <mitr> Based on adamw's suggestion, it seems reasonable that at the Alpha freeze ("all features testable") most of the code should actually _exist_ , so we should slip _alpha_ until that happens (without blocking on them working).
17:33:43 <limburgher> pjones:  Yes. :)
17:33:59 <wwoods> except insofar as they'll use the "anaconda-yum-plugins" package
17:34:03 <pjones> mitr: huh?  that's exactly not what he said
17:34:03 <mitr> That's the other extreme option - but I agree with adamw that a week-by-week slip is the worst option
17:34:13 <drago01> wwoods: so the code is yet to be written? or does it exit somewhere?
17:34:22 <mjg59> Could everyone please stop talking?
17:34:22 <pjones> what he said was that the criteria were designed to be applied in that situation.
17:34:37 <mjg59> And could wwoods please explain the implementation plan and rough timeline?
17:34:44 <mjg59> Because I think that that would be useful
17:34:46 * nirik nods to mjg59. waits.
17:35:20 <Viking-Ice> with regards to upgrades we should officially stop supporting it preupgrade or yum upgrade we in QA where never asked about that
17:35:23 <wwoods> well, I suppose I should start by asking when the Beta freeze is currently scheduled for
17:35:31 <Viking-Ice> we can never cover all upgrades bases
17:35:33 <mjg59> Viking-Ice: Please stop talking.
17:35:42 <nirik> 2012-10-02
17:35:56 <jreznik> wwoods: 2012-10-02
17:36:02 <pjones> 27 calendar days
17:36:03 <jreznik> #link http://fedoraproject.org/wiki/Releases/18/Schedule
17:36:06 <nirik> (but it seems likely since we have no rc yet, that we will slip another week)
17:36:14 <adamw> i'd call it about 50/50 atm, fwiw.
17:36:19 <jreznik> yep
17:36:37 <Viking-Ice> I call it two week slippage
17:36:51 <pjones> Can we stop taking bets on the schedule?
17:37:00 <mjg59> Viking-Ice: Again, please stop talking.
17:37:09 <wwoods> so the implementation, as I was saying
17:37:12 <wwoods> as was requested
17:37:43 <wwoods> possibly the existing preupgrade code, possibly a new codebase (since the existing preupgrade code is.. unpleasant to work with)
17:38:18 <Viking-Ice> mjg59, adamw does not represent the qa community so why are allowing him to call on this?
17:38:24 <wwoods> I have a working prototype of the depsolving / package downloading parts, at least. no GUI, but the existing GUI could probably be used as-is
17:38:44 <pjones> Viking-Ice: we're not.  we're not talking about QA right now at all.  We're listening to wwoods explain the implementation plan.  Please stop talking.
17:38:47 <wwoods> not that it'd be much harder to set up a slightly refreshed one
17:39:25 <wwoods> anyway: that's the frontend bit. same as preupgrade: fetch packages, kernel, and initrd.
17:39:47 <mjg59> wwoods: Does beta freeze seem like a reasonable timeframe for this, and if not would additional assistance be a help or a hinderance?
17:40:29 <nirik> wwoods: so for the dvd it would boot up and launch this app? or all upgrades would be run by the app in their normal boot?
17:40:33 <wwoods> the initrd will be a specially-built (dracut) image that contains something (either yum or plain RPM) to install the packages downloaded previously. much like anaconda used to do, but far simpler.
17:40:56 <wwoods> nirik: right. app would be included on the DVD; initrd would use the DVD as source for packages.
17:41:02 <wwoods> again, much like anaconda.
17:41:16 <wwoods> oh, wait, sorry
17:41:25 <wwoods> nirik: no - booting the install DVD is how you start an install
17:41:42 <mitr> wwoods: How does yum upgrade in dracut, long-term, cover difficult upgrade issues like we've had (FS upgrades, GRUB upgrades,  ...)?
17:41:45 <drago01> wwoods: what about dealing with stuff like usrmove (upgrade from f16) ?
17:41:59 <wwoods> to start an upgrade, you'd insert the media into your running system and run the preupgrade app (possibly from the media)
17:42:13 <limburgher> Isn't the usrmove dracut stuff still there?
17:42:16 <wwoods> drago01: usrmove is already handled in dracut
17:42:34 <pjones> drago01: mitr: the general case for those is "write a dracut module that does the transition"
17:42:37 <wwoods> right
17:42:51 <wwoods> in fact the plan for the dracut stuff is to add a 'system-upgrade' module
17:42:53 <nirik> ok, so if you boot dvd, presumeably there would be a 'Hey, if you meant to upgrade, reboot in your system and run the app on this dvd' or something.
17:42:57 <pjones> which is better than the old anaconda way simply because we get to make the feature owner do it :)
17:43:20 <drago01> wwoods, pjones : so can we expect to run the new app, reboot and have a working 18 setup (from an f16 system) ?
17:43:45 <wwoods> which adds two hooks: system-upgrade and post-system-upgrade
17:44:04 <mitr> drago01: "working 18 initrd", which sounds plausible
17:44:07 <pjones> drago01: I don't think anybody's talking about adding support for N-1 -> N+1 transitions.  At some point I assume people will not want to maintain dracut hooks indefinitely into the past.
17:44:53 <limburgher> pjones: <nods>
17:45:01 <wwoods> any migration-style tasks can be handled from either the pre-mount hook (for stuff that needs to mess with filesystems)
17:45:07 <drago01> pjones: we always supported upgrades from "last supported release" to "current release"
17:45:19 <wwoods> or system-upgrade (which runs before the system upgrade) or post-system-upgrade (same)
17:45:20 <drago01> i.e f16 goes eol -> update to f18
17:45:21 <pjones> drago01: you just asked f16->f18 though.  last supported release is f17->f18
17:45:30 <wwoods> err, not same - "obvious"
17:45:40 <t8m> pjones, ugh?
17:45:43 <pjones> ugh?
17:45:47 <pjones> ugh is not a question.
17:46:05 <t8m> f16 is supported at f18 release
17:46:21 <t8m> it's made unsupported only some time after that
17:46:22 <wwoods> nirik: if you insert the DVD there should be a "README.upgrade" and a "upgrade.desktop" or similar
17:46:26 <pjones> yes, and f16->f17 f17->f18 has been the supported upgrade path
17:46:27 <drago01> pjones: err ... I am talking about the "going to be eol shortly after release" release i.e f16 in case of f18
17:46:32 <wwoods> so you either a) run the app or b) double-click the icon
17:46:37 <wwoods> and Stuff Happens
17:46:46 <mmaslano> wwoods: the main question is how much time do you need for development of the rest of blockers
17:46:59 <wwoods> then you reboot, the upgrade happens (progress UI provided by plymouth), then you reboot again and you're in the upgraded system
17:47:01 <mitr> pjones: That would be a change... not necessarily impossible, but a change.
17:47:03 <mjg59> drago01: Where's it documented that we support n-1 → n+1?
17:47:12 <adamw> drago01: we don't actually 'support' direct upgrades across a two-version gap (as far as the criteria and validation tests go)
17:47:13 <pjones> mitr: uh, no?
17:47:23 <pjones> mitr: we've *never* supported a 2-version gap
17:47:25 <wwoods> mmaslano: are there blocker bugs filed on these things?
17:47:31 <drago01> mjg59, adamw : oh ok
17:47:39 <notting> and now we argue about the supported meaning of 'support' again
17:47:53 <mjg59> I mean sure it sometimes works but I don't think it's ever been a deliberate goal
17:47:57 <drago01> adamw: reason for that?
17:47:58 <pjones> notting: never supported a) in the code, b) in the package set, c) in the "providing help with" sense.
17:48:01 <wwoods> going back to mjg59's question: Beta freeze seems reasonable, assistance would be appreciated in a few areas
17:48:18 * nirik thought it was supported in the package set/advised.
17:48:20 <adamw> drago01: anaconda team never considered it a 'supported' case, the current criteria were drawn up with considerable input from anaconda team.
17:48:38 * gholms looks for the documentation that says we only support N -> N+1 upgrades
17:48:49 <adamw> wwoods: personally i'd kind of like a better guarantee than 'seems reasonable', though i know that was the question as phrased.
17:48:49 <drago01> wwoods: do you feel that we have enough time to test / fix bugs between beta - GA ?
17:49:02 <notting> wwoods: not to be too direct, but is this your main task in the interim, or are you otherwise engaged?
17:49:08 <drago01> adamw: ok fair enough
17:49:11 <mjg59> adamw: What decisions would you make differently depending on the answer?
17:49:33 <adamw> mjg59: basically, i'd like us to be very sure that upgrade functionality is written at the time we freeze beta.
17:49:36 <nirik> all I can find is the provides for renamed packages.
17:49:41 <nirik> "If there is no standard naming for a package or other long term naming compatibility requirements involved with the rename, the Provides should be assumed to be deprecated and short lived and removed in the distro release after the next one (ie. if introduced in FC-X, keep in all subsequent package revisions for distros FC-X and FC-(X+1), drop in FC-(X+2))"
17:49:58 <adamw> beta criterion #11 states "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria"
17:50:10 <adamw> there is no criterion which says anything about the 'last but one stable Fedora release'
17:50:10 <drago01> mjg59: check whether revert is more reasonable then waiting for new code to be written?
17:50:22 <mjg59> drago01: The people who know the code have said that reversion is not reasonable
17:50:29 <wwoods> it's possible you could meet that criteria via yum upgrade.
17:50:31 <mitr> nirik: right, that's what I based this on as well.
17:50:39 <jwb> they said it wasn't reasonable when they filed the feature
17:50:44 <jwb> we approved it anyway
17:50:45 <drago01> wwoods: yum is not "the installer"
17:50:54 <wwoods> drago01: "the installer" doesn't perform upgrades anymore
17:50:57 <adamw> wwoods: it says "either via preupgrade or by booting to the installer manually". it does not say anything about yum. we could of course declare yum to be a supported upgrade method and adjust the criterion, but that has never been the case.
17:50:58 <wwoods> so that's moot.
17:51:20 <pjones> drago01: for practical purposes we have to assume upgrade cases in the criteria that say "the installer" mean "the thing doing upgrades"
17:51:29 <jwb> circles are very round
17:51:33 <adamw> we'll have to reword the criterion slightly for the new design wwoods has described, but the intent is clear enough - our primary supported upgrade mechanisms must work at beta, from the previous release (not the last-but-one release).
17:51:40 <mjg59> Right
17:51:49 <mmaslano> wwoods: what kind of assistance do you need?
17:51:56 <mjg59> So is anyone proposing anything other than "This should work by beta, and we don't release beta until it works"?
17:52:06 <nirik> So, it sounds like there's not enough votes to consider revert, right, so what other proposals do we have for action? just wait, slip longer than a week?
17:52:11 <adamw> mjg59: so my position is that we should give wwoods enough time to be sure the code is written, before we start validating the beta release. i'm not proposing a reversion.
17:52:13 <notting> mjg59: i would prefer that question not be open-ended to quite that degree
17:52:19 <pjones> So wwoods' point stands - if we wanted to declare yum "the supported upgrade tool" for this release, it may be reasonable to do so from a technical perspective.
17:52:31 <pjones> (it seems like it would confuse the hell out of our users, though)
17:52:33 <mitr> mjg59: Is there an advantage to slipping alpha over slipping beta?
17:52:35 <drago01> nirik: mjg59's proposal? i.e "This should work by beta, and we don't release beta until it works"
17:52:41 <wwoods> mmaslano: 1) some exploratory work on yum/rpm - a) are whiteout/blacklist still needed, b) can the upgrade itself be done without yum
17:52:42 <adamw> mjg59: what i want to avoid is the case where we're frozen, and spinning sixteen TCs, but the upgrade code still isn't written. because then anaconda team is distracted fixing blockers, and everyone else is annoyed by the long freeze.
17:52:54 <mmaslano> wwoods: can fesco help?
17:53:00 <wwoods> 2) help with UI (re)design, since glade3 really does badly with GtkAssistant
17:53:23 <wwoods> 3) testing, of course, is always appreciated
17:53:26 <mjg59> notting: Sure, sorry, didn't mean that as a formal position
17:53:33 <nirik> drago01: yeah, but I am with adamw too. I don't think a long ass beta freeze is good.
17:53:53 <mjg59> mitr: Slipping alpha holds up *everything*, including code that can be adequately tested. I think just doing alpha now and heading to beta makes more sense.
17:53:56 <drago01> nirik: don't release does not imply "freeze"
17:54:06 <adamw> if wwoods is confident enough that it'll be done by beta freeze on current schedule, i'm happy with that. but if it's a 'cross fingers, god willin' and the creek don't rise' kind of confidence...i'd like to give him an extra week or two *before* we freeze, rather than winding up slipping multiple weeks under freeze conditions.
17:54:23 <mjg59> adamw: That sounds like something you could ask him just before freezing
17:54:24 <mitr> drago01: Can we iterate anaconda testing without freezing the rest?
17:54:34 <jreznik> adamw: +1
17:54:43 <pjones> mitr: with the exception of anaconda dependencies, yes?
17:54:45 <adamw> mjg59: that's true, we could make a call on it later.
17:54:49 <t8m> also we should slip the beta freeze dates early enough before the freeze if that will be needed
17:54:55 <mitr> pjones: So that's a "sort of no"?
17:55:08 <notting> also also, this implies that The New Upgrading Thingy is exempt from the string freeze
17:55:10 <Viking-Ice> adamw, +1
17:55:11 <mjg59> adamw: It's just that right now it sounds like we're trying to draw up a schedule for the schedule, which is right up there with conference calls for arranging conference calls
17:55:13 <pjones> mitr: no different than every other freeze ever, really
17:55:22 <mjg59> adamw: Let's just get on with doing useful things and make a call at the appropriate time
17:55:24 <adamw> mjg59: heh. fair point
17:55:44 <mitr> notting: https://fedoraproject.org/wiki/Anaconda/Task_Status says "translations: F-19 RC". - bad in itself, but perhaps not critical for us right now - or is it?
17:55:56 <adamw> mjg59: that works for me, throw it on the fesco schedule for the meeting before the beta freeze date.
17:56:02 <wwoods> depends on your definition of "done". GUI? remote (network) monitoring of upgrade process?
17:56:14 <notting> proposal: proceed with alpha as planned. new upgrade code needs to be working at beta per beta criteria. will revisit state of new code one week before beta freeze (this would be on 09-26, in current schedule)
17:56:24 <nirik> wwoods: the list of stuff in the ticket (gathered from qa requirements)
17:56:25 <mjg59> notting: +1
17:56:32 * gholms rings the 30 minute bell
17:56:44 <t8m> notting, +1
17:57:00 <pjones> notting: +1
17:57:03 <mmaslano> +1
17:57:07 <nirik> I guess I'm +1...
17:57:14 <jwb> +1
17:57:24 <notting> #info please see meeting logs for info on new upgrading tool
17:57:28 <mitr> +1, I guess
17:57:36 <adamw> nirik: i think everything else listed in the ticket looks like it's pretty much under control, from wwoods and clumens' responses i was only worried about upgrades.
17:57:39 <nirik> wwoods: is there any document on this setup? wiki?
17:58:00 <nirik> adamw: yeah. live install was the fear, but thats looking much more... implemented.
17:58:03 <drago01> can we update the roadmap as well?
17:58:24 <jwb> you said roadmap.  -3 points
17:58:40 <wwoods> nirik: I've got a set of asciidoc notes. I could put them somewhere public?
17:58:45 <limburgher> +1
17:58:49 <drago01> jwb: s/roadmap/task_status/
17:58:59 <notting> #agreed FESCo agrees to proceed with alpha as planned in anaconda. The new upgrade code needs to be working at beta freeze per beta criteria. FESCo will revisit the state of this code one week before Beta Freeze; this review is currently scheduled for 2012-09-26.
17:59:07 <wwoods> but more docs/meetings means less time for actually implementing the damn thing
17:59:10 <nirik> wwoods: sure, would be cool. Perhaps a call for assistance in parts that could use more help would be great too... (of course the danger is the wrong kind of help)
17:59:43 <jreznik> wwoods: I can help you with that docs side...
17:59:45 <notting> ready to move on?
17:59:51 <nirik> so we close the ticket? or leave open for beta?
17:59:55 * nirik votes close
17:59:57 <jwb> close
18:00:05 <notting> i'll open a new one for upgrade code review
18:00:36 <nirik> +1
18:00:44 <t8m> fine
18:01:07 <mmaslano> +1
18:01:16 <notting> ok
18:01:18 <notting> #topic #944 Revert to old anaconda for F18
18:01:19 <notting> .fesco 944
18:01:21 <zodbot> notting: #944 (Revert to old anaconda for F18) – FESCo - https://fedorahosted.org/fesco/ticket/944
18:01:29 <mjg59> So just close this one?
18:01:30 <notting> #agreed noting for reference that per decision on #941, this is rejected.
18:01:31 <limburgher> YEah
18:01:39 <pjones> yes, this one is pure insanity.
18:02:03 <notting> back to other tickets...
18:02:09 <notting> #topic #940 The tmp-on-tmpfs feature should be disabled by default
18:02:09 <notting> .fesco 940
18:02:14 <zodbot> notting: #940 (The tmp-on-tmpfs feature should be disabled by default) – FESCo - https://fedorahosted.org/fesco/ticket/940
18:02:57 <mjg59> I really wish we wouldn't end up with people deciding that because the feature process made a decision they don't like we should go through it again
18:02:57 * nirik is sad that the ticket became a redo of the devel thread.
18:03:23 <t8m> I think the arguments for revert are pretty clear.
18:03:27 <mjg59> Either there's a point to process or there isn't
18:03:29 <notting> there is a little bit of new info, in that debian has decided to revert the feature
18:03:33 <t8m> And I propose we revert it.
18:03:43 <mjg59> Has anyone changed their mind?
18:04:09 <pjones> notting: also sandeen has a fairly valid point
18:04:10 <limburgher> From our initial vote on the feature you mean?
18:04:15 <mjg59> limburgher: Yeah
18:04:35 <limburgher> mjg59:  I've gone from +1 for default to +-0.  really on the fence.
18:04:37 <mitr> We also have our data on progress... past experience shows that we _don't_ have enough people interested in making this work well.  The tracking bug contains only 1 item (which doesn't seem to be close to being resolved), at least 2 other were mentioned in the threads (sort, brasero) and haven't been fixed, debian threads mention many more packages
18:04:43 <nirik> anyhow, this is something where I think it's useful for most folks, we need to make it clear how to disable or that it's there for the people who hate it. If we can automate that detection somehow, that might be great.
18:04:48 <pjones> It's not clear that either of those is a particularly compelling reason for reversion, though.
18:05:04 <mjg59> Also, do we have a link to debian choosing to revert it?
18:05:09 <mitr> nirik: It's not at all clear that it is useful for most folks - I haven't seen any data
18:05:09 <mjg59> Because it's not my recollection of that thread
18:05:10 <pjones> nirik: how to disable it only came up about thirty thousand times in the thread.
18:05:13 <mjg59> But then, Debian
18:05:17 <nirik> pjones: I know.
18:05:17 <t8m> Proposal: The tmp-on-tmpfs feature should be disabled by default
18:05:33 <notting> mjg59: i've read it somewhere. lemme find it.
18:05:35 <mitr> mjg59: http://packages.debian.org/changelogs/pool/main/s/sysvinit/current/changelog#version2.88dsf-26 , http://lists.debian.org/debian-devel/2012/06/msg00311.html
18:05:46 <mmaslano> rjones ask in ticket to copy his statements about it
18:05:48 <pjones> t8m: yes, we know what your proposal is.  Let's discuss it for a bit.
18:05:49 <mmaslano> see https://fedorahosted.org/fesco/ticket/940#comment:13
18:06:04 <mjg59> mitr: Serge is just some guy
18:06:20 <mmaslano> I guess virtualization case is also good reason
18:06:22 <nirik> mitr: yeah, thats the changelog... it's unclear the discussion. They do mention 4 bugs...
18:06:27 <mitr> nirik: It actually seems to me that in the _typical_ case (/tmp used fairly infrequently, for small files), the change will not be noticeable at all.  And the case where it would be noticeable (large files) is precisely the case where we are likely to uncover bugs
18:06:28 <mjg59> But let me look at the changelog
18:06:54 <mitr> mjg59: The 4 referenced bugs don't end with any summary statement AFAICT - I haven't read them all
18:07:30 <mjg59> Ok, it does seem that the decision in Debian was to change it back
18:07:45 <mjg59> Most of the bugs are handwaving, but there is one example of specific breakage
18:07:45 <pjones> mjg59: are there specific reasons?
18:08:02 <mjg59> Which is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665635
18:08:21 <jwb> if we don't enable it by default, that basically leaves /tmp as it exists today.  so we'd be rejecting the feature, correct?
18:08:32 <t8m> jwb, correct
18:08:38 <nirik> mjg59: thats a mc bug? no rationale I see there.
18:08:53 <pjones> sounds like the answer is to fix mc
18:08:58 <gholms> pjones: IIRC, there was little evidence that putting /tmp, specifically, on tmpfs fixed real problems.
18:08:58 <t8m> nope
18:09:15 <mjg59> nirik: mc performs archive navigation by unpacking them in /tmp
18:09:21 <notting> jwb: we would be reverting /tmp-on-tmpfs as a default; enabling it would be a systemctl cmd away
18:09:35 <mitr> pjones: So we know that there are bugs in the feature, and we don't have people interested/motivated to fix them, why should we like that feature?
18:09:50 <pjones> gholms: well, it obviously fixes at least one real problem - you can't hardlink in to /tmp any more, which has been a security problem for at least the last 20 years.
18:09:57 <t8m> pjones, the main rationale is that if applications want to use memory they should use memory, if they think their temporary data should be placed in files it should not occupy memory apart from the caching
18:09:58 <mjg59> Well, arguable whether they're bugs in the feature or false assumptions in the apps
18:10:08 <jwb> notting, ...  that is not a Feature
18:10:09 <mitr> pjones: On a default install, people can just as well hardlink to /home
18:10:18 <t8m> mjg59, false assumptions in the feature
18:10:28 <mjg59> t8m: mc is a Linux-only application?
18:10:35 <pjones> mitr: right but it's hard to make a hardlink race exploitable if you can only do it in directories you own in the first place.
18:10:43 <t8m> mjg59, how is that relevant?
18:10:49 <mitr> mjg59: The assumptions were only declared false by the feature.
18:10:51 <pjones> mitr: nevertheless we're way into the weeds
18:10:52 <gholms> pjones: I'm just re-iterating what the debian people found.
18:10:59 <notting> mitr: have a link to the tracker?
18:11:01 <mjg59> t8m: Because /tmp is tmpfs on some non-Linux systems
18:11:12 <mitr> notting: https://bugzilla.redhat.com/show_bug.cgi?id=826015
18:11:17 <mjg59> So if the application isn't Linux-specific then it's a false assumption in the application
18:11:39 <mitr> notting: IMHO notable are the known cases that aren't there
18:11:40 <t8m> mjg59, that some other systems are buggy doesn't mean mc is
18:12:01 <mitr> t8m: Well, there really isn't any 100% portable place
18:12:07 <mjg59> t8m: If you're going to declare that tmpfs on /tmp is a bug then there's really no point in discussing it
18:12:07 <drago01> t8m: solaris has been using tmpfs for like 10 years?
18:12:15 <t8m> mitr, sure
18:12:16 <notting> mitr: why are they not there? is no one who is intereested filing them?
18:12:22 <mjg59> Meanwhile, it's also a reality
18:12:26 <t8m> mjg59, yep, it is a bug
18:12:27 <drago01> t8m: err 20 years
18:12:47 <mjg59> Anyway, it's unimportant
18:12:50 <t8m> reality is often buggy
18:13:01 <mitr> notting: seems so.  At one time I asked the feature owners to go through the Fedora discussions - I didn't have time, and they are of course not obligated to do something just because I asked
18:13:03 <nirik> perhaps we should just vote again if no one is changing their minds?
18:13:08 <mjg59> The question is whether this change is going to cause problems for our users that outweigh the benefits
18:13:11 <mmaslano> I don't think people are now scanning and streaming video, so no bug reports. Also it won't be easy to find out that tmpfs is the problem
18:13:43 <mjg59> So far we've seen approximately no complaints from people who are actually having problems, and a lot of complaining from people who don't seem to be testing it
18:13:45 <drago01> can't we disable it while running inside a vm?
18:13:50 <drago01> like we do for readahead?
18:13:55 <drago01> that should solve the vm issue
18:14:02 <mjg59> drago01: That's certainly a thing that could be done
18:14:03 <nirik> drago01: if we can find a way to determine that, sure.
18:14:09 <mitr> drago01: That doubles the testing matrix
18:14:19 <pjones> drago01: let's not talk about that without first answering the question of if there are real virt workloads that depend on putting a lot of junk in /tmp
18:14:21 <mitr> nirik: systemd already determines that kind of things I think
18:14:35 <pjones> drago01: since right now "running mc" doesn't seem to be a giant virt target market
18:14:44 <drago01> pjones: nod
18:14:52 <t8m> pjones, have you ever heard about mysql?
18:14:54 <adamw> mitr: it'd be trivial to do, yeah. systemd can stop a service running if it's in a virt environment.
18:14:55 <mitr> pjones: "running mc" is sort of a national religion about here
18:15:09 <pjones> mitr: I had noticed that.
18:15:10 <mjg59> In the absence of bugs, there are no problems
18:15:15 <notting> things noted in comments, if not in fedora bugs: mc, sort, firefox + plugins
18:15:17 <mjg59> If people have problems, file bugs
18:15:32 <pjones> t8m: no, tell me more about this "mysql" bug in bugzilla filed as a blocker against this?
18:15:33 <t8m> also mysql
18:15:48 <t8m> pjones, so if bug is not in a bugzilla it does not exist?
18:15:52 <drago01> t8m: what's with mysql?
18:15:52 <t8m> fine
18:15:58 <t8m> http://lists.debian.org/debian-devel/2012/06/msg00311.html
18:16:00 <pjones> YES FOR THE LOVE OF GOD IF YOU DON'T FILE SOMETHING IT ISN'T DATA
18:16:05 <mitr> mjg59: "I know there are bugs but la la la procedure"?
18:16:07 <mjg59> But this entire mythical "I can conceive of a problem, therefore this problem exists" argument is pointless
18:16:16 <mjg59> File the bugs
18:16:16 <t8m> " MySQL often uses /tmp,
18:16:17 <t8m> for example mysqldump does, and files there can be huge too."
18:16:31 <mitr> pjones: OTOH if the feature owners dismiss discussion as "noise"...
18:16:34 <drago01> t8m: mysqldump uses whatever dir you point it to ...
18:16:39 <mjg59> mitr: Discussion without data *is* noise
18:17:02 <pjones> mitr: they'd be completely right to do so if people keep on insisting that there are problems that they just haven't bothered to file.
18:17:03 <mjg59> Are there bugs? If so, why are they not in bugzilla? If not, why are we talking about this?
18:17:43 <adamw> could the general state of f18 have something to do with it?
18:17:55 <mmaslano> adamw:  ;-)
18:17:55 <mjg59> adamw: Well, sure
18:17:57 <mitr> mjg59: This does go both ways - if there are relevant performance improvements, where is the data?
18:18:00 <adamw> i mean, to file a bug in /tmp-on-tmpfs you need to at least get an f18 system with tmp-on-tmpfs installed and running well enough to confirm it...
18:18:09 <mjg59> mitr: Yeah, I'd like to see that too
18:18:13 <adamw> which hasn't been the easiest thing in the world to do, so far. and we don't officially even _have_ an alpha.
18:18:25 * nirik nods.
18:18:30 <misc> adamw: people can run that on f17 too
18:18:34 <adamw> true.
18:18:34 <mjg59> mitr: But reverting a feature because evidence we didn't ask for wasn't presented when we originally approved it?
18:18:36 <drago01> adamw: then it is too early to declare it broken
18:18:46 <t8m> This is going nowhere, can't we just vote on the revert?
18:18:50 <nirik> /tmp on tmpfs has been working just fine here. I've not run into a problem, so I have not filed any bugs </anecdote>
18:18:53 <limburgher> adamw: Which means that reverting is premature, now, but might not be later.
18:18:58 <mitr> mjg59: *shrug* I did complain about the lack of benefit back then.
18:19:02 <drago01> nirik: same here
18:19:08 <mjg59> If the problem is that there's nobody testing, we should wait until people are testing
18:19:29 <mjg59> So let's just defer this until some time post-Alpha
18:19:44 <mjg59> And maybe explicitly mention it in the Alpha announcement
18:19:48 <mitr> mjg59: If the problem is that people don't care about finding the corner cases which used to work fine, does that automatically imply that we are fine with breaking the corner cases?
18:19:56 <t8m> mitr, +1
18:20:08 <t8m> mitr, some definitely are as you can see
18:20:11 <mjg59> Tell people that this change has been made and ask them to explicitly test use cases they have which may be impacted
18:20:28 <mjg59> mitr: If nobody's in the corners, the corner doesn't matter
18:20:35 <notting> mjg59: i suspect the problem is the cases that people don't know would be impacted
18:20:46 <mitr> mjg59: Given the lack of benefit, it seems much simpler to me to just revert and be happy that nothing got broken by this
18:20:46 <mjg59> notting: Well sure, but that's true of most features
18:20:52 <adamw> notting: the unknown unknowns? :)
18:20:55 <t8m> mitr, +1
18:21:14 <mitr> mjg59: I can accept the unknowns, but there needs to be something gained by them.
18:21:55 <mjg59> Anyway, I'm not going to vote to revert a feature with no evidence of it causing problems
18:22:11 <limburgher> I think it's just too soon to know.
18:22:20 <notting> /tmp-on-tmpfs is a requirement of certain use cases. given that, problems should be discovered and fixed anyway as long as they are relevant for those cases.
18:22:24 <mjg59> But nor do I want to say "This isn't going to cause problems", and so I'd rather revisit it when testing has actually happened
18:22:30 <limburgher> If we have a pile of bugs at Beta, revert.
18:22:31 <mitr> notting: which use cases are these?
18:22:35 <notting> mitr: readonly root.
18:22:38 <pjones> I'd also like to see real workload-performance data, but I'd be against reverting at this time unless we see major issues.  We can revert later if there are major bugs.
18:22:47 <mitr> notting: Can't it just place /tmp on the stateful device?
18:22:48 <limburgher> pjones:nods
18:22:56 <t8m> notting, nope
18:23:46 <notting> t8m: the default for r/o root has been tmp on tmpfs since it was added six and half years ago
18:23:54 <mjg59> Proposal: Defer discussion of this until people have actually tested it
18:24:09 <jwb> mjg59, +1
18:24:26 <t8m> mjg59, -1
18:24:33 <nirik> +1
18:25:08 <limburgher> +1
18:25:30 <mmaslano> I don't think we can do anything better now +1
18:25:35 <t8m> notting, perhaps you do r/o root only on systems where you have heaps of ram, perhaps you don't run there things that need big tmp space etc.
18:26:10 <pjones> mjg59: +1
18:26:35 <pjones> t8m: perhaps I can find the loch ness monster in bugzilla as well - hrm, no, I can't.
18:26:38 <mitr> I can't see that the situation would noticeably shift from the "unknkown unknowns" situation by deferring, +-0
18:27:00 <notting> t8m: i'm telling you how the feature we've had has been implemented by default ever since it was added. if you really want to argue that the default case supported by the r/o root feature shouldn't be supported... <mdwm>
18:27:03 <mitr> pjones: The people runinng into problems with tmpfs do actually exist,
18:27:31 <nirik> if so, they should be able to file bugs with their use cases and where it breaks... no?
18:27:35 <mitr> Just because they are rare doesn't really mean the software isn't broken.
18:27:49 * nirik wishes we could move on?
18:27:49 <pjones> mitr: and if they're not filing bugs and they're not fixing the problems they find then they're not participating in the process
18:28:00 <notting> in any case, i'm +1 to deferring as well
18:28:13 <mitr> pjones: *shrug* how many million users do we have?
18:28:19 <t8m> pjones, they are fixing the problems - just disabling the tmp on tmpfs
18:28:31 <pjones> t8m: that's not fixing the problems at all.  that's ignoring them.
18:28:38 <mjg59> I fix all my problems by just rewriting the software myself and not telling anyone
18:28:44 <t8m> pjones, nope, the problem is in the feature, not in the apps
18:28:47 <notting> #agreed Discussion of this deferred until some point after alpha where this has had a chance to be more widely tested (+:7, -1:1, 0:1)
18:29:02 <pjones> t8m: that's a nice fiction you're maintaining.  must be fun.
18:29:14 <notting> #topic #943 Yum repository format and its effects on Fedora infrastructure
18:29:14 <notting> .fesco 943
18:29:15 <mjg59> t8m: Dude you've previously declared that /tmp-on-tmpfs, something that's been part of UNIX for at least *20* *years*, is a bug
18:29:15 <zodbot> notting: #943 (Yum repository format and its effects on Fedora infrastructure) – FESCo - https://fedorahosted.org/fesco/ticket/943
18:29:22 <t8m> pjones, I can say the same about you as well
18:29:50 <mjg59> t8m: It does seem that you're veering into unreasonable positions here
18:30:00 <t8m> mjg59, not at all
18:30:00 <jwb> MOVE THE HELL ON
18:30:01 <mitr> mjg59: Sorry, Solaris counts very little.  (Note that we didn't "need" to be that compatible back in 1992 either)
18:30:04 <pjones> hey look, we've moved on.
18:30:29 <mjg59> I read this and got confused
18:30:32 <mjg59> What are we being asked to do?
18:30:36 <nirik> so, I propose we close this and ask them to come up with a consensus/concrete proposal for changes with stakeholders.
18:30:40 <notting> i am not convinced that this (#943) is something that fesco needs to weigh in on, but i'm willing to take other opinions
18:30:43 <jwb> nirik, yes
18:30:46 <mitr> mjg59: lead the implementation of the change, it seems.
18:30:47 <mjg59> nirik: Yeah, that seems about right
18:30:49 <t8m> nirik, +1
18:30:56 <mjg59> We can't force the yum people to do anything
18:31:02 <pjones> we're being asked to agree to do something without a clear proposal for what that something would be.
18:31:19 <limburgher> nirik +1
18:31:23 <notting> mjg59: well, we *can* by magic admin clickety-clack powers, but that's not something we would or should do
18:31:25 <pjones> nirik: +1
18:31:34 * notting agrees with nirik as well, +1
18:31:39 <mjg59> And while I agree that I'd love an implementation that came with free beer, I have no idea what the tradeoffs for that free beer are
18:31:43 <mjg59> So +1
18:32:01 <mitr> BTW, a significant part of the proposal seems to depend on keeping more than one version of a RPM in rawhide.
18:32:03 <mitr> Is that realistic to start with?
18:32:06 <nirik> yeah, it's not clear to me that this idea is all that great. I think it would help some cases, but it would actually be MORE work on infra side.
18:32:28 <nirik> mitr: mash changes... notting ?
18:32:40 <nirik> (well, and mirror space and compose time and ...)
18:32:41 <notting> mitr: that's something that has been generally rejected due to size of the metadata required, and size of the mirror required
18:32:57 <notting> mitr: but technically, it's pretty simple to fix.
18:33:23 <mitr> notting: But if we can't increase the mirror size, we won't be able to deliver the primary promised benefit (rollback) either....
18:33:32 <nirik> personally I'd be for it if we could find enough buy in from mirrors/keep yum usable. I'd also be for it in updates for stable releases too (ditto)
18:33:51 <notting> nirik: mash already lets you include all versions in a tag. we don't set that, though
18:33:51 <mitr> I'm +1 to the proposal to close, but if we knew that it can't happen anyway, it would be good to note that in the ticket as well.
18:34:06 <nirik> notting: yeah, so updates would probibly be more work right?
18:34:32 <notting> nirik: it's flipping one config option - the problems are the consequences of doing that
18:35:20 <nirik> ok. so really we are back to: get buyin from stakeholders. ;)
18:35:41 <notting> jwb, mmaslano - any disagreement?
18:35:48 <mmaslano> no
18:35:58 <jwb> no
18:36:46 <notting> #agreed close the ticket - Please come up with a consensus/concrete proposal for changes with stakeholders and re-open when necessary.
18:36:57 <notting> #topic Open Floor
18:37:28 <mjg59> I'm probably going to be out next week
18:37:34 <nirik> I had one item I wanted to mention...
18:38:23 <notting> go for it
18:38:32 <nirik> So, we had a few packages git repos where maintainers accidentially checked in binary blobs a while back. I now have a script to detect them and remove them and can have a hook that rejects them. So, that leaves policy around this:
18:38:54 <nirik> 1) should we scan everything and remove blobs? or only remove them when asked by owners? or never remove them.
18:39:06 <mjg59> What are you defining as a binary blob?
18:39:08 <nirik> 2) should we have the hook to reject them in place? or just remove when asked?
18:39:38 <mitr> 1) if removing blobs mean rewriting history, I'd rather not - koji depends on it, among other things
18:40:22 <nirik> mjg59: by git mime type.
18:40:27 <nirik> mitr: yes, it would.
18:40:33 <mitr> That also would suggest that if we prohibit the blobs, 2) should have a hook
18:40:49 <nirik> http://git.fedorahosted.org/cgit/git-handle-binary-blobs.git/tree/
18:41:06 <notting> #2, i'd say 'yes'.
18:41:10 <mitr> Now, do we care about binary in general?  Or it's mainly because they are large?
18:41:14 <drago01> nirik: would that blacklist firmware files as well?
18:41:19 <pjones> nirik: hrm, removing them automatically isn't that great.  if we do #2 we definitely need an acl/exception list
18:41:37 <pjones> oh, nevermind.  you can just fedpkg upload them instead.
18:41:41 <nirik> drago01: I would think so yes, but shouldn't those be in lookaside?
18:41:50 <nirik> mitr: yeah, the size.
18:41:56 <nirik> fedpkg clone mono
18:41:57 <drago01> nirik: oh yeah nm
18:42:00 <nirik> and weep. :)
18:42:19 <nirik> (for several reasons, but it has 2 mono tar.bz2's in there, so it's like 100+MB)
18:42:21 <pjones> right.  this is all about the location of them, not the idea of them.
18:42:32 <mjg59> Yeah, if expectation is that they be in looksaide rather than git, that seems fine
18:42:44 <mjg59> But I think I'd lean towards reject rather than remove
18:42:55 <mjg59> Otherwise we break a bunch of packages
18:43:10 <limburgher> mjg59: +1
18:43:23 <pjones> yeah
18:43:26 <mitr> Are there any small binaries that would be better in git?  GPG signatures perhaps?  (AFAICT it shouldn't matter much either way... but if we can avoid breaking existing workflows)
18:43:27 <nirik> it just makes contributing harder on packages with them, due to clone time/bw
18:43:31 <limburgher> Maybe file "hey, move this to lookaside" bugs.
18:43:38 <limburgher> Image files?
18:43:41 <limburgher> Icons?
18:43:48 <pjones> the problem is that it's hard to move things from the past in git
18:43:57 <nirik> well, once they are in git they are in forever unless you re-write history
18:44:04 <pjones> it's still there in terms of checkout even once they've been git rm'd
18:44:07 <nirik> which changes hashes for builds, etc.
18:44:35 <mitr> Can we perhaps start on agreeing that rewriting history is undesirable?
18:44:42 <mitr> s/on/by/
18:44:47 <nirik> we could possibly also rewrite koji db too.
18:44:52 <nirik> to point to the new hash.
18:44:58 <nirik> but it gets messy
18:45:34 <notting> yeah, that seems like overkill
18:45:40 <pjones> yeah, I really don't think that's tenable
18:45:52 <notting> proposal: do not remove old blobs, but add hook to reject them on checkin/push
18:46:18 <t8m> at some point in future we will have to handle the ever growing git repositories of some big packages anyway
18:46:21 <mitr> I can be +1 to that.  I would like to see blobs <10k accepted, but I'm not willing to do the work, so...
18:46:50 <limburgher> notting +1
18:46:56 <pjones> notting: +1
18:47:07 <jwb> +1
18:47:16 <nirik> t8m: we can just rename ourselves when we get to Fedora 20! :)
18:47:32 <mmaslano> +1
18:47:36 * nirik is fine with that plan.
18:47:37 <t8m> notting, +1 why not although using lookaside for really small binaries might be overkill
18:47:46 <t8m> nirik, yep
18:47:56 <nirik> so, I'll test this hook and get packager feedback on it before we deploy it.
18:48:22 <nirik> thanks
18:48:25 <notting> #agreed nirik will work on hook to reject new binaries added to git (as opppoesd to the lookaside)
18:49:57 <notting> anything else for open floor?
18:50:08 * nirik has nothing
18:50:10 <limburgher> not here
18:50:24 <notting> #topic Next week's chair
18:50:27 <notting> ... volunteers?
18:51:00 * nirik hasn't in a while.
18:51:01 <nirik> I can
18:51:12 <notting> #info nirik to chair 2012-09-12 meeting
18:51:21 <notting> #topic Open Floor
18:51:27 <limburgher> thanks to notting for chairing this week.
18:52:01 <notting> if there's nothing else for open floor, i'll close the meeting in 2 minutes
18:53:10 <gholms> Who should open the ticket about coming up with a spin preset standard?
18:53:26 <notting> i can
18:53:45 <gholms> Ok.  Thanks.
18:54:06 <notting> #endmeeting