Minutes/Summary for today's FESCo meeting (2011-03-16)
Kevin Fenzi
kevin at scrye.com
Wed Mar 16 19:22:13 UTC 2011
===================================
#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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110316/adda26cb/attachment.bin
More information about the devel
mailing list