Summary/Minutes for today's FESCo meeting (2012-07-09)
Tomas Mraz
tmraz at redhat.com
Mon Jul 9 19:05:26 UTC 2012
===================================
#fedora-meeting: FESCO (2012-07-09)
===================================
Meeting started by t8m at 17:02:00 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2012-07-09/fedora-meeting.2012-07-09-17.02.log.html
.
Meeting summary
---------------
* init process (t8m, 17:02:23)
* #861 Cleanup of maintainers with bugzilla account issues (t8m,
17:06:30)
* ACTION: nirik will orphan the remaining packages with bugzilla
account issues today (t8m, 17:15:16)
* #868 F18 Feature: MiniDebugInfo -
https://fedoraproject.org/wiki/Features/MiniDebugInfo (t8m, 17:15:36)
* #873 F18 Feature: 256 Color Terminals -
https://fedoraproject.org/wiki/Features/256_Color_Terminals (t8m,
17:31:59)
* LINK: http://marcoschuh.de/wp/?p=873 makes it sound reasonably
widespread (mjg59, 17:51:06)
* AGREED: The 256 Color Terminals feature is approved (+1:5 0:0 -1:0)
(t8m, 17:56:15)
* #880 Timing of FESCo Elections (t8m, 17:56:34)
* The current FESCo does not have any strong opinion on the election
date change if you want to please propose a concrete change of the
date to be voted on. (t8m, 18:02:58)
* #882: F18 Feature: CIM Management -
https://fedoraproject.org/wiki/Features/CIMManagement (t8m, 18:06:32)
* AGREED: CIM Management feature is approved (+1:6 0:0 -1:0) (t8m,
18:12:25)
* Please consider standardizing on one CIMOM. (t8m, 18:12:40)
* #883: F18 Feature: Display Manager Infrastructure Rework -
https://fedoraproject.org/wiki/Features/DisplayManagerRework (t8m,
18:13:11)
* LINK: https://fedoraproject.org/wiki/Features/PackagePresets
(nirik, 18:16:24)
* Decision on this feature is deferred till the PackagePresets feature
is accepted. (t8m, 18:21:47)
* #884: F18 Feature: Fontconfig 2.10 -
https://fedoraproject.org/wiki/Features/Fontconfig2.10 (t8m,
18:22:15)
* AGREED: Feature Fontconfig 2.10 is approved (+1:6 0:0 -1:0) (t8m,
18:23:37)
* #886: F18 Feature: Rails 3.2 -
https://fedoraproject.org/wiki/Features/Rails_3.2 (t8m, 18:24:57)
* AGREED: Feature Rails 3.2 is approved (+1:6 0:0 -1:0) (t8m,
18:30:02)
* Please mention the specific packages that need to be updated and
added on the feature page. (t8m, 18:30:40)
* #887: F18 Feature: Perl 5.16 -
https://fedoraproject.org/wiki/Features/perl5.16 (t8m, 18:31:30)
* AGREED: Feature Perl 5.16 is approved (+1:6 0:0 -1:0) (t8m,
18:34:12)
* Please announce the Perl version upgrade rebuild before starting
rebuilding next time. (t8m, 18:34:55)
* #885: F18 Feature: PowerPC ppc64p7 subarch support in rpm and yum and
in packages - https://fedoraproject.org/wiki/Features/Power7Subarch
(t8m, 18:35:29)
* AGREED: Feature PowerPC ppc64p7 subarch support in rpm and yum and
in packages is approved (+1:6 0:0 -1:0) (t8m, 18:47:19)
* Next week's chair (t8m, 18:48:55)
* notting will be the next week's chair for FESCo (t8m, 18:50:20)
* Open Floor (t8m, 18:51:02)
Meeting ended at 19:00:32 UTC.
Action Items
------------
* nirik will orphan the remaining packages with bugzilla account issues
today
Action Items, by person
-----------------------
* nirik
* nirik will orphan the remaining packages with bugzilla account
issues today
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* t8m (114)
* mjg59 (58)
* notting (53)
* nirik (52)
* pjones (35)
* jwb (32)
* dsd_ (15)
* zodbot (13)
* dwa (12)
* gholms (9)
* mitr (0)
* mmaslano (0)
* limburgher (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
-------------------------------------------------
17:02:00 <t8m> #startmeeting FESCO (2012-07-09)
17:02:00 <zodbot> Meeting started Mon Jul 9 17:02:00 2012 UTC. The chair is t8m. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:02:12 <t8m> #chair notting nirik mjg59 mmaslano t8m pjones mitr limburgher jwb
17:02:12 <zodbot> Current chairs: jwb limburgher mitr mjg59 mmaslano nirik notting pjones t8m
17:02:21 <pjones> hallo.
17:02:23 <t8m> #topic init process
17:02:27 <t8m> Hello
17:02:27 <pjones> mjg59 said he'd be a few minutes late.
17:02:57 <jwb> hi there
17:02:58 <nirik> Hello everyone.
17:03:24 <mjg59> Here
17:03:26 * notting is here, sorry about that
17:03:50 <t8m> seems that we have quorum
17:04:14 <t8m> mmaslano is on holidays afaik
17:04:18 <t8m> not sure about mitr
17:05:10 <t8m> and limburgher
17:06:01 <t8m> OK, let's start with old tickets
17:06:30 <t8m> #topic #861 Cleanup of maintainers with bugzilla account issues
17:06:31 <t8m> .fesco 861
17:06:32 <zodbot> t8m: #861 (Cleanup of maintainers with bugzilla account issues) – FESCo - https://fedorahosted.org/fesco/ticket/861
17:06:37 <nirik> ok, I have some info on this...
17:06:55 <nirik> I forgot that I was going to still be out of town on the 2nd, so I wasn't able to do anything then.
17:07:07 <nirik> I mailed everyone again and sent a thing to the devel list on friday.
17:07:24 <nirik> we are down to 72 issues now (from a high of about 190)
17:07:49 <nirik> I can do the orphaning today, or we could wait longer. There was a bit of response on the devel list...
17:08:04 <nirik> 2 folks that said they contacted people on the list to fix things.
17:08:47 <nirik> so, I'm happy to do the orphaning/cleanup later today, or wait longer if we think it will help out.
17:09:41 <jwb> we still have a ways before we branch, right?
17:09:47 <notting> since we're doing the usual orphan blocking before we branch, orphaning sooner (for some value of sooner) is probably better to get more people to pick things up
17:09:51 <notting> jwb: ~1 month
17:09:54 <nirik> yep.
17:10:04 <t8m> I don't care much either way, but given the mail on devel list was sent on Friday when it was supposed to be mailed on Monday you might delay the orphaning to Friday as well
17:10:07 <jwb> notting, right. i'd say wait until friday, then orphan
17:10:26 <jwb> i doubt e.g. nasrat is going to suddenly rejoin fedora but one can always hope
17:10:37 <t8m> hehe
17:10:59 <nirik> t8m: monday was supposed to be the 'orphan day'
17:11:14 * nirik has been mailing people weekly for a long time now.
17:11:23 <t8m> nirik, this monday or last monday?
17:11:42 <jwb> nirik, ok, i changed my mind. just orphan them
17:11:56 <nirik> in https://fedorahosted.org/fesco/ticket/861#comment:13 we agreed to a 2012-07-02 deadline.
17:12:04 <nirik> I was still away from the internets then.
17:12:15 <t8m> nirik, OK then go ahead and orphan
17:12:39 <nirik> it's been about 7 weeks since I started poking people. Happily it has been cleaned up a lot since then...
17:13:08 * nirik is fine either way. Getting it done today is good for me too.
17:13:49 <nirik> votes?
17:14:07 <t8m> nirik, I don't think we need voting as we voted already?
17:14:16 <notting> +1 to whenever (today is included in that)
17:14:17 <nirik> true, ok.
17:14:24 * nirik will just do it later today.
17:15:16 <t8m> #action nirik will orphan the remaining packages with bugzilla account issues today
17:15:36 <t8m> #topic #868 F18 Feature: MiniDebugInfo - https://fedoraproject.org/wiki/Features/MiniDebugInfo
17:15:37 <t8m> .fesco 868
17:15:38 <zodbot> t8m: #868 (F18 Feature: MiniDebugInfo - https://fedoraproject.org/wiki/Features/MiniDebugInfo) – FESCo - https://fedorahosted.org/fesco/ticket/868
17:15:59 * dsd_ is here
17:16:36 <nirik> I don't think there's a way to disable this just for one consumer.
17:16:56 <jwb> i don't really think there needs to be
17:17:01 <notting> only in image postprocessing
17:17:03 <t8m> So basically we were asked to revoke our decision to accept this feature because of OLPC
17:17:45 <mjg59> Specifically 1.0, right?
17:17:48 <mjg59> This isn't a problem on 1.5
17:18:14 <dsd_> its a bigger problem on 1.0, but its a problem all round, and not just for OLPC (in my eyes)
17:18:17 <pjones> yeah, honestly - too bad the old one is old
17:18:39 <mjg59> dsd_: We decided we were fine with the increase in disk usage
17:18:45 <pjones> dsd_: in the sense that the problem is "all round", I think that was covered in the initial discussion before we voted on it the first time.
17:18:51 <pjones> It's not clear why we'd want to discuss that again.
17:19:20 <dsd_> did anyone represent small systems that time around?
17:19:23 <mjg59> "This thing that you voted for on the understanding that it increased disk usage turns out to increase disk usage" isn't a *hugely* compelling argument for revisiting it
17:19:33 <pjones> dsd_: yes
17:19:48 <dsd_> ok
17:19:51 <nirik> well, I think the thought was "this increase of disk usage is impacting OLPC, did you consider that?"
17:20:02 <mjg59> nirik: Well, it impacts everyone
17:20:08 <nirik> sure.
17:20:13 <t8m> mjg59, but someone more than others
17:20:17 <mjg59> It just turns out that OLPC is plausibly the most resource constrained device we care about at all
17:20:41 <dsd_> my thinking was only that it has no OLPC-specific impliciations other than the fact we ship a small disk. and we cant be the only fedora consumer with a small disk
17:20:43 <nirik> I'm just suggesting thats why we were asked to revisit it and see if this information changes anyones thoughts on it.
17:20:44 <mjg59> Eventually XO-1.0 isn't going to be a viable Fedora target
17:20:56 <mjg59> The question is just whether we're ok with that happening sooner or later
17:20:59 <t8m> mjg59, or it can be said that if you're not too resource constrained it doesn't impact you much
17:21:23 <mjg59> But overall, Fedora isn't a great choice for highly resource-constrained devices
17:21:36 <mjg59> We make a bunch of design decisions without that being a significant concern
17:21:39 <notting> dsd_: two full desktops?
17:21:45 <t8m> I'd probably change my vote to -1 as I was not too fond of the feature before anyway.
17:21:46 <notting> dsd_: what's the other one?
17:21:51 <dsd_> sugar and gnome-fallback
17:22:25 <notting> well, upstream gnome is solving that problem of two desktops for you </bad jokes>
17:22:38 <mjg59> Chances are that by F19 we'll have gained another 43MB for you anyway
17:22:48 * nirik continues to be -1 on it as before, but thats only -2. ;)
17:22:55 <jwb> mjg59, for?
17:23:08 <pjones> Proposal: Let's not re-address this since there's actually no new information
17:23:18 <mjg59> jwb: For extra code in core packages
17:23:36 <jwb> mjg59, oh, just the general software growth problem
17:23:46 <mjg59> dsd_: I don't think there's any benefit in revisiting this on the basis of resource constraints unless that's part of a significant overall goal of reducing Fedora's disk use
17:24:08 <pjones> mjg59: in which case it should be a new, separate feature about reducing disk space
17:24:09 <notting> hm. sugar at least would be less affected by this than gnome/kde/xfce/etc
17:24:10 <mjg59> dsd_: We can go back on this and you get some space back. But what's your long-term plan?
17:24:22 <t8m> pjones, by dropping minidebuginfo information?
17:24:24 <t8m> :]
17:24:46 <dsd_> long term plan for what?
17:24:49 <pjones> t8m: Well, I wouldn't vote yes to that, but if you're proposing a "make it smaller" feature, that's a thing you /could/ include.
17:25:00 <pjones> dsd_: for when the code you're shipping just gets to big to fit
17:25:31 <dsd_> i guess we;d have to ditch fedora if that became true :/
17:25:39 <dsd_> but in recent years it has been pretty constant
17:25:42 <mjg59> dsd_: The software we ship is getting larger over time
17:26:06 <dsd_> i.e. beyond F11 we havent changed that much
17:26:35 <t8m> #proposal Drop the minidebuginfo feature because of the OLPC being overly affected by it
17:26:41 <jwb> -1
17:26:45 <t8m> +1
17:26:49 <mjg59> -1
17:26:56 <notting> <looking at numbers>
17:27:10 <pjones> -1
17:27:56 <nirik> (well, I am -1 to the feature, but not simply due to OLPC, so I guess count me +1 here
17:28:14 <mjg59> But I'd be in favour of a feature that looked at the entire distribution and identified areas that could be trimmed down
17:28:23 <jwb> as would i
17:28:23 <dsd_> i wouldnt say we're overly affected, and the main thing i was wondering is if you'd reconsider the point that it doesnt have an easy/clean on/off switch (right?)
17:28:44 <jwb> notting, you're the potential deciding vote here
17:28:51 <notting> example: xorg server package gained 20k in compressed size, for a delta of 1.5%. geode driver gained 40 bytes ,for percentage diff of <niL>
17:29:16 <mjg59> notting: Over what timescale? Does that include us changing compression method?
17:29:28 <t8m> jwb, we're done with this topic as we won't find enough votes for revoking this feature
17:29:49 <notting> mjg59: last build before minidebuginfo landed in rawhide. a few months in the geode case, a week or two in the server case
17:29:52 <jwb> t8m, but if notting votes +1 to your proposal, we tie and need the missing members to weigh in
17:30:03 <mjg59> notting: Ah, that's the increase due to minidebuginfo?
17:30:15 <mjg59> Sorry, was thinking that was F11->now
17:30:31 <t8m> jwb, I thought that the +5 in the meeting is what counts
17:30:40 <notting> mjg59: yes
17:30:41 <jwb> then why did you make another proposal?
17:31:04 <notting> digikam looks to be ~1.8% bigger compressed as another example
17:31:23 <mjg59> jwb: I believe features need +5 rather than simply a majority of those present
17:31:27 <notting> i am -1 to reverting
17:31:51 <t8m> Let's go ahead with another topic then.
17:31:59 <t8m> #topic #873 F18 Feature: 256 Color Terminals - https://fedoraproject.org/wiki/Features/256_Color_Terminals
17:32:00 <t8m> .fesco 873
17:32:01 <zodbot> t8m: #873 (F18 Feature: 256 Color Terminals - https://fedoraproject.org/wiki/Features/256_Color_Terminals) – FESCo - https://fedorahosted.org/fesco/ticket/873
17:32:02 <notting> and i am willing to help any and all dependency chain pruning to help shrink images where necessary
17:32:20 <dsd_> its understandable if this goes ahead
17:32:31 <dsd_> but could someone at the very least write and test the "give me my space back" script?
17:33:06 <jwb> we'd appreciate a contribution like that, yes
17:33:06 <nirik> dsd_: what would be in such a script?
17:33:23 <nirik> dsd_: perhaps ask notting out of band since he offered to help?
17:33:26 <notting> dsd_: you mean for stripping the minidebuginfo from your image post rpm-install pre-squashfs-ing (or whatever)?
17:33:33 <dsd_> notting: yes, something like that
17:33:42 <notting> dsd_: sure, will do
17:33:46 <dsd_> thanks
17:35:16 <notting> this discussion died down on the list, didn't it?
17:35:29 <nirik> so where are we on this one? I saw some discussion on list, but not sure it was definitive...
17:35:43 <t8m> more less - there were some proposals to work with openssh upstream and so on
17:36:07 <t8m> I think what was definitive was the rejection of the profile.d file solution
17:36:12 <t8m> mangling the $TERM
17:37:04 <notting> in the absence of that, do we have a viable feature proposal?
17:37:15 <mjg59> Not currently
17:37:23 <t8m> I think the feature proposal is not meant to use this file
17:37:29 <nirik> so the main issue was: should this happen in a) profile, or b) vte or some lower level... ?
17:37:38 <t8m> They want to change the default in the terminals.
17:37:51 <t8m> The script is only a quick hack for testing.
17:38:03 <t8m> "For quick testing and development you can also use this /etc/profile.d/256color.sh file. That keeps the config central, and set things up in a standard way such that LS_COLORS will be set appropriately. "
17:38:07 <t8m> citing the feature page
17:38:27 <t8m> "This will be mainly configuration changes. After some discussion it was thought best to update each terminal to adjust the TERM environment variable, to indicate that 256 colors are supported."
17:38:40 <t8m> So i think we can tentatively accept it.
17:38:50 <t8m> I am +1 to the feature.
17:39:28 * nirik is fine with it. +1. I'd ask feature owners to work with terminal maintainers and/or vte/vte3, etc maintainers to make sure everything is done.
17:39:54 <mjg59> It's still a problem
17:40:08 <mjg59> It doesn't deal with the ssh case
17:41:38 <nirik> well, so we defer this and say 'get it working with ssh' ?
17:41:49 <notting> mjg59: in which way?
17:42:00 <t8m> mjg59, ssh could be patched to drop the -256color suffix from $TERM
17:42:03 <notting> mjg59: will try and pass a term not supported on the remote side?
17:42:23 <mjg59> notting: Yes
17:42:51 <mjg59> t8m: That's a pretty gross hack, and would break any existing setups where people have manually configured this
17:43:04 <mjg59> I don't have a good solution
17:43:15 <mjg59> The question is really just whether this is worth the pain it'll cause some users
17:43:22 <t8m> mjg59, I suppose it would have to be configurable
17:44:18 <t8m> but I don't really see any other way - we always had the problem with remote end not knowing the terminal we use
17:45:56 <notting> historically, have we used less-than-standard $TERM values for anything?
17:46:07 <mjg59> Don't /think/ so
17:46:23 <notting> how old does xterm-256color go?
17:46:25 <mjg59> Back in the dark ages Debian used xterm-debian because of subtly different backspace/delete handling
17:46:28 <mjg59> And that was miserable
17:46:42 <mjg59> notting: My understanding is that current Debian stable doesn't know xterm-256color
17:47:04 <mjg59> So I'd guess it's a loss on all legacy Unix
17:47:16 <notting> ... ?
17:47:24 <notting> debian stable doesn't? heck, rhel5 has it
17:47:31 <notting> exactly how old is debian stable?
17:47:33 <nirik> yeah, rhel5 works here.
17:48:46 <mjg59> Ah, sorry, my misunderstanding
17:48:48 <mjg59> "Debian for example traditionally didn't support xterm-256color unless the ncurses-term package was installed."
17:48:51 <notting> even rhel4 has it
17:49:05 * notting runs out of ancient machines to ssh into
17:49:25 <gholms> Debian stable is newer than rhel 6. How far back do you need to look?
17:49:43 <mjg59> Nothing on my Debian system actually depends on ncurses-term
17:50:07 <mjg59> So it's not necessarily "Can this platform be made to support it", it's "Does this platform support it by default"
17:50:12 <notting> so 1) systems that split up their terminfo db somewhat arbitrarily 2) really ancient unix
17:50:23 <mjg59> Yeah
17:50:30 <notting> i'm inclined to +1
17:50:42 * nirik thinks those people can just reset it for their old machine use case.
17:50:52 <jwb> since we're off staring at obscure stuff, does this work with *BSD?
17:51:06 <mjg59> http://marcoschuh.de/wp/?p=873 makes it sound reasonably widespread
17:51:15 * pjones is also leaning towards +1
17:52:36 <mjg59> Given Apple's use of it by default I suspect that the rest of the world will catch up quickly
17:52:50 <mjg59> The only reason I'm cautious is that it doesn't give a huge benefit and it's going to result in some loud complaining
17:53:12 <mjg59> But eh that's probably not going to rate given how much other complaining I'm dealing with, so +1
17:53:30 <gholms> Heh
17:53:32 <pjones> Yeah, I don't think that's going to peak above the noise floor tbh :)
17:54:13 <t8m> I'm counting +5 if the above tentative votes are counted
17:54:17 <jwb> +1
17:55:00 <pjones> t8m: yeah, okay.
17:55:04 <t8m> notting, ?
17:55:19 <notting> +1, thought i said that
17:55:32 <t8m> notting, well it was not really clear to me
17:55:34 <t8m> :)
17:56:15 <t8m> #agreed The 256 Color Terminals feature is approved (+1:5 0:0 -1:0)
17:56:34 <t8m> #topic #880 Timing of FESCo Elections
17:56:34 <t8m> .fesco 880
17:56:35 <zodbot> t8m: #880 (Timing of FESCo Elections) – FESCo - https://fedorahosted.org/fesco/ticket/880
17:57:32 <nirik> I'm fine with the idea of moving it to be better aligned with others.
17:57:48 <notting> not to be a complete wet blanket, but i really don't care one way or another
17:57:52 <nirik> I'd say whoever wants to change things should propose dates and we could ack/nack?
17:58:16 <jwb> i have no opinion on the topic
17:58:23 <t8m> I don't really care much about the FESCo elections timing. Although it would make sense to me to have the timing so all the features for the release that the elected FESCo will be taking care of are approved by the newly elected FESCo
17:58:51 <t8m> nirik, +1
18:00:11 <pjones> Yeah, I can't really bring myself to care.
18:00:26 <notting> so, +1 to nirik's semi-proposal
18:01:01 <pjones> nirik: +1
18:01:43 <jwb> +1 to nirik's proposal
18:02:20 * nirik is fine with it too... not surprisingly
18:02:29 <mjg59> +1
18:02:58 <t8m> #info The current FESCo does not have any strong opinion on the election date change if you want to please propose a concrete change of the date to be voted on.
18:03:32 <t8m> Do we want to discuss the feature tickets that were submitted today?
18:04:02 <t8m> There are some uncontroversial ones, some maybe not.
18:04:16 <notting> i've got time
18:04:24 * nirik is fine either way
18:04:41 <t8m> I'm fine at least with the uncontroversial ones for today.
18:05:15 <jwb> out of curiosity, how long is the fesco meeting supposed to go for?
18:05:57 <pjones> undefined
18:06:03 <pjones> though I think we reserve 2 hours?
18:06:06 <t8m> I think we mostly finish by 2 hours
18:06:32 <t8m> #topic #882: F18 Feature: CIM Management - https://fedoraproject.org/wiki/Features/CIMManagement
18:06:38 <t8m> .fesco 882
18:06:39 <zodbot> t8m: #882 (F18 Feature: CIM Management - https://fedoraproject.org/wiki/Features/CIMManagement) – FESCo - https://fedorahosted.org/fesco/ticket/882
18:07:25 <t8m> +1 - pretty uncontroversial as it is more of the advertisement type
18:07:43 <notting> i'd really prefer that we pick one cimom and standardize on it
18:07:56 <jwb> notting, agreed
18:08:15 <nirik> sure, +1. Dunno how many people will be excited by it, but ok
18:08:17 <jwb> i was under the impression that sblim was the current trend there
18:10:14 <notting> as a self-contained feature, sre, +1
18:10:39 <jwb> +1 with the suggestion of standardizing on one cimom
18:11:08 <pjones> yeah +1
18:11:26 <t8m> mjg59, ?
18:11:35 <mjg59> +1
18:12:25 <t8m> #agreed CIM Management feature is approved (+1:6 0:0 -1:0)
18:12:40 <t8m> #info Please consider standardizing on one CIMOM.
18:13:03 <t8m> #883: F18 Feature: Display Manager Infrastructure Rework - https://fedoraproject.org/wiki/Features/DisplayManagerRework
18:13:11 <t8m> #topic #883: F18 Feature: Display Manager Infrastructure Rework - https://fedoraproject.org/wiki/Features/DisplayManagerRework
18:13:17 <t8m> .fesco 883
18:13:19 <zodbot> t8m: #883 (F18 Feature: Display Manager Infrastructure Rework - https://fedoraproject.org/wiki/Features/DisplayManagerRework) – FESCo - https://fedorahosted.org/fesco/ticket/883
18:13:29 <t8m> This one is more intrusive.
18:13:50 <t8m> but looks like a nice cleanup
18:14:27 <mjg59> Yeah, I'm +1
18:14:47 <pjones> yes, +1
18:14:48 <nirik> +1 here. It may be difficult for some dm's that aren't very active to get the correct changes for vt1, etc, but thats life
18:15:00 <notting> this depends on presets, no? shouldn't we adopt that first? (did we?)
18:15:00 <jwb> +1
18:15:20 <t8m> I wonder what happens if you have multiple dms installed and then you remove the package with the default one, will some else be picked up?
18:15:53 <nirik> notting: good question. I think we defrred them in the past? /me looks
18:15:56 <notting> t8m: from my understanding of the implementation, not afaik
18:16:24 <nirik> https://fedoraproject.org/wiki/Features/PackagePresets
18:16:26 <t8m> notting, that's how I understood it too. Not sure if that's a big loss though.
18:16:44 <t8m> but at least it should be clearly documented
18:18:15 <t8m> I propose we defer this until the Presets are accepted.
18:18:38 <nirik> thats fine with me.
18:21:05 <mjg59> Sure
18:21:47 <t8m> #info Decision on this feature is deferred till the PackagePresets feature is accepted.
18:22:15 <t8m> #topic #884: F18 Feature: Fontconfig 2.10 - https://fedoraproject.org/wiki/Features/Fontconfig2.10
18:22:19 <t8m> .fesco 884
18:22:20 <zodbot> t8m: #884 (F18 Feature: Fontconfig 2.10 - https://fedoraproject.org/wiki/Features/Fontconfig2.10) – FESCo - https://fedorahosted.org/fesco/ticket/884
18:22:35 <mjg59> +1
18:22:46 <nirik> sure, +1
18:22:50 <jwb> +1
18:22:59 <t8m> +1
18:23:04 <pjones> +1
18:23:05 <notting> +1
18:23:29 <notting> the bit about the config files moving might be irritating, but *shrug*
18:23:37 <t8m> #agreed Feature Fontconfig 2.10 is approved (+1:6 0:0 -1:0)
18:24:57 <t8m> #topic #886: F18 Feature: Rails 3.2 - https://fedoraproject.org/wiki/Features/Rails_3.2
18:25:01 <t8m> .fesco 886
18:25:02 <zodbot> t8m: #886 (F18 Feature: Rails 3.2 - https://fedoraproject.org/wiki/Features/Rails_3.2) – FESCo - https://fedorahosted.org/fesco/ticket/886
18:25:49 <nirik> I thought rails needed mod_passenger...
18:25:55 * nirik is probibly just confused.
18:25:58 <t8m> hehe :]
18:26:01 <notting> does this break any packaged rails apps?
18:26:28 <t8m> "all the packages from the Rails stack are dependencies of other cca 50 packages. These will have to be rebuilt and possibly updated."
18:26:44 <mjg59> Enterprise ready
18:26:51 <t8m> LOL
18:27:08 <t8m> but +1 anyway
18:27:19 <jwb> i wonder what 8 Gems packages will have to be reviewed and included
18:27:33 <nirik> yeah, would be good to update the page with the specific packages mentioned.
18:28:08 <notting> i'm fine to doing the upgrade, so +1. just concerned that apps might break
18:28:18 <mjg59> +1
18:28:51 <jwb> +1 with the suggestion of updating the page with more specifics and possibly using a koji buildtag for it
18:28:54 <nirik> +1 in any case
18:29:32 <pjones> +1
18:30:02 <t8m> #agreed Feature Rails 3.2 is approved (+1:6 0:0 -1:0)
18:30:40 <t8m> #info Please mention the specific packages that need to be updated and added on the feature page.
18:31:30 <t8m> #topic #887: F18 Feature: Perl 5.16 - https://fedoraproject.org/wiki/Features/perl5.16
18:31:37 <t8m> .fesco 887
18:31:38 <zodbot> t8m: #887 (F18 Feature: Perl 5.16 - https://fedoraproject.org/wiki/Features/perl5.16) – FESCo - https://fedorahosted.org/fesco/ticket/887
18:32:13 <t8m> +1
18:32:18 <notting> ack. +1
18:32:20 <mjg59> +1
18:32:22 <notting> didn't they start building this already?
18:32:29 <nirik> another fedora, another perl. ;) +1, but it would be nice if this was announced before the mass building had started.
18:32:34 <nirik> yes.
18:32:45 <jwb> aside from me wanting perl removed entirely, +1
18:33:20 <t8m> pjones, ?
18:34:09 <pjones> +1
18:34:12 <t8m> #agreed Feature Perl 5.16 is approved (+1:6 0:0 -1:0)
18:34:55 <t8m> #info Please announce the Perl version upgrade rebuild before starting rebuilding next time.
18:35:29 <t8m> #topic #885: F18 Feature: PowerPC ppc64p7 subarch support in rpm and yum and in packages - https://fedoraproject.org/wiki/Features/Power7Subarch
18:35:33 <t8m> .fesco 885
18:35:34 <zodbot> t8m: #885 (F18 Feature: PowerPC ppc64p7 subarch support in rpm and yum and in packages - https://fedoraproject.org/wiki/Features/Power7Subarch) – FESCo - https://fedorahosted.org/fesco/ticket/885
18:35:41 <dwa> hi, I'm here.
18:36:03 <pjones> Not really sure why this needs a feature, but nevertheless I'm fori t.
18:36:04 <pjones> for it
18:36:27 <dwa> pjones: it touches a few things that could affect primary (e.g. mash, rpm & yum)
18:36:28 <mjg59> Only one quibble
18:36:43 <mjg59> The notes might make it clearer that it's as a scondary arch?
18:37:04 <dwa> mjg59: sure, can do
18:37:18 <mjg59> Right now I think I'd read that and think it was primary
18:37:29 <pjones> mjg59: er... not sure why that matters to adding yum and rpm support
18:37:37 <dwa> mjg59: you mean release notes, right?
18:37:39 <mjg59> pjones: It doesn't
18:37:40 <mjg59> dwa: Right
18:37:46 <jwb> pjones, features get added to the PR stuff
18:37:46 <nirik> +1 here.
18:38:00 <mjg59> jwb: Looking forward to that new feature process
18:38:05 <dwa> mjg59: nod. We wouldn't necessarily have to include it in the primary release notes either
18:38:13 <dwa> but I'll update them regardless
18:38:23 <t8m> mjg59, as PPC is secondary and this is just subarch I think it is implicit
18:38:27 <notting> are you building everything as it, or just some things?
18:38:34 <dwa> notting: just some things
18:39:02 <dwa> notting: we've got a list with notes at https://fedoraproject.org/wiki/Ppc64p7subarch
18:39:16 <jwb> +1 with the caveat mjg59 added
18:39:20 <notting> the mailers???
18:39:42 <notting> i ... did not know they were ever cpu bound
18:40:07 <t8m> also pam does not seem to me to be perf critical either
18:40:13 <dwa> notting: heh. I can get specifics from IBM if you're curious - the packages they suggested apparently have significant gains. *shrug*.
18:40:22 <jwb> i would add xz to that list if you're already doing zlib and bzip, given that every RPM is xz compressed
18:41:28 <notting> pp64 app can use pp64p7 lib,right?
18:41:42 <notting> wait, that's a silly question, of course it could
18:41:46 <t8m> +1 anyway
18:41:50 <notting> in any case, sure, +1.
18:41:51 <dwa> notting: we'd still build ppc64 versions of everything
18:42:05 <dwa> notting: so it'd be like i686 & i386 way back when.
18:44:31 <t8m> pjones, mjg59, ?
18:44:44 <pjones> Already said I'm fori t.
18:44:46 <pjones> for it.
18:44:53 <pjones> Even made that same typo the first time.
18:44:53 <mjg59> +1
18:46:48 <t8m> pjones, I'm sorry I overlooked it
18:47:19 <t8m> #agreed Feature PowerPC ppc64p7 subarch support in rpm and yum and in packages is approved (+1:6 0:0 -1:0)
18:47:36 <dwa> thanks guys.
18:48:04 <t8m> I am not sure we want to discuss the SecureBoot feature as the Board still did not vote on it?
18:48:22 <pjones> Yeah, I think we're still waiting for them to do something other than talk about it
18:48:28 <nirik> yeah, probibly defer
18:48:55 <t8m> #topic Next week's chair
18:48:56 <jwb> did we just stop?
18:49:09 <jwb> sigh, ignore that. wrong tab
18:49:19 <t8m> Anybody wants it?
18:49:21 <notting> presets aren't specifically filed as a feature yet?
18:49:42 <notting> i'll take chair
18:50:02 <t8m> notting, it seems that the page is still in FeaturePageIncomplete
18:50:20 <t8m> #info notting will be the next week's chair for FESCo
18:51:02 <t8m> #topic Open Floor
18:51:09 <t8m> anything?
18:53:02 * nirik has nothing.
18:53:15 <t8m> I'll close the meeting if nothing appears in one minute.
18:55:23 <gholms> Quick question?
18:55:34 <pjones> go ahead
18:55:41 <gholms> What, exactly, are you looking to get out of the board?
18:55:57 <gholms> There's been discussion, yes, but I'm still unclear about what it is you folks are wondering.
18:56:14 <nirik> gholms: well, if the Board feels that they need to approve the feature instead of us?
18:56:16 <pjones> For secure boot? An agreement that we can go ahead with a shim signed by the signing service and still be Fedora? :)
18:56:17 <gholms> Just a stance from a political/freedom standpoint?
18:56:23 <gholms> Ok
18:56:28 <pjones> I mean, it seems like that's what they're saying they want
18:56:40 <pjones> if they don't feel the need to do that, we can cover it from a technical perspective without it
18:56:55 <pjones> so either their okay or their statement of opting out of making that decision :)
18:56:56 <t8m> gholms, exactly what pjones said
18:57:08 <gholms> Alrighty. Thanks.
18:57:31 * t8m will opt out of acking the feature if board opts out of making that decision though :)
18:57:37 <gholms> I'd just hate to participate in a board discussion about this and come up with a completely irrelevant resolution.
18:59:04 <t8m> I'll close the meeting if nothing appears in one minute.
19:00:32 <t8m> #endmeeting
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
More information about the devel
mailing list