16:59:54 <nirik> #startmeeting FESCo meeting 20100108
16:59:54 <zodbot> Meeting started Fri Jan  8 16:59:54 2010 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:59:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:06 <nirik> #meetingname fesco
17:00:06 <zodbot> The meeting name has been set to 'fesco'
17:00:07 * skvidal awaits
17:00:14 <nirik> #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones cwickert mjg59
17:00:14 <zodbot> Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 nirik notting pjones skvidal
17:00:16 <jds2001> oh geez, thx nirik :)
17:00:27 * dgilmore is here
17:00:27 <nirik> #topic init process
17:00:29 * skvidal is here
17:00:37 * cwickert is here too
17:00:57 <ajax> GOOD MORNING IRC
17:01:35 <dgilmore> welcome new fesco peeps
17:01:36 <pjones> zonk
17:02:29 <nirik> Welcome to new fesco folks, and thanks to departing ones...
17:03:03 <nirik> for the record:
17:03:08 <nirik> Welcome New members - Adam Jackson, Christoph Wickert, Peter Jones and Matthew Garrett
17:03:08 <nirik> Farewells to departing members - Jon Stanley, Dan Horák, Jarod Wilson, and David Woodhouse
17:04:24 <notting> sorry i'm late
17:04:45 <nirik> ok, I guess lets go ahead and start in.
17:04:53 <nirik> #topic New Chair
17:05:03 * skvidal nominates nirik
17:05:22 * notting seconds!
17:05:27 <mjg59> Works for me
17:05:28 <ajax> subscribe
17:05:30 <nirik> I'd be happy to do it unless someone else wants it... if so they are welcome to it. ;)
17:05:38 <pjones> no, that's okay, you can do it ;)
17:05:50 <cwickert> +1 for nirik
17:06:22 <nirik> ok, will try not to screw up too badly. ;)
17:06:35 <skvidal> no, that's fine
17:06:40 <skvidal> :)
17:06:52 <nirik> #topic Meeting time
17:07:01 <nirik> so, do we want to keep meeting at this time? or change?
17:07:06 <mjg59> I've a mild preference for it not to be at 12
17:07:09 <mjg59> (EST)
17:07:18 <dgilmore> +1 for nirik
17:07:21 <skvidal> mjg59: lunch is for the weak -- or maybe the hungry
17:07:21 <mjg59> It interferes with lunch...
17:07:27 <cwickert> mjg59: what it this in UTC?
17:07:36 <mjg59> cwickert: Right now we're at 1700UTC
17:07:43 <cwickert> right
17:07:43 <pjones> 2pm (EST5EDT) on a thursday would be nice.
17:07:48 <mjg59> 1800 would suit me better
17:07:51 <skvidal> hmm
17:07:55 <skvidal> 2pm thursday would be fine
17:07:59 <skvidal> pjones: +1
17:08:09 <pjones> friday meetings suck.  as do meetings during or immediately after lunch time.
17:08:22 <dgilmore> 2pm thursday doesnt really work for me
17:08:22 <cwickert> mjg59: 1800 UTC is fine for me, even better than 1700, but both are ok
17:08:24 <nirik> whats 2pm EST in UTC? :)
17:08:30 <mjg59> nirik: 1900
17:08:32 <pjones> 1900 I think/
17:08:35 <pjones> right now, anyway ;)
17:08:35 <ajax> nirik: add 5.
17:08:41 <nirik> (at least for now, stupid DST)
17:08:41 <Kevin_Kofler> 19:00 UTC is very late…
17:08:53 * cwickert likes 1900 UTC
17:08:56 <Kevin_Kofler> It's dinner time or even after dinner time around here.
17:09:01 <pjones> 11am (1600) would also work?
17:09:13 <dgilmore> pjones: not on thursdays
17:09:14 <pjones> or even 10:30 (1530)
17:09:27 <pjones> dgilmore: I'm open to any of three other days of the week as well ;)
17:09:28 <cwickert> pjones: not really, still working then
17:09:28 <nirik> pjones: thats on the early side for me. ;( (MST/MDT)
17:09:35 <ajax> 11am is a conflict for me
17:09:46 <ajax> 1100EST thursdays that is
17:09:54 <ajax> E*T really
17:09:57 <nirik> how about 18:00 UTC on fridays? (ie, just push it out one hour from now)?
17:10:00 <Kevin_Kofler> For the record, +1 from me for nirik as a chair (and sorry for joining in late).
17:10:13 <nirik> Kevin_Kofler: thanks. No problem.
17:10:19 <pjones> nirik: that works for me, but I would /prefer/ non-friday.
17:10:22 <mjg59> From my point of view, any time between 14:30UTC and 21:00UTC works for me, except for 18:00UTC
17:10:35 <mjg59> Sorry, 17:00UTC
17:10:37 * notting is ok with current, but would prefer slightly later
17:10:37 * dgilmore thinks we should use something to work out a suitable time
17:10:40 <skvidal> how about we use whenisgood?
17:10:48 <cwickert> +1
17:10:49 <pjones> skvidal: good plan
17:10:49 <dgilmore> skvidal: we should
17:10:51 <nirik> yeah, we could use one of those things...
17:11:09 <mjg59> Ok. Do that, discuss results on list, enact next week?
17:11:19 * skvidal goes to open one
17:11:27 <nirik> mjg59: sounds good to me.
17:11:41 <Kevin_Kofler> I guess I can deal with many times, no go at the moment is Tuesday between 12:00 and 15:00 UTC, otherwise I could deal with most times (though some are more inconvenient than others).
17:11:45 <nirik> note that moving the fesco meeting does affect some things like packaging comittee...
17:11:59 * skvidal waits
17:12:12 <mjg59> nirik: Then we simply need to abolish the packaging committee
17:12:19 <nirik> mjg59: :)
17:12:38 <nirik> #agreed Will try and come up with a better time/day for meeting and announce it early next week.
17:12:43 <Kevin_Kofler> The current time range is a bit annoying because it's around dinner time (and it's around lunch time in the US, so everyone kept complaining).
17:12:58 <nirik> ok, shall we move on to the next topic then?
17:13:06 <pjones> okay.
17:13:07 <cwickert> go for it
17:13:54 <nirik> #topic #298 Revoke Paul Johnsons pacakger access and put him on probation. -
17:13:59 <nirik> .fesco 298
17:14:00 <zodbot> nirik: #298 (Revoke Paul Johnsons pacakger access and put him on probation.) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/298
17:14:02 <skvidal> this sounds like it's been resolved
17:14:13 <nirik> Yeah, I think we should defer/not deal with this now.
17:14:17 <pjones> or at least delayed.
17:14:19 <nirik> He's having problems with his mail server.
17:14:28 <nirik> so, on to the next... sorry about that. ;)
17:14:46 <Kevin_Kofler> Yeah, -1 to the sledgehammer approach, let's try diplomacy first. :-)
17:15:00 <pjones> +1 for "defer"
17:15:07 <nirik> The next one we need to defer probibly too.
17:15:10 <ajax> defer.
17:15:19 <nirik> #topic #278 Better Hostname - https://fedoraproject.org/wiki/Features/BetterHostname
17:15:21 <cwickert> nevertheless there needs something to be done, he even deleted his own changelog entries
17:15:23 <nirik> .fesco 278
17:15:24 <zodbot> nirik: #278 (Better Hostname - https://fedoraproject.org/wiki/Features/BetterHostname) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/278
17:15:34 <notting> cwickert: yeah, he said that was a script that he's not using now
17:15:48 <nirik> this is waiting on the desktop folks for some more info... it's not high priority for them.
17:16:06 <nirik> However, if any folks want to add new questions or discuss it now we can.
17:16:10 <mjg59> This keeps coming up every week. If we're going to keep deferring it, can we flag it as deferred until updated?
17:16:22 <skvidal> +1
17:16:36 <mjg59> Though really, it seems to have been scrutinised far more than the majority of features
17:16:46 * dgilmore thinks that we should reject it due to the proposerscontinually not providing the requested info
17:17:03 <skvidal> mjg59: I disagree - it's just been scrutinized the normal amount and questioned
17:17:09 <skvidal> and the questions have not been answered
17:17:23 <nirik> I'd be fine with moving it off the agenda until there is new info.
17:17:41 <mjg59> nirik: I think that's preferable to rejecting it
17:17:53 <pjones> mjg59: part of that is probably my fault - in that he's asking anaconda to add features that aren't specified in the proposal
17:17:59 <ajax> yeah, defer until updated.
17:18:06 <pjones> but yeah, defer until updated.
17:18:08 * nirik isn't against it, just would like more info about corner cases, etc.
17:18:09 <mjg59> It'll defacto get rejected if there's no progress in implementation
17:18:53 <nirik> ok, I'll removing meeting keyword and move on then.
17:19:11 <nirik> #topic #299 Feature: AtSpiTwo - https://fedoraproject.org/wiki/Features/AtSpiTwo
17:19:12 <Kevin_Kofler> defer +1
17:19:16 <nirik> .fesco 299
17:19:17 <zodbot> nirik: #299 (Feature: AtSpiTwo - https://fedoraproject.org/wiki/Features/AtSpiTwo) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/299
17:19:18 <wonderer> mchua: ticket now?! as you wish...
17:19:47 <mjg59> Looks sane, this code has needed reworking for a long time
17:19:58 <Kevin_Kofler> Re AtSpiTwo, that one is cool as it may allow accessibility interoperability between GTK+ and Qt apps.
17:20:04 <Kevin_Kofler> There's a Qt implementation of it.
17:20:06 <mjg59> And it's what upstream are doing
17:20:14 <pjones> mjg59: the code looks fine.  I can't figure out why it needs a feature proposal htough.
17:20:24 <pjones> seems like it's just boring development.
17:20:25 <dgilmore> +! for it it seems like a win,  and can co-exist with whats there
17:20:29 <dgilmore> +!
17:20:31 <nirik> yeah, most users won't care much, but it might be nice to tout us doing it first
17:20:34 <dgilmore> +1
17:20:37 <mjg59> pjones: If it were relnoted as "Accessibility will no longer make your desktop crash randomly"?
17:20:38 <pjones> I guess.
17:20:55 <Kevin_Kofler> I hope we can get the Qt part in, but that'll be a KDE SIG task.
17:20:56 * notting is +1
17:20:56 <pjones> mjg59: relnoting it is fine - we seriously need to divorce that from being a "Feature".
17:20:57 <ajax> i don't have any engineering objections to it.
17:21:02 <Kevin_Kofler> The feature page is OK as is.
17:21:04 <Kevin_Kofler> So +1 from me.
17:21:14 <mjg59> In the sense that it fits the current feature process, +1
17:21:18 <cwickert> +1 from me too, looks sane
17:21:19 <pjones> right.
17:21:28 <nirik> +1 here as well.
17:21:55 <nirik> #agreed The AtSpiTwo feature is accepted.
17:22:05 <Kevin_Kofler> #link https://labs.codethink.co.uk/index.php/p/qt-atspi2/
17:22:08 <Kevin_Kofler> #info (the Qt implementation)
17:22:27 <nirik> #topic #300 Feature: BetterWebcamSupportF13 - https://fedoraproject.org/wiki/Features/BetterWebcamSupportF13
17:22:32 <nirik> .fesco 300
17:22:33 <zodbot> nirik: #300 (Feature: BetterWebcamSupportF13 - https://fedoraproject.org/wiki/Features/BetterWebcamSupportF13) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/300
17:23:01 <mjg59> Incremental improvement in hardware support? Seems worth mentioning.
17:23:43 <pjones> yeah
17:23:44 <Kevin_Kofler> Right, +1.
17:23:55 <nirik> yeah, this is a add on to the f10 feature that brough in a bunch of support.
17:24:05 <cwickert> as I own one of these cams I'm +1
17:24:14 <ajax> nice doc, no engineering objections, approve.
17:24:18 * notting is +1
17:24:32 <dgilmore> +1
17:24:33 <mjg59> +1
17:24:36 * skvidal sees no reason to -1
17:24:37 <skvidal> so +1
17:25:03 <nirik> yeah, +1 here as well... hopefully folks to who webcam support is important will see this feature and give fedora a try.
17:25:18 <nirik> #agreed The BetterWebcamSupportF13 feature is approved.
17:26:01 <nirik> #topic #291: Man pages Packaging Guideline
17:26:04 <nirik> .fesco 291
17:26:05 <zodbot> nirik: #291 (Man pages Packaging Guideline) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/291
17:26:19 <nirik> This was approved at the last fesco meeting, but still needs to be written up.
17:26:42 <nirik> does someone want to take the task of doing so, or bugging the packaging folks to do so?
17:27:03 <mjg59> I can write it up
17:27:23 <nirik> it may need special powers in the Packaging space of the wiki (see abadger1999 or spot)
17:27:34 <mjg59> Will do
17:27:45 <dgilmore> nirik: only packaging committe can update the packaging guidelines
17:28:08 <mjg59> Well, I'll submit a writeup to them
17:28:08 <nirik> yeah
17:28:17 <nirik> thanks mjg59
17:28:20 <nirik> #topic Open Floor
17:28:25 <nirik> thats all I had for meeting items.
17:28:32 <nirik> Anyone have any topics for Open Floor?
17:28:49 <dgilmore> just a reminder mailing lists are about to be migrated
17:28:59 <skvidal> dgilmore: thanks
17:29:13 <pjones> nirik: might we want to discuss not having to approve every release note as a feature? ;)
17:29:43 <mjg59> I think it was pretty clear from the voting period that several of us had concerns about the current feature process
17:29:51 <ajax> pjones: sort of hard to know whether a feature is "just a release note" or notwithout someone reviewing it.
17:29:55 <nirik> Sure, proposals for change welcome.
17:30:03 <mjg59> But I'm not sure IRC is the best way to start this conversation
17:30:12 <pjones> mjg59: fair enough
17:30:14 <nirik> also note that "release note" doesn't really carry much weight in reviews or media writeups.
17:30:15 <Kevin_Kofler> Uh, people can add whatever they want to the release note beats already.
17:30:18 <skvidal> umm
17:30:28 <Kevin_Kofler> There's no requirement that everything has to go through the feature process.
17:30:30 <skvidal> I don't want fesco meetings to move to phone conversations
17:30:39 <nirik> skvidal: me either. ;)
17:30:40 <Kevin_Kofler> skvidal: +1
17:30:41 <skvidal> mjg59: if that's what you were suggesting
17:30:41 <mjg59> pjones: Perhaps better to come up with some strawmen proposals first?
17:30:44 <mjg59> skvidal: No
17:30:47 <skvidal> mjg59: okay, good
17:30:47 <Kevin_Kofler> IRC is great.
17:31:08 <mjg59> What I meant was that it's easier to have this kind of discussion if we have a more concrete starting point
17:31:21 <pjones> I think he was suggesting emailing some strawmen out
17:31:50 <skvidal> okay. that's fine
17:31:55 <mjg59> If people can formualte a list of their perceived issues and ways that they'd fix them, we can take a bash at that and see whether we end up with something that turns out to be the current process or not
17:32:03 * nirik nods.
17:32:10 <skvidal> other than there being a lot of features to review
17:32:20 <skvidal> I don't have any specific issues with the process
17:32:53 <mjg59> But I don't think we need a specific action point on this
17:33:16 <mjg59> The people with issues (me included) should just get on with it and come up with something to present to the community/committee
17:33:20 <nirik> at times it seems strange to approve or nitpick something that someone is already going to do...
17:33:24 <Kevin_Kofler> The main weirdness about the process is that features can get rejected for various reasons, but still implemented, just not advertised.
17:33:33 <nirik> Kevin_Kofler: yeah.
17:34:11 <nirik> I do see we have some outstanding non meeting tickets we could go over for status, etc if folks are willing...
17:34:14 <pjones> nirik: yeah, there's certainly a bright line of "will it happen and just not be noticed if it wasn't a 'Feature'", and in that case there's a strong argument that it shouldn't need to be a Feature to get relnoted.
17:34:21 <Kevin_Kofler> I think it would make more sense to document what actually got implemented, no matter whether it made some deadline or not, and on the other hand, if we reject something due to strong technical reasons, stricter enforcement of our "no".
17:34:37 <Kevin_Kofler> I also think that we need a process to advertise features in updates.
17:34:38 <pjones> but since we've already all agreed we should come up with lists and proposals on the mailing list, I think it's maybe time to move to the next subject.
17:34:57 <Kevin_Kofler> Especially new packages are allowed in updates, they should also be advertised as such and not as a feature of the next release months later.
17:35:03 <nirik> pjones: yeah, sounds good.
17:35:47 <notting> Kevin_Kofler: that can always be fixed by changing what goes in updates
17:35:56 <Kevin_Kofler> But that's a bad solution.
17:36:05 <Kevin_Kofler> The problem is not that we allow those updates, they are a GOOD thing.
17:36:10 <pjones> I'd prefer to /mitigate/ features in updates.
17:36:14 <Kevin_Kofler> The problem is that we don't advertise them enough.
17:36:15 <pjones> they're not a good thing - they slow down development.
17:36:27 <Kevin_Kofler> Not from the user's perspective, they don't.
17:36:33 <Kevin_Kofler> For the user, they speed it up.
17:36:41 <Kevin_Kofler> They get their new feature up to 6 months earlier.
17:36:44 <nirik> Kevin_Kofler: we don't have a good channel for advertising them to our end users tho... Features get media coverage and reviews and our docs.
17:36:45 <pjones> that sounds like a problem on it's own
17:37:35 <Kevin_Kofler> With sufficient work on the developer side, PackageKit could do a better job of documenting those enhancement updates.
17:37:51 <Kevin_Kofler> For example, we could already fill in a feature page for the update which the update notes could then link to.
17:38:05 <Kevin_Kofler> It'd just needs a process.
17:38:06 <pjones> the "up to six months earlier" argument is sortof a silly math problem
17:38:20 <Kevin_Kofler> No, it's just basic Mathematics. :-)
17:38:29 <pjones> if a developer is working on a feature in N-1, then yes, they'll get that feature earlier, but there's something else that they're getting reciprically later.
17:38:40 <Kevin_Kofler> Not necessarily.
17:38:45 <mjg59> Is this discussion likely to lead to a useful conclusion that's within our field of responsibility?
17:38:59 <nirik> shall we move this to the lists for strawman/proposals and move on?
17:39:05 <pjones> sure.
17:39:07 <Kevin_Kofler> You're assuming that the developers working on features are a saturated resource.
17:39:17 <pjones> Kevin_Kofler: of this I am sure.
17:39:19 <Kevin_Kofler> Maybe they are now.
17:39:23 <nirik> #topic #225 Bugzilla 484855 - Mediawiki Fedora-only patch
17:39:26 <Kevin_Kofler> But if you ban feature updates, no they won't be anymore.
17:39:26 <nirik> .fesco 225
17:39:28 <zodbot> nirik: #225 (Bugzilla 484855 - Mediawiki Fedora-only patch) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/225
17:39:31 <nirik> Kevin_Kofler: any news on this?
17:40:01 <nirik> it seems to have just gone back to status quo. ;(
17:40:03 <Kevin_Kofler> No. I'm starting to think it would make more sense to appoint another mediator, as I completely and utterly failed there.
17:40:28 <Kevin_Kofler> Too much stuff to do, and right now a broken Internet connection at home to compound things.
17:40:47 <nirik> Kevin_Kofler: :( Sorry to hear it...
17:41:18 <Kevin_Kofler> I might have more time to look into this next week, but then again I might not.
17:41:20 <nirik> Anyone willing to step up and mediate? or have ideas who we could appoint to do so that has no horse in the race?
17:41:34 <ajax> that bug is way into tl;dr land.  someone one-line it for me.
17:41:46 <skvidal> tl;dr?
17:41:51 <wwoods> "too long; didn't read"
17:41:54 <skvidal> ah
17:41:56 <Kevin_Kofler> That's the main issue, the dispute is complex.
17:42:11 <Kevin_Kofler> It's hard to figure out who's doing the right thing there.
17:42:11 <nirik> ajax: the fedora mediawiki package is packaged in weird way that some say is broken. (some parts of upstream as well).
17:42:33 <nirik> maintainer is unwilling to change.
17:42:36 <Kevin_Kofler> The maintainer says it's required for FHS compliance, upstream says that's not true.
17:42:40 <pjones> hrm, seems like kevin's right about it generally being the package maintainers call, but also seems like the patch is broken.
17:43:06 <Kevin_Kofler> And they promised in August to sort it out with each other, but nothing happened since then.
17:43:18 <pjones> at the same time, not having perfect FHS compliance (though it is against the policy) isn't the worst thing to ever happen
17:43:59 <nirik> pjones: FHS is a SHOULD item...
17:44:04 <nirik> "Any deviation from the FHS should be rationalized when the package is reviewed."
17:44:07 <pjones> right.
17:44:48 * nirik notes also that fedora's mediawiki is NOT using the fedora/epel packaging, it's using the method ricky / upstream suggest.
17:45:27 <ajax> well, i don't have a horse in the race, but i'm unlikely to be able to look at it for a good three weeks
17:45:29 <nirik> So, anyone willing to be a moderator? Or do we want to propose some other solution?
17:45:31 <notting> nirik: by 'fedora's', you mean fedora infrastructure?
17:45:35 <nirik> notting: yes, sorry.
17:46:45 * nirik hears the chirping crickets. ;)
17:47:00 <nirik> ok, we can ask around and see if we can come up with a mediator before next meeting?
17:47:57 <ajax> i'd be happy to look into it, as long as no one minds that not being soon
17:48:15 <nirik> well, it's waited this long... and Kevin_Kofler might be able to look further as well...
17:48:49 * nirik would be perfectly happy for ajax to look at it.
17:48:55 <mjg59> The bug mentioned appears to have been fixed?
17:49:24 <mjg59> A good start would probably be to have a separate bug that just discusses this patch
17:50:08 <mjg59> Although the ticket seems to have taken on that role
17:50:27 <nirik> mjg59: it's not clear that it is fixed... the maintainer says so, ricky/upstream say not, or only one case of the bug.
17:50:35 <nirik> there's a lot of back and forth. ;(
17:50:58 <mjg59> nirik: The bug was opened with a pretty defined problem report, and nobody (in the bug) appears to say that it hasn't been resolved
17:51:03 <ajax> right then, i'll take a look first week of february if no one beats me to it.
17:51:26 <mjg59> I think it's also the case that the FHS aspect is probably a red herring
17:51:33 <pjones> mjg59: it certainly appears so
17:51:42 <nirik> ajax: thanks.
17:51:44 <mjg59> In that FHS compliance can be achieved without patches upstream doesn't like
17:52:03 <nirik> #agreed ajax will take a look at the issue for FESCo
17:52:03 <mjg59> But the maintainer believes that the benefits of his approach outweigh the disadvantages caused in terms of upstream divergence
17:52:16 <mjg59> But beyond that, yeah, if ajax is going to take a look then that would be great
17:52:54 <mjg59> We got anything else for today?
17:53:08 * nirik looks over the open tickets at https://fedorahosted.org/fesco/report/1
17:54:10 <nirik> we could discuss #297 Please consider the idea of a security (privilege escalation) policy I suppose.
17:54:25 <nirik> But again, looks like more something that should get hashed out on the lists/have a proposal attached.
17:54:35 <nirik> #topic Open Floor (again)
17:55:00 <nirik> There's some other things that that need to be closed... I can do that over the next week
17:55:14 <nirik> Does anyone have anything they would like to bring up/discuss?
17:55:32 <notting> who's starting the whenisgood thing for scheduling?
17:55:50 <nirik> skvidal: ?
17:56:07 <pjones> seth seemed to indicate that he would
17:56:23 * cwickert can do it, I'm already logged in atm
17:56:26 <notting> ok, sorry, missed that
17:57:02 <cwickert> skvidal: are you going to do the whenisgood poll or should I?
17:59:04 <nirik> cwickert / skvidal: You guys can work out who is making it and mail the link to the list?
17:59:14 * nirik can make sure everyone has been added to the list.
17:59:25 <skvidal> sorry my network dropped for a few minutes
17:59:31 <skvidal> cwickert: if you'd like to make it, that's fine
17:59:40 <cwickert> already working on it
17:59:44 <skvidal> cwickert: thanks
17:59:49 <skvidal> nirik: all worked out
18:00:08 <nirik> groovy. ;)
18:01:17 <cwickert> #link http://whenisgood.net/fesco-meeting
18:01:28 <Oxf13> is it still open floor?
18:01:32 <nirik> Oxf13: yep
18:01:58 <Oxf13> quick question for FESCo, how do you feel about packages using macros for things like description, when the macro definition exists in some other package?
18:02:14 <Oxf13> %description
18:02:14 <Oxf13> %{_mingw32_description}
18:02:22 <Oxf13> where that description exists somewhere else
18:02:23 <notting> that initially sets off my 'ew' meter
18:02:25 <skvidal> is there a buildreq relationship?
18:02:43 <Oxf13> skvidal: there is, however the srpm that gets published out of koji will not have that description filled in
18:02:47 <pjones> it's ew, but in the case where it's a suite of programs that belong together and there's a buildreq, it /kindof/ makes sense.
18:02:57 <Oxf13> because the initial srpm creation is done without the builddeps installed, and then passed around to the builders
18:03:09 <Kevin_Kofler> If the SRPM doesn't get the macro filled in, that's an issue somewhere indeed.
18:03:12 <pjones> that's very ew.
18:03:15 <skvidal> Oxf13: the srpm seems like an issue
18:03:22 <dgilmore> Oxf13: i dont find it acceptable
18:03:32 <Kevin_Kofler> I'd blame Koji, but on the other hand having the SRPM creation pull in lots of BRs would also suck.
18:03:33 <skvidal> Oxf13: maybe another question - what's the justification?
18:03:37 <Oxf13> (this just landed on my plate as  "mock" bug)
18:03:37 <skvidal> I mean it's a frelling description
18:03:38 <pjones> yeah, if the srpm winds up not having the description, that's a problem.
18:03:45 <skvidal> is it really that big of a deal to dupe it?
18:03:48 <Kevin_Kofler> The justification is not to have to copy and paste the same blurb all the time, I guess.
18:03:52 <pjones> skvidal: in the case of mingw - a lot of typing.
18:03:54 <ajax> i would only find that acceptable if the template macro ended up in redhat-rpm-macros or something
18:03:56 <pjones> or copy+paste.
18:03:58 <skvidal> pjones: ?
18:03:58 <Kevin_Kofler> And not to have to do the changes everywhere.
18:04:01 <pjones> which admittedly isn't that compelling
18:04:10 <skvidal> does the descript change A LOT?
18:04:12 <skvidal> and if so, why?
18:04:17 <Oxf13> I don't think it does
18:04:18 <dgilmore> ajax: thats the only way it could possibly be acceptable
18:04:32 <Oxf13> I think rjones is just trying to macro out everything he possibly can to make it 'fast' to churn out packages
18:04:34 <skvidal> -1 - this shouldn't be allowed and someone is "over optimiizing"
18:04:43 <Southern_Gentlem> 0xf13 squash it now before it grows
18:04:46 <pjones> -1 - what seth said
18:04:48 <ajax> we already have template macros in r-r-m (for debuginfo packages, but still)
18:04:57 <Oxf13> skvidal: it's mingw so that shouldn't be surprising
18:06:06 <nirik> yeah, -1 don't do this.
18:06:19 <ajax> gedankenexperiment: is it reasonable to have some package metadata describing the srpm construction requirements for a package?
18:06:26 <Oxf13> so the next question is how does FESCo fix this?
18:06:38 <ajax> are there other scenarios where you'd want that kind of information passed in?
18:06:44 <nirik> Oxf13: ask him to pretty please change it?
18:06:47 <pjones> Oxf13: we refer you to the packaging group.
18:06:58 <ajax> presumably they write a sed script.
18:07:07 <pjones> there are rules.  this probably ought to be among them ;)
18:07:15 <Kevin_Kofler> ajax: I like that idea.
18:07:18 <skvidal> pjones: 'don't be a nimrod'? I think that's a rule of life
18:07:24 <Kevin_Kofler> I think just banning the macros in the specfiles is suboptimal.
18:07:29 <pjones> skvidal: sometimes, I find it useful to be a bit more specific.
18:07:41 <skvidal> pjones: don't be a nimrod in packaging
18:07:54 <skvidal> pjones: "if you're being that clever, go find a hobby"
18:07:55 <nirik> "you cannot legislate common sense". ;)
18:07:56 <abadger1999> Oxf13: If you can come up with a good Packaging Guideline that nixes this, I'll try to get it passed.
18:08:09 <Oxf13> this might run afoul of one of the more "fuzzy" guidelines, about readability and what not
18:08:19 <ajax> Kevin_Kofler: i can't think of a motivation against the extra metadata, but i can't come up with another instance where it'd be useful.
18:08:39 <abadger1999> I think it encourages readaility :-)  (Too many macros is unreadable)
18:09:04 <Oxf13> ajax: well, BuildRequires are that metadata.  They describe what is required to be installed in order to full create the srpm
18:09:20 <Kevin_Kofler> I could imagine adding some macros to kde-filesystem for use at SRPM build time.
18:09:24 <Kevin_Kofler> Though right now we don't have any.
18:09:27 <pjones> "if your description doesn't show up right in the srpm, the srpm is broken"
18:09:27 <Oxf13> abadger1999: "this" in my statement meant the macros
18:09:30 <ajax> Oxf13: well, we could create the srpm twice ;)
18:09:33 <Kevin_Kofler> All our macros are only needed at package build time.
18:09:47 <ajax> build it, inspect its BRs, install them, build it again, toss the chroot
18:09:54 <Oxf13> ajax: the problem with going down this route is that some of the macros may be arch specific
18:10:06 <abadger1999> Oxf13: Ah -- well, I agree... but I also think clearly spelling this out would be better.
18:10:10 <Oxf13> we've never made a promise that hte srpm you get is suitable in its exact form for every arch
18:10:16 <ajax> Oxf13: ick, yes.
18:10:24 <Kevin_Kofler> The main problem I see there is that it'll slow down SRPM creation a lot. :-(
18:10:31 <Oxf13> and I really don't want to go back to having specific srpms for each arch, as the mirrors would hate us
18:10:37 <pjones> the main problem I see here is that this is crazy.
18:10:43 <skvidal> pjones: +1
18:10:47 <Kevin_Kofler> Koji takes quite some time to fetch BRs.
18:10:47 <nirik> I don't think the "problem" here justifies some more code.
18:10:54 <skvidal> nirik: +1
18:10:55 <Oxf13> pjones: yeah, forming a guideline around that is hard :/
18:10:56 <ajax> i agree, i'm just trying to elaborate the justification.
18:11:05 <ajax> so that we can write it down
18:11:06 <skvidal> okay
18:11:11 <Kevin_Kofler> Maybe we could just hardcode the mingw32 macros into the buildroot for SRPM creation?
18:11:13 <skvidal> does the packaging guidelines have anything tlike
18:11:17 <Oxf13> now, the buildsystem /does/ rebuild the srpm before it uses it to build the binary
18:11:23 <skvidal> "anything fesco or the pkg commit says is bad"?
18:11:27 <Kevin_Kofler> We'd allow only macro and -filesystem packages, on explicit request.
18:11:28 <Oxf13> each builder takes the canonical srpm, rebuilds it, then binary builds it
18:11:28 <skvidal> and if not, why not
18:11:31 <Kevin_Kofler> I don't think that'd hurt a lot.
18:11:33 <pjones> Kevin_Kofler: maybe we could just put the text for the packages into the packages.
18:11:49 <Oxf13> skvidal: we say it's bad today, what's to stop the next package from duplicating this ?
18:11:57 <pjones> adding them to f-r-c sets a terrible precedent.
18:12:02 <ajax> here's a proposal:
18:12:05 <skvidal> Oxf13: nothing orther than people checking things
18:12:12 <skvidal> Oxf13: and that's the point - we cannot stop all stupid
18:12:16 <pjones> (or anywhere else, really)
18:12:16 <skvidal> but we can catch as catch can
18:12:20 <Oxf13> skvidal: fair enough.
18:12:21 <Kevin_Kofler> Oxf13: If it's only small -filesystem or -macros packages, I don't see that as a big issue at all.
18:12:22 <ajax> i'll write up a description of how srpms get created that mortals can understand
18:12:29 <Kevin_Kofler> Those packages are fast to install into the buildroot.
18:12:30 <abadger1999> skvidal: Nope.  It has something about common sense or whatnot but that's not so useful ... many of the Guidelines are created /c two people disagree on what is common sense.
18:12:38 <Oxf13> Kevin_Kofler: doesn't solve the problem unless we start forcing all those packages to be pulled in at srpm creation time
18:12:43 <skvidal> abadger1999: which is why the committee exists
18:12:48 <Oxf13> Kevin_Kofler: the /initial/ srpm creation time.
18:12:50 <Kevin_Kofler> Yeah, we'd require an explicit request to get those pulled in.
18:12:55 <skvidal> to decide what is the commone sense
18:12:57 <ajax> and in that, i'll point out the caveats packagers should be aware of (arch-specificity, etc)
18:13:00 <Kevin_Kofler> And then we'd just hardcode the list.
18:13:07 <ajax> including this bit about macro expansion
18:13:14 <Kevin_Kofler> I don't think those will ever grow to a problematic size.
18:13:22 <Oxf13> 1 is a problematic size
18:13:22 <Kevin_Kofler> Right now I think there's only the MinGW macros.
18:13:27 <abadger1999> skvidal: true... but normally, we encode the decision into a new guideline rather than having a blanket, do what we say rule.
18:13:44 <ajax> so if we then say "srpms emitted by koji must meet these requirements", people can know how to make that happen
18:13:47 <skvidal> abadger1999: I like a do what we say rule when the rule violation is 'over optimization and ugliness'
18:13:48 <Kevin_Kofler> It takes what to install on the builder… 10 seconds?
18:13:52 <nirik> do we have a way to detect all current cases of this issue?
18:13:53 <abadger1999> :-)
18:14:06 <skvidal> abadger1999: think of it like declining a patch b/c of code style
18:14:07 <Oxf13> nirik: a big grep across all the spec files
18:14:09 <ajax> nirik: sure, grep for %{ in srpm descriptions
18:14:18 <skvidal> abadger1999: the Packaging committee and fesco are the  arbiters of taste here
18:14:19 <nirik> is it only description?
18:14:21 <skvidal> this is godawful ugly
18:14:25 <nirik> or any other fields?
18:14:26 <Oxf13> there are likely other fields where macros in srpms can get you in trouble
18:14:37 <nirik> right.
18:14:44 <Kevin_Kofler> ajax: That won't catch everything.
18:14:47 <Oxf13> although due to how koji builds things we mitigate most of those
18:14:52 <Kevin_Kofler> Or actually the opposite.
18:14:56 <nirik> so, perhaps we should figure out how to find them / which cause problems and then base the guideline on that?
18:14:56 <Kevin_Kofler> It'll catch a lot of stuff that's fine.
18:15:00 <pjones> Kevin_Kofler: incremental improvement is not a bad thing.
18:15:17 <Kevin_Kofler> A lot of rdieter's packages have a %description of: %{summary}.
18:15:20 <Kevin_Kofler> That's valid.
18:15:27 <Oxf13> we'd have to scrub out any macro that is defined within the spec itself, or within r-r-c
18:15:27 <Kevin_Kofler> It doesn't require anything in the buildroot.
18:15:31 <ajax> Kevin_Kofler: that'll be expanded though
18:15:37 <ajax> i said srpm, not spec.
18:15:38 <Oxf13> actually yea
18:15:47 <Kevin_Kofler> ajax: OK, I guess you're right. :-)
18:15:50 <Oxf13> ajax is right, query the pile of srpms for unexpanded macros
18:16:02 <pjones> +1 to that
18:16:15 <abadger1999> skvidal: So.... if we want that, I think it's fesco's juridiction to say so.  It's kind of a "All power for FPC derives from fesco" so fesco can add the ability for fpc to rule on matters of style.
18:16:19 <Oxf13> at least in description/summary
18:16:36 <nirik> so, perhaps a "MUST: you must run a rpm -qlivp foo.src.rpm on your koji produced src.rpm and confirm that it has no undefined macros in it" ?
18:16:51 <pjones> nirik: unexpanded
18:16:55 <nirik> sorry, yeah.
18:16:58 <Oxf13> that seems pretty reasonable.
18:17:03 * nirik is out of coffee.
18:17:11 <ajax> nirik: that's a way to do it.  i'd kind of like that automated by autoqa, but.
18:17:18 <ajax> walk before we run
18:17:20 <Oxf13> right
18:17:23 <nirik> sure, this would be another great one for autoqa.
18:17:48 <wwoods> sounds like an rpmguard sub-test
18:17:53 <abadger1999> So that's what to do... what are we preventing?
18:17:54 <skvidal> this is a great reason why we need to stab specfiles through the heart
18:17:58 <wwoods> and/or rpmlint
18:17:58 <skvidal> frelling language of doom
18:18:09 <pjones> why -l ?
18:18:21 <abadger1999> unexpanded macros in summary + description + ?
18:18:26 <wwoods> filenames?
18:18:48 <nirik> abadger1999: it's not clear to me what fields this affects...
18:19:00 <nirik> abadger1999: perhaps someone could go play with it some and come up with a proposal for packaging?
18:19:07 <Oxf13> abadger1999: yes, that's what we're preventing.
18:19:16 <abadger1999> <nod>I'd like to know that before approving a Guideline.
18:19:20 <Oxf13> unexpanded macros in our shipped srpms
18:19:52 <ajax> nirik: i'd start with "anything you can see in rpm -qip foo.src.rpm"
18:20:06 <nirik> so, who will take this action item? test it and propose to packaging a guideline?
18:20:10 <abadger1999> Oxf13: What about %{?not_at_srpm_buildtime} macros?
18:20:21 <Oxf13> $ rpm -qlivp /pub/fedora/linux/development/source/SRPMS/mingw32-* 2>/dev/null|grep '%{' |wc -l
18:20:25 <abadger1999> Oxf13: Do you want those tobelegalor illegal?
18:20:25 <Oxf13> 24
18:20:42 <Oxf13> abadger1999: example?
18:20:50 <abadger1999> grrr... spaces: to be legal or illegal
18:21:09 <abadger1999> %description
18:21:14 <abadger1999> %{?_mingw32_description}
18:21:24 <pjones> %description doesn't show up in srpm...
18:21:24 <skvidal> does  anyone like the idea of delegating style/taste decisions to the packaging committee and dispensing with this one?
18:21:37 <Oxf13> yes it does
18:21:38 <pjones> skvidal: I think I suggested that 10 minutes ago ;)
18:21:42 <ajax> i am pro-delegation.
18:21:44 <Oxf13> er shoops
18:21:59 <Oxf13> abadger1999: I'm not sure what you're asking.
18:21:59 <pjones> yes, er shoops.
18:22:19 <abadger1999> Oxf13: Won't that expand to nothing in the srpm?
18:22:19 <ajax> but if fpc has taste, they'll shoot this down.
18:22:26 <pjones> abadger1999: that won't show up in an srpm, though it'll still have an empty description which is bad.
18:22:30 <Oxf13> abadger1999: oh the ?
18:22:33 <abadger1999> pjones: Exactly.
18:22:38 <ajax> we have templates for this already, they're in rpmdev-newspec.
18:22:40 <pjones> abadger1999: and thus it is wrong.
18:22:48 <Oxf13> yeah, harder to catch, but all the same.
18:23:25 <Oxf13> I don't care what body takes this issue on, I'm going to close it as WONTFIX in mock
18:23:41 <skvidal> Oxf13: yes
18:23:55 <pjones> I say we give it to FPC since it's obviously theirs.
18:24:01 <ajax> yes.
18:24:14 <ajax> also, where's the autoqa todo list, because this belongs on it.
18:25:12 <nirik> is there going to be someone on FPC that will be willing to run with this?
18:25:14 <Oxf13> ajax: that should go into rpmguard
18:25:43 <Oxf13> although I'm having difficulty finding where rpmguard is housed
18:25:48 <skvidal> in autoqa
18:25:49 <skvidal> tests/
18:25:58 <Oxf13> I thought it was it's own project
18:26:05 <Oxf13> its
18:26:21 <skvidal> umm
18:26:28 <skvidal> recent commits to rpmguard in autoqa
18:26:31 <skvidal> I'd say its there
18:26:32 <Kevin_Kofler> Oxf13: I'd close it as NOTABUG if you consider it not worth fixing, not WONTFIX.
18:26:40 <Kevin_Kofler> But that's just splitting hairs. ;-)
18:26:49 <skvidal> it's
18:26:52 <skvidal> :)
18:27:08 <abadger1999> All macros in summary and description need to be expandable at srpm buildtime.  rpm -qpvi [SRPM] 2>/dev/null|grep '%{' can find cases where the macro is unconditionally included. Watch out for %{?Foo} which is also wrong but will just lead to the information being left out of srpms.
18:27:19 * abadger1999 will put that on the FPC agenda
18:27:24 <Oxf13> Kevin_Kofler: NOTABUG means I don't think it's a bug.  WONTFIX means "yeah, it could be a bug, but I'm not fixing it"
18:27:32 <nirik> abadger1999: excellent. Thanks.
18:27:41 <Kevin_Kofler> abadger1999: Yeah, that makes sense, go ahead!
18:27:52 <nirik> anyone have any other items they would like to discuss? (either from our trac or whatever)?
18:28:13 <Oxf13> abadger1999: you'll have to explain why this can happen due to uninstalled buildreqs
18:28:26 <Oxf13> abadger1999: so perhaps add in there something about built with --nodeps
18:28:29 * nirik would like any feedback on his proposal to split the rawhide repos into a subpackage, but that could be on list just fine.
18:28:39 <abadger1999> Okay.
18:28:52 <Oxf13> nirik: seems so far the best solution is to have it as a sub-package, but still disabled by default
18:28:57 <Oxf13> for complete nanny-state
18:29:26 <nirik> Oxf13: yeah. I was hoping to avoid the disabled, but it seems it's going to have to be that way for some use cases. ;(
18:29:42 <Oxf13> nirik: right, either you want to protect people, or you don't :/
18:29:47 <ajax> filed rpmguard ticket: https://fedorahosted.org/autoqa/ticket/108
18:29:56 <nirik> thanks ajax
18:30:01 <Kevin_Kofler> Yeah, it should be disabled by default even if it's not installed by default.
18:30:12 <Kevin_Kofler> Installing packages changing system configuration is evil.
18:30:13 <Oxf13> ajax: wow, that was like all responsible and stuff (:
18:30:27 <Kevin_Kofler> It's part of what caused the "Big PackageKit Security Fiasco" in F12.
18:30:39 <Oxf13> Kevin_Kofler: it's not 'changing configuration' because the configuration doesn't exist without the package
18:30:44 <nirik> oh, while abadger1999 is around. Any news on ticket 275?
18:30:50 <nirik> .fesco 275
18:30:51 <zodbot> nirik: #275 (Propose a soft-path via co-maintainer status to becoming sponsored) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/275
18:31:04 * Oxf13 glares at that proposal
18:31:47 <Oxf13> I /really/ don't like the solution of adding more groups
18:32:11 <abadger1999> nirik: jds2001 started working on that.  We got a lot of it done byend of FudCon. Wehit some hangups but I'm not sure if that's because of optional features(turing theaclsinto fsacls)or corefunctionality.
18:32:22 <abadger1999> I'll ping jds2001 about it this week.
18:32:42 <nirik> Oxf13: does the additional group cause issues with the git migration?
18:32:45 <pjones> I like the idea, but like Oxf13 I really don't like the implementation
18:33:22 <Oxf13> nirik: I haven't fully explored it, but likely not.  It certainly makes things more complicated when this really feels like a social problem, not a technical one
18:33:37 <nirik> Perhaps add objections/other ideas to the ticket(s) and we can discuss more next meeting?
18:34:59 <ajax> sounds reasonable to me
18:35:06 * nirik proposes we close out the meeting today. Will try and be more organized next week.
18:35:29 <skvidal> nirik: +1
18:35:44 <ajax> second
18:36:07 <nirik> Thanks for coming everyone.
18:36:22 <mjg59> \o/
18:36:29 <nirik> #endmeeting