16:15:07 <abadger1999> #startmeeting Fedora Packaging Committee
16:15:07 <zodbot> Meeting started Wed May 26 16:15:07 2010 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:15:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:15:31 <abadger1999> #chair tibbs|h racor limburgher SmootherFrOgZ rdieter spot
16:15:31 <zodbot> Current chairs: SmootherFrOgZ abadger1999 limburgher racor rdieter spot tibbs|h
16:15:48 <limburgher> I fear the day it achieved sentience. . .
16:15:54 <limburgher> s/d/s/
16:16:39 <abadger1999> So here's the open drafts: https://fedoraproject.org/wiki/PackagingDrafts
16:17:14 <abadger1999> Last meeting we decided this needd more work and there hasn't been motion: https://fedoraproject.org/wiki/PackagingDrafts/CMPIPlugins
16:17:14 <tibbs|h> Let's go through the three marked "next meeting".
16:17:31 <tibbs|h> They actually wrote that because I asked them to.
16:17:34 <abadger1999> https://fedoraproject.org/wiki/User:Ajax/Static_Library_PICness_Guidelines
16:17:56 <abadger1999> ajax: You around?
16:18:27 <abadger1999> ajax: The thing I wonder about most wrt static library picness is: is it overkill?
16:18:54 <abadger1999> Should the guideline be restricted to packages that only provide static libraries?
16:19:07 <tibbs|h> Why is there ever a reason to build both pic and non-pic?
16:19:45 <tibbs|h> Because as I recall, there was objection to the whole libfoo-pic renaming thing.
16:20:40 <limburgher> abadger1999: I think it is anyway.
16:21:07 <rdieter> tibbs|h: I figure it's for folks who *insist* on shipping a non-pic static lib
16:21:14 <rdieter> as crazy as that sounds
16:21:24 <limburgher> I'd honestly like to get through this one so I can package lzma and possibly fix the upx sitch.
16:21:50 <limburgher> rdieter: I think he's looking for an example of said craziness.  I can't think of one.
16:22:04 <abadger1999> Okay, that's also a fair point.  I just wonder if we're asking for unnecessary work here (verifying that static libraries have been built with PIC and patching build scripts that don't do so properly)
16:22:36 <limburgher> What if we pass it without an exception for non-PIC, and deal with it if it comes up, thus dodging the renaming issue altogether?
16:23:02 <tibbs|h> You mean "must build PIC" and delete the rest of the document?
16:23:08 <abadger1999> limburgher: How does this one affect upx/lzma?  I'm not current on that issue so I'm curious.
16:23:11 <limburgher> more or less.
16:23:34 <tibbs|h> Or better, why does upx/lzma need this guideline to move forward?
16:23:46 <limburgher> abadger1999: It would just be nice to have it out of the way, because I thought a static lzma was a prereq for non-bundled lzma support in upx.
16:23:54 <limburgher> abadger1999: I could be wrong.
16:23:59 <racor> tibbs: Yes, that's what I'd go for
16:24:09 <limburgher> tibbs|h: It might not.
16:24:28 <limburgher> Churn saving, that's all.
16:24:57 <abadger1999> limburgher: Ah... if that's all that's needed -- you can do so now.  There's already static guidelines.  This is a potential modification.
16:25:03 <tibbs|h> There's really no need to document an exception process in this guideline since it's no different than any other exception that you'd go to FESCo for.
16:25:51 <rdieter> good point
16:26:04 <tibbs|h> Is the issue here one of folks who argue that non-PIC is some kind of performance gain?
16:26:12 <abadger1999> I'm not sure if no exception for non-PIC  is good or not -- the math and science people that the exception seems aimed at seem to think they have to link statically for speed.
16:26:24 <rdieter> tibbs|h: I think so
16:26:29 <limburgher> <headdesk>
16:26:34 <tibbs|h> Then let's see some numbers.
16:27:08 <rdieter> and, if given numbers, what amount of gain is sufficient justification?  2% 5% 10% more?
16:27:18 <abadger1999> Otherwise we would have gotten rid of static libraries except where upstream doesn't ship dynamic libraries too.
16:28:03 <abadger1999> I think the math people argue that 2% of a multi-week computation is significant for them.
16:28:13 <abadger1999> But IAMAMP :-)
16:28:18 <tibbs|h> At some point we have to say that folks who want that last bit of performance can roll their own.  We have to worry about the entire distro.
16:28:23 <abadger1999> err IANAMP
16:28:39 <rdieter> tibbs|h: +1
16:28:42 <tibbs|h> I am a math person.  Rex probably is as well.
16:28:48 <rdieter> :)
16:28:56 <limburgher> I used to be.
16:29:18 <limburgher> tibbs|h: +1
16:29:35 <abadger1999> Cool.  We can fend off the flames easily then :-)
16:30:11 <abadger1999> Do we have an idea of how much work this will cause?
16:30:49 <abadger1999> ie: how many  static packages cannot be shipped PIC without patching (adding a configure flag seems easy enough)
16:30:49 <limburgher> Also, relatedly, how would be detect violations later?
16:31:05 <limburgher> s/be/we/
16:31:24 <tibbs|h> And I guess we should know what happens if we just don't do anything.
16:31:28 <racor> abadger1999: Are you referring to this proposal? Renaming all static libs would mean a lot of work.
16:31:38 <abadger1999> racor: No renaming.
16:32:17 <abadger1999> racor: Just -- when rebuilding the packages, how much work to turn on -fPIC for the builds.
16:32:23 <tibbs|h> Even the proposal doesn't require renaming for what seems to be the vast majority of packages.
16:32:32 <racor> OK, then, exept of verifying the package will build PIC, the effort should be close to 0
16:33:47 <limburgher> racor: Correct, from all appearances.
16:34:41 <abadger1999> Okay, I'm +1 for tibbs|h's proposal -- This proposal with removal of renaming/exception.
16:35:05 <tibbs|h> That boils down to "must build PIC".
16:35:08 <limburgher> +1 from me for same.
16:35:16 <rdieter> +1
16:35:17 <SmootherFrOgZ> same thing, +1
16:35:39 <tibbs|h> And we can dispense with this document entirely and just say that in the "Packaging Static Libraries" section of the guidelines.
16:35:51 <tibbs|h> +1
16:36:32 <abadger1999> <nod>
16:36:36 <limburgher> Yup.
16:37:10 <abadger1999> That's five.  racor, care to vote too?
16:37:13 <racor> +1
16:37:48 <tibbs|h> It may be nice to have some info on how to double-check that things are properly built.  I don't even have i386 around any longer so I'm not sure how to check.
16:39:17 <abadger1999> Yeah.. tibbs, do you want to take redrafting that as the changes to the static Guidelines + a page for rationale/how to check if we can figure it out?
16:39:48 <tibbs|h> Sure.
16:40:00 <abadger1999> Thanks
16:40:26 <abadger1999> #info Static_Library_PICness_Guidelines passes with modifications from tibbs
16:40:40 <abadger1999> Next we have: https://fedoraproject.org/wiki/User:Walters/Packaging_VCS_key_proposal
16:40:47 <abadger1999> #topic FPC: https://fedoraproject.org/wiki/User:Walters/Packaging_VCS_key_proposal
16:41:09 <tibbs|h> This has not changed since the last meeting.
16:41:09 <fedori> hi. possible ambassador for NL. mentor is Robert Scheck. just signing in for a first taste.
16:41:25 <abadger1999> We talked about this lasat week without quorum and leaned towards this not belonging in the guidelines at this time.
16:41:45 <abadger1999> fedori: I think the ambassadors meeting in 20 minutes
16:42:00 <limburgher> That matches what I recall.
16:42:16 <abadger1999> cwalters wanted to get an official FPC vote before deciding whether to push this to tips and tricks rather than official fpc guidelines.
16:42:22 <fedori> thx
16:42:24 <tibbs|h> I believe that we don't regulate the comments people can add to their spec.
16:42:37 <abadger1999> Yeah.
16:42:46 <abadger1999> I'm still -1
16:42:52 <tibbs|h> -1 here as well.
16:43:00 <limburgher> -1
16:44:19 <SmootherFrOgZ> -1 for that tag
16:44:45 <rdieter> I guess I'm -1 too
16:45:03 <racor> -1
16:45:25 <abadger1999> Okay, with -6 it does not pass.  We can revisit when rpm or other tooling changes.
16:45:41 <abadger1999> #info Packaging_VCS_key_proposal does not pass
16:45:55 <tibbs|h> I do think that if RPM formalizes this as a tag, we'll need to talk about it in the guidelines.
16:46:10 * SmootherFrOgZ hopes not
16:46:12 <abadger1999> <nod>  I think so too
16:46:14 <abadger1999> #topic https://fedoraproject.org/wiki/PackagingDrafts/ArchSpecificRequires
16:46:40 <abadger1999> People were tentatively n favor of this last week -- I wrote in some changes jsut before the meeting
16:47:29 <skvidal> hi
16:48:01 <abadger1999> skvidal: hi.  So I made a few changes -- mostly jsut wording but I had two questions atthe end.
16:48:09 <abadger1999> https://fedoraproject.org/wiki/PackagingDrafts/ArchSpecificRequires
16:48:33 * skvidal looks
16:48:39 <abadger1999> Should more work be done?
16:48:54 <rdieter> the last question is true.  don't add %{?_isa} if the thing being required is noarch
16:49:12 <rdieter> if I understand the question correctly
16:50:03 <skvidal> lemme check something real quick
16:50:11 <SmootherFrOgZ> rdieter: +1, that shoud be not MUST as well
16:50:56 <skvidal> rdieter: correct - in noarch cases adding it to requires will make it specify an 'arch preference' which doesn't exist
16:50:56 <rdieter> the first question is mostly harmless either way, imo
16:51:14 <dgilmore> abadger1999: autoprovides and requires will force the right thing to happen for libraries
16:51:27 <rdieter> if there's only one (arch'd) candidate, it neither helps or hurts to add the arch'd dependency
16:52:43 <rdieter> adding it may help future-proof things though, if the multilib'ing of said dep ever changes though
16:53:27 <abadger1999> Okay -- so -devel packages and -devel subpackages are the only two use cases at the moment?  (the fooapp-plugins depends on foo-app example is not needed b/c it wouldn't be multilib)?
16:54:04 <tibbs|h> I can't recall just which dep problems had cropped up in the past due to this issue.
16:54:52 <skvidal> lemme look it up
16:54:57 <skvidal> there's one that was a sore point for me
16:55:05 <abadger1999> <nod>
16:55:16 <rdieter> abadger1999: that's the primary use-case I think, and maybe we can take baby-steps starting with just that one
16:55:25 <rdieter> unless skvidal has more
16:55:26 <dgilmore> abadger1999: somthing that has say a "Requires: make" usually doesnt matter what arch make is  it just needs to be able to exec make somewhere.  but something that does a dlopen of something likely needs a arch specific object to dlopen
16:55:35 <abadger1999> This version of the draft is more of a whitelist/blacklist than the original.
16:55:45 <abadger1999> So I want to make sure :-)
16:56:41 * abadger1999 notes there's one more thing he knows of to discuss if we have time: GSettings
16:56:59 <tibbs|h> Well, it would be unfortunate to have people dropping %{?_isa} all over the place where it's pointless.
16:57:22 <tibbs|h> But it would also be unfortunate to have this long list of places where you need it and places where you don't.
16:59:01 <skvidal> https://bugzilla.redhat.com/show_bug.cgi?id=573183
16:59:38 <skvidal> but that looks like a devel case, too
17:01:25 <rdieter> ugh, this is one of those cases where it's easy to just say:  use %{?_isa} where it make sense.  it's defining what 'makes sense' where it gets harder
17:01:53 <abadger1999> <nod>
17:02:10 <skvidal> rdieter: yes.
17:02:17 <rdieter> most arch'd packages with deps on the parent <=== makes sense , includes -devel case
17:02:35 <rdieter> dlopen'd libs
17:02:36 <kalev> perhaps this could be solved in yum depsolver instead? when package foo(i686) requires package bar, and available are bar-1.1-1.i686 and bar-1.1-2.x86_64, the depsolver would pick matching arch instead of higher NVR?
17:03:00 <skvidal> kalev: no
17:03:02 * rdieter waits for skvidal to puke
17:03:19 <tibbs|h> I was getting some popcorn.
17:03:24 <skvidal> kalev: adding special-case logic to yum to 'assume' things based on arbitrary data is just asking for pain
17:03:28 <skvidal> not only b/c it is a BAD idea
17:03:32 <racor> rdieter: What will happen if  usbmuxd goes "arch" -> "noarch"?
17:03:36 <skvidal> but also b/c then yum behaves different than apt and smart
17:03:45 <skvidal> and we have to chase does a god awful rathole
17:04:22 <skvidal> kalev: also - the issue here is not about picking a matching arch
17:04:22 <tibbs|h> I believe arch->noarch transitions create broken deps in this situation.
17:04:28 <rdieter> racor: yep, that's bad
17:04:40 <racor> AFAIU, this proposal hard codes a "one time state" into concrete and breaks the flexibility of rpm
17:04:56 <tibbs|h> I think broken deps is better than installing hundreds of i686 packages by mistake.
17:04:58 <rdieter> but as tibbs|h mentioned, the problem will become very obvious, and easily fixed at that point.
17:05:03 <skvidal> kalev: oh and finally - if you want arch to trump version I think you'll find that we'll be exchanging this set of bugs for a thousand other sets of bugs
17:05:07 <rdieter> tibbs|h: +1
17:05:10 <skvidal> where someone wants version to trum arch
17:05:23 <skvidal> tibbs|h: thanks :(
17:05:24 <racor> The appropriate place to tackle these issues are yum and rpm, not rpm spec.
17:05:28 <skvidal> unfortunately you don't get any of these bugs
17:05:29 <skvidal> I do
17:05:49 <tibbs|h> I think you misunderstood something.
17:06:00 <tibbs|h> Or I misunderstood something.
17:06:07 <racor> Sorry boys, my time's up, I've got to go,
17:06:22 <tibbs|h> My point is that if we add this, and then we have an arch->noarch transition, we may see broken deps but that's not a big problem.
17:06:34 <skvidal> tibbs|h: ah - then yes-  I agree
17:06:46 <abadger1999> So... I *think* that the present wording with the fooapp-plugins example will let people see that they shold be putting %{?_isa} into things like gvfs-afc;  it's a little overbroad but not a lot.
17:06:47 <skvidal> and the tools we're developing are for catching those issues before they hit the repo
17:06:53 <dgilmore> tibbs|h: right but thats highly visable and easily fixable
17:06:56 <tibbs|h> Not doing this at all seems to hose people's systems, and that's worse even though dealing with arch->noarch transitions is a valid issue.
17:07:15 <abadger1999> The lists are there but they don't seem too long to me.
17:07:45 <abadger1999> Would someone else want to take a stab at changing the draft or should we vote on it as is?
17:08:03 <tibbs|h> One question that remains from the last meeting is whether we're going to go adding these, or whether it will just be added to new packages and those where we see real problems.
17:08:17 <tibbs|h> For some definition of "we", of course.
17:08:33 <rdieter> tibbs|h: probably added everywhere, over time
17:08:33 <skvidal> I think it makes sense to refer to this as the problem crops up
17:08:59 * dgilmore wonders if we should not version the guidelines at points in time
17:09:08 <rdieter> anyway, I'm +1 to it as-is, I think, it's better than the status quo
17:09:19 <dgilmore> so we can see if things have been updated for new guidelines
17:09:20 <abadger1999> rdieter: +1 Old packages are not grandfathered but also not required to change until it's pointed out that it's wrong.
17:09:39 <tibbs|h> My main concern with this is that the rules be clear enough that package reviewers can understand when %isa needs to be added.
17:09:42 <limburgher> +1
17:09:49 <abadger1999> <nod>
17:10:01 <tibbs|h> abadger1999: Note that that's pretty much always the case with new guidelines.
17:10:02 <abadger1999> tibbs|h: Do they seem so in the present form or does something need clarification?
17:10:10 <abadger1999> tibbs|h: Very true.
17:10:18 <dgilmore> tibbs|h: unless its being execed or the dep is noarch it needs it
17:10:43 <limburgher> I'd love to see a way to determine the truth of the first bullet for a particular package.
17:10:50 <limburgher> But it's not a must
17:10:52 <limburgher> .
17:12:19 <abadger1999> skvidal: Could that bullet be changed to "explicitly required libraries (example: for dlopen'd libraries)"
17:12:36 * skvidal thinks
17:12:56 <limburgher> Meaning things autorequires wouldn't catch?
17:13:02 <skvidal> for any library that rpm is not going to be able to find on its own
17:13:03 <skvidal> yes
17:13:03 <abadger1999> limburgher: Right.
17:13:05 <tibbs|h> We also need to think about how this works with the existing "Explicit Requires" guideline.
17:13:10 <tibbs|h> http://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires
17:13:22 <limburgher> tibbs|h: Bingo
17:13:25 <tibbs|h> It may be worth combining the two so it's not confusing to readers.
17:15:23 <limburgher> <nods>
17:17:21 <abadger1999> Okay -- I'll take the task of merging this with the explicit requires section (and the subpackage-requires-main-package) section and we can look at it at the next meeting?
17:17:43 <abadger1999> Any other changes that people would like to see go in?
17:18:08 <tibbs|h> Sorry, I lagged out for about 90 seconds.  Comcastic.
17:18:52 <skvidal> abadger1999: if you could add a "and listen to seth when he says this is pain" to any of the rules, that'd be great.
17:19:15 <abadger1999> heh.
17:19:17 <abadger1999> Okay.
17:19:21 <abadger1999> Final topic:
17:19:28 <limburgher> :)
17:19:54 <abadger1999> #action abadger1999 will combine ArchSpecificRequires with a few more guidelines for next meeting
17:19:58 <abadger1999> #topic GSettings
17:20:15 <abadger1999> http://www.pubbs.net/201005/fedora/28725-packages-using-gsettings.html
17:20:42 <abadger1999> mclassen sent this addition for ScriptletSnippets.
17:21:02 * abadger1999 realizes there should  be a better thread on packaging-list too..
17:21:38 <abadger1999> http://lists.fedoraproject.org/pipermail/packaging/2010-May/007063.html
17:21:47 <abadger1999> That's the better link^
17:22:21 <tibbs|h> Was there ever any resolution about doing this in %posttrans or finding some way to not do it for every package?
17:22:32 <abadger1999> There wasn't.
17:22:34 <tibbs|h> Or was it determined to be a quick operation?
17:22:43 <abadger1999> No data either way :-(
17:22:59 <rdieter> I had suggested %posttrans here (as well as considering using %posttrans for other similar items)
17:23:04 <abadger1999> we can go with the "something is better than nothing and we can change it later" decision.
17:23:05 <tibbs|h> I sure wish the people coming up with these schemes could figure out how to do it in a way that isn't so antithetical to reasonable packaging.
17:23:26 <limburgher> I'd like a unicorn.
17:23:39 <abadger1999> Or we can try to work out something complex like the present gconf2 work.
17:24:02 <tibbs|h> Using a cache if its fast and not using the cache if it's outdated isn't exactly ace programming.
17:24:10 <abadger1999> rdieter: What do you think about the potential for breakage with %posttrans and settings stuff?
17:24:30 <rdieter> abadger1999: I think it's... none
17:24:53 <tibbs|h> I thought there was an issue with stale data being used if the update is delayed.
17:25:00 <tibbs|h> Otherwise why not just do it from cron.
17:25:17 <abadger1999> Because schema update can't break apps or because we aren't likely to run an app that depends on schemas in a post script?
17:25:20 <rdieter> tibbs|h: I suggested that eons ago, but it was throughourly rejected
17:25:41 <rdieter> sp?  you get the idea. :)
17:26:01 <tibbs|h> Yeah, I recall.
17:26:21 <tibbs|h> So it sounds like simple %post/%postun solves the immediate problem.
17:26:26 <rdieter> tibbs|h : stale data is a problem theoretically, in between the time the pkg lands on disk, until %posttrans runs
17:26:57 <rdieter> but I think the potential performance gains by the %post -> %posttrans move is worth it
17:27:24 <rdieter> ie, if these scriptlets were ever optimized to be noops in the case of non-stale cacche
17:27:56 <tibbs|h> Not to mention that running the script N times in posttrans is still faster because everything is cached.
17:28:19 <rdieter> that too, yeah
17:28:40 <tibbs|h> So, simple known to work solution that's potentially slow?  Or the alternative solution that may be faster but may have stale data problems?
17:29:16 <tibbs|h> Whatever we do, the guidelines are currently wrong so we shouldn't leave them as is.
17:29:45 <tibbs|h> Personally I'm inclined to optimize later.
17:29:52 <limburgher> I'm more inclined to try B.
17:30:25 <rdieter> I'm +1 either, though I'd prefer the %posttrans one  (we can consider extending that to other stuff like  update-desktop-database and update-mime-database later)
17:31:10 <limburgher> Yeah, at least fix the status quo
17:32:22 <tibbs|h> So nobody disagrees that we need to fix the current guidelines.
17:32:36 <tibbs|h> Ignoring %post/%posttrans, what should that fix look like?
17:32:38 <abadger1999> I'm +1 to either -- I think the particular apps that will use gsettings are unlikely to be used in this setup but avoiding stale cache *is* more correct.
17:32:46 <tibbs|h> The current scriptlets are correct for F13 and older, right?
17:32:59 <abadger1999> Yeah -- this is mostly an addition.
17:33:18 <SmootherFrOgZ> +1 for %posttrans one
17:33:29 <abadger1999> GSettings is a new tech being used in gnome... once apps port away from gconf, I imagine that we'll deprecate it and maybe eventually get rid of it.
17:33:39 <tibbs|h> Ugh, I can see the nasty scriptlets that would come from people trying to make one spec work with both.
17:35:04 <tibbs|h> It might be nice if there were some helper script or package that would just do the right thing.
17:35:13 <rdieter> as I understand it, apps/packages will use one or the other
17:37:19 <abadger1999> <nod>
17:39:46 <tibbs|h> So....
17:40:21 <tibbs|h> I'm +1 for doing something.  I can't really evaluate one over the other.
17:40:54 <abadger1999> We're at +3 for either %post or %posttrans  versions, +1 for %posttrans, and limburgher leaning towards %posttrans.
17:41:46 <limburgher> +1 for either, really.
17:42:46 <abadger1999> Okay, we pass the %posttrans version if everyone thinks that's acceptable :-)
17:43:36 <abadger1999> #info GSettings snippets passed, abadger1999 will write up the version we passed for the ScriptletSnippet page.
17:43:47 <abadger1999> #topic open floor
17:44:00 <abadger1999> Anyone want to bring anything up?  We're over time.
17:44:20 <tibbs|h> I'm done.  spot scheduled another meeting two weeks hence.
17:44:35 * abadger1999 remembers we had nottings question of FPC meeting reports but doesn't really want to hold us for that.
17:44:53 <tibbs|h> I thought the bot gave us those.
17:45:49 <abadger1999> tibbs|h: Yeah, his question was -- does FPC want the explicit back and forth of FPC passing; FESCo reviewing and ratifying; FPC writing up.
17:45:57 <abadger1999> FPC announcing
17:46:38 <tibbs|h> I thought we discussed that already.
17:46:44 <tibbs|h> Maybe it was a different discussion.
17:47:03 <abadger1999> I think it was the same -- but we only had three people present.
17:47:49 <limburgher> Was i there?  I don't remember that discussion.
17:47:51 <tibbs|h> My opinion has remained that I'd welcome allowing FPC to do more to fix broken or outdated guidelines without review, but that sending to FESCo should still be the default.
17:48:00 <abadger1999> k
17:48:45 <rdieter> what's the alternative?  stuff being tacitly auto-approved unless explicitly vetoed by fesco?
17:49:30 <limburgher> rdieter: I suppose.  I don't recall an explicit alternative.
17:49:46 <tibbs|h> I believe so.  We pass guidelines; if people complain to FESCo then they review.
17:50:33 <rdieter> personally, I'd prefer that optimization then, gets stuff done and in faster. less chance for items getting lost or forgotten too
17:50:55 <rdieter> but I don't feel strongly about it.  If folks like the extra oversight in now, that's fine
17:51:15 <abadger1999> rdieter me too... fesco can review explicitly if they want.
17:51:17 <tibbs|h> That's not beyond the realm of reason but I think we should at least reserve the chance to ask FESCo for things we know will be controversial.
17:51:27 <abadger1999> but it ould be asynchronous
17:51:33 <abadger1999> *would
17:51:55 <tibbs|h> Still, spot has indicated that he wants FESCo oversight.
17:53:49 <limburgher> I feel like rdieter does, so oversight is ok by me.
17:53:54 <abadger1999> I think asking fesco things would be separate -- that's part of fact finding for whether we should pass a guideline as is.
17:54:11 <pjones> well, the current fesco policy is that we try to ratify FPC's recommendations before our meetings happen.
17:54:16 <pjones> (on the tracker)
17:54:36 <limburgher> pjones: Saves time, no?
17:54:47 <pjones> limburgher: yeah, assuming everybody participates.
17:54:54 <abadger1999> pjones: <nod> still leaves problems where guidelines don't get written up b/c it goes from here to you and then doesn't get reassigned to someone to do the final writeup.
17:54:55 <limburgher> pjones: :)
17:54:58 <pjones> (one FESCo member has boycotted the async oversight, but...)
17:55:15 <pjones> abadger1999: yeah, that's a gap that should get fixed.
17:56:06 <limburgher> pjones: That's a bit like not voting.  If you won't participate, you can hardly complain.
17:56:17 <pjones> limburgher: no argument here.
17:56:50 <pjones> anyway, I didn't mean to derail.
17:57:05 <dgilmore> pjones: at least one person doing that doesnt block things
17:57:18 <limburgher> It sounds like the consensus is soft, but in favor of keeping FESCO oversight.
17:57:32 <pjones> tibbs|h: I don't think anybody on FESCo has a problem with FPC asking FESCo for things that are controversial, really.
17:58:02 <pjones> (though that might be better to simply bring up at a FESCo meeting than to float by in an FPC change and see if we notice ;)
17:58:10 <limburgher> I would hope not.
17:58:37 <tibbs|h> The bottom line is that it's FESCo's decision as to whether they want to spend time dealing with FPC stuff.
17:58:37 <limburgher> pjones:  Then how are we to implement our nefarious takeover?
17:58:50 <pjones> limburgher: most of us can be bribed with beer.
17:59:18 <tibbs|h> If things work it shouldn't take more than a couple of minutes of meeting time.  When I was on FESCo it sure took a lot longer.
17:59:22 <limburgher> tibbs|h: And they have yet to make this decision?
17:59:36 <tibbs|h> Dunno, I don't really follow FESCo these days.
18:00:04 <pjones> limburgher: we decided to do it asynchronously, with the possibility of bringing it up during meetings if things are contentious.
18:00:22 <pjones> (because spot asked us to keep reviewing FPC rule changes)
18:00:52 <limburgher> I don't see why we can't leave it at that for awhile, and see how we all (FPC+FESCO) like it.
18:01:34 <abadger1999> limburgher: Well, I would like to make it async -- FPC does its thing and then FESCo can ask that a new guideline be revisited if there's problems.
18:02:29 <pjones> that's certainly the goal of the current policy
18:02:32 <abadger1999> But yeah -- the fesco change is recent so we can see how it goes.
18:02:56 <limburgher> abadger1999: Sounds more streamlines.
18:03:01 <limburgher> s/s/d/
18:03:03 * abadger1999 notes  that I did the latest round of writeups since spot didn't -- but I've left announcing to spot so they aren't announced yet.
18:04:36 <limburgher> So is that all for today?
18:05:27 <tibbs|h> I sure hope so.
18:07:23 <abadger1999> Sounds like.
18:07:28 <abadger1999> #endmeeting