18:02:05 <t8m> #startmeeting FESCO (2012-03-12)
18:02:05 <zodbot> Meeting started Mon Mar 12 18:02:05 2012 UTC.  The chair is t8m. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:02:06 <nirik> ah, got it
18:02:14 <t8m> #meetingname fesco
18:02:14 <zodbot> The meeting name has been set to 'fesco'
18:02:23 <pjones> loads of fun for all involved.
18:02:25 <t8m> #chair notting nirik mjg59 mmaslano t8m pjones sgallagh mitr limburgher
18:02:25 <zodbot> Current chairs: limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m
18:02:39 <t8m> #topic init process
18:02:46 <t8m> Hi all
18:02:55 <mjg59> Afternoon
18:03:03 * limburgher here
18:03:03 * nirik waves
18:03:05 <mitr> Hello
18:03:15 * notting is here
18:03:47 <t8m> mmaslano is I think away today
18:04:12 <t8m> and sgallagh is _afk
18:04:20 <t8m> sgallagh_afk, around?
18:04:37 <mitr> t8m: He sad on #fedora-devel he won't be able to make it
18:04:46 <t8m> OK, then we can start
18:04:53 <t8m> with followups
18:05:03 <t8m> #topic #699 Proposal to remove the package "tzdata" from Critical Path
18:05:04 <t8m> .fesco 699
18:05:05 <zodbot> t8m: #699 (Proposal to remove the package "tzdata" from Critical Path) – FESCo - https://fedorahosted.org/fesco/ticket/699
18:05:44 <t8m> So do we want to exempt tzdata from all testing?
18:05:46 <notting> so, the request is to have a special case in bodhi that exempts it from any and all checking?
18:05:47 <nirik> I'm fine with not having it in the critpath.
18:05:56 <nirik> I am NOT fine with allowing it to go direct to stable. ;)
18:06:15 <t8m> notting, seems so
18:06:15 <nirik> notting: allowing it to push to stable directly. (which no other package can do currently)
18:06:30 <limburgher> That's a bit like having a surge protector on everything but your dialysis machine.
18:06:44 <limburgher> How about treating it like prerelease updates?
18:07:21 <t8m> I also agree that to allow direct push to stable just for tzdata is not desirable.
18:07:44 <mitr> I imagine it should be possible to automate all relevant tzdata tests, then a direct push might be considered
18:07:55 <notting> limburgher: per-package timeout configurability? not sure it's worth that level of bodhi hackery just for this
18:08:41 <mjg59> The original request was pretty clearly for an exemption from all testing
18:08:53 <nirik> I'm against further special casing for this one package.
18:09:10 <mjg59> And we approved it at the time
18:09:14 <limburgher> notting: If it's a lot of trouble, then I agree.
18:09:25 <pjones> mjg59: and it still makes a lot of sense, tbh
18:09:41 <mitr> If tzdata is not critpath, the maintainer can still set stable karma to "1" and then +1 it himself, can't he?
18:09:49 * nirik doesn't remember us agreeing to that.
18:09:56 <nirik> I think we said "how about just making it not critpath"
18:10:08 <t8m> nirik, +1
18:10:20 <t8m> nirik, I do not remember special casing it either
18:10:36 <t8m> just removing from critpath
18:11:03 <mjg59> We really didn't talk about it much
18:11:12 <mjg59> Most of the discussion was about what would have to be done in bodhi
18:11:35 <t8m> mjg59, that was discussion about the critpath list
18:11:46 <mjg59> Merely removing it from critpath does little to deal with the issues that were raised in the original request
18:11:59 <notting> mjg59: the discussion seemed all about the removal from critpath, though
18:12:22 <nirik> the title of the ticket is somewhat misleading. ;)
18:12:33 <mjg59> Yeah, the title doesn't help things
18:12:52 <mjg59> I see little real risk of a tzdata update being pushed that manages to break things
18:13:02 <nirik> http://meetbot.fedoraproject.org/teams/fesco/fesco.2011-11-21-18.00.log.html#l-115
18:13:35 <t8m> I see little real reason not to treat multiple other packages the same way as would be desirable for tzdata
18:13:54 <nirik> If we have a class of packages we think should be ok to push to stable with 0 testing, we should consider that... I think adding _another_ special case in bodhi for one package is not a reasonable use of developer time.
18:13:59 <mjg59> t8m: tzdata is only useful if it reflects the real world
18:14:05 <mjg59> And the real world keeps changing
18:14:21 <pjones> t8m: well, very few of them are data-only and change at the whim of governments constantly in the spring and autumn.
18:14:22 <t8m> nirik, +1
18:14:45 <pjones> t8m: and in a very real way, this same problem is why we split it out from glibc in the first place.
18:15:01 <mjg59> An analogy might be that people keep changing the root DNS servers with 36 hours of notice, and if you don't get an update your bind stops working
18:15:12 <mitr> nirik: I think we should first discuss whether we want the requirements (i.e. find a tester or wait 3 days).  If we do want to relax them, it probably can be done manually without extending bodhi again
18:15:17 <nirik> do we exempt bind from testing? ;)
18:15:27 <mjg59> I think tzdata should be eempted from testing
18:15:47 <t8m> mitr, manually how?
18:15:54 <mitr> mjg59: Funny that you mention that, RHEL had a sort of dizaster with a root server update a few years ago
18:16:00 <mjg59> For the dual reasons that it has a very low risk of causing regressions while also being in the unfortunate position of actually having to reflect rapidly changing reality
18:16:00 <mitr> t8m: set "required karma" to 1 and self-+1 ?
18:16:13 <t8m> mitr, but would it really work?
18:16:14 * mitr is a typo generator today
18:16:20 <pjones> nirik: no, but if we actually had the analogous problem, we might separate out name.ca and have this policy for that
18:16:23 * nirik thinks it should go via testing... and get +1 karma from a actual tester.
18:16:23 <mitr> t8m: I don't know.  Anyone?
18:16:38 <nirik> yes, it does, but it's not supposed to.
18:16:53 <pjones> nirik: point being, root nameservices are at least somewhat responsible with that sort of thing - awesomely countries don't seem to be very responsible at all when it comes to the time of day.
18:17:03 <nirik> yeah, sadly true.
18:17:21 <mjg59> What would the reasons for not exempting it be?
18:17:36 <mjg59> Risk of regressions, technical issues with special-casing?
18:17:56 <nirik> yeah.
18:18:09 <nirik> our bodhi logic is already too complex.
18:18:26 <nirik> (IMHO)
18:18:31 <mjg59> I think that's a question we should put to the bodhi maintainer rather than worrying about ourselves
18:18:37 <t8m> I don't think that having pmachata just asking one another person (for example from his Brno colleagues) to install the update and say that he does not see any problems during the install is a real problem.
18:18:43 <notting> everyone fat-fingers things sometimes,even for something like tzdata
18:18:47 <nirik> in 2.0 the update logic is config... in 1.0 it's part of the app, so you have to add code and push our a new version.
18:18:52 <mjg59> t8m: The issue isn't for current, it's for previous releases
18:19:25 <mitr> t8m: If there _is_ a new problem, such a testing is rather unlikely to catch it - there are too many timezones for that
18:19:26 <nirik> so, perhaps we vote? or do we want more info from bodhi maintainer? (who is at pycon this week)
18:19:35 <mjg59> notting: For tzdata the real risk would seem to be that it's broken in a subtle way - as long as the maintainer actually installs the package, anything grossly wrong is going to be obvious
18:20:11 <t8m> mitr, I mean not testing the changes just to see if the system does not explode after installing the package
18:20:16 <mjg59> notting: And if it's a subtle breakage there's no real expecation that testing is going to pick it up - we just get daylight savings time in Indonesia wrong for years before 1976 or something
18:20:29 <mitr> t8m: What if it explodes, but not in .cz?
18:20:40 <t8m> mitr, we can't catch this anyway
18:21:01 <limburgher> mjg59: That would probably break connecting to my VPN from my DeLorean, but that's unsupported anyway.
18:22:23 <mitr> So, proposal: FESCo is fine with tzdata not having another tester or waiting for 3 days if every new package goes through an automated test that involves at least 1) (TZ=$foo date) working for foo being each shipped timezone, 2) determining the date range that is changed for each timezone, and manual review of these changes.  (This proposal doesn't talk about how would that be achieved in bodhi.)
18:22:38 <notting> mjg59: no testing policy has nothing to verify 'maintainer installed the package and didn't screw it up'
18:23:00 <mitr> s/these changes /these date ranges/
18:23:41 <t8m> #proposal FESCo is fine with tzdata not having another tester or waiting for 3 days if every new package goes through an automated test that involves at least 1) (TZ=$foo date) working for foo being each shipped timezone, 2) determining the date range that is changed for each timezone, and manual review of these changes.
18:24:04 <mjg59> Can we define what "not having another tester" means?
18:24:10 <nirik> proposal: require tzdata to follow normal testing process for now, ask bodhi maintainer how hard it would be to except or if it would be possible in 2.0 to configure this.
18:24:16 <t8m> mitr, I am afraid this is too complex
18:24:29 <notting> mjg59: 'not having to reach the normal karma threshold', presumably?
18:24:40 <mjg59> #proposal Exempt tzdata from karma requirements in bodhi
18:24:46 <pjones> notting: let's define what it does have to do instead of what it doesn't, then?
18:24:55 <mitr> "not having to reach the normal karma threshold by the ordinary process" :)
18:25:59 <mitr> t8m: Would s/with.*if/with tzdata going to stable if/ help, or do you mean the condition?
18:26:38 <t8m> mitr, I mean the condition
18:26:43 * nirik is -1 for mitr and mjg59's.
18:26:56 * t8m is -1 for both as well
18:27:53 <limburgher> -1, I think rounding up a few people to smoketest a tzdata package should be simple enough.
18:27:53 <notting> 0 to mitr (it's too complex). although if someone can rig up that tests, they can also apply karma
18:28:05 * limburgher meant for both.
18:28:12 <t8m> What is the current status of AutoQA?
18:28:24 <mjg59> limburgher: The maintainer has explicitly said that it's not simple enough
18:28:31 * limburgher will be AFK for up to 30 minutes, will catch up upon return.
18:28:47 <nirik> it can do dep tests and nvr-upgrade tests... it can run rpmlint and various stuff.
18:29:05 <mitr> notting: Right... so that boils down to "no exceptions" after all
18:30:05 <notting> i'd be +1 to nirik's proposal, which is an implicit -1 to mjg59, i guess
18:30:07 <nirik> well, it's not in critpath at least, so it can push to stable after N
18:30:11 <t8m> I think it would be nice if we could have a group of packages defined in bodhi for which AutoQA tests would be sufficient to get to stable.
18:30:34 <nirik> currently autoqa is just advisory...
18:30:55 <mitr> There was no proposal to just refuse the request?
18:31:16 <t8m> nirik, yes, it would just gradually move it to 'allowing' for specified group of packages
18:31:46 <nirik> mitr: guess not. I'd be +1 on that too.
18:32:00 <t8m> mitr, well if we do not agree with the exception we implicitly refuse the request
18:32:03 <nirik> I think it would be good to consider packages like this for bodhi 2.0 tho
18:32:28 <mitr> nirik: "like this" is exactly what?  time-sensitive and unlikely to be tested correctly?
18:32:42 <mitr> It seems to me that the set is pretty small
18:32:57 <t8m> mitr, I'd rather like time-sensitive and autoqa tested
18:33:05 <nirik> mitr: time sensitive and brokenness doesn't really affect much
18:33:56 <pjones> mitr: time sensitive and something you could write a plugin to do near-100% testing of?
18:34:13 <mjg59> An out of date tzdata means that there's a window where we're shipping an OS that is entirely useless to segments of our userbase
18:34:37 <nirik> time being off is 'entirely useless'?
18:34:38 <t8m> mjg59, strange definition of useless
18:35:04 <mjg59> t8m: Having all your timestamps be wrong is pretty crippling
18:35:25 <mjg59> We're all in the favourable position of living in places where time changes occur rarely and with advance notice
18:35:34 <mitr> mjg59: happens about once a week currently to me, until chronys corrects it... and it seems everything survives
18:35:37 <mitr> *shrug* Proposal: refuse the request; the maintainer can set karma threshold to 1, and find one person to do minimal sanity testing and/or run an automated test.   We can discuss AutoQA when it is relevant (i.e. "we will spend >30 minutes of the FESCo meeting on tzdata in a year again")
18:35:42 <mjg59> -1
18:35:54 <nirik> +1
18:36:00 <t8m> mitr, +1
18:37:49 <t8m> Anybody else votes?
18:37:58 * nirik waits for votes. considers getting coffee.
18:38:05 <pjones> definitely -1 to that proposal
18:38:31 <t8m> pjones, note that this is implicit resolution anyway
18:38:38 <pjones> effectively you're telling the maintainer "sorry you can't find testers, suck it up"
18:39:10 <mitr> pjones: No, I'm pretty sure that somebody around here can be found if necessary.
18:39:17 <nirik> I think it's more "sorry, you're not that special, please follow the process everyone else does for now"
18:39:23 <t8m> nirik, +1
18:39:31 <mjg59> mitr: The maintainer has said that somebody can't be found
18:39:46 <pjones> mitr: you think the maintainer is lying, or what?
18:39:48 <mitr> (the primary goal of this proposal is to clarify whether we want to grant an exception at all or not - it's not clear to me)
18:40:07 <mitr> pjones: I must have missed that
18:40:31 <t8m> I think pmachata just does not believe real testing can be done.
18:40:34 <mitr> specific quote?  (note that originally it was "proventester", I'm not claiming that a proventester can be found)
18:40:38 * nirik notes we have been on this 40min so far.
18:40:53 <mjg59> "On the other hand, older or even too new Fedora releases take a long time to get the karma necessary for auto-push. Or even the first karma point that I need for manual marking."
18:41:53 <mitr> OK, I did miss that.
18:42:33 <notting> but he doesn't need that first karma point for manual makring now
18:43:09 <pjones> notting: still, what's the point of us making him manually mark it every time if we know (and basically encourage) that's what he's going to do?
18:43:25 <mitr> pjones: not having to worry about bodhi functionality for a single package?
18:43:44 <mjg59> I'm touched by the concern we're all having for Luke
18:44:01 <mjg59> But maybe we should ask him whether he thinks that it's going to be a problem in bodhi or not, rather than making that decision for him?>
18:44:10 <pjones> mitr: can we please talk about the policy here instead of holding up bodhi as a strawman?
18:44:55 <notting> pjones: what we're asking is for an exception for a specific maintainer's processes of how he builds and stages his update. i'm against certifying that in policy
18:44:57 <nirik> sure, we could ask and defer to next week if folks want.
18:45:11 <nirik> but I really don't see why we are special casing this one package.
18:45:14 <t8m> I have no problem with adding functionality to bodhi I have a problem with doing it for one single package.
18:45:27 <pjones> notting: honestly I think this has more to do with the nature of the data than with the maintainer.
18:45:30 <adamw> not to lob a grenade in here, but is this whole discussion taking place under the assumption that tzdata updates can't possibly break anyting?
18:45:37 <pjones> adamw: no.
18:45:41 <adamw> okay, cool.
18:45:52 <notting> well, that *was* the reasoning presented in the ticket, yes.
18:46:04 <notting> "Besides, I argue that it's not likely that tzdata actually breaks the system in the first place."
18:46:16 <mjg59> It's unlikely, yes
18:46:20 <pjones> notting: well, I was holding adamw's phrasing as intentionally stronger than that.
18:46:29 <mjg59> tzdata is clearly different to other packages
18:46:31 <adamw> right, i'm okay with that kind of qualified side note.
18:46:42 <adamw> no problem here, i'll be quiet.
18:46:50 <mjg59> We have very little in the distribution that's time sensitive
18:48:04 <t8m> another 15 minutes passed
18:48:59 <nirik> so, gather more info and defer? finish voting?
18:49:21 <mjg59> Well, do people think that this exception is justified?
18:49:27 <mjg59> (Ignoring bodhi completely)
18:49:32 <mjg59> Because, if not, there's no point in deferring
18:50:28 <notting> i don't think a direct-to-stable path is justified without some step to catch a bad package. given that the only such check in this proposal is the goodwill that the maintainer did such testing, i'm -1 to the exception.
18:51:02 * nirik nods. what notting said
18:51:13 <adamw> if there's a problem getting +1s on tzdata updates, i can possibly do something about that, if i'm asked. it could be the case that people are not +1ing it because they think they need to do more than just check nothing explodes when they boot with it.
18:51:28 <t8m> -1 for the same reasons as notting and also because I'd really like to see a generalized exception if we'd like to give one
18:52:33 <mjg59> So we're at -3 to an exception. Does that mean we're at +5 to one?
18:52:43 <mjg59> Or has everyone just died?
18:52:49 <mjg59> Oh, limburgher was afk
18:53:09 <pjones> I think it certainly needs something other than the process it currently gets.
18:53:22 <mjg59> The impression I get is that we don't actually care about this enough to even agree whether or not we care about it
18:53:22 <notting> mmaslano is not here. so... an exception can't pass at ths point.
18:53:42 <mitr> mjg59: That's where I ended up
18:53:44 <mjg59> So I'd suggest we defer it
18:53:54 <t8m> OK, deferred.
18:54:04 <notting> ack tp deferring and moving on
18:54:09 <mitr> Um, what does deferring solve?
18:54:17 <mjg59> Nothing
18:54:22 <nirik> mitr: I guess we might have more people next week to vote?
18:54:26 <t8m> #info Deferred to next meeting
18:54:28 <mitr> right
18:54:29 <t8m> #topic #800 Feature Freeze exception: JBoss AS 7
18:54:30 <t8m> .fesco 800
18:54:32 <zodbot> t8m: #800 (Feature Freeze exception: JBoss AS 7) – FESCo - https://fedorahosted.org/fesco/ticket/800
18:55:16 * limburgher is back, sorry.
18:55:18 <mjg59> Feature freeze exception for something that's still unstable?
18:55:29 <mjg59> Well, I guess there'd be no point otherwise
18:55:45 <nirik> the feature page is at 75%
18:55:46 <mjg59> So, eh, +1
18:56:13 <notting> the fact that legal issues have been resolved doesn't say anything about the current status from a 'is it in' perspective
18:56:37 <mitr> These are new packages, so what does us +1'ing or -1'ing affect? release notes only?
18:56:41 <mitr> +1 I suppose
18:56:49 <limburgher> I've seen movement on packaging in the last few days, but I'm not sure what %.
18:56:52 <nirik> http://fedoraproject.org/wiki/JBossAS7 has the packaging status
18:56:54 <pjones> sure, +1
18:57:04 <notting> sure, +1
18:57:05 <t8m> +1
18:57:14 <nirik> looks like about 13 packages.
18:57:21 <mjg59> mitr: Yeah, only outcome would be dropping it from the release notes
18:57:36 <limburgher> +1
18:57:41 <nirik> sure, I guess if it doesn't affect anything else... +1
18:57:42 <t8m> #agreed The feature freeze exception for JBoss AS 7 is granted.
18:57:48 <nirik> however, the feature page should be adjusted.
18:58:10 <t8m> Now for the new business
18:58:13 <t8m> #topic #820 Feature Freeze exception: Mingw-w64 cross-compiler
18:58:14 <t8m> .fesco 820
18:58:15 <zodbot> t8m: #820 (Feature Freeze exception: Mingw-w64 cross-compiler) – FESCo - https://fedorahosted.org/fesco/ticket/820
18:58:41 <mitr> "All this work has been completed now, so the MinGW-w64 feature itself is 100% implemented in Fedora 17. "
18:58:45 <notting> given that, +1
18:58:46 <mitr> So, this is again relnotes only?
18:59:00 * mitr would be very -1 to starting these changes (rebuild with different toolchain) now
18:59:19 <limburgher> Yeah, just renamed package blocking to go.
18:59:23 <t8m> As the percentage of completion is 100% anyway
18:59:25 <t8m> +1
18:59:28 <nirik> sure, +1
18:59:29 <mjg59> +1
18:59:36 <limburgher> +1
18:59:48 <pjones> +1
18:59:58 * t8m wonders if we do not set some wrong expectations with these exceptions for future.
19:00:28 <mitr> +1
19:00:47 <t8m> #agreed The feature freeze exception for  Mingw-w64 cross-compiler is granted
19:00:54 <mitr> t8m: Not with these exceptions, but with failing to notice and/or complain about the change happening 13 days ago
19:01:40 <t8m> mitr, I'm not quite sure that is a business of Fesco to explicitly look at every update happening on the release
19:01:45 <t8m> #topic #707 Updates to language on FESCo Election page
19:01:45 <t8m> .fesco 707
19:01:49 <mitr> t8m: it's not
19:01:52 <zodbot> t8m: #707 (Updates to language on FESCo Election page) – FESCo - https://fedorahosted.org/fesco/ticket/707
19:02:06 <mitr> +1
19:02:16 <t8m> This one is older but it did not have the meeting keyword.
19:02:26 <t8m> But I added it nevertheless
19:02:38 <notting> i am fully in favor of making the wiki reflect reality. +1
19:02:44 * nirik didn't recall seeing this one.
19:02:46 <t8m> +1
19:02:55 <nirik> +1 for the first change, +1 to dropping the reminder email
19:02:55 <mjg59> +1
19:03:34 <pjones> +1 yeah
19:04:14 <t8m> #agreed The updates to the FESCo Election page as described in the ticket are approved.
19:04:45 <t8m> I suppose toshio can update the page or would someone else do it?
19:04:51 <nirik> anyone can
19:05:36 <t8m> OK I'll do it.
19:05:39 <limburgher> +1
19:05:45 <t8m> #action t8m will update the page
19:06:03 <t8m> #topic #819 Please review our determination of IPv6 issue blocker status
19:06:03 <t8m> .fesco 819
19:06:04 <zodbot> t8m: #819 (Please review our determination of IPv6 issue blocker status) – FESCo - https://fedorahosted.org/fesco/ticket/819
19:06:33 <nirik> +1 is fine with this change.
19:07:03 <mjg59> +1
19:07:10 <notting> +1
19:07:12 <limburgher> +1 Absolutely.  Agreed, and logically arrived at.
19:07:24 <t8m> +1
19:07:25 <mitr> +1
19:07:54 <t8m> #agreed FESCo agrees with the IPv6 issue blocker status.
19:07:55 <pjones> the phrase "IPv6-only networks are becoming a configuration sufficiently important" strikes me as bizarre wishful thinking, but nevertheless I agree that the bug should be a release blocker, so +1
19:08:21 <t8m> #topic #808 Unretiring policy (or Fedora policies in general) needs a "common sense" clause
19:08:21 <t8m> .fesco 808
19:08:23 <zodbot> t8m: #808 (Unretiring policy (or Fedora policies in general) needs a "common sense" clause) – FESCo - https://fedorahosted.org/fesco/ticket/808
19:08:44 <t8m> More controversial topic.
19:09:14 <notting> -1 to "use common sense", because common sense isn't.
19:09:33 <pjones> completely with agreement on notting there.  was about to type almost exactly the same thing.
19:09:34 <limburgher> notting: Except when it is. :)  </bikeshed>
19:09:40 <t8m> I think the biggest problem is that the announcement of the retiring is not being read by people who will be affected by it.
19:09:45 <nirik> Unretiring packages that were accidentally retired, or right after it's noted that they were needed is fine with me.
19:09:53 <nirik> but waiting 3 weeks and complaining about it isn't. ;)
19:10:01 <notting> t8m:  devel@ is wrong? should it go to devel-announce as well?
19:10:02 <mjg59> In theory I'm absolutely fine with the idea that we should be able to skip re-review on recently orphaned packages, but there's an obvious argument over what "recently" would mean here
19:10:08 * mitr would +1 "unretiring within a month is fine _for packages that were ever properly reviewed_", but that's too complex, so -1
19:10:09 <t8m> notting, perhaps
19:10:23 <notting> also, 'recently' isn't exposed anywhere sanely to make such a determination
19:10:31 <mitr> notting: I think it's more that it's difficult for owners of dependent packages to notice
19:10:34 <notting> other than guessing from the git log
19:11:14 <mjg59> How about "Packages may be unretired without review up to a month after retirement providing that the package has ever previously been reviewed"
19:11:25 <limburgher> Ideally, owners of about-to-be-kicked packages and their dependers would be directly emailed, but really devel should be enough.
19:12:08 <nirik> mjg59: a month seems long, but I guess...
19:12:27 <t8m> mjg59, I'd like to see a shorter time than month
19:12:42 <limburgher> 2 weeks?
19:12:56 <mjg59> Blue.
19:13:02 <limburgher> Lemon curry.
19:13:05 <mjg59> So yeah sure 2 weeks
19:13:13 <mjg59> Anyone?
19:13:14 <t8m> #proposal Packages may be unretired without review up to 2 weeks after retirement providing that the package has ever previously been reviewed
19:13:16 <mitr> t8m: I think the risk is not in the one month between retiring and unretiring, but in the ~1 year the package had been FTBFS (... and presumably not being updated for guidelines)
19:13:31 <t8m> mitr, hmm that's true
19:13:40 <mjg59> mitr: But since that's true for packages that are nominally actively maintained too, it seems an odd distinction to make
19:13:51 <nirik> right, but someone unretiring it has incentive to get it to build. ;)
19:13:58 <mitr> mjg59: often.
19:14:00 <nirik> hopefully
19:14:01 <limburgher> nirik: One would hope. :)
19:14:20 <nirik> so, +1 to proposal, thats fine.
19:14:30 <pjones> yeah, I think I can be +1 to that.
19:14:41 <nirik> we should note that this should be a rel-eng ticket, not random email to someone or irc or mention on a list.
19:14:48 * mitr is +1, and would be +1 to a month as well
19:14:51 <limburgher> +1  Does this mean the onus is on the unretiring owner to get someone to do it?
19:14:51 <t8m> I suppose unretiring it doesn't get it back from the old collections in koji
19:15:02 <pjones> limburgher: it would be anyway.
19:15:07 <notting> +1, with the 'via ticket to rel-eng caveat'
19:15:14 <pjones> notting: indeed
19:15:18 <mitr> ... but on the whole, sorting the list of dependent package in the "retiring packages" mail by owner would do more good I think.  Now only to find someone to code it.
19:15:27 <limburgher> pjones:  Oh.  Duh. :)  Sorry, one of those days.
19:16:35 <t8m> I suppose given the last week discussion we will see some objections from dgilmore?
19:17:27 * nirik shrugs. I doubt it.
19:17:52 <t8m> I think the review (old one) would be necessary for having the bug where to place the git request for revival
19:18:18 <t8m> so yes I am +1 as well
19:18:20 <nirik> we should update the orphaning page with this info.
19:18:24 <nirik> and possibly announce it. ;)
19:18:36 <limburgher> t8m: Unless it's positively ancient, in which case it really needs a re-review anyway.
19:19:00 <t8m> #agreed Packages may be unretired without review up to 2 weeks after retirement providing that the package has ever previously been reviewed
19:19:21 <t8m> Anyone wants to take the action
19:20:40 <t8m> #action t8m will update the orphaning page and announce it on devel
19:21:26 <nirik> thanks t8m
19:21:55 <limburgher> Now, to make people read their email.
19:21:58 <t8m> We have new features for F18 from package wrangler but I suppose we should postpone them to next week.
19:22:09 <pjones> limburgher: thanks for volunteering for that.
19:22:09 <t8m> given the length of today's meeting
19:22:21 <limburgher> pjones: /me shoots self
19:22:44 <notting> i'm ok either way
19:22:51 * nirik is too.
19:23:23 <limburgher> I'm a bit busy but can probably go either way if everyone else can.
19:23:24 <mitr> +1 to postponing
19:23:26 <dgilmore> t8m: i dont object as long as the package is taken care of
19:23:33 <t8m> dgilmore, nice
19:23:47 <pjones> I've got some other work I need to do in the next hour or so, so I'd just as soon not do that today
19:24:08 <t8m> #topic Next week chair
19:24:24 <t8m> Anybody volunteers?
19:24:34 <nirik> do we want to move the meeting for daylight savings time? or keep it at the same time?
19:24:46 <limburgher> I can chair.
19:24:50 <pjones> nirik: *shrug*.
19:25:03 <t8m> Can we move it one week later - we are still at standard time here
19:25:04 <limburgher> I say leave it unless someone needs to move it.
19:25:05 * nirik also doesn't care, just wants to ask.
19:25:07 <pjones> I actually like 2pm a bit better in general, but it really depends on the people in europe
19:25:35 <t8m> I would have no problem with not moving it either
19:26:04 <notting> 1PM works better for my schedule
19:26:42 <notting> as i have a once-a-month or so conflict at 2/2:30
19:26:51 <t8m> notting, do you care if we move it after Europe changes DST?
19:26:57 <notting> t8m: no.
19:27:23 <t8m> #action limburgher will be the next week chair
19:28:01 <t8m> So let's discuss the meeting time change next week again.
19:28:11 <t8m> for now keeping the 18:00 UTC
19:28:24 <t8m> #topic Open floor
19:28:53 <t8m> Anybody has anything for the open floor?
19:29:13 <limburgher> No.
19:29:42 * nirik has nothing.
19:30:32 <notting> not i
19:30:35 * t8m will close this meeting in a minute if nobody speaks up.
19:31:23 <t8m> #endmeeting