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