=================================== #fedora-meeting: FESCO (2011-03-16) =================================== Meeting started by nirik at 17:30:14 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-03-16/fesco.2011-03-16-17.30.log.html Meeting summary --------------- * skipping first 3 items as they have no updates this week. (nirik, 17:34:06) * #544 List of services that may start by default (nirik, 17:34:08) * LINK: https://fedoraproject.org/wiki/User:Kevin/DefaultServices (nirik, 17:45:42) * AGREED: https://fedoraproject.org/wiki/User:Kevin/DefaultServices draft is approved. (nirik, 18:09:08) * #563 suggested policy: all daemons must set RELRO and PIE flags (nirik, 18:09:16) * revist this topic next week. (nirik, 18:12:33) * #570 Interim autostart policy (nirik, 18:12:47) * will just put the final policy in place. (nirik, 18:13:03) * #298 Revoke Paul Johnsons pacakger access and put him on probation. (nirik, 18:13:15) * LINK: http://fpaste.org/W12w/ (tibbs|h, 18:24:32) * AGREED: will remove pfj from provenpackagers (nirik, 18:28:56) * AGREED: remove provenpackager status, try and contact Paul more over the next week to work with us, revisit next week? (nirik, 18:35:26) * affected packages: mono nant mono-debugger boo libgdiplus (nirik, 18:47:30) * AGREED: ask dgilmore and Oxf13 if there are any unforseen problems with doing this (re-writing history) If not, do it. If so, revisit next week. (nirik, 18:50:13) * ACTION: mjg59 to start discussion on list about binaries and large files in packager git. (nirik, 18:53:15) * #572 NetworkManager-0.9 (nirik, 18:53:41) * AGREED: will look for more info in ticket and revisit as it becomes available. (nirik, 19:20:17) * Open Floor (nirik, 19:20:22) Meeting ended at 19:21:39 UTC. Action Items ------------ * mjg59 to start discussion on list about binaries and large files in packager git. Action Items, by person ----------------------- * mjg59 * mjg59 to start discussion on list about binaries and large files in packager git. * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * nirik (164) * mjg59 (64) * kylem (33) * notting (32) * mmaslano (29) * ajax (22) * gholms|work (19) * zodbot (10) * caillon (9) * rdieter (8) * tibbs|h (6) * drago01 (6) * abadger1999 (4) * SMParrish (3) * mclasen (3) * SMParrish_mobile (2) * thomasj (1) * SMParris1 (1) * cwickert (0) -- 17:30:14 <nirik> #startmeeting FESCO (2011-03-16) 17:30:14 <zodbot> Meeting started Wed Mar 16 17:30:14 2011 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:30:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:30:15 <nirik> #meetingname fesco 17:30:15 <zodbot> The meeting name has been set to 'fesco' 17:30:15 <nirik> #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano 17:30:15 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 mmaslano nirik notting 17:30:21 <kylem> ah, cool, nirik's back :) 17:30:24 * notting is here 17:30:33 * mmaslano here 17:30:37 <nirik> #meetingname fesco 17:30:37 <zodbot> The meeting name has been set to 'fesco' 17:30:37 <mjg59> Here 17:30:38 * kylem was worried he'd have to remember the meetbot commands. 8) 17:30:53 <nirik> ha. ;) on the way home, so might drop off due to coverage, but otherwise I am here. 17:31:45 <nirik> I guess thats 5... 17:32:09 <mjg59> ajax should be here 17:32:18 <mjg59> He was around a minute ago 17:32:20 <nirik> I'm thinking we can skip the first 3 items... 17:32:21 * thomasj lurking 17:32:26 <notting> meeting while commuting? advanced committee chair maneuver! 17:32:49 <nirik> I didn't add anything to updates adjustments 17:32:58 <nirik> cwickert isn't around for features repo info 17:33:10 <nirik> no new updates in the ticket on metrics. 17:33:28 <nirik> notting: heading back from vet... I'm not driving. ;) 17:33:36 <ajax> yeah, i'm here 17:34:06 <nirik> #info skipping first 3 items as they have no updates this week. 17:34:08 <nirik> #topic #544 List of services that may start by default 17:34:08 <nirik> .fesco 544 17:34:09 <zodbot> nirik: #544 (List of services that may start by default) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/544 17:34:16 <nirik> notting added some info to this one. 17:34:58 <nirik> we can't really use critpath very much here. 17:35:00 <notting> yeah, critpath isn't going to help much 17:36:19 <nirik> so, what shall we do here? do we want to adjust our proposed policy some? or vote on it? or ? 17:37:35 <nirik> I guess we wanted to note dbus activated ones in the policy. 17:39:03 * SMParris1 here sorry I'm late 17:39:17 <notting> vote and work on adding dbus ones to the policy later? 17:39:28 <mmaslano> I suppose dbus will be activated automatically or not? 17:40:00 <nirik> how often do we think there will be some new service that will want to start by default or a old service that will want to change to start by default? 17:40:30 <nirik> I wonder if we couldn't just say 'ask fesco if you think your thing should start by default, otherwise don't' 17:40:36 <nirik> or would that be too much busy work? 17:40:44 <notting> mmaslano: in general, yes. however, systemd has some means they're working on to mitigate this 17:41:26 <mmaslano> it's hard to come with guidelines if there will be changes (again) 17:43:04 * nirik is lagging. 17:43:16 <kylem> i don't mind us voting in the future on a case by case basis 17:43:49 <kylem> i mean, we already have the feature process busywork which is probably going to far exceed this. 17:43:55 <SMParrish> can we make it part of the package review process for future services 17:44:21 <nirik> I think some people worry that a bunch of services might change to start by default after our policy and cause annoyance for users. 17:44:25 <mclasen> that is a good point 17:45:14 <nirik> SMParrish: well, the FPC wants us to decide, so the package review guidelines will say: "If your package has a service, see -> fesco service policy page to see if you can have it start by default or not" 17:45:42 <nirik> https://fedoraproject.org/wiki/User:Kevin/DefaultServices 17:45:47 <nirik> is what we have currently. 17:45:56 <nirik> that allows a number of cases as just 'you can' 17:46:47 <SMParrish> nirik: yes but we could have them set a flag in the review to bring the package to fesco's attention so we can comment and follow its progress 17:48:32 <nirik> well, I think it would be easier to just say "You must not start by default", but if you think you should/need to, ask fesco if you can. Things that would be good reasons would be: one shot service, things that are useful without config, doesn't listen on external networks by default, is something the user needs to login, etc 17:48:52 <nirik> just an idea... since there were some concerns on our current draft 17:50:48 <nirik> I hate to drag this out more, but if people want I can write up a second draft based on that idea (more restrictive/fesco approves any new start by default services) 17:51:29 <abadger1999> Note, activation covers both dbus activation and systemd activation. 17:51:35 <mjg59> Ugh. 17:52:05 <mjg59> I'm really on the side of just letting people do whatever they feel is appropriate if the code isn't listening to the internet. 17:52:07 <nirik> abadger1999: hey. Any thoughts on the above idea? (since you had issues with the first draft when it was in FPC) 17:52:26 <nirik> mjg59: ok, so the current draft seems ok to you? 17:52:31 <mjg59> nirik: Yeah. 17:53:08 <abadger1999> nirik: It's basically the same strategy as FPC currently uses for bundled libraries. 17:53:15 <nirik> abadger1999: yes 17:54:10 * gholms|work rings the 20-minute bell 17:54:24 <nirik> yeah, shall we keep going? 17:54:46 * nirik is +1, would like to get somewhere on this. 17:55:07 <mmaslano> could you sum up your +1? 17:55:15 <mmaslano> I'dlike to also move with this topic 17:55:25 <nirik> +1 to continue discussing it. 17:55:43 <mmaslano> ok, please continue 17:55:47 <SMParrish> +1 17:56:19 <nirik> I'm ok with either the current draft, or a more restrictive draft that defaults to no, but allows us to add them as exceptions if they ask and present a good rationale. 17:56:57 * nirik gets home, back in a few minutes. 17:56:57 * notting is +1 to either as well 17:58:10 <mjg59> What problem are we trying to solve by being more restrictive than the current draft? 18:00:44 <notting> the problem of not being restrictive enough? (circular reasoning is circular) 18:01:16 <notting> that did seem to be the underlying tone, though - a general idea of being 'more strict' 18:01:51 <nirik> mjg59: well, the draft on the list seemed to get a number of people thinking it would result in a ton of new services starting by default. 18:02:02 <nirik> where they were not things people wanted to. 18:02:22 <nirik> but I have no examples, that was just the impression I got. 18:03:05 <nirik> we can of course always adjust policy if something happens thats not good. 18:03:20 <mjg59> notting: I'm fine with being more strict if we're trying to solve something other than "I don't trust the scheduler/vm" 18:04:45 <nirik> in practice I suspect the number of new things that come along that want to start by default will be small. 18:04:58 <nirik> as will the number of things currently that want to change. 18:06:08 <nirik> so, votes? more discussion/revisit next week? throw tomatoes at it? 18:06:27 <mjg59> In the absence of a well-formed reason for why we're better of being stricter, I'm +1 for the current draft and -1 to further restriction 18:06:43 <ajax> same 18:07:08 * mmaslano agree with mjg59 18:07:17 <nirik> ok, thats +3 to the current draft. 18:07:46 * nirik is fine with it, and if it turns out it causes problems, we can revisit it and perhaps replace it with the more restrictive version. 18:08:06 <mclasen> +1 for not making it more restrictive 18:08:42 <nirik> ok, thats +5... any other votes? 18:08:53 * notting was +1 to the current draft 18:08:54 <kylem> +1. 18:08:58 <kylem> to the current one. 18:09:08 <nirik> #agreed https://fedoraproject.org/wiki/User:Kevin/DefaultServices draft is approved. 18:09:16 <nirik> #topic #563 suggested policy: all daemons must set RELRO and PIE flags 18:09:17 <nirik> .fesco 563 18:09:18 <zodbot> nirik: #563 (suggested policy: all daemons must set RELRO and PIE flags) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/563 18:09:22 <nirik> any news on this one? 18:10:25 <nirik> kylem: ? 18:10:41 <kylem> sorry, i've been really swamped with school work this week :\ 18:11:09 <kylem> (i'm also completely unable to see any different outside of standard deviation with relro 18:11:16 <kylem> still working on the pie stuff.) 18:11:23 <nirik> ok. revisit next week? 18:12:12 <kylem> please 18:12:24 <kylem> this is the last week of schoolwork for me, so things will be looking up after tomorrow. 18:12:27 <kylem> heh 18:12:33 <nirik> #info revist this topic next week. 18:12:37 <nirik> thanks, no problem. 18:12:41 <kylem> thanks. 18:12:47 <nirik> #topic #570 Interim autostart policy 18:12:48 <nirik> .fesco 570 18:12:49 <zodbot> nirik: #570 (Interim autostart policy) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/570 18:12:55 <nirik> I think this was made moot by our voting above. 18:13:03 <nirik> #info will just put the final policy in place. 18:13:13 <nirik> ok, on to new business... 18:13:15 <nirik> #topic #298 Revoke Paul Johnsons pacakger access and put him on probation. 18:13:15 <nirik> .fesco 298 18:13:16 <zodbot> nirik: #298 (Revoke Paul Johnsons pacakger access and put him on probation.) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/298 18:13:37 <nirik> so, several issues here: 18:13:45 <mjg59> nirik: Did you hear anythng back from Paul? 18:13:55 <nirik> Paul is not following our workflow, which makes it hard for others to work with him on those packages. 18:14:00 <nirik> no, not a peep. ;( 18:14:32 <nirik> second issue is that we have binaries checked into our git repos. ;( 18:14:40 <gholms|work> Huge binaries 18:14:43 <notting> this would be an unprecedented step, correct? 18:14:44 <kylem> wtf? 18:14:51 <nirik> So, on the first issue, what would we like to do? 18:15:07 <nirik> I'd love to open a dialog with Paul, but he's not answered anywhere I see. ;( 18:15:19 <mjg59> It's not the first time we've had problems with him 18:15:28 <tibbs|h> That ticket is a year old. 18:15:29 <nirik> notting: if we revoked his status? yeah, i think it would be. 18:15:31 <mjg59> Have the other Mono developers complained at all last time? 18:15:36 <mjg59> tibbs|h: Yes, and was reopened 18:15:39 <nirik> this is a reopened ticket from the past. 18:15:56 <nirik> in that case he promised to work more with folks and try and improve his checkins/workflow 18:15:57 <ajax> the commit hooks really should kvetch if you try to commit anything over like 200k 18:16:33 <mjg59> nirik: Was this just you checking up on him, or has anyone actively complained? 18:16:33 <ajax> i feel comfortable saying that's orthogonal to this though 18:17:00 <nirik> mjg59: someone brought it to my attention, but they didn't want to be named if possible. 18:17:27 <mjg59> nirik: Ok 18:18:03 <mjg59> So we've got a developer who (a) can't follow standard workflow, (b) can't use our tools properly and (c) doesn't reply to email? 18:18:22 <nirik> yeah, he is active for $timeperiod, then disappears, then comes back, etc. 18:18:30 <mjg59> And this is causing difficulty for developers who can follow standard workflow, can use ur tools properly and do reply to email? 18:18:44 <nirik> yeah. 18:18:54 <mjg59> From a technical standpoint I think the answer is obvious 18:19:09 <kylem> so. 18:19:12 <mjg59> From an implementation standpoint I think we should bump it to the board, perhaps with a recommendation 18:19:17 <nirik> the mono fedpkg repo is not 60+MB (making it slow/hard to checkout), the rm and checking in new specs overwrites people's changes, etc. 18:19:41 <gholms|work> s/not/now/ 18:19:47 <nirik> right, sorry. 18:19:53 <tibbs|h> I'm a bit confused though; he's have to actually back out existing changes in order to import his, wouldn't he? 18:20:01 <mjg59> tibbs|h: git rm, git add 18:20:04 <nirik> tibbs|h: he just imports his new spec. 18:20:13 <nirik> yeah, like that. 18:20:18 <tibbs|h> Man. 18:20:27 <tibbs|h> With CVS it could be accidental. 18:21:17 <nirik> well, that may have been a mistake... 18:21:34 <nirik> it was 2 commits: changing the spec normally, then rming it. 18:21:41 <nirik> then another commit that added the entire spec again. 18:21:50 <mjg59> Rather than reset 18:22:29 <nirik> so, what action do we want to take here? 18:22:47 <mjg59> And appears to have checked in merge conflicts? 18:22:53 <nirik> yes, that as well. 18:22:54 <mmaslano> well, the owner of package should take him permission to commit 18:23:02 <nirik> mmaslano: he's the owner. ;) 18:23:18 <mmaslano> um fasnames... 18:23:39 <nirik> hum... or no he is not 18:23:47 <mmaslano> I'm not sure 18:24:12 <mjg59> Proposal: We recommend to the board that Paul's permission to commit to the repository be removed until such time as he demonstrates he understands our tools and can commit to being available 18:24:30 <gholms|work> Recommend to the board? 18:24:30 <ajax> wfm 18:24:32 <tibbs|h> http://fpaste.org/W12w/ 18:24:44 <tibbs|h> Those are all of the owners (including unapproved one) on the mono package. 18:24:54 <nirik> why do we need to go to the board? aren't we supposed to handle maintainer issues? 18:25:20 <mmaslano> yes, we should solve it 18:25:21 <notting> ha ha desktop acls on mono. 18:25:26 <mjg59> nirik: In the case of doing something that hasn't been done before I'd like to get the board's input before doing something that they might find problematic 18:25:44 <notting> should it be referred to the CWG? 18:25:47 * nirik notes he is also a provenpackager 18:25:47 <mjg59> But if people feel that we should just do it ourselves then just remove the bit in my proposal about the board 18:26:25 <mjg59> notting: Mmf. Changing to a CWG hat, when we discussed this kind of thing we felt that we didn't want to include this kind of community issue in our remit for now. 18:26:39 <mmaslano> ok, so main owner is someone else, shouldn't he solve it in his package? 18:26:46 <mjg59> nirik: Yeah, that's not looking like such a hot decision in hindsight 18:26:47 <nirik> mjg59: ok. Just wondering the rationale. I guess I would be ok with either... if we want the board to ack things thats ok with me. 18:26:51 <kylem> heh 18:27:08 <nirik> mmaslano: he could remove commits, but pfj is also a provenpackager. ;) 18:27:10 <ajax> i don't have any real preference on whether we ask the board or just do it, tbh 18:27:23 <mmaslano> nirik: surely he can't be after this 18:27:54 <mjg59> I think provenpackager is within our remit, and he certainly shouldn't be one of those 18:27:57 <notting> ok, intermediate proposal: remove pfj's provenpackager? 18:28:00 * notting is +1 to that 18:28:11 * nirik is +1 also to that. 18:28:13 <kylem> if he's demonstrated incompetence, i don't particularly want incompetent people working on the OS i use... 18:28:17 <kylem> +1. 18:28:20 <mjg59> +1 18:28:20 * mmaslano +1 remove him from provenpackagers 18:28:56 <nirik> #agreed will remove pfj from provenpackagers 18:29:08 <ajax> +1 for the record 18:29:33 * mclasen as not following due to another meeting, so will abstain 18:29:41 <nirik> so, on the commits on other things... I could try and contact him further (I don't know if we could find phone # for him or the like) 18:30:46 <nirik> or we could remove things now and ask him to contact us to re-aquire permissions. 18:30:55 <nirik> or we could ask the board if they are ok with that. 18:31:06 <mjg59> nirik: I guess bring it up with the package owners? 18:31:33 <nirik> thats an option too. 18:31:41 <kylem> maybe temporarily suspend them? 18:31:52 * mmaslano thinks package owners should solve it 18:31:54 <kylem> with the default action being not to renew them. 18:32:20 <notting> well, he's the owner of a couple of things, as well as a co-maint/packager on others, right? 18:32:25 <nirik> well, theres no suspend in pkgdb, but we could remove commits. They would then have to request them and have the owner ack 18:32:33 * nirik looks. 18:32:34 <kylem> nirik, well, maybe if we ask toshio nicely 18:32:42 <kylem> ;-) 18:32:53 <ajax> suspend seems like an unnecessary feature 18:33:13 <nirik> owner: 26 packages - https://admin.fedoraproject.org/pkgdb/users/packages/pfj?acls=owner 18:34:07 <nirik> proposal: remove provenpackager status, try and contact Paul more over the next week to work with us, revisit next week? 18:34:32 <ajax> +1 18:34:33 <kylem> given the timescale of the ticket already, what's another week? +1. 18:34:41 <SMParrish_mobile> +1 18:34:55 <mjg59> +1 18:35:10 <mmaslano> and ask nicely toshio about suspend 18:35:12 <mmaslano> +1 18:35:16 <notting> +1 18:35:26 <nirik> #agreed remove provenpackager status, try and contact Paul more over the next week to work with us, revisit next week? 18:35:38 <nirik> I have a feeling we won't hear from him, but we can deal with that next week... 18:35:43 <nirik> so, the second issue here: 18:35:54 <nirik> we have packages with binaries checked into them. 18:35:58 <nirik> We could: 18:36:00 <gholms|work> Huge binaries 18:36:05 <nirik> a) do nothing, too bad, so sorry. 18:36:24 <nirik> b) rewrite history and remove them. But then packages that are built will point to hashes that no longer exist. 18:36:37 <mjg59> Just as another data point: 18:36:37 <nirik> c) do some kind of package rename or the like 18:36:56 <mjg59> In bbed3987249cb2b730bee8cf6cde83470cdb3e18 Dan Horak removed the tarball from git 18:37:07 <gholms|work> mjg59: It's still in the history. 18:37:10 <nirik> yeah, but it's still in history. 18:37:22 <mjg59> In 55121410d3dc97c0cb94796dbe72a83247a40de7 Paul added it back 18:37:31 <mjg59> So we have multiple copies of it in history 18:37:46 <notting> interim: fix commit scripts? 18:37:48 <gholms|work> Unless and until someone removes it from the history every clone is going to be unreasonably large. 18:38:18 <mjg59> there's no real way to remove it from git and retain history 18:38:22 <nirik> notting: yeah, thats another issue here... 18:38:37 <mjg59> So it'd be a package rename 18:38:51 <gholms|work> Might I offer a suggestion to go along with nirik's "b" option? 18:38:53 <nirik> mono-nonborked 18:39:13 <kylem> heh 18:39:17 <kylem> 1:mono 18:39:18 <kylem> ;-) 18:39:28 <nirik> gholms|work: sure.. 18:40:13 <nirik> none of the builds of mono since the source checkin's are shipped in a final Fedora... only 15/rawhide, FWIW. 18:40:17 <gholms|work> Tag all the builds that happened after he checked in tarballs so the srpms don't disappear from koji, then rewrite the portion of the history that follows. 18:40:37 <gholms|work> Then the fact that the hashes won't exist won't be a problem. 18:40:40 <mjg59> gholms|work: Not sure that's possible? 18:40:52 <mjg59> They're not added as individual commits 18:40:52 <gholms|work> Just create a koji tag explicitly for this purpose. 18:41:02 <mjg59> They're added as part of the overall version update commit 18:41:14 <gholms|work> I'm not sure what you mean. 18:41:28 <mjg59> Rewriting history here isn't just a matter of git rebase -i 18:41:36 <nirik> mjg59: I've been told we can do it as part of a interactive history re-write... go back to that commit, rm the tar.gz and re-write the commit without it 18:41:50 <mjg59> nirik: Mm. Yeah, ok, that'd work. 18:41:55 <gholms|work> mjg59: Sure, that's why you use git filter-branch. 18:42:02 <gholms|work> It's designed for exactly this sort of thing. 18:42:10 <kylem> it'll break anyone with a checkout from fast-forwarding, but, i guess that's not so bad 18:42:26 <mjg59> Ok, I'm good with that option 18:42:47 <gholms|work> Since the real problem with rewriting history seems to be dangling koji hashes, tagging the builds to the srpms don't get garbage-collected seems like a good solution. 18:42:52 <mjg59> Providing we don't feel that it should always be possible to regenerate a given srpm from git, and we don't have any process depending on that 18:42:55 <nirik> note that this is not just mono... there are several packages. 18:44:14 <nirik> so, votes? more discussion? 18:44:46 * nirik is ok with b), but we might try and check that nothing else uses those hashes. 18:44:47 <mjg59> Raise it with infrastructure, make sure there aren't any technicald etails we haven't considered, then rewrite history? 18:45:13 * mmaslano also likes b) rewrite history in git 18:45:15 <mjg59> Also, can I just say that I am *very* enthusiastic for finally being allowed to vote to rewrite history 18:45:16 <ajax> mjg59: no, but it's an invariant we used to have 18:45:34 <mjg59> And I won't even be called a dictator! 18:45:48 <gholms|work> mjg59: The git devs call it a conspiracy. 18:45:59 <gholms|work> As in, "It takes a conspiracy to rewrite history." 18:46:25 <abadger1999> on the infra side -- probably dgilmore and Oxf13 are the two people who can discuss the pros and cons . 18:46:26 <nirik> I can ask dgilmore when he's around if there are concerns from that side. 18:46:28 <notting> we have 9 members. that's a reasonable set of conspirators. 18:46:29 <nirik> yeah. 18:46:32 <kylem> i'm not a huge fan of the idea, tbh. but i also don't plan on checking out mono, ever 18:47:20 <abadger1999> The rest of us are only basic git/koji users so we wouldn't be able to add anything to the discussion. 18:47:30 <nirik> #info affected packages: mono nant mono-debugger boo libgdiplus 18:47:34 <nirik> (at least) 18:48:09 <nirik> so, proposal: ask dgilmore and Oxf13 if there are any unforseen problems with doing this. If not, do it. If so, revisit next week? 18:48:30 <notting> +1 18:49:14 * nirik is +1 to that. 18:49:23 <mjg59> +1 18:49:25 * mmaslano +1 18:50:06 <ajax> +1 18:50:13 <nirik> #agreed ask dgilmore and Oxf13 if there are any unforseen problems with doing this (re-writing history) If not, do it. If so, revisit next week. 18:50:26 <nirik> so, the final subtopic: should we add hooks to git to stop this from happening again? 18:50:37 <gholms|work> file size limits? 18:50:40 <nirik> nack anything binary 18:50:44 <nirik> or file size limit 18:51:09 <nirik> there are some large patches out there. 18:51:21 <notting> both? 18:51:22 <caillon> there are some images that are also in git 18:51:22 <mjg59> I think bring this up on the list 18:51:32 <mjg59> We have cases where there are small binaries in git, yeah 18:51:48 <ajax> "anything binary" is a little fuzzy in a unicode world, but sure. 18:51:49 <notting> but certainly anything that's both a) binary b) over ... 1MB? 18:52:09 <nirik> ok, would someone like to start that discussion? 18:52:26 <mjg59> I'll bring it up 18:52:28 * nirik looks at the lua 1.4MB "add autotools support" patch 18:52:56 <nirik> mjg59: thanks. 18:53:15 <nirik> #action mjg59 to start discussion on list about binaries and large files in packager git. 18:53:22 <nirik> ok, whew. Anything else on this topic? 18:53:35 <nirik> one more agenda item today: 18:53:41 <nirik> #topic #572 NetworkManager-0.9 18:53:42 <nirik> .fesco 572 18:53:43 <zodbot> nirik: #572 (NetworkManager-0.9) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/572 18:54:04 <kylem> i was wondering why that hadn't turned up in updates-testing. 18:54:24 <mmaslano> I wonder why now 18:55:01 <nirik> so, it seems like dcbw is trying hard to help out any kde folks who want to get things moved to the new version. 18:55:06 <nirik> but the new version is also landing late. 18:55:25 <mmaslano> not sure how hard, I spoke with them and they don't think it's doable 18:55:44 <caillon> jiri klimes has been working on it since last week 18:55:51 <mmaslano> also it's late for such change 18:55:57 <ajax> it's certainly not the timing i'd like 18:56:23 * nirik nods. me either. 18:56:59 <kylem> meh, we're still two whole months from final release. ;-) 18:57:14 <mmaslano> also this would create precedent for other people, who would like to push their changes after alpha 18:57:31 <ajax> only if we let them. 18:57:39 <ajax> (now, or later) 18:57:45 <mjg59> I've expresed my concern about the timing 18:57:49 <ajax> i mean, precent only matters if you bother to pay attention to it. 18:58:05 <ajax> precedent, argh this lag is murder 18:58:12 <mjg59> It should really have been part of the original feature process, and the impact on non-gnome explained 18:58:48 <caillon> well, it's hard to write up a feature for "change a few devy things, and drop support for the thing we deprecated two years ago" 18:59:13 <mmaslano> caillon: but it should be there earlier 18:59:26 <kylem> it's kind of a sub feature of existing features, isn't it? 19:00:06 <nirik> so, I guess the question is: what are the chances the kde bits can be working by the 29th are. 19:00:20 <caillon> mmaslano, i'll grant that, sure, since the GNOME3 feature isn't complete without it. 19:01:13 <mmaslano> caillon: it's not about gnome, but about breaking software from other DE 19:01:17 <notting> options that have been suggested: 19:01:21 <mmaslano> nirik: so le'ts ask rdieter? 19:01:55 <notting> 1) ship KDE with nm-applet from nm09 2) drop feature, ship gnome with nm08 & nm-applet 3) port kde-plasma-NM to NM09 4) ship two NM versions 19:01:59 <rdieter> nirik: imo, odds are very much against it, but I'll try pinging jiri klimes about any progress he has (I haven't heard from him recently) 19:02:14 <caillon> mmaslano, we understand that. nobody expected the other DE to not support system connections when everything else does. 19:02:20 <drago01> notting: 5) slip 19:02:22 <notting> IMO, #1 isn't fair to KDE. #2 isn't fair to GNOME. which leaves #3 and #4 19:02:27 <mjg59> mmaslano: In the general case I think it's absurd to hold back the progress of the DE we spend most of our engineering time on in favour of one that has far less engineering resources available to it. However, this has come sufficiently close to release that I think that argument is much less solid. 19:02:40 <mjg59> Shipping two NM versions is practical and solves the immediate problems, but creates others 19:02:44 <nirik> 4 is horrible for many reasons. 19:02:53 <mjg59> They're only parallel installable in the very loosest sense 19:03:00 <drago01> notting: which means do 3) and if it takes more time take that time 19:03:14 <rdieter> notting: fwiw/imo and all that, #1 can work, it's just sub-optimal, and work on #3 is ongoing 19:03:35 <notting> mjg59: you could make them claim different binary, bus names. but then you'd just be really really hoping no one tries to launch both at once 19:03:47 <rdieter> (though *some* certain unnamed people won't like it at all) 19:03:57 <mjg59> notting: You could, and then if anyone did manage that the world would end 19:03:59 <nirik> I think we should try for 3 and fall back to 1. 19:04:11 <notting> rdieter: are they really unnamed if they commented in the ticket? 19:04:13 <drago01> nirik: why not 3 and fall back to 5 ? 19:04:21 * rdieter whistles 19:04:28 <caillon> notting, and that would potentially break more apps. 19:04:36 <caillon> s/potentially/almost certainly/ 19:04:37 <mjg59> drago01: I think it's kind of unfair to block everyone else's work because we screwed up in this respect 19:04:39 <drago01> nirik: if the options are "broken kde" vs. "broken gnome" vs. "ship latter" 19:04:43 <drago01> I'd opt for 3 19:04:47 <nirik> drago01: well, thats an option too, but slipping isn't going to be good if it's a long slip... 19:05:00 <nirik> ie, if someone says it will take an extra month? 19:05:26 <notting> the problem with #3 is that it gates landing & testing it on getting at least something working in the port, doesn't it? or you break the devel tree for KDE users for X weeks. 19:05:34 <rdieter> no one is suggesting keeping nm-0.8 ? I mean it *is* an option, even if no one likes it. 19:05:48 <drago01> mjg59: and it is unfair to our user to ship a "broken" user expirence 19:05:50 <mjg59> dcbw has said he'll work with Jiri 19:05:59 <rdieter> or sorry, that was #2 (notting) 19:06:08 <mjg59> rdieter: That was option 2 19:06:35 <mjg59> rdieter: The problem with that is that it leaves Gnome 3.0 in a less than ideal state, which is a problem if that's our big feature for this release 19:07:36 <mjg59> In this case I don't thik we can really make a decision yet 19:07:52 * nirik nods. perhaps gather progress info on 3 and revisit next week? 19:07:53 <mjg59> I'd like to hear from dcbw and Jiri as to how plausile a stable Plasma NM applet for 0.9 is 19:08:00 <mjg59> (in the timescale we have) 19:08:17 <mmaslano> I can ask jklimes tomorrow 19:08:23 <ajax> the answer i want, of course, is "yeah, it's already working" 19:08:33 <mmaslano> that would be best 19:09:14 <nirik> indeed. 19:09:32 <nirik> proposal: gather more info, revisit next week. 19:09:41 <notting> but if we can't do #3, we need to then choose to either bounce feature, or slip 19:10:27 <rdieter> serving as kde-sig messenger (not necessarily my own opinion), #2 is what is being asked for here, or a virtual restraining order. landing nm0.9 will likely be very difficult to revert later. 19:10:59 <nirik> well, is it ok to ask that they hold landing it for another week? or will that block other things? 19:11:02 <ajax> so would gtk3... 19:11:31 <caillon> nirik, well, eg anaconda broke because it added the patch for NM 0.9 already... 19:11:41 <notting> ajax: not understanding the context there? 19:11:51 <ajax> notting: gtk3 would be pretty hard to revert at this point, too. 19:11:54 <nirik> caillon: fun. ;( 19:12:14 <notting> ajax: yes. but its mere presence does not break most (*) apps 19:12:25 <notting> (*) should check the double-linkage bugs at some point 19:12:33 <ajax> anyway. i'm broadly for getting nm09 merged, but i'm also on the desktop team so i feel obliged to recuse myself from voting 19:12:49 <ajax> also i really need to bow out for the day, i've got other meetings 19:13:04 <nirik> thanks ajax. Enjoy. 19:13:23 <nirik> caillon: can we wait another week to land it and gather more info? 19:13:53 <rdieter> it doesen't necessarily even need to be a whole week, just until we (err, you) can get update-to-date status info 19:14:13 <nirik> sure, althought we have been bad in the past voting in tickets and the like. 19:15:23 <nirik> proposal: gather more info in ticket, ask NM to hold off pushing 0.9 for now, revisit in ticket as soon as we have more info? 19:15:28 <caillon> nirik, i think we're all in agreement that more info is good. 19:17:05 <nirik> votes? 19:17:32 <SMParrish_mobile> +1 19:17:45 <kylem> :\ 19:17:46 <notting> i guess +1. doesn't really solve the issue of what we may do with what the more info is, but... a bridge for another day. 19:18:02 <nirik> yeah. 19:18:16 <nirik> the info will be either 1) it can be made to work in time, or 2) it can't. 19:18:19 <kylem> +1 to procrastinating. ;-) 19:18:41 <mmaslano> now +1 for more info 19:18:45 * nirik was meaning to vote to procrastinate, but hasn't gotten to it yet. 19:19:46 <nirik> ok, so I guess thats enough votes to wait for more info. I can try and bug people later in the week if info arrives to do something with it. 19:20:17 <nirik> #agreed will look for more info in ticket and revisit as it becomes available. 19:20:22 <nirik> #topic Open Floor 19:20:26 <nirik> anything for open floor? 19:21:28 <gholms|work> [Somewhere in the distance, a dog barks] 19:21:29 * nirik listens to the crickets chirp 19:21:35 <nirik> ok, thanks for coming everyone! 19:21:39 <nirik> #endmeeting
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
