17:04:58 <abadger1999> #startmeeting fpc
17:04:58 <zodbot> Meeting started Wed Feb 13 17:04:58 2013 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:04:58 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:06:20 <abadger1999> #chair SmootherFrOgZ Rathann geppetto rdieter
17:06:20 <zodbot> Current chairs: Rathann SmootherFrOgZ abadger1999 geppetto rdieter
17:06:46 <abadger1999> racor, tibbs, spot, limburgher: FPC meeting time
17:06:53 * racor is here
17:07:05 * limburgher is here, but distracted, cannot promise full attention today.
17:07:07 <abadger1999> #chair racor tibbs spot limburgher Rathann
17:07:07 <zodbot> Current chairs: Rathann SmootherFrOgZ abadger1999 geppetto limburgher racor rdieter spot tibbs
17:07:50 <abadger1999> Okay --- first, we had to deal with some big things recently so the smaller tickets have built up -- is there any tickets that people want to address today?  We'll do those first.
17:09:07 * SmootherFrOgZ hasn't
17:11:08 <abadger1999> #topic github url changes
17:11:20 <abadger1999> #info https://fedorahosted.org/fpc/ticket/252
17:11:25 <abadger1999> We don't have a drafat here.
17:11:38 <abadger1999> I'll take care of answering the question posed in the ticket today.
17:12:04 <abadger1999> #topic Bundling request for pinguino in icaro -- https://fedorahosted.org/fpc/ticket/253
17:12:48 <abadger1999> So this is a request to bundle code where "these routines are executed in the PIC and not directly on the Fedora user's host"
17:13:53 <abadger1999> Does this seem like it would fall under the firmware guidelines and be okay?
17:14:13 <rdieter> seems so
17:14:47 <SmootherFrOgZ> yep
17:14:50 <abadger1999> "* An exception is made for binary firmware, as long as it meets the requirements documented here: Licensing:Main#Binary_Firmware  "
17:14:50 <geppetto> yeh
17:14:56 <rdieter> though reading though all that, seems there's a lot of extraneous commentary (which left me a bit confused)
17:15:15 <abadger1999> Yeah.... It wasn't until I got to the end that I understood what was being asked for.
17:15:34 <abadger1999> Alright, I'll note that this falls under existing guidelines and is okay.
17:16:19 <abadger1999> #topic bndling exception for cpanm  -- https://fedorahosted.org/fpc/ticket/250
17:16:49 <abadger1999> #info https://bugzilla.redhat.com/show_bug.cgi?id=907464
17:17:19 <abadger1999> This is a little different from our usual bundling requests in the following ways:
17:17:45 <abadger1999> * pieces of the dependent libraries are being copied rather than the libraries as a whole
17:18:37 <abadger1999> * The reason for hte copying is to provide a smaller runtime overhead since the perl script consumes much less memory when it is reduced in size in this way.
17:19:37 <geppetto> hmmm
17:19:53 <geppetto> seems like someone should just fix the upstream library/module
17:20:46 <geppetto> I mean if we allow this there are a _lot_ of people who'd want to bundle for "efficiency" reasons
17:21:25 <geppetto> pretty sure spot knows of at least one example :)
17:22:50 <rdieter> while I'd like to trust upstream rationale here, we don't have enough information to justify an exception yet.  I see no effort to answer any of our standard question
17:24:21 <racor> geppetto, rdieter: I am inclined to agree.
17:25:16 <abadger1999> rdieter: <nod>  Although the standard questions seem pretty self explanatory in this case.  The one thing we don't know is: "Is upstream keeping the base library updated or are they continuously one or more versions behind the latest upstream release?"
17:25:52 <rdieter> ok, that's fair.  not that question is super important or not.
17:27:30 <abadger1999> I can ask that question.... not sure the answer would change our votes by looking at what we've said so far.
17:28:07 <abadger1999> I'll add the question to the ticket and ask if mmaslano could perhaps come to next week's meeting?
17:28:19 <rdieter> or was upstream consulted about considering unbundling?  (I think we know the answer to that, just curious if it's been asked)
17:28:33 <abadger1999> (This is right before the fesco meeting, so it might be possible)
17:29:08 <rdieter> I'd tend to agree to the exception if upstream is against or hostile to unbundling it
17:29:13 <abadger1999> heh, probably not but given what's stated in their README file, I think they'd say that bundling was pretty critical to what they're achieving
17:29:26 <tibbs> Ugh; hoped to be back before now.
17:29:47 <rdieter> alright, I wasn't aware it was documented (README).  in that case, consider me +1 in favor of exception
17:30:48 <rdieter> cause no exception means essentially patching/forking or dropping the package, both of which is more distasteful to me
17:32:01 <racor> rdieter: granting an execptions means rendering our perl modularization efforts add absurdum.
17:32:07 <abadger1999> patching/forking I'd be okay with in general.... In this case, it seems like it changes the whole point of the package.... I'm okay with either allowing this (and setting precedent) or saying this sort of package doesn't belong in Fedora (and setting the opposite precedent) :-)
17:32:49 <racor> If upstream or the fedora maintainer are hostile, I'd rather see this package removed.
17:32:58 <tibbs> One interesting thing about this is that I'm not sure their perfectly valid reasons for bundling are even remotely relevant to our situation as a distro.
17:33:08 * rdieter repoqueries, if anything depends on this
17:33:19 <rdieter> perl-Padre-0:0.90-6.fc18.noarch, perl-Task-Kensho-Toolchain-0:0.28-7.fc18.noarch
17:35:34 <tibbs> Another thing that's troubling is that someone actually had to be convinced that the issue should be brought to FPC.
17:35:52 <tibbs> How on earth did this even pass review?  (And yes, that's rhetorical.)
17:36:00 <racor> rdieter: perl-Padre is black whole. I don't know about its current shape, but it used to be broken for longer periods.
17:36:56 <rdieter> ok, so not allowing this seems like the fallout will be minimal
17:37:39 <tibbs> Well, the fallout will be that they continue to ignore us.
17:37:41 <racor> .. a black hole ...
17:38:30 <tibbs> I really don't know what to do here.
17:38:38 <abadger1999> tibbs: We could ask fesco to remove it from the distro since it will be impossible to unbundle I suppose.
17:38:51 * abadger1999 notes that mmaslano is on fesco :-)
17:39:28 <tibbs> Well, yeah, that's sort of the disturbing thing.
17:39:40 <abadger1999> <nod>
17:40:01 <rdieter> sounds like they kinda assumed we'd rubber-stamp the exception
17:41:52 <abadger1999> <nod>  The person who found and reported the problem made a similar assumption -- I think it's a question of what your assumptions are on the question of "Can anything be packaged for Fedora regardless of code quality?"
17:42:06 <misc> (person being me)
17:42:45 <tibbs> Now, one interesting question, is that if upstream is really keeping up to date and isn't really forking the underlying modules then why can't the code just use unbundled modules directly?
17:43:11 <abadger1999> ah -- misc do you think you could add anything?  Or is it better if I asked mmaslano to come next week?
17:43:16 <tibbs> Their reason for bundling is purely to keep the dependency chain down because it's basically its own distro installer.
17:43:31 <tibbs> How would we feel if yum, for example, tried to do the same thing?
17:43:40 <misc> abadger1999: well, i have given my reason in the ticket, but I think mmaslano would be better to explain
17:44:04 <abadger1999> misc: Is the bundling for the dependency chain only?  Or also to keep the memory size down?
17:44:14 <tibbs> We don't particularly care about the cpanm dependency chain in Fedora.
17:44:37 <tibbs> Or at least, we shouldn't since we have our own perfectly good way of getting things installed.
17:44:42 <misc> abadger1999: no idea. i agree the bundling is weird for a linux distro, but I am not familliar enough with cpanm and perl people to see if there is others use case
17:44:46 * abadger1999 notes that in his mind he was reading the docs and thinking /usr/bin/cpan took 256MB while this took 10MB but now sees that those numbers were apples and oranges.
17:44:54 <geppetto> tibbs: that would be a reason to not have it in the distro. no?
17:44:58 <misc> my point was more to reduce the work needed from a security point of view
17:45:06 <abadger1999> misc: <nod>
17:45:37 <misc> and try to avoid basically forking too much upstream package with lots of modification :/
17:45:52 <tibbs> geppetto: Well, there's the issue of using things like cpan (and I assume cpanm) to get things installed that aren't packaged.
17:46:31 <geppetto> tibbs: Not sure my views on that are printable :)
17:46:36 <tibbs> That's a valid thing to want to do.  My point is that as long as we actually have the dependency chain underneath cpanm packaged, why would it need the bundling?
17:46:44 <geppetto> tibbs: my view is more that cpan is there for cpan2spec
17:47:12 <misc> tibbs: ease of maintainance of a non unblunded file vs ease of maintance of the bundled one
17:47:29 <misc> unbundle may be annoying on every update, while bundling is annoying in case of security/bugs
17:47:54 * abadger1999 sees the need for developers and things like "I'm developing a web service that runs on my servers but works for the internet" to be able to step outside of rpm/distro packaging... so more agrees with tibbs.
17:49:35 * rdieter still thinks fpc going beyond *packaging* and into code maintenance/quality is a dangerous slippery slope
17:49:42 <abadger1999> Okay -- I don't think we'll pass this today.  Looking remote that we'd pass it next week, but I'll ask mmaslano if she can come to next week's meeting and summarize our thoughts in the ticket.
17:49:51 <tibbs> To be honest, I'd like to see racor expand on how this undoes the work done on perl modularization.  Because I think I agree, but I'm not entirely sure what's behind his reasoning.
17:50:37 <Rathann> Also, the standard questions weren't answered
17:50:54 <tibbs> But to me this case isn't all that different from the other bundling things that come up: upstream's rationalization makes sense for them but doesn't make sense in the context of our distro.
17:51:25 <geppetto> yeh
17:51:36 <geppetto> if we vote now I'm a strong -1
17:51:41 * rdieter <offotopic alert> would greatly prefer default to trusting upstreams to know what they're doing, and make exceptions for egregious faults, rather than the opposite: defaulting to bundlings always being "bad", and have to make exceptions otherwise.  </offtopic>
17:51:49 <geppetto> but they can answer the std. questions to try to make me change my mind
17:52:15 <tibbs> So much for plowing through the easy tickets.
17:52:25 <abadger1999> heh
17:52:36 <geppetto> hey, this one seemed like a simple -1 to me
17:53:06 <tibbs> I have to agree that I don't want to make a decision possibly based on incorrect assumptions because the information we asked for wasn't provided.
17:54:21 <rdieter> obviously no exception has been granted (yet).  just that more information *may* sway the decision (but seems unlikely)
17:54:49 <abadger1999> k
17:55:26 <racor> tibbs: Sorry, was digging through the code.
17:55:54 <tibbs> I, too, think I'd need to have a look through it.
17:56:11 <tibbs> Not sure if anyone else can still speak Perl.
17:56:24 <abadger1999> speak yes, read no.
17:56:47 <abadger1999> I'm very, very rusty.
17:57:25 * abadger1999 Looks for a topic that can either be addressed in 4 minutes, or can be mentioned and then thought about more for next time.
17:57:39 <abadger1999> okay... here's one of the latter
17:58:00 <abadger1999> #topic blanket bundling exception for things needed to test a package: https://fedorahosted.org/fpc/ticket/245
17:58:00 <racor> abadger1999: ACK, this requires more time.
17:59:25 <tibbs> Not sure this is remotely common enough to warrant any kind of blanket exception.
17:59:59 <tibbs> But wasn't it the Java guidelines authors themselves to added the need to delete all jars in %prep?
18:00:36 <tibbs> Originally we only said that the stuff can't make it into the final package at all.
18:00:41 <abadger1999> I think it was nim-nim
18:01:15 <tibbs> It's tough to remember back that far.
18:01:24 <abadger1999> who is a java packager but I think there's been a new generation of java packagers now.
18:01:34 <abadger1999> yeah.
18:01:58 <geppetto> fwiw, I'm fine for people to bundle anything that's just used at %check phase
18:02:06 <abadger1999> okay, I think rdieter and I stated the two positions we could take on a blanket style exception.
18:02:07 <tibbs> Interesting.
18:02:21 <abadger1999> Think about it, and let's get back to this next week?
18:02:25 <tibbs> So I could bundle an executable that just gets run in %check?
18:02:39 <tibbs> My proprietary non-free test suite?
18:02:47 * abadger1999 has to go to fesco meeting but ya'll are chaired so anyone can close the meeting :-)
18:02:59 <rdieter> tibbs: as long as the code is redistributable too, of course.
18:03:01 <tibbs> Oh, I have a hard stop two minutes ago.  Ugh.
18:03:24 <tibbs> Thanks, folks; really have to run.
18:03:31 <abadger1999> Later tibbs!
18:03:38 <racor> I am with gepetto. As long as these binaries are legal to be shipped in src.rpms and only used as build-time local test-data, I don't have a problem with them. They must never be installed.
18:03:50 <rdieter> but extreme policy decisions will have to be made by others (board/fesco)
18:03:56 <rdieter> (and legal)
18:04:17 <SmootherFrOgZ> agreed
18:04:38 <geppetto> tibbs: I think we aren't allowed to ship proprietary stuff … and it's hard to know what the binary is doing (Eg. altering what is shipped) … but apart from that, I'm fine.
18:05:37 <SmootherFrOgZ> we're over time. shall we vote on this?
18:06:55 <geppetto> I'm +1
18:08:16 <SmootherFrOgZ> +1
18:08:17 <racor> Another thought: We have the "must be built from source" requirement for "libraries/programs", but we don't have such a requirement for "data"
18:08:40 <racor> Are these *.jars, programs, libraries, scripts or data?
18:09:31 <rdieter> racor: that requirement is for "stuff we ship".  not the case here
18:09:48 <rdieter> (but having that clarified explicitly would be nice)
18:10:43 <rdieter> racor: in general, data is probably not included.  though exceptions could be made for cases where said data isn't in the "prefered form" of the source
18:11:25 <rdieter> voting to grant exception?  if so, +1 (as mentioned in the ticket)
18:13:32 <SmootherFrOgZ> Rathann: limburgher want to vote for the record?
18:13:33 <racor> rdieter: I am not sure if what you say really applies and would have to check the FPGs wording (c.f. the OSI/FLOSS constraints).
18:14:06 <limburgher> Sure, let me catch up a bit. . .
18:14:23 <rdieter> racor: possible, but i'd argue that's not for us (FPC) to decide.  that's fedora legal's area
18:15:17 <SmootherFrOgZ> agreed with rdieter
18:15:27 <limburgher> Sorry, I'm a bit harried right now, but why can't they just BR what they need for make check?
18:15:46 <SmootherFrOgZ> abadger1999: if you can fire your vote as well
18:15:48 <rdieter> limburgher: because it's not in the distro  (yet)
18:16:17 <rdieter> and potentially might not be allowed to be in either (that's the separate question we're tossing around)
18:16:23 <limburgher> rdieter:  And so it's a sort of temporary exception on the condition that they get it in the distro and the stop bundling?
18:16:26 <abadger1999> In FESCo, unable to think about it right now... +0 (which amounts to -1 for fpc voting)
18:16:28 <racor> rdieter: Then we likely should ask legal: Is a package, which depends on prebuilt libraries/programs OSI-compliant?
18:16:55 <rdieter> racor: obviously of fe-legal doesn't allow it, then the point is moot
18:17:01 <abadger1999> but we can surely finish discussion/voting next week :-)
18:17:18 <rdieter> racor: doesn't stop us from making our own decision
18:19:03 <racor> rdieter: As I tried to express before: Using binary "testing-data" would be OK with me. Using bundled prebuilt, or even unbuildable prebuilt programs/libraries would not be OK with me. .... so, not sure how to vote.
18:20:32 <rdieter> racor: ok, maybe we can clarify the propsal, if pass/fail is on your vote.   would testing code be ok with you?
18:20:38 <rdieter> (not prebuilt)
18:20:49 <rdieter> would "bundled" testing code, that is.
18:22:38 <SmootherFrOgZ> limburgher: yes
18:23:03 <Rathann> I'd say: if it can be built from source, it should, so -1 for blanket exception
18:23:15 <limburgher> II'm with Rathann.
18:23:32 <limburgher> I'd prefer prebuilt data as well, libs and binaries are out.
18:23:39 <racor> I'm with Rathann, too.
18:24:01 <SmootherFrOgZ> k, we've +1:3, 0:1, -1:3
18:24:07 <SmootherFrOgZ> this not pass
18:24:27 <racor> Sorry folks, I've got to quit (dinner is waiting)
18:24:46 <SmootherFrOgZ> racor: no worries
18:24:56 <SmootherFrOgZ> #topic Open floor
18:25:10 <SmootherFrOgZ> Anything else before we close this meeting?
18:25:31 <rdieter> probably not, quorum is gone
18:25:51 <SmootherFrOgZ> indeed
18:25:58 <SmootherFrOgZ> thanks everyone for coming
18:26:04 <SmootherFrOgZ> #endmeeting