18:00:08 <nirik> #startmeeting FESCO (2015-09-30) 18:00:08 <zodbot> Meeting started Wed Sep 30 18:00:08 2015 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:08 <nirik> #meetingname fesco 18:00:08 <zodbot> The meeting name has been set to 'fesco' 18:00:08 <nirik> #chair ajax dgilmore hguemar jwb nirik paragan rishi thozza sgallagh 18:00:08 <nirik> #topic init process 18:00:08 <zodbot> Current chairs: ajax dgilmore hguemar jwb nirik paragan rishi sgallagh thozza 18:00:14 <ajax> hi 18:00:31 <jkurik> .hello jkurik 18:00:32 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com> 18:00:35 <sgallagh> .hello sgallagh 18:00:36 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com> 18:00:43 <thozza> .hello thozza 18:00:44 <zodbot> thozza: thozza 'Tomas Hozza' <thozza@redhat.com> 18:00:45 <nirik> morning everyone 18:01:04 <thozza> evening everyone :) 18:01:47 * nirik waits for at least one more for quorum 18:03:51 <nirik> dgilmore jwb rishi number80 ? 18:04:00 <number80> o/ 18:04:11 * number80 sick so expect some latency 18:04:27 <number80> .hello hguemar 18:04:29 <zodbot> number80: hguemar 'Haïkel Guémar' <karlthered@gmail.com> 18:04:42 <nirik> ok. lets go ahead then 18:04:49 <nirik> #topic ticket #1480 F24 Schedule 18:04:49 <nirik> .fesco 1480 18:04:50 <zodbot> nirik: #1480 (F24 Schedule) – FESCo - https://fedorahosted.org/fesco/ticket/1480 18:05:08 <dgilmore> hola 18:05:30 <nirik> so, any more comments on the last proposal? 18:06:20 <jkurik> there are currently two proposals. One as we agreed on the last FESCo meeting and then the second one, which moves dates to earliest days 18:06:50 <dgilmore> when is devconf? 18:06:58 <jkurik> https://fedorapeople.org/groups/schedule/f-24/f-24-key-tasks.html 18:07:01 <jkurik> https://fedorapeople.org/groups/schedule/f-24-2nd-proposal/f-24-key-tasks.html 18:07:19 <jkurik> DevConf -- 2015-02-05 ... 2015-02-07 18:08:36 <number80> I was fine with the first one 18:08:41 <ajax> looks fine to me 18:08:56 <thozza> I was also fine with the first one 18:09:17 * nirik likes the first one better 18:09:48 <dgilmore> I like the first better 18:09:49 <ajax> i honestly don't have that strong of a preference as long as i get "release near may 1" 18:09:52 <dgilmore> but eitehr is fine 18:10:23 <nirik> I don't like the second one having change submission deadline before the holidays. 18:10:23 <number80> Unless someone wants to push the change, let's keep our decision from last week 18:10:25 <jkurik> ajax: the second proposal is closer to May 1st 18:10:32 <dgilmore> ajax: the second is closest 18:10:34 <rishi> Sorry for being late. I am here now. 18:10:54 <sgallagh> ajax: Why May 1st, specifically? 18:11:21 <ajax> sgallagh: cadence from f23, planning my upstream xserver releases, ... 18:11:46 <jkurik> sgallagh: we are trying to have GA releases as close as possible to May 1st and Oct 31st 18:11:55 <sgallagh> /me nods 18:12:12 <sgallagh> I'm slightly in favor of the 2nd proposal myself, but I won't lose sleep over it if we take the first one. 18:12:52 <nirik> should we vote? or anything to sway folks? 18:13:14 <nirik> ajax: how much pain would the may 17th one be for you? 18:13:20 <ajax> nirik: none at all 18:13:30 <ajax> later is fine, much earlier is worse. 18:14:39 <jkurik> sounds like the first variant is preffered 18:14:51 <nirik> ajax: ah, ok, misunderstood you. 18:14:54 <sgallagh> nirik: I seem to be the only one thinking the second and I'm not strongly in favor, so let's vote on the first 18:15:01 <nirik> +1 on the first one 18:15:07 <number80> +! 18:15:30 <ajax> +1 18:15:50 <rishi> +1 18:16:02 <sgallagh> +1 18:16:33 <thozza> +1 (first one) 18:16:56 <nirik> #agreed F24 schedule will be https://fedorapeople.org/groups/schedule/f-24/f-24-key-tasks.html (+6,0,0) 18:16:58 <dgilmore> +1 18:17:01 <nirik> #undo 18:17:01 <zodbot> Removing item from minutes: AGREED by nirik at 18:16:56 : F24 schedule will be https://fedorapeople.org/groups/schedule/f-24/f-24-key-tasks.html (+6,0,0) 18:17:05 <nirik> #agreed F24 schedule will be https://fedorapeople.org/groups/schedule/f-24/f-24-key-tasks.html (+7,0,0) 18:17:17 <nirik> jkurik: can you take care of updating pages and announcing? 18:17:22 <jkurik> Thanks FESCo for the approval 18:17:29 <jkurik> nirik: yes I will 18:17:31 <thozza> jkurik: thanks for the schedule 18:17:37 <nirik> thanks jkurik 18:17:40 <nirik> #topic ticket #1481 Decision on distro-sync during upgrades with dnf-plugin-system-upgrade 18:17:40 <nirik> .fesco 1481 18:17:42 <zodbot> nirik: #1481 (Decision on distro-sync during upgrades with dnf-plugin-system-upgrade) – FESCo - https://fedorahosted.org/fesco/ticket/1481 18:18:40 <nirik> so where are we here? 18:18:42 <sgallagh> So there is a proposal in the ticket. Do we want to debate the issue more or start with a vote? 18:18:53 <nirik> wwoods: are you around? 18:19:38 <nirik> I'm in favor of the proposal as long as there's no technical doom we don't know about that wwoods knows. ;) 18:19:40 <dgilmore> TC1 droped upgrade.img support 18:20:32 <wwoods> I'm around, what's the thing? 18:20:33 <sgallagh> Right, so that's the last nail in fedup's coffin 18:20:41 <sgallagh> wwoods: https://fedorahosted.org/fesco/ticket/1481 18:21:02 <number80> well, I don't want end-users ending up with broken system during updates (power users can easily workaround this) 18:21:04 <sgallagh> Current proposal is: "Upgrades use distro-sync by default. On resulting conflicts, the user is presented with the list of problematic packages and the choice of removing them as part of the upgrade or aborting." 18:21:06 <nirik> well, also we are dropping the fedora-install repo in mirrormanager (for 23+)... that might be the last nail. ;) 18:21:25 <number80> +1 18:21:30 <wwoods> I don't have a strong opinion about what the best choice for default behavior should be. 18:21:38 <wwoods> That's not my decision to make. 18:21:40 * nirik is +1 to the proposal as well. 18:21:41 <ajax> sgallagh: to be clear, the proposal is in comment 8? 18:21:54 <sgallagh> wwoods: We're asking for your opinion on technical feasibility of that propopsal 18:21:56 <sgallagh> ajax: Correct 18:22:01 <sgallagh> (And also restated just above) 18:22:08 <sgallagh> I'm +1 to my own proposal 18:22:17 <dgilmore> i am +1 for the proposal 18:22:29 <thozza> +1 it looks good 18:22:31 <wwoods> hm 18:22:36 <ajax> +1 18:22:44 <wwoods> in short the proposal is: use --distro-sync --allowerasing by default, AFAICT? 18:23:01 <sgallagh> wwoods: Does that prompt before erasing? 18:23:04 <sgallagh> If so, then yes :) 18:23:11 <wwoods> I don't know. 18:23:26 <wwoods> It prompts before downloading, and in the enormous list of packages it tells you what will be removed 18:23:26 <sgallagh> wwoods: The prompt is a mandatory step; I don't want users to be surprised by anything. 18:23:32 <wwoods> will users read it? no. 18:23:42 <dgilmore> wwoods++ 18:23:43 <zodbot> dgilmore: Karma for wwoods changed to 7 (for the f22 release cycle): https://badges.fedoraproject.org/tags/cookie/any 18:23:55 <dgilmore> indeed they will not 18:24:00 <sgallagh> wwoods: I explicitly did not specify a mechanism for the decision process so that we could engage with the UX folks on how best to do that. 18:24:03 <nirik> right. 18:24:06 <wwoods> the default is that it shows you the list of all 1500+ install/remove/upgrades 18:24:14 <wwoods> and asks you if you want to proceed 18:24:29 <nirik> (yes/no/what could possibly go wrong?) 18:24:33 <wwoods> the proposal also doesn't address whether we should be using --best or not 18:24:51 <wwoods> or --allowerasing 18:24:52 <sgallagh> What does --best even do? 18:25:01 <nirik> we should not use --best IMHO 18:25:08 <wwoods> sgallagh: forces the depsolver to only consider the newest version of each available package 18:25:12 <nirik> distro-sync allowerasing will take care of that. 18:25:25 <sgallagh> nirik: +1 18:25:31 <nirik> FWIW, it does list the removals toward the bottom. 18:25:44 <wwoods> (...and if it doesn't, that's probably simple enough to rejigger in DNF) 18:25:56 <nirik> hum... 18:26:07 <nirik> one possible issue: would this result in all old kernels being removed? 18:26:18 <wwoods> nirik: that's a DNF question 18:26:29 <wwoods> not something a plugin can influence, AFAIK 18:26:48 <sgallagh> nirik: Just tried it on my system. Doesn't appear to 18:27:14 <sgallagh> At least, `dnf distro-sync --allowerasing` isn't trying to remove either of my currently-installed kernels 18:27:18 <nirik> well, I am not sure how that interacts with distro-sync --releasever because the old kernels are not in the new repo 18:27:25 <nirik> right, it's releasever that would change that 18:27:26 <wwoods> sgallagh: not sufficient 18:27:39 <wwoods> dnf system-upgrade --distro-sync --allowerasing would be a better test 18:28:03 <sgallagh> OK, we don't necessarily need to solve the implementation here 18:28:11 <sgallagh> We just need to decide the intended behavior 18:28:28 <brunowolff> I had distro-sync -allowerasing --exclude='kernel*' remove all kernels and have filed a bug report about it. 18:28:33 <wwoods> ...within the limits of the current implementation 18:29:18 <nirik> right, so we have +6 for the proposal 18:29:34 <nirik> if it turns out to be inpractical we can revisit... 18:29:46 <sgallagh> OK, so let's proceed with the following: "We will implement this as `dnf system-upgrade --distro-sync --allowerasing` assuming that this does not remove kernels` 18:29:54 <nirik> brunowolff: I see that here too... can you send me the bug in #fedora-qa or something? 18:29:55 <wwoods> (because n.b. the current implementation does *not* allow for the old fedup behavior) 18:30:03 <rishi> nirik: I am also +1 for the proposal. 18:30:03 <brunowolff> If you don't exclude the kernel if seems common for distro-sync to fail due to not being able to remove the running kernel. I also filed and RFE bug for this to just skip removing the kernel and do the rest. 18:30:09 <rishi> Took me a while to read everything. 18:30:20 <wwoods> okay so real quick: do we want a switch to turn *off* --allowerasing, and if so what should it be? 18:30:46 <sgallagh> wwoods: Out of scope for this meeting :) 18:31:23 <sgallagh> The proposal defines the minimum that must work. I'm not prepared to demand additional options (too much to test) 18:31:24 <wwoods> no, it isn't. someone has to decide what the allowable upgrade behaviors are 18:31:57 <wwoods> but I'm going to take that as "currently we don't care about turning off --allowerasing" 18:32:11 <sgallagh> That's my view. Anyone want to contradict? 18:32:18 <nirik> IMHO those folks could use dnf directly... 18:32:27 <nirik> and have all the peices left 18:32:27 <wwoods> nirik: sadly, no 18:32:34 <wwoods> I mean, not the plugin, anyway 18:32:46 <nirik> right, I mean not the plugin... using just distro-sync live 18:33:07 <wwoods> ah! sure. if we consider that a viable alternative then I *definitely* don't have to worry 18:33:08 <dgilmore> wwoods: they could run dnf distro-sync --releasever=<next release> 18:33:22 <sgallagh> wwoods: Not a *supported* alternative. But a viable one. 18:33:46 <nirik> #agreed "Upgrades use distro-sync by default. On resulting conflicts, the user is presented with the list of problematic packages and the choice of removing them as part of the upgrade or aborting. " (+7,0,0) 18:33:51 <nirik> anything else on this for now? 18:34:21 <wwoods> word. I can have new builds with that behavior in a day or two. 18:34:33 <nirik> wwoods: awesome. thanks much. :) 18:34:37 <nirik> #topic ticket #1477 Nonresponsive Package Maintainer 18:34:37 <nirik> .fesco 1477 18:34:38 <zodbot> nirik: #1477 (Nonresponsive Package Maintainer) – FESCo - https://fedorahosted.org/fesco/ticket/1477 18:35:11 <dgilmore> +1 he is very clearly not responsive 18:35:30 <nirik> I'm +1 to orphaning mjakubicek's packages. 18:35:49 * nirik notes we really should redo the non responsive maintainer process, but thats a bigger topic. 18:36:08 <sgallagh> +1 orphan 18:36:13 <thozza> +1 18:36:33 <number80> +1 orphan 18:37:15 <nirik> #agreed will orphan mjakubicek's packages (+5,0,0) 18:37:25 <nirik> and another... 18:37:27 <nirik> #topic ticket #1482 unresponsive maintainer: thias 18:37:27 <nirik> .fesco 1482 18:37:28 <zodbot> nirik: #1482 (unresponsive maintainer: thias) – FESCo - https://fedorahosted.org/fesco/ticket/1482 18:37:38 <nirik> one thing to note here and with the last one... we have final freeze. 18:37:53 <nirik> coming up... and if some of these packages are orphaned/blocked it could cause doom 18:38:23 <nirik> but thias has been gone a long time now, so +1 to just doing it. 18:38:26 <dgilmore> same thing here 18:38:52 <number80> +1 18:38:57 <sgallagh> +1 18:39:09 <nirik> thias is poc on a lot of packages. ;) 18:39:17 <rishi> I am a little confused. 18:39:18 <sgallagh> nirik: If something is truly critical, someone will pick it up. 18:39:29 <rishi> Are we sure that mjakubicek has left? 18:40:00 <nirik> rishi: well, they didn't answer tickets or mails to devel... 18:40:23 <sgallagh> rishi: If they come back to life, they can re-request comaintainership 18:40:25 <nirik> do you know some way to contact them? 18:40:43 <nirik> actually they should still be co-maintainer, they just won't be point of contact. 18:40:47 <rishi> The ticket (https://bugzilla.redhat.com/show_bug.cgi?id=1140826 ?) is a EPEL request. 18:41:05 <rishi> Not really a critical bug. 18:41:23 <rishi> But if we are sure that he is gone, then he is gone. I will trust you. :) 18:41:44 <jkurik> nirik: he at least left RedHat 18:41:48 <nirik> well, they also said they mailed and also mailed devel 2 times asking if anyone could know how to contact them... 18:42:05 <rishi> Ok. 18:42:11 <rishi> nirik: +1 to both then. 18:42:31 <thozza> +1 18:42:44 <thozza> rishi: the first was already approved 18:43:14 <nirik> #agreed will orphan thias's packages (+6,0,0) 18:43:21 <nirik> #topic next weeks chair 18:43:25 <nirik> who wants the chair 18:43:27 <nirik> ? 18:43:44 <Pharaoh_Atem> . 18:43:56 <Pharaoh_Atem> man, I just realized I missed everything 18:44:10 <Pharaoh_Atem> oh well, the distro-sync policy is agreed upon, so I'm okay with this 18:44:15 <sgallagh> nirik: I can pick it up for next week. 18:44:21 <nirik> thanks sgallagh 18:44:28 <nirik> #action sgallagh to chair next week 18:44:31 <nirik> #topic Open Floor 18:44:35 <nirik> any items for open floor? 18:44:46 <sgallagh> I requested that we add the bundling question to this week's agenda... 18:44:50 <rishi> sgallagh: nirik: Are we going to discuss the bundling issue? 18:44:52 <rishi> right 18:44:54 <nirik> Pharaoh_Atem: you had something or just wanted to discuss the upgrade thing? 18:45:03 <sgallagh> (Sorry I was late in sending the proposal) 18:45:03 <nirik> oh, we can I suppose. 18:45:15 <Pharaoh_Atem> nirik: well, I was going to note that if we agreed upon distro-sync, it'd be nice if we can use it to reset epochs 18:45:24 <Pharaoh_Atem> as we have some truly ridiculous ones all over the place 18:45:26 <nirik> Pharaoh_Atem: that will not work at all.. 18:45:50 <sgallagh> Yeah, we still can't reset epochs because of upgrade triggers and the like 18:45:50 <Pharaoh_Atem> nirik: why not? the suse folks used it to reset them across releases 18:46:13 <nirik> it's a horrible waste of time IMHO. 18:46:27 <sgallagh> By all means, make a proposal. I'll -1 it :) 18:46:36 <Pharaoh_Atem> haha 18:47:00 <nirik> #topic #topic ticket #1483 - bundling 18:47:05 <nirik> .fesco 1483 18:47:06 <zodbot> nirik: #1483 (Decision on bundling policy in the Fedora Package Collection) – FESCo - https://fedorahosted.org/fesco/ticket/1483 18:47:16 <nirik> I'm personall not too opposed, but would -1 any vote today 18:47:23 <Pharaoh_Atem> on this topic, I think the policy is sound 18:48:13 <sgallagh> /me has been presently surprised that the responses thus far have been largely positive. 18:48:23 <sgallagh> s/presently/pleasantly/ ... 18:48:31 <Pharaoh_Atem> sgallagh: I think it's both :) 18:48:32 <nirik> I definitely like this more than the previous one. way less handwavy. ;) 18:48:50 <Pharaoh_Atem> it strikes a nice balance, and we could fairly easily implement this into the review process and potentially even the tooling 18:49:38 <Pharaoh_Atem> with decent guidelines on how they are declared, and potentially a system that indexes and shows the bundled "thingies" would make it easier to track 18:49:58 <sgallagh> Well, we already have the requirement on Provides: bundled(foo) 18:50:12 <sgallagh> But that's only used for things that went through FPC. 18:50:34 <Pharaoh_Atem> most of the infra we need for that exists today (as we parse the Provs/Reqs/Recs/Sugs in Koji and stuff) 18:50:37 <sgallagh> I'm hopeful that with this policy in place, people will be less likely to "hide" bundling 18:50:55 <nirik> well, there's also unaware people. 18:51:12 <sgallagh> Sure, but that's no worse than the present situation 18:51:17 <rishi> sgallagh: I am struggling to figure out exactly how it differs from the current policy. Currently we do have the possibility of bundling exceptions, right? 18:51:38 <nirik> rishi: the current policy requires you to get an exception from FPC... 18:51:39 <sgallagh> rishi: It's a very slow and heavyweight process that blocks the addition of useful packages 18:51:45 <rishi> Are you trying to nudge it towards a "looser" direction using the critical / non-critical split? 18:51:53 <sgallagh> And often results in people giving up or attempting end-runs around the policy 18:51:53 <rishi> nirik: Right. 18:51:55 <Pharaoh_Atem> rishi: the difference is that the bundling is explicitly parsed through during review rather than having to wait for FPC to do it ahead of time 18:52:05 <sgallagh> rishi: Yes 18:52:08 <Pharaoh_Atem> and the effort is just not worth it 18:52:13 <Pharaoh_Atem> for most people 18:52:13 <nirik> I'd like to note that FPC process shouldn't be that slow anymore. 18:52:23 <nirik> it's just a lot more strict than the proposal 18:52:51 <rishi> Out of curiosity, why is the FPC process so slow? 18:52:59 <nirik> it's not IMHO 18:53:12 <nirik> last year there was a backlog of things. 18:53:13 <Pharaoh_Atem> but I think if we just allowed it while having virtual Provides declare the information, it gives us an opportunity to offer software and gain some leverage with upstream to get changes to occur 18:53:19 <nirik> they are prettty much completely caught up these days 18:53:20 <sgallagh> nirik: In the absolute best-case (the exception is proposed right before the meeting agenda goes out and it's agreed on right away), that's 24 hours. 18:53:40 <tibbs|w> Oh, crap, I almost missed this one. 18:53:40 <sgallagh> It's rare that a bundling exception happens the first time it's discussed, so it's usually more than a week. 18:53:41 <nirik> sgallagh: I submit that if you require your package to be accepted in less than 24 hours, you should reset your expectations 18:53:58 <Pharaoh_Atem> I've worked with several upstream projects that bend over backwards for Ubuntu but refused to give me time of day as a Fedora packager over the years because they consider us a non-entity 18:53:58 * nirik waves his cane and yells at everyone to get off his lawn 18:54:24 <tibbs|w> I didn't really get a chance to make a counter proposal since I was trying to work on it through FPC. 18:54:26 <sgallagh> nirik: I think you missed "best-case" there. 18:54:38 <tibbs|w> But this got jumped straight to fesco, and, well... 18:54:51 <Pharaoh_Atem> a big part of it is because there's no reason for them to work with us, because we have no users of their software *now* 18:55:04 <Pharaoh_Atem> Copr slightly changes things as it continues to get used 18:55:12 <nirik> tibbs|w: thats why I would be -1 for any vote today. 18:55:14 <sgallagh> tibbs|w: In fairness, I indicated two weeks ago that we would have *something* for FESCo by today. 18:55:29 <nirik> there shouldn't be any rush here. we should listen to feedback and hear counterproposals 18:55:52 <Pharaoh_Atem> what would make up a counterproposal? 18:56:05 <nirik> a different process... ? 18:56:08 <Pharaoh_Atem> I liked how sgallagh announced his proposal and people debated it rather furiously 18:56:27 <Pharaoh_Atem> we got a fairly balanced thing out of that, which people appear to be okay with 18:56:40 <rishi> So, after re-reading https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries ... 18:56:50 <nirik> Pharaoh_Atem: in the few hours it's been up, sure. 18:56:54 <rishi> I must say that it isn't that unreasonable on the surface. 18:57:07 <nirik> the wiki pages are a bit of a mess. 18:57:14 <sgallagh> rishi: Define "it" please 18:57:18 <nirik> adamw was going to propose some changes/clarifications to it, but not sure he has 18:57:29 <adamw> i did 18:57:30 <sgallagh> nirik: https://fedorahosted.org/fpc/ticket/573 18:57:41 <nirik> cool 18:57:48 <adamw> i mentioned some further changes on the ml, but those are the most immediate/obvious ones 18:57:49 <rishi> sgallagh: I am curious - is your proposal meant to prevent a re-run of the darktable issue? Or do you have some other incidents in mind? Or something more generic? 18:57:52 <nirik> adamw++ Thanks for archeology! 18:57:52 <zodbot> nirik: Karma for adamwill changed to 13 (for the f22 release cycle): https://badges.fedoraproject.org/tags/cookie/any 18:58:02 <adamw> my change is a clarification of the current rules, though, it does not involve any *change* to them 18:58:24 * nirik is boggled he hadnt given adamw a cookie yet. 18:58:45 <rishi> sgallagh: For starters, https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Requirement_if_you_bundle covers the Provides: bundled(...) bit. 18:59:03 <sgallagh> rishi: It's meant to be more generic. I have only anecdotal evidence, but there are many cases where people simply give up packaging attempts because this is too big of a hurdle. 18:59:07 <rishi> Then the stuff under https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Exceptions looks reasonable. 18:59:10 <sgallagh> (See the endless discussion on devel@) 18:59:42 <sgallagh> rishi: Sure, it all looks reasonable and has sound justifications. The problem is the Law of Unintended Consequences. 19:00:08 <sgallagh> It adds a hurdle on packagers that a great many simply can't leap 19:00:16 <nirik> so, how much more discussion do we want to have today? we are reaching an hour... of course we can go more if desired... 19:00:27 <sgallagh> In most cases because the upstream simply doesn't care or has self-justified that bundling is preferable for their own reasons 19:00:29 <rishi> sgallagh: Yeah, I get that. Sure. 19:00:41 <dgilmore> I need to run in 5 minutes 19:01:00 <rishi> So basically you are arguing in favour of empowering the package reviewer to grant the exception, as opposed to going to FPC. Right? 19:01:09 <rishi> nirik: Yeah, let's not vote today. 19:01:43 <sgallagh> rishi: Not exactly, no. The package reviewer shouldn't need to, except in the rare cases where something is being newly-added to the critical path. 19:01:56 <sgallagh> It should simply *not be part of the review* unless it's in the critical path 19:02:09 <sgallagh> Actually no 19:02:13 <sgallagh> That's incorrect. 19:02:18 <nirik> IMHO it should be noted in the review 19:02:27 <sgallagh> The reviewer should make sure that any detectable bundles are Provides: bundled(foo) 19:02:38 * dgilmore would vote to let the FPC look at it and seem if it makes sense or needs some adjustment 19:02:42 <sgallagh> But the bundling exception is assumed. 19:02:47 <thozza> sgallagh: and that there is a justification for bundling 19:03:01 <thozza> I mean the statement from upstream 19:03:11 <sgallagh> /me nods 19:03:20 <rishi> sgallagh: Right. 19:03:53 <thozza> I'm also for postponing the vote on this one 19:04:08 <nirik> sometimes it may be difficult/impossible to get a statement from upstream... 19:04:20 <nirik> but I suppose you can still add a justification based on what you do know 19:05:09 <nirik> ok, shall we go back to open floor then? 19:05:13 <sgallagh> non-responsive upstream should be a red flag on package inclusion anyway :) 19:05:32 <nirik> sgallagh: well, I was thinking of packing hostile apps... 19:06:10 <nirik> "why do you bundle x y and z?" "People should install our app from our website, we don't like distro packages, we don't want to talk to you" 19:06:35 <nirik> but I'm sure there's lots of corner cases. 19:06:40 <nirik> #topic Open Floor redux 19:06:49 <nirik> anyone have anything for the new improved open floor? 19:06:55 <nirik> if not, will close out in a minute. 19:08:03 <sgallagh> nirik: That specific case still falls into "upstream refuses to unbundle" 19:08:12 <nirik> thanks for coming everyone! 19:08:15 <nirik> #endmeeting