2:22 p.m.
===================================
#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-...
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