1:56 p.m.
===================================
#fedora-meeting: FESCO (2010-11-17)
===================================
Meeting started by nirik at 18:30:00 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2010-11-17/fesco.2010-11-...
Meeting summary
---------------
* init process (nirik, 18:30:01)
* townhall with the fesco election candidates tomorrow at 1500
UTC/10AM EST. (nirik, 18:31:54)
* Updates policy / Vision implementation status (nirik, 18:33:09)
* ACTION: nirik to try and remove redundant wiki pages and mark things
that are old. (nirik, 18:37:14)
* ACTION: ajax and nirik to try and remove redundant wiki pages and
mark things that are old. (nirik, 18:38:43)
* ACTION: nirik to check with the Board about the updates policy.
(nirik, 18:49:15)
* #493 Hatari update exception request (nirik, 18:57:23)
* AGREED: This package is granted an exception. Thanks for asking.
(nirik, 19:08:39)
* #494 F15Feature: BoxGrinder -
http://fedoraproject.org/wiki/Features/BoxGrinder (nirik, 19:09:10)
* AGREED: Feature is approved. (nirik, 19:13:00)
* #495 F15Feature: CloudFS -
http://fedoraproject.org/wiki/Features/CloudFS (nirik, 19:13:13)
* AGREED: Feature is approved. (nirik, 19:15:19)
* #496 F15Feature: ConsistentNetworkDeviceNaming -
http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming
(nirik, 19:16:29)
* AGREED: Feature is approved. (nirik, 19:21:04)
* #497 F15Feature: Gnome3 -
http://fedoraproject.org/wiki/Features/Gnome3 (nirik, 19:22:35)
* #498 F15Feature: LessFS -
http://fedoraproject.org/wiki/Features/LessFS (nirik, 19:39:23)
* AGREED: Feature is approved. (nirik, 19:42:33)
* #499 F15Feature: Ocaml3.12 -
http://fedoraproject.org/wiki/Features/OCaml3.12 (nirik, 19:44:06)
* AGREED: Feature is approved. (nirik, 19:46:18)
* #500 F15Feature: Xfce48 -
http://fedoraproject.org/wiki/Features/Xfce48 (nirik, 19:46:40)
* AGREED: Feature is approved. (nirik, 19:48:23)
* Open Floor (nirik, 19:48:57)
Meeting ended at 19:55:22 UTC.
Action Items
------------
* nirik to try and remove redundant wiki pages and mark things that are
old.
* ajax and nirik to try and remove redundant wiki pages and mark things
that are old.
* nirik to check with the Board about the updates policy.
Action Items, by person
-----------------------
* ajax
* ajax and nirik to try and remove redundant wiki pages and mark
things that are old.
* nirik
* nirik to try and remove redundant wiki pages and mark things that
are old.
* ajax and nirik to try and remove redundant wiki pages and mark
things that are old.
* nirik to check with the Board about the updates policy.
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* nirik (131)
* kylem (53)
* cwickert (51)
* pjones (44)
* ajax (43)
* mjg59 (38)
* notting (37)
* mclasen_ (28)
* zodbot (15)
* rwmjones (6)
* gholms (5)
* jonmasters (3)
* mdomsch (3)
* rbergeron (2)
* skvidal (2)
* mgoldmann (2)
* drago01 (2)
* rdieter (1)
* tibbs (1)
* dinnes (1)
* mclasen (0)
* SMParrish (0)
--
18:30:00 <nirik> #startmeeting FESCO (2010-11-17)
18:30:00 <zodbot> Meeting started Wed Nov 17 18:30:00 2010 UTC. The chair is nirik.
Information about MeetBot at http://wiki.debian.org/MeetBot.
18:30:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:30:01 <nirik> #meetingname fesco
18:30:01 <zodbot> The meeting name has been set to 'fesco'
18:30:01 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert
mjg59
18:30:01 <nirik> #topic init process
18:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik
notting pjones
18:30:21 <nirik> who all is around for fesco meeting time?
18:30:24 <cwickert> ouch
18:30:29 <mjg59> Hi
18:30:30 <cwickert> that late already?
18:30:31 <pjones> I'm right here.
18:30:38 <kylem> yo
18:30:49 <rwmjones> I'm here ..
18:31:11 <kylem> just like to remind everyone we're doing a townhall with the
fesco election candidates tomorrow at 1500 UTC/10AM EST.
18:31:11 <ajax> Uh, I think so Brain, but this time, you wear the tutu.
18:31:33 <nirik> kylem: thanks for organizing that.
18:31:36 <kylem> np.
18:31:54 <nirik> #info townhall with the fesco election candidates tomorrow at 1500
UTC/10AM EST.
18:32:55 <nirik> ok, I guess lets go ahead and dive in.
18:33:09 <nirik> #topic Updates policy / Vision implementation status
18:33:09 <nirik> .fesco 351
18:33:10 <nirik> .fesco 382
18:33:11 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac -
https://fedorahosted.org/fesco/ticket/351
18:33:14 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac -
https://fedorahosted.org/fesco/ticket/382
18:33:18 <nirik> Our fav tickets. ;)
18:33:33 <nirik> SMParrish: any news on metics?
18:34:01 <nirik> cwickert: were you working on a features repo proposal?
18:34:17 <cwickert> nirik, nope, no time
18:34:25 <nirik> More discussion on list about older stable releases not finding
testers...
18:34:32 <cwickert> nirik, have we cleaned up the wiki?
18:35:07 <nirik> not sure. was I supposed to do that?
18:35:11 * nirik looks back at action items.
18:36:14 <nirik> not sure if we had anyone who would do that.
18:36:27 <nirik> Anyone want to step up to do so? If not, I guess I could try...
18:37:14 <nirik> #action nirik to try and remove redundant wiki pages and mark
things that are old.
18:37:15 <ajax> what needed doing again?
18:37:30 <nirik> we have the same info in a few places, as well as a bunch of
proposals that were never accepted.
18:37:42 <nirik> just need to make sure people don't read those and think thats
what we are doing.
18:37:55 * jonmasters here
18:38:17 <ajax> i can take a pass or two at that this week
18:38:28 <ajax> but you're welcome to help
18:38:29 <nirik> ajax: that would be great.
18:38:43 <nirik> #action ajax and nirik to try and remove redundant wiki pages and
mark things that are old.
18:39:14 <nirik> so, do we wish to adjust the policy any at this time?
18:39:31 <nirik> There have also been some security updates that are waiting on
testing in old releases...
18:39:54 <ajax> as i said last week, i'm fine with turning down the security
updates timeout
18:40:04 <mjg59> I'm not enthusiastic about reducing the testing for security
updates
18:40:21 <mjg59> But if we don't have the resources to test them more, it may be
the lesser of the two evils
18:40:36 <pjones> mjg59: I'm similarly skeptical
18:40:43 <mjg59> We do, ideally, need a team that can verify these packages
18:40:48 <pjones> but yeah, if we're really resource constrained on that,
there's not a lot of option
18:40:51 <nirik> yeah, also given how security updates in the past have broken
things. ;(
18:41:06 <cwickert> we already removed the "only serious bugs and security
issues" limitation, right?
18:41:25 <ajax> and i can see some argument for trying to refine the critpath set
further
18:41:26 <nirik> cwickert: which?
18:41:51 <ajax> but in general i really think this is getting what we asked for and
what we want
18:42:02 <ajax> if it's important and it can't find testing it must not be
that important.
18:42:22 <nirik> it would be nice if we had a way to get some more of the stable
release consumers involved in testing... but not sure how. ;(
18:42:46 <notting> sorry, i'll try and be around
18:42:52 <cwickert> nirik, IIRC we had a sentence in the updates policy that must
only "fix serious bugs and security issues" and I cannot find it any longer
18:43:05 <cwickert> s/and/or
18:43:58 <rdieter> cwickert: this?
http://fedoraproject.org/wiki/Stable_release_updates_vision "Stable releases should
provide a consistent user experience throughout the lifecycle, and only fix bugs and
security issues."
18:44:21 <nirik> yeah, the Board vision.
18:44:49 <cwickert> rdieter, thanks, that was it
18:45:20 <cwickert> but it is not in the updates policy, so strictly speaking we did
not implement the board's vision?!
18:45:21 <pjones> oh, that old thing?
18:45:25 <nirik> yeah, we have: "Updates should aim to fix bugs, and not
introduce features, particularly when those features would materially affect the user or
developer experience"
18:46:16 <nirik> which perhaps is not matching the board vision.
18:47:27 <cwickert> it's not as strict, but IIRC people her did not like it.
should we get back to the board and ask them if they are fine with our wording or they
should reconsider their vision?
18:47:28 <notting> as I understand it, that was a compromise point.
18:47:45 <cwickert> for me the compromise is ok, the vision is not
18:47:55 * nirik is fine with either. We could ask the Board if they feel our policy is
ok.
18:48:23 <nirik> shall I do that?
18:48:27 <ajax> sure.
18:48:37 <ajax> i mean, i would hope they tacitly approve already
18:48:43 <ajax> otherwise they've not been paying attention
18:48:55 <notting> hard to ever assume people are paying attention
18:49:15 <nirik> #action nirik to check with the Board about the updates policy.
18:49:40 <nirik> ok, so does anyone want to propose adjustments at this time to the
policy? Or shall we move on?
18:50:30 <ajax> policy, no.
18:50:38 <ajax> critpath set, maybe.
18:51:15 <nirik> well, there were a few people who said they had trouble getting
proventesters, but this last week the issues noted were all with non critpath getting any
testers.
18:51:40 <nirik> f12 doesn't have too much time left, but still...
18:51:46 <nirik> @f12eol
18:51:50 <cwickert> ajax, what's wrong with the critpath set?
18:52:37 <ajax> cwickert: having not looked at it in detail i couldn't say
18:52:48 <ajax> i suspect it contains too many things
18:52:53 <ajax> i did say "maybe"
18:53:18 <cwickert> there are indeed some odd things due to yum's way to resolve
dependencies
18:53:27 <nirik> FYI, there are 5 critpath packages that have been in testing more
than 2 weeks without being approved.
18:53:36 <skvidal> cwickert: ?
18:53:42 <pjones> some of which should probably be reworked to not have the deps
they do; and when they do, we should re-evaluate critpath.
18:53:45 <notting> ajax: is that a potential future discussion point, or something
you'd like to handle today?
18:53:50 <pjones> skvidal: I think he meant "some things are pulled in by
deps."
18:53:55 <cwickert> skvidal, xfce4-notifyd was pulled in due to the short name
18:54:09 <pjones> or that.
18:54:18 <ajax> notting: not something i feel we should spend everyone's time
looking at right now, no.
18:54:24 <skvidal> cwickert: shortest name is the last of long list of thigns
compare_providers does
18:54:27 <nirik> mash, openchrome driver, libwnck, openldap, gnome-settings-daemon.
18:54:41 <cwickert> that is already fixed, but still the 'short name' rule
is strange
18:55:20 <notting> nirik: mash is speshul
18:55:30 <nirik> anyhow, if there's nothing we have to consider/propose/vote on
here, should we look at moving on?
18:55:30 <ajax> i'll happily take a look at the elaborated list and see if i
can't find suss out weird things
18:55:42 <nirik> notting: yeah, I thought about testing it here, but thats only +1.
;)
18:57:19 <nirik> ok, speaking of updates:
18:57:23 <nirik> #topic #493 Hatari update exception request
18:57:26 <nirik> .fesco 493
18:57:27 <zodbot> nirik: #493 (Hatari update exception request) - FESCo - Trac -
https://fedorahosted.org/fesco/ticket/493
18:57:39 <cwickert> brb
18:57:46 <nirik> our first exception request.
18:57:57 <nirik> New maintainer took over a old package, wants to update to the
newest.
18:57:59 <notting> how nice, they asked!
18:58:06 <nirik> yeah, very nice.
18:58:56 <nirik> sounds like there is a 'old interface' thats the same as
the current version and a 'new interface' thats spiffier.
18:59:05 <ajax> an atari emulator! mission critical.
18:59:07 <nirik> as well as a bunch of bugfixes/backend changes.
18:59:14 * nirik goes to add it to critpath. ;)
18:59:21 <pjones> seems like a pretty clear "what? no."
18:59:27 <notting> hm. 1.4 dates back to july. le sigh.
18:59:38 <pjones> that's unfortunate.
19:00:35 <kylem> i'm +1 on this since they were nice enough to as.
19:00:37 <kylem> ask
19:01:05 <nirik> since the 'new interface' is seperate, it's unclear to
me how much change to the user experence there is...
19:01:14 <notting> it does sound like the new feature is seperable, and does not
affect the existing interface
19:01:17 <ajax> yeah, i think i'm okay with this.
19:02:03 <mjg59> On the assumption that nobody's going to be terribly unhappy
about their Atari emulator suddenly not working with a given game, sure
19:02:15 <mjg59> But I do think that we need to provide a better mechanism for this
19:02:20 * nirik is also +1 in this case.
19:02:27 <nirik> mjg59: suggestions?
19:02:43 <mjg59> In the long run, separate update repositories
19:03:06 <notting> oh, they pushed the new version for re-review in july, but it
wasn't picked up until last week.
19:03:09 <kylem> mjg59, indeed.
19:03:19 <mjg59> app update repositories, that is
19:03:20 <kylem> was this an issue of the MIA maintainer process being slow or?
19:03:25 <kylem> notting, ah!
19:03:41 <notting> realistically, i don't know that they needed a re-review
19:03:45 <nirik> mjg59: yeah, we talked about that. A backports or whatever. We need
to come up with a concrete proposal for what it would take to set that up and if we want
to do it.
19:04:03 <kylem> hrm. in light of repos.fedorapeople.org, maybe i'm not for or
against this...
19:05:17 <nirik> repos.fp.o is handy, but I worry it will become a contrib/
19:05:26 <mjg59> Yeah
19:06:02 <mjg59> I think the ideal solution is an updates repo that just contains
security and other serious updates, and a second one that contains *application* (ie, not
library or infrastructure) updates
19:06:03 <nirik> it would be nice to have something more integrated that was _just_
newer versions of existing packages already available.
19:06:18 <notting> mjg59: but that's a new thing, obvs
19:06:22 <kylem> oh great, combinatorics explosion of bugs. :)
19:06:23 <mjg59> notting: Right
19:06:37 <nirik> yeah, adds more branches, bugs, mixes, etc.
19:06:50 <mjg59> kylem: Eh. The idea of keeping it at the application level would be
that bugs should be fairly independent
19:06:52 <kylem> i like repos because it's explicitly 'no bugs'.
19:07:03 <mjg59> It'd build against updates rather than itself
19:07:05 <kylem> mjg59, except for mismatched python vers, yadda adda.
19:07:12 <mjg59> kylem: Right, no python
19:07:24 <notting> repos.fp.o is versioned
19:07:26 <nirik> so, where are we on this request?
19:07:51 <ajax> i'm +1 since the ui for optional repos is still bad
19:07:52 <nirik> I think we are at +4?
19:08:03 <kylem> kyle: +1, nirik: +1, ajax: +1?, mjg59: +1?
19:08:06 <mjg59> Yeah, +1 in the absence of a better solution at present
19:08:14 <mjg59> And the low risk, etc
19:08:15 <nirik> notting: ? cwickert ?
19:08:20 <notting> same here. +1
19:08:23 <pjones> I'm fairly +0 here.
19:08:39 <nirik> #agreed This package is granted an exception. Thanks for asking.
19:09:04 <nirik> ok, on to features, we have a pile. ;)
19:09:08 <pjones> indeed.
19:09:10 <nirik> #topic #494 F15Feature: BoxGrinder -
http://fedoraproject.org/wiki/Features/BoxGrinder
19:09:10 <nirik> .fesco 494
19:09:11 <zodbot> nirik: #494 (F15Feature: BoxGrinder -
http://fedoraproject.org/wiki/Features/BoxGrinder) - FESCo - Trac -
https://fedorahosted.org/fesco/ticket/494
19:09:11 <kylem> +\Inf
19:09:14 <mjg59> +1
19:09:27 * gholms attempts to summon mgoldmann
19:09:30 <mjg59> Although someone's misinterpreted "Release notes"
19:09:40 <notting> is rel-eng expected to use this?
19:09:40 <mjg59> I'll note that on the talk page
19:10:09 <mgoldmann> notting: that's the plan in long term
19:10:22 <mgoldmann> I'm BoxGrinder lead, hello everyone!
19:10:33 <nirik> +1, looks cool. Perhaps we can mark the reviews somehow to note
they block a feature to get them reviewed in time.
19:10:51 <kylem> that looks pretty cool, +1.
19:11:15 * pjones is +1 on this
19:11:18 <cwickert> re
19:11:22 <kylem> nirik, add it to F15Alpha or something?
19:11:36 <nirik> or a whiteboard for it or something.
19:11:44 <ajax> yeah, looks very cool, +1
19:12:12 <kylem> i agree, we should really try to avoid blocking feature process
stuff on reviews... we seem to be a little short on reviewer manpower :/
19:12:15 <cwickert> +1
19:12:23 <tibbs> "a little"
19:12:34 <notting> i'm +1, just noting there's a lot of movement in all this
cloud space
19:12:43 <kylem> tibbs, understatement of the century, i'm sure. :)
19:12:44 <nirik> yeah, which is a good thing, IMHO.
19:13:00 <nirik> #agreed Feature is approved.
19:13:13 <nirik> #topic #495 F15Feature: CloudFS -
http://fedoraproject.org/wiki/Features/CloudFS
19:13:13 <nirik> .fesco 495
19:13:14 <zodbot> nirik: #495 (F15Feature: CloudFS -
http://fedoraproject.org/wiki/Features/CloudFS) - FESCo - Trac -
https://fedorahosted.org/fesco/ticket/495
19:13:31 <mjg59> +1
19:13:57 <kylem> ah, i wondered how i ended up with glusterfs installed. :)
19:14:03 <pjones> looks reasonable enough to me.
19:14:03 <pjones> +1
19:14:04 <cwickert> +1 because of the 'cloud' buzzword ;)
19:14:30 <kylem> is jdarcy here by some other nick?
19:14:31 <nirik> +1 here.
19:14:33 * notting is +1
19:14:41 <ajax> +1 cloud cloud cloud cloud
19:14:56 <kylem> hopefully this doesn't need any of the userspace crypto blah
that we had issues with last go 'round.
19:14:59 <kylem> +1.
19:15:18 <notting> kylem: what do you mean?
19:15:19 <nirik> #agreed Feature is approved.
19:15:27 <nirik> yeah, it doesn't note any kernel deps.
19:15:40 <notting> all the encryption is done client-side, which means userspace (i
presume)
19:16:06 <kylem> notting, right, we turned down a feature for kernel-based userspace
crypto last cycle, because it was unmerged.
19:16:07 <nirik> yeah, sounds like.
19:16:12 <kylem> (to let the kernel do key management and stuff.)
19:16:25 <kylem> hopefully this doesn't use that for it. anyway. moving on.
19:16:29 <nirik> #topic #496 F15Feature: ConsistentNetworkDeviceNaming -
http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming
19:16:29 <nirik> .fesco 496
19:16:29 <notting> kylem: i thought we turned down /dev/crypto b/c it wasn't
upstream
19:16:32 <zodbot> nirik: #496 (F15Feature: ConsistentNetworkDeviceNaming -
http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming) - FESCo - Trac -
https://fedorahosted.org/fesco/ticket/496
19:16:43 <kylem> oh, the fun ticket.
19:16:46 <kylem> notting, we did.
19:16:58 <nirik> I'm +1 on this. I don't care about the naming... no matter
what name is picked someone will hate it.
19:17:13 <nirik> and they can always rename them to whatever they like.
19:17:35 <notting> +1. use the 'bob' (Bandwidth On Board) namespace.
19:17:37 <kylem> nirik, i agree, i don't think its job.
19:17:38 <rwmjones> it might be good to add some guidance to how to rename them?
19:17:40 <pjones> I'm +1 on this, despite it being a kindof mediocre solution -
we've been trying to find a solution for this for years, and all the others are
worse.
19:17:46 <jonmasters> Matt is changing the name again in rawhide today, and he and I
have been discussing (e.g. on the phone last night) about namespaces. Not that that
matters to getting the feature in.
19:17:56 <mjg59> +1
19:18:03 <kylem> +1.
19:18:04 <cwickert> +1
19:18:12 <ajax> +1 make the bad man stop
19:18:13 <pjones> jonmasters: way to do it in the open.
19:18:18 <gholms> Quick question for you folks about this?
19:18:18 <mjg59> (Despite it not being of any interest to desktop users, who are the
only ones we care about)
19:18:20 * nirik notes he has a firewall where he renamed all the interfaces...
'dsl' 'cable' 'wireless'. It's not that hard if you want to.
19:18:44 <jonmasters> pjones: just avoiding bikeshedding. Any proposal will hit the
list.
19:19:06 <nirik> gholms: go ahead?
19:19:24 <gholms> If we're going to start using different names for different
types of NICs then why not just start naming *everything* according to its type or driver
like the BSDs do?
19:19:40 <mjg59> driver is pretty arbitrary
19:19:42 <pjones> gholms: you're thinking of "type" in the wrong way
19:19:43 <mjg59> Type I could live with
19:19:53 <pjones> in bsd land, they mean "by driver". here we mean
"builtin or not"
19:19:56 <mjg59> But yes, it depends on what you mean by "type"
19:20:30 <notting> hm. proposal doesn't list anything about getting seabios to
include the necessary info
19:20:36 <pjones> and if you're confused about this, I'd recommend you go
find a video of any of the many presentations mdomsch has done on this at various
conferences.
19:20:49 <gholms> Ooh, I shall.
19:21:04 <nirik> #agreed Feature is approved.
19:21:05 <pjones> notting: I'd think that'd be an orthogonal issue
19:21:12 <notting> pjones: there are etherpad notes from lpc.
http://etherpad.osuosl.org/lpc2010-user-visible-network-issues
19:21:15 <nirik> notting: might note for them to do that.
19:21:22 <pjones> gholms: those might be worthwhile as well ;)
19:21:59 <nirik> anything more on this? or shall we move on?
19:22:32 <kylem> unless we want to argue for hours about names, let's just move
on. :)
19:22:35 <nirik> #topic #497 F15Feature: Gnome3 -
http://fedoraproject.org/wiki/Features/Gnome3
19:22:35 <nirik> .fesco 497
19:22:36 <zodbot> nirik: #497 (F15Feature: Gnome3 -
http://fedoraproject.org/wiki/Features/Gnome3) - FESCo - Trac -
https://fedorahosted.org/fesco/ticket/497
19:23:13 <pjones> +1, assuming they manage to pull it off this time.
19:23:16 <kylem> +1. we addressed my questions about it last week when we approved
the release cycle.
19:23:19 <cwickert> any feature owners around?
19:23:38 * mclasen_ is around and missing a meeting here at the same time...
19:23:51 * notting is +1
19:24:01 <cwickert> I have some questions on it: what about panel applets?
19:24:22 <mclasen_> the shell doesn't have panel applets
19:24:23 <cwickert> and what about the notification area?
19:24:36 <cwickert> so will all these applet packages need to go?
19:24:40 <mclasen_> it doesn't have that either
19:24:54 <mclasen_> the panel will be around for a while still
19:24:56 <mclasen_> for fallback mode
19:25:14 <cwickert> ok, does it affect anything outside the GNOME desktop?
19:25:15 <mjg59> +1
19:25:30 <cwickert> the libnotify update was pretty inversive
19:25:43 <mclasen_> yeah, that was an example
19:25:57 <mclasen_> notification-daemon is getting some new capabilities, which
should not cause problems
19:26:00 <nirik> sure, +1. (I would be happy if someone could write up a way to
fallback for those that want to. I suppose using vesa would work, but thats a bit non
ideal)
19:26:01 <notting> there is a working list uptream on what to do with the
notification area icons of various upstreams
19:26:06 <notting> can't find it at the moment
19:26:14 <mclasen_> gtk3 will give other gtk-based desktop something to do, for
porting
19:26:17 <cwickert> what about other notification servers?
19:26:28 <mclasen_> but gtk2 is not going away, so no hurry
19:26:49 <ajax> nirik: the fallback strategy is still a bit of an open question,
i'll probably be spending some time on that with owen.
19:27:03 <mclasen_> cwickert: they can either implement the new capabilities, or not
- thats what capabilities are about
19:27:12 * rbergeron sees everyone cheering for cloud above and hopes they'll all be
coming to the cloud-sig meetings, yo :)
19:27:15 <cwickert> nether knotify nor xfce4-notifyd have the capabilities yet
19:27:21 <nirik> ajax: I bet I will get asked a million times by people in #fedora
how to fall back to old gnome if they don't like gnome3.
19:27:25 <kylem> rbergeron, welcome to the team, fwiw
19:27:30 <mclasen_> e.g. the shell itself has them, for its notification server
19:27:33 <gholms> The Team
19:27:35 <nirik> rbergeron: keep up the clouding. ;)
19:27:45 <cwickert> does this mean the notificytions will appear randomly
somewhere?
19:27:46 <drago01> notting:
http://live.gnome.org/GnomeShell/Design/Guidelines/MessageTray/Compatibility
19:27:53 <mclasen_> cwickert: thats why we recommend that apps actually check for
the cababilities before assuming that they are there...
19:27:59 <rbergeron> kylem: thanks. I'll be with y'all as soon as I get this
vpn stuff functioning properly :)
19:28:05 <kylem> hehe.
19:28:34 <kylem> nirik, put it in the F15CommonQuestions? :)
19:29:00 <nirik> yep. I just want to note that it would be nice if there was an easy
way to do this... ;)
19:29:01 <ajax> nirik: well the answer is 'run desktop-effects and switch',
like it is in f13, but there's some interest in trying to wire it up so gnome-shell
might be able to work in a software GL environment.
19:29:12 <nirik> ajax: cool, ok.
19:29:16 <cwickert> mclasen_, theses capabilities were guaranteed by libnotify and I
haven't seen a discussion on the xdg mailing list before they were removed
19:29:42 <mclasen_> cwickert: not sure I follow, cababilities are something that the
server has or doesn't have
19:30:22 <cwickert> mclasen_, yes, but before we could rely on a tray to be present
and attach a notification to it. now this is the server#s job
19:30:30 <mclasen_> anyway, we should perhaps take this offline, unless you think it
affects the feature directly
19:30:45 <mclasen_> yes, that has changed
19:30:45 <ajax> i'm +1 which i think puts us at +6 (not trying to halt
discussion though)
19:31:07 <cwickert> my question is: will this feature affect anything outside of
GNOME itself? this is something we need to consider here
19:31:32 <cwickert> I don't see this covered by the feature page
19:32:00 <mclasen_> note that I've only started to update the feature page this
morning
19:32:04 <nirik> it's a pile of packages, it could affect other things. I
don't know if there is a known list tho.
19:32:24 <mclasen_> I'll make sure to discuss the notification changes
19:32:47 <cwickert> as long as I don't know if/how it affects say Xfce and LXDE,
I cannot decide on this feature
19:33:23 <cwickert> it's not that I want slow things down, I just don't want
unpleasant surprises
19:33:25 <mjg59> cwickert: Well, us failing to approve the feature doesn't mean
the feature doesn't land
19:33:36 <mjg59> It just means we don't relnote it
19:33:53 <drago01> mjg59: *cough* systemd *cough*
19:33:56 <pjones> Was Re: Our feature process sucks.
19:33:58 <mjg59> The libnotify transition has happened in rawhide already. Are other
destops broken?
19:34:05 <mclasen_> well, I guess having some discussion about how to land it with
managable fallout would be good, I guess
19:34:07 <notting> mjg59: but the point is we're the body that's supposed to
handle/ensure there's cross-sig discussion
19:34:19 <nirik> well, I would hope that if there are changes that do affect
xfce/lxde the gnome folks will work to mitigate or solve those issues?
19:34:21 <mjg59> notting: Yes, but I don't think that's part of the feature
process
19:34:48 <cwickert> mjg59, correct me if I'm wrong, but the package maintainer
responsibilities include to avoid breaking other packages and notifying maintainers in
question
19:34:48 <mjg59> And in this case we appear to be arguing about something that's
already happened?
19:34:48 <mclasen_> cwickert: any other fallout that you foresee or have noticed
already ?
19:35:09 <mclasen_> cwickert: one other thing is that the gio default application
lookup has changed
19:35:19 <nirik> the libnotify stuff was pretty easy to patch for... I don't
know if it has longer term issues.
19:35:23 * mclasen_ notes that he did notify maintainers before landing libnotify
19:35:33 <cwickert> mclasen_, ok, i missed the announcement on that one (if there
was one)
19:36:00 <cwickert> mclasen_, I meant for the gio thing
19:36:24 <mclasen_> that was discussed with the pcmanfm (?) maintainer before
landing it, I believe
19:36:37 <cwickert> there was one for libnotify, but it was burried under lots of
mails on fedora-devel
19:36:53 <cwickert> note that I know of although I'm co-maintainer of pcmanfm
19:36:59 <ajax> (i have a hard stop at 3, sorry all)
19:37:00 <cwickert> s/note/not
19:37:46 <cwickert> another question: what about updates? will they still get the
old desktop?
19:37:50 <nirik> I would say lets approve this and ask mclasen_ to try and notify
others of big changes and work with them to mitigate the issues.
19:37:55 <pjones> Does this discussion actually need all of us, or do cwickert and
mclasen just need to coördinate?
19:37:59 <pjones> seems like we should move on.
19:38:03 <mclasen_> we'll coordinate
19:38:05 <mclasen_> lets move on
19:38:09 <cwickert> ok ok
19:39:23 <nirik> #topic #498 F15Feature: LessFS -
http://fedoraproject.org/wiki/Features/LessFS
19:39:23 <nirik> .fesco 498
19:39:27 <zodbot> nirik: #498 (F15Feature: LessFS -
http://fedoraproject.org/wiki/Features/LessFS) - FESCo - Trac -
https://fedorahosted.org/fesco/ticket/498
19:40:16 <ajax> the upstream website for this is really offputting
19:40:21 <notting> so, ksm for your disk?
19:40:22 <ajax> check me out, i know design patterns!
19:40:36 <mjg59> I'm not convinced that a fuse filesystem is really going to be
more attractive to enterprise users than just buying more storage, but it seems like it
may have some niche users and it's a nice technology demonstration if nothing else
19:40:48 <kylem> i like the idea there.
19:41:13 <ajax> it's a cute trick though
19:41:15 <dinnes> Enterprise users are starting to spend huge money on dedupe stuff
19:41:20 * nirik notes max (the package submitter) was moving last weekend/this week.
19:41:31 <ajax> +1
19:41:41 <nirik> zfs has dedup.
19:41:44 <pjones> +1 - seems fine. not sure how useful it really is, but it's
not in the way or something.
19:41:54 <notting> +1. wonder if it will eventually land in the fs, or lvm
19:42:06 <nirik> sure, +1 here... I guess it may be something our users would like
to hear about
19:42:09 <pjones> notting: well, btr already has COW stuff...
19:42:11 <kylem> btrfs will grow it i'm sure.
19:42:13 <mjg59> Yeah, +1 even if I suspect this isn't what a long-term solution
would look like
19:42:16 <notting> pjones: mooo.
19:42:21 <cwickert> +1
19:42:28 <pjones> notting: exactly.
19:42:30 <cwickert> can somebody please pick up the review?
19:42:33 <nirik> #agreed Feature is approved.
19:42:35 <kylem> +1.
19:42:39 <nirik> cwickert: it's got a reviewer
19:42:50 <cwickert> I doubt tht the current reviewer is capable of doing it
properly
19:42:51 <nirik> the submitter is moving, so I don't think he has net access in
his new home yet.
19:43:09 <kylem> is the submitter != feature owner? :)
19:43:23 <kylem> 'cause the owner is right here. :)
19:43:51 <kylem> i can't seem to connect to bugzilla right now...
19:43:56 <nirik> correct. Different people.
19:44:06 <nirik> #topic #499 F15Feature: Ocaml3.12 -
http://fedoraproject.org/wiki/Features/OCaml3.12
19:44:06 <nirik> .fesco 499
19:44:07 <zodbot> nirik: #499 (F15Feature: Ocaml3.12 -
http://fedoraproject.org/wiki/Features/OCaml3.12) - FESCo - Trac -
https://fedorahosted.org/fesco/ticket/499
19:44:11 <rwmjones> hello
19:44:44 <nirik> welcome rwmjones
19:44:46 <kylem> +1.
19:44:46 <pjones> +1, sounds nice.
19:44:55 <mjg59> +1
19:44:58 <ajax> "scope" implies there are some packages that are neither
simple rebuilds nor upgrades
19:45:10 <ajax> but whatever, that happens for python bumps too
19:45:10 <ajax> +1
19:45:11 <rwmjones> there are ~80 packages, and some are not simple upgrades
19:45:20 <nirik> yeah, +1 here. It looks like it might be a fair bit of updating
work, but it would be great to have fedora on the first here. ;)
19:45:22 <pjones> ajax: yeah - but that's not really surprising, it happens with
all major language revs.
19:45:30 <cwickert> +1
19:45:39 <kylem> (changing the language with a minor rev of the version numbr seems
like a bit of a ... jerk move tho.)
19:45:44 <notting> rwmjones: anything that isn't that is a major loss if it
can't be made to work?
19:45:56 <rwmjones> well, it'll be made to work
19:45:57 * notting is +1 in any case
19:45:58 <pjones> kylem: yeah, but not one that us voting against it will change.
19:46:06 <kylem> pjones, indeed.
19:46:09 <mclasen_> +1
19:46:18 <nirik> #agreed Feature is approved.
19:46:24 <nirik> thanks for working on this rwmjones
19:46:28 <rwmjones> np
19:46:40 <nirik> #topic #500 F15Feature: Xfce48 -
http://fedoraproject.org/wiki/Features/Xfce48
19:46:40 <nirik> .fesco 500
19:46:42 <zodbot> nirik: #500 (F15Feature: Xfce48 -
http://fedoraproject.org/wiki/Features/Xfce48) - FESCo - Trac -
https://fedorahosted.org/fesco/ticket/500
19:46:47 <cwickert> +1
19:46:48 <cwickert> :)
19:46:55 <mjg59> +1
19:47:10 <nirik> :) yeah, +1 here too (unless I should recuse myself from my own
feature. ;)
19:47:14 <pjones> I'm totally against this :)
19:47:18 <pjones> (but seriously, +1 )
19:47:20 <ajax> +1
19:47:22 <notting> +1
19:47:26 <cwickert> site note: I have packages at
http://cwickert.fedorapeople.org/repo/fedora/14/
19:47:31 <kylem> +1, glad you're doing it in a dist tag.
19:47:54 <nirik> cwickert: excellent. was goign to ask where that was.
19:48:14 <nirik> I hope the release really happens this time. ;)
19:48:23 <nirik> #agreed Feature is approved.
19:48:26 <mclasen_> +1
19:48:26 <cwickert> nirik, they are not perfect, but you can mock against them for
the thunar-vfs review we need
19:48:47 <nirik> cwickert: cool. Will give a try.
19:48:51 * mdomsch is here in case ConsistentNetworkNaming hasn't come up yet
19:48:57 <nirik> #topic Open Floor
19:48:59 <pjones> mdomsch: it came and went
19:49:00 <kylem> mdomsch, it has. :)
19:49:02 <nirik> mdomsch: it did already. ;)
19:49:15 <mdomsch> ok thanks
19:49:28 <kylem> we approved it but only if you name them 'curly'
'larry' and 'moe' by default.
19:49:33 <nirik> I'll note we have ticket 501 that came up after our agenda was
sent out. We can address it next week.
19:49:37 <nirik> .fesco 501
19:49:39 <zodbot> nirik: #501 (Fixing the glibc adobe flash incompatibility) - FESCo
- Trac - https://fedorahosted.org/fesco/ticket/501
19:49:40 <mdomsch> --policy=pony
19:49:52 <kylem> nirik, grumble.
19:49:52 <notting> mdomsch: the ponies namespace!
19:50:14 <ajax> i don't mind having a workaround for flash being broken, but
changing glibc to do it is just goofy.
19:50:30 * nirik also notes on this a post to the devel list that adobe has a rebuilt
flash that has gone to their QA. (no eta on release for it tho)
19:50:31 <pjones> nirik: I propose that we recommend that if you absolutely must use
flash, use the 32-bit version with nspluginwrapper
19:50:34 <kylem> yeah, uhm.
19:50:42 <pjones> nirik: since that appears to be the most secure of the bad choices
you can make here anyway...
19:50:51 <nirik> well, best case: don't use flash.
19:50:53 <notting> ajax: you want nspluginwrapper to shim an LD_PRELOAD in?
19:50:58 <notting> pjones: they updated the 64-bit one
19:51:04 <kylem> unless we paper over in glibc (which means we hurt the perf of
/EVERYTHING ELSE/) there's no really easy way to fix it either.
19:51:06 <pjones> notting: eventually.
19:51:10 <ajax> i mean, we used to have a glibc that would let you do free() on
garbage data
19:51:23 * mclasen_ saw a binary patch by halfline that changes all memcpy references to
memmap...
19:51:23 <ajax> and we stopped doing that because it was stupid and broken
19:51:28 <nirik> did we want to do a full discussion/decision on this this week? or
wait until next?
19:51:43 <pjones> mclasen_: memmove surely?
19:51:52 <notting> mclasen_: that was horrifying and awesome.
19:51:52 <mclasen_> of course
19:51:52 <ajax> full discussion can wait, particularly if there's word of a
patch already
19:52:06 <ajax> i was just getting a cheap shot in.
19:52:16 <nirik> the thing that gets me, is that it's unclear if the change in
glibc had any advantage.
19:52:20 <pjones> yeah, really i think the answer is to wait and see.
19:52:29 <pjones> sounds like adobe is actually fixing their bug.
19:52:36 <notting> pjones: on a 'months' timeframe
19:52:40 <mjg59> If we want to fix this anywhere ourselves, I think it ought to be
in the browser
19:52:48 <mjg59> notting: Latest update on the thread is more optimistic
19:52:48 <pjones> nirik: indeed. but at the same time, I'm wildly in favor of
letting the glibc guys maintain glibc.
19:52:54 <pjones> because you know what job I don't want?
19:53:03 <kylem> mjg59, i'm inclined to agree.
19:53:04 <ajax> grub maintainer?
19:53:12 <pjones> ajax: ugh.
19:53:13 <nirik> ha
19:53:19 <nirik> ok, anyone have anything for open floor?
19:53:27 <kylem> though, papering over it in ld.so if the shlib name is
libflashplayer would be fun too.
19:53:31 <ajax> nothin' from me
19:53:36 <mjg59> Nope
19:54:30 * nirik will close out the meeting in a minute if nothing else comes up.
19:54:34 <kylem> another reminder that we've got a fesco election townhall
tomorrow at 10AM EST/1500UTC.
19:54:43 <kylem> while we have a captive audience. ;-)
19:54:59 <pjones> yep
19:55:16 <nirik> Thanks for coming everyone!
19:55:22 <nirik> #endmeeting