18:00:23 <limburgher> #startmeeting FESCO (2012-03-19)
18:00:23 <zodbot> Meeting started Mon Mar 19 18:00:23 2012 UTC.  The chair is limburgher. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:23 <limburgher> #meetingname fesco
18:00:24 <limburgher> #chair notting nirik mjg59 mmaslano t8m pjones sgallagh mitr limburgher
18:00:24 <limburgher> #topic init process
18:00:24 <zodbot> The meeting name has been set to 'fesco'
18:00:24 <zodbot> Current chairs: limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m
18:00:31 <pjones> yes yes I am here.
18:00:33 <limburgher> Roll call
18:00:34 * nirik waves.
18:00:36 * notting is here
18:00:37 <t8m> Hello
18:00:39 * limburgher here, obv.
18:00:46 <mmaslano> hi
18:00:46 <mitr> Hello all
18:00:49 <sgallagh> Hello
18:01:21 <twoerner> hi
18:01:31 <limburgher> I'll give mj959 a few min.
18:01:47 <limburgher> And his friend mjg59.
18:01:58 <sgallagh> heh
18:02:46 <adamw> can twoerner and i ask that you try to make sure there's a bit of time available for open floor?
18:02:56 <adamw> we'd like to bring up the firewalld feature request, since it doesn't seem to be on the agenda
18:03:11 <limburgher> Sure, if we don't take to long on 828.
18:03:15 <adamw> thanks
18:03:22 <limburgher> s/to/too/
18:04:28 <limburgher> Just saw mjg59 won't make it here today, so let's get moving:
18:04:35 <limburgher> #topic #821 F18 Feature: PCRE 8.30 -- https://fedoraproject.org/wiki/Features/pcre8.30
18:04:50 <limburgher> .fesco 821
18:04:52 <zodbot> limburgher: #821 (F18 Feature: PCRE 8.30 -- https://fedoraproject.org/wiki/Features/pcre8.30) – FESCo - https://fedorahosted.org/fesco/ticket/821
18:05:11 <notting> well, it's already done. so, sure! +1
18:05:16 <mmaslano> +1
18:05:18 <nirik> sure, +1
18:05:19 <t8m> +1
18:05:19 <limburgher> +1
18:05:22 <mitr> +1
18:05:25 <pjones> +1
18:05:35 <sgallagh> +1, does this need a mass-rebuild?
18:05:44 <mmaslano> it was already done
18:05:47 <limburgher> #agreed F18 PCRE 8.30 is passed  (+:8,-:0,0:0)
18:05:49 <sgallagh> oh right, I remember that
18:05:57 <limburgher> #topic #822 F18 Feature: AE1000 USB wifi driver - https://fedoraproject.org/wiki/Features/AE1000usb
18:06:00 <limburgher> .fesco .822
18:06:01 <zodbot> limburgher: An error has occurred and has been logged. Please contact this bot's administrator for more information.
18:06:08 <limburgher> .fesco 822
18:06:09 <zodbot> limburgher: #822 (F18 Feature: AE1000 USB wifi driver - https://fedoraproject.org/wiki/Features/AE1000usb) – FESCo - https://fedorahosted.org/fesco/ticket/822
18:06:23 <mitr> -1; out-of tree driver, and
18:06:25 <mitr> <linville> mitr besides, it appears that the hardware should already be supported by the rt2800usb driver
18:06:32 <sgallagh> -1 For all the reasons identified on the mailing list
18:06:37 <notting> -1 for all of the reasons
18:06:42 <limburgher> -1 all of the above.
18:06:44 <mmaslano> -1 for reasons on mailing list
18:06:52 * nirik nods. -1...
18:06:54 <pjones> minus everything.
18:07:11 <nirik> we should note in the 'fix feature process' that we should let people know things like this eariler...
18:07:16 <t8m> -1
18:07:42 <limburgher> Yeah.  abadger1999?
18:07:43 <t8m> nirik, isn't this handled in packaging rules already?
18:07:45 * nirik doesn't want someone to go through all the trouble of the feature process only to hit some forbidden items, etc
18:07:47 <limburgher> #agreed F18 AE1000 USB wifi driver is rejected  (+:0,-:8,0:0)
18:07:58 <nirik> t8m: yes.
18:08:01 <limburgher> Ideally they should check that first, but. . .
18:08:10 <limburgher> #topic #823 F18 Feature: Network Manager hotspots - https://fedoraproject.org/wiki/Features/RealHotspot
18:08:14 <limburgher> .fesco 823
18:08:16 <zodbot> limburgher: #823 (F18 Feature: Network Manager hotspots - https://fedoraproject.org/wiki/Features/RealHotspot) – FESCo - https://fedorahosted.org/fesco/ticket/823
18:08:24 <abadger1999> limburgher: Yeah, note it on the Fix Features page.
18:08:33 <nirik> looking forward to this... +1
18:08:38 <mitr> I have asked on the talk page, and the response already noted taht "this might be a dead topic now", so the submitter did get some advance notification
18:08:40 <t8m> +1
18:08:40 <abadger1999> limburgher: I plan to go through that after I wrap up the rubygems draft for the FPC.
18:08:44 <notting> re-ack for f18. +1
18:08:46 <mitr> +1 to hotspots
18:08:53 <limburgher> abadger1999:  Heh.  Yeah.  Thanks! :)
18:09:00 <limburgher> +1
18:09:05 <sgallagh> +1, would like to see this land early
18:09:08 <mmaslano> +1
18:09:21 <nirik> folks in #fedora have asked for this a fair bit recently... I think it will be popular. ;)
18:10:25 <limburgher> pjones?
18:10:40 <pjones> yes, +1
18:10:43 <limburgher> Cool.
18:10:51 <limburgher> #agreed F18 Network Manager hotspots is passed  (+8,-:0,0:0)
18:10:57 <limburgher> #topic #824 F18 Feature: Rework Package Groups -- https://fedoraproject.org/wiki/Features/ReworkPackageGroups
18:11:01 <limburgher> .fesco 824
18:11:02 <zodbot> limburgher: #824 (F18 Feature: Rework Package Groups -- https://fedoraproject.org/wiki/Features/ReworkPackageGroups) – FESCo - https://fedorahosted.org/fesco/ticket/824
18:11:18 <nirik> +1 here.
18:11:24 <pjones> definitely +1
18:11:26 <t8m> +1
18:11:29 * notting abstains, but can answer any questoins.
18:11:29 <mmaslano> +1
18:11:32 <limburgher> +1
18:11:41 <sgallagh> +1
18:11:58 <limburgher> Long overdue and very welcome, IMO.
18:12:06 <sgallagh> limburgher: +1
18:12:16 <mitr> +0 - the description is rather vague; AFAICT the relevant parties know what the plan is, and are happy with it, but I can't in good conscience +1 it
18:12:29 <limburgher> Fair enough.
18:12:42 <limburgher> #agreed F18 Rework Package Groups is passed  (+6,-:0,0:2)
18:12:48 <limburgher> #topic #826 F18 Feature: KRB5 Credential Cache Move - https://fedoraproject.org/wiki/Features/KRB5CacheMove
18:12:54 <limburgher> .fesco 826
18:12:59 <zodbot> limburgher: #826 (F18 Feature: KRB5 Credential Cache Move - https://fedoraproject.org/wiki/Features/KRB5CacheMove) – FESCo - https://fedorahosted.org/fesco/ticket/826
18:13:13 * sgallagh abstains but will answer questions as needed
18:13:21 <nirik> sure, +1.
18:13:22 <notting> +1, this makes way too much sense.
18:13:27 <mitr> sgallagh: what's the connection to nfsv4?
18:13:31 <mitr> +1 anyway :)
18:13:36 <t8m> +1
18:13:38 <limburgher> +1 notting:  Yeah, it'll probably be the death of us all.
18:13:42 <mmaslano> +1
18:13:46 <mitr> ah, it's on the talk page already. never mind
18:13:48 <pjones> sure, +1
18:13:54 <sgallagh> mitr: I replied on the discussion page, but the answer is "gssd trolls through /tmp, which is dangerous and ineffectual"
18:14:22 <limburgher> #agreed F18 KRB5 Credential Cache Move is passed  (+7,-:0,0:1)
18:14:41 <limburgher> #topic #827 F18 Feature: RPM 4.10 - https://fedoraproject.org/wiki/Features/RPM4.10
18:14:42 <sgallagh> I'm going to be filing a second half of this soon as well
18:14:47 <limburgher> .fesco 827
18:14:48 <sgallagh> (support for multiple TGTs)
18:14:48 <zodbot> limburgher: #827 (F18 Feature: RPM 4.10 - https://fedoraproject.org/wiki/Features/RPM4.10) – FESCo - https://fedorahosted.org/fesco/ticket/827
18:15:02 <mitr> +1
18:15:02 <nirik> +1 here.
18:15:08 <limburgher> +1
18:15:10 <t8m> +1 sure
18:15:11 <sgallagh> +1 rubber stamp
18:15:13 <mmaslano> +1 but I hope this time it will rpm go in earlier in development phase
18:15:20 <nirik> it's ready to go in now I think.
18:15:22 <pjones> +1
18:15:32 <notting> +1
18:15:37 <limburgher> #agreed F18 RPM 4.10 is passed  (+8,-:0,0:0)
18:15:45 <limburgher> #topic #828 F18 Feature: systemd-journal -- https://fedoraproject.org/wiki/Features/systemd-journal
18:15:49 <limburgher> .fesco 828
18:15:50 <zodbot> limburgher: #828 (F18 Feature: systemd-journal -- https://fedoraproject.org/wiki/Features/systemd-journal) – FESCo - https://fedorahosted.org/fesco/ticket/828
18:16:36 <t8m> -1 as systemd-journal is not a full syslog replacement
18:16:50 <t8m> and for other reasons as well
18:16:53 <sgallagh> t8m: What is it lacking?
18:16:55 * nirik isn't sure what overlap there is between the two.
18:16:55 <mitr> 1) journal developers are not interested in replacing/reimplementing the syslog ecosystem, so disabling rsyslogd is a net decrease in functionality
18:16:57 <mitr> 2) disabling rsyslogd right now would hinder adoption of project lumberjack (http://lwn.net/Articles/484731/ ); there's no rush, we can let the coexist for some time
18:17:00 <mitr> 3) The feature severely underestimates the impact of the change (no plain-text files in /var/log), and doesn't mention any plan to deal with packages like logwatch that would be broken by it, i.e. is not thought out/investigated enough.
18:17:01 <mitr> so -1
18:17:31 <limburgher> I'm not thrilled about a binary log for anything, esp. syslog.
18:17:33 <mitr> sgallagh: network transfer/interoperability, configurable backends, ability to map/transform messages, ...
18:17:50 <limburgher> -1
18:17:51 <sgallagh> I'm convinced. -1
18:18:03 * nirik is also a weak -1...
18:18:05 <pjones> I'm pretty meh on the whole thing
18:18:32 <notting> don't think it's worth the effort at this point. maybe in the future...
18:18:35 <notting> so, -1
18:18:46 <mmaslano> I discussed it with feature submiter some time ago. It can't be used as replacement, at least now -1
18:18:59 <pjones> yeah, -1 for now.  it just doesn't appear to be really ready yet.
18:19:07 <limburgher> Ok.
18:19:15 <limburgher> #agreed F18 systemd-journal is rejected  (+0,-:8,0:0)
18:19:36 <limburgher> #topic firewalld
18:19:43 <limburgher> I don't see the ticket, but. . .
18:19:53 <twoerner> this is https://fedorahosted.org/fesco/ticket/805
18:19:58 <limburgher> thx.
18:20:25 <twoerner> should be this one: https://fedorahosted.org/fesco/ticket/805#comment:15
18:20:52 <limburgher> So test day is today, correct?
18:20:57 <twoerner> yes
18:21:01 <twoerner> https://fedoraproject.org/wiki/Test_Day:2012-03-19_firewalld
18:22:14 <sgallagh> How are we defining a "successful" Test Day?
18:22:26 <sgallagh> So far, I only see three testers on the matrix
18:22:33 <limburgher> I see 3 testers, one with no issues.
18:23:10 <twoerner> yes, but one only partly updated
18:23:19 <mitr> The [1] is a selinux-policy issue, already fixed
18:23:21 <limburgher> From a scientific perspective, that's successful testing.  Possibly not from a feature perspective.  I'd like to see more testers.
18:23:26 <twoerner> and the other one had bigger selinux problem
18:23:42 <sgallagh> limburgher: May I suggest that FESCo might step in and help with testing following this meeting?
18:23:48 * sgallagh will spin up a VM
18:24:04 <mmaslano> sgallagh: I agree
18:24:27 <limburgher> I would but I'm utterly swamped today.
18:24:42 <mmaslano> limburgher: I'll do it tomorrow morning ;-)
18:24:46 * nirik could try, but is also pretty busy.
18:25:23 <mitr> It seems that the basic functionality is fine
18:25:40 <limburgher> #proposal FESCO members, along with others, test, and add results to wiki page.  Vote in ticket, remaining votes at next weeks meeting if needed.
18:25:41 <mitr> twoerner: what would we lose with a broken firewall-applet? zone UI, something else?
18:25:59 <nirik> limburgher: +1
18:26:01 <twoerner> only a control applet to see what is going on
18:26:05 <sgallagh> limburgher: +1 (I'm firing up a VM as we speek)
18:26:07 <sgallagh> *speak
18:26:27 <mmaslano> +1
18:26:30 <limburgher> That way if I get time later in the week I can help.
18:26:35 <twoerner> mitr: it can send notifactions
18:27:15 <mitr> +1 to proposal
18:27:19 <mitr> twoerner: thanks
18:27:37 <t8m> +1 to proposal
18:27:51 <notting> +1
18:27:58 <pjones> sure, +1
18:28:31 <limburgher> #agreed Proposal to have FESCO test firewalld and vote in ticket is passed  (+7,-:0,0:0)
18:28:45 <twoerner> great, thanks
18:29:09 <limburgher> #topic #830 F18 Feature: ARM as Primary Arch -- https://fedoraproject.org/wiki/Features/FedoraARM
18:29:10 <twoerner> so it is ok to add firewalld to base in comps
18:29:19 <limburgher> .fesco 830
18:29:19 <zodbot> limburgher: #830 (F18 Feature: ARM as Primary Arch -- https://fedoraproject.org/wiki/Features/FedoraARM) – FESCo - https://fedorahosted.org/fesco/ticket/830
18:29:29 <nirik> twoerner: if it passes votes in ticket?
18:29:48 <mitr> wait, beta change deadline is tomorrow already
18:29:59 <limburgher> <headdesk>
18:30:07 <mitr> should the comps be stable by then?
18:30:13 <limburgher> I'd think so.
18:30:14 <Viking-Ice> It would be good to get a technical feed back on the journal rejection in the terms of we like this to be fixed before we can considered an default thanks ( btw we dont ship logwatch by default afaik )
18:30:21 <notting> so, yeah, i think we need a sooner decision
18:30:30 <nirik> mitr: yes, the request is for a freeze break?
18:30:55 <mitr> nirik: We _can_ approve the comps change later, of course.  I'm just not sure whether we want to.
18:31:18 <t8m> Viking-Ice, you get some in the meeting log
18:31:43 <limburgher> It can be in spins without being in comps.
18:32:32 <nirik> it could, but that might be pretty confusing...
18:32:41 <limburgher> True.
18:32:43 <nirik> 'firewalld is sorta kinda default'
18:32:46 <jonmasters> bconoboy: we're about to get to ARM btw
18:32:53 <bconoboy> jonmasters: I'm watching
18:32:54 <notting> might want to undo current topic
18:32:58 <jonmasters> :)
18:33:20 <limburgher> notting:  Want to do the honors?  I'm still getting my chair legs.
18:33:23 <notting> #undo
18:33:23 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x1c7da190>
18:33:46 <notting> so, we could have people vote in the ticket, but we'd need sooner feedback than 'by next week'
18:33:48 <limburgher> <goggles at complexity of command>
18:34:04 <nirik> proposal: vote in firewalld ticket by end of day. ?
18:34:10 <mitr> I won't be able to test today - I'm inclined to +1 adding to comps now - from the current tests the base firewall seems to work, applet/zones are a new feature so I can't see why they should block this
18:34:18 <adamw> practically speaking, comps doesn't freeze.
18:34:21 <limburgher> +1
18:34:28 <mmaslano> mitr: +1
18:34:30 * nirik nods at adamw, but still.
18:34:33 <adamw> and we don't have anything written down saying that it can't be changed after the freeze date.
18:34:38 <adamw> i would like that to be different, but it isn't. =)
18:34:55 <mmaslano> adamw: we might change it for next time ;-)
18:35:00 <Viking-Ice> t8m, sorry fail to see them? user that want to use lumberjack could just enable rsyslog,logwatch is not shipped by default 3 item on the list. Documentation can be updated
18:35:10 <nirik> adamw: in the features process we do say that things that are default must be in and default for alpha. So this is really a request from back post alpha
18:35:28 * rbergeron nods to that
18:35:28 <t8m> Viking-Ice, textual log files?
18:35:40 <mitr> Viking-Ice: "users that don't want rsyslog could just disable it" just as well, "it's not shipped by default" is not an excuse for breaking it, really.
18:35:44 <mmaslano> could we stick to the previous topic? :)
18:35:49 <limburgher> Please.
18:35:56 <t8m> mmaslano, sorry for that
18:36:31 <mitr> adamw: any opinion on firewalld / test day results compared to other test days from QE?
18:36:42 <limburgher> So I see 2 to vote by EOD, 1 to add to comps now.  Not mutually exclusive, of course.
18:36:49 <Viking-Ice> mitr, administrative users need to configure and setup up things all the time hows this different?
18:36:58 <notting> i can be +1 to mitr's proposal
18:37:09 <limburgher> Viking-Ice: There will be open floor after we discuss ARM.
18:37:19 <Viking-Ice> limburgher, ok
18:37:21 <t8m> I can be +1 to add to comps now as well
18:37:21 <sgallagh> I'm planning to test today, and I will vote in the ticket after that
18:37:35 * nirik is a slight -1... would prefer landing in f18 at this point. But I won't yell too much if everyone else thinks it's ready.
18:37:53 <mmaslano> I'm also for adding firewalld into comps, but we could do the testing anyway
18:38:11 <sgallagh> nirik: I'm also a slight -1, but I'm willing to give them the benefit of the doubt and try it for myself before committing to that
18:38:34 <nirik> so whats that? any other votes?
18:38:49 <limburgher> We've got two seperate items being voted on.
18:39:02 <limburgher> A: is test and vote in ticket by EOD.
18:39:17 <limburgher> B: add to comps now.
18:39:22 <limburgher> +1 A, +1 B.
18:39:34 <nirik> +1 A, -1 B.
18:39:35 <sgallagh> +1 A, -1 B
18:39:43 <pjones> I'm vaguely +1 to B, and I don't think I can commit to A.
18:39:59 <mmaslano> -1 A, +1 B
18:40:12 <notting> 0 A (-ENOTIME), +1 B
18:40:15 <mitr> +1 A (won't be able to test, but wouldn't want to prevent others from agreeing), +1 B
18:40:20 <pjones> notting: exactly.
18:40:28 <notting> i suppose +1 to A in that i'm ok with others doing it
18:40:33 <pjones> likewise.
18:40:46 <t8m> likewise
18:40:49 <sgallagh> pjones, notting: Is that an implication to trust the judgement of the members that DO test?
18:40:53 <nirik> I think thats enough to pass B...
18:40:55 <adamw> mitr: sorry, i really haven't had a lot of time to look
18:41:05 <notting> sgallagh: yes.
18:41:08 <pjones> sgallagh: well, to trust them more than people who don't test, certainly ;)
18:41:12 <sgallagh> hahaha
18:41:58 <adamw> nphilipp would be nils philippsen, right?
18:42:01 <adamw> he's pretty trustworthy.
18:42:18 <limburgher> #agreed Test firewalld and vote in ticket by EOD is passed  (+5,-:1,0:1)
18:42:26 <sgallagh> Well, it does look like nirik is right and there are +5 to just put it in comps
18:42:38 <nirik> limburgher: but didn't B just pass? making A moot? :)
18:42:53 <limburgher> . . .I was still counting.
18:42:57 <limburgher> #undo
18:42:57 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x2e3d9cd0>
18:43:02 <limburgher> <sigh>
18:43:40 <limburgher> #agreed Add firewalld to comps now passed  (+5,-:2,0:0)
18:43:55 <limburgher> So is that all we need to discuss for firewalld?
18:44:05 <twoerner> yes, I think ...
18:44:09 <limburgher> Ok.
18:44:13 <limburgher> #topic #830 F18 Feature: ARM as Primary Arch -- https://fedoraproject.org/wiki/Features/FedoraARM
18:44:14 <sgallagh> limburgher: It's all I'm *willing* to discuss, I think :)
18:44:19 <limburgher> .fesco 830
18:44:21 <zodbot> limburgher: #830 (F18 Feature: ARM as Primary Arch -- https://fedoraproject.org/wiki/Features/FedoraARM) – FESCo - https://fedorahosted.org/fesco/ticket/830
18:44:26 <limburgher> sgallagh:  Nuff said. :)
18:44:45 <sgallagh> Interesting proposal, but I wonder whether we have the hardware resources to accomplish this.
18:45:00 <nirik> right, so I am +1... but there needs to be some coordination of hardware and storage and other details before we can add it in...
18:45:02 <notting> scope points #3/#4 are the concern, here (imo)
18:45:02 <pjones> I'm -1 on this honestly; we should wait until <mumble>
18:45:02 <sgallagh> We probably need to make a few test machines available to packagers if we move ahead
18:45:04 <t8m> same concers from me
18:45:22 <jonmasters> sgallagh: so as we mentioned in the proposal, we would gate this on the hardware being installed in Phoenix
18:45:22 * nirik has a test smartbook for anyone who wants to look around...
18:45:37 <pjones> which I guess might be what #3 is about?
18:45:37 <limburgher> sgallagh:  YEah, I've seen some of my packages fail on arm and I have on arm machines.
18:45:42 <nirik> http://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
18:45:46 <sgallagh> jonmasters: build hardware is one thing, test hardware another thing entirely
18:46:00 <jonmasters> We have enterprise grade hardware coming from a couple of OEMs. We can provision nodes for remote access.
18:46:04 <t8m> I am +1 as I suppose we can always kick it back to secondary if it becomes serious bottleneck.
18:46:20 <bconoboy> sgallagh: what hardware are you concerned about? build systems? infrastructure?
18:46:25 <limburgher> +1, same caveat as t8m
18:46:25 <jonmasters> sgallagh: we can provide remote access to boards currently hosted at Seneca, this has been discussed
18:46:35 <mitr> To clarify, this is two 32-bit architectures, no 64-bit at this time, right?
18:46:43 <sgallagh> bconoboy: Most people developing on Fedora do not have access to client machines on which to test their packages
18:46:47 <jonmasters> mitr: correct. The AArch64 will follow later
18:46:47 <notting> i've seen discussion of hardware 'coming', is there a more concrete timeframe?
18:46:48 <nirik> mitr: yeah, thats my understanding.
18:46:53 <bconoboy> mitr: no 64 bit at this time.
18:47:01 <sgallagh> ARM brings a whole host of new endian-ness issues that need to be addressed
18:47:13 <jonmasters> sgallagh: how so?
18:47:13 <pjones> so what's the point of doing all this if it's not for AArch64?
18:47:17 <bconoboy> sgallagh: We will do little endian only. No BE.
18:47:29 <pjones> sgallagh: yeah I don't think anybody is even considering BE devices
18:47:32 <bconoboy> pjones: AArch64 won't exist for years.
18:47:34 <mitr> What about the installation? Are we 1) able to implement, and 2) happy with, tree composes that don't produce anything that runs anaconda?
18:47:41 <jonmasters> pjones: we have an established base of 32-bit users. Witness the success of the Raspberry Pi
18:47:44 <sgallagh> Sorry, got my wires crossed.
18:47:52 <sgallagh> I meant to be talking about alignment issues
18:48:18 <jonmasters> AArch64 software will exist in <mumble> but we don't want to wait for that <mumble>
18:48:30 <bconoboy> notting: Timeframe is between 2-5 months.
18:48:44 <notting> bconoboy: 2 is good. 5 is awfully late :)
18:48:47 <pjones> jonmasters: and is being a secondary arch *hurting* that effort in some way?
18:48:49 <bconoboy> we don't actually need arm hardware until mid-way through the transition.
18:49:07 <jonmasters> To be clear, we are quite happy with a plan that calls for F18 PA *if* we meet all of the goals. If we don't, it's trivial to punt to F19
18:49:16 * nirik notes we could push out a release if anything doesn't seem like it will make it
18:49:18 <pjones> jonmasters: I ask because there *is* tangible cost to other primary arches for doing this.
18:49:37 <pjones> tangible ongoing cost, that is.
18:49:59 <limburgher> jonmasters: Any idea how much is FTBFS on Arm as of today?
18:50:09 <jonmasters> pjones: we think ARM (even 32-bit, especially that at the moment) has a growing and significant penetration. We think it would not be forward thinking of Fedora (and in line with the mission of Fedora) not to adapt to that
18:50:18 <bconoboy> mitr: Installation will start with prebuilt images, but our medium-term goal is anaconda installation for supported platforms.
18:50:25 <pjones> jonmasters: that doesn't really answer my question?
18:50:38 <sgallagh> jonmasters: Sure, but is there any reason it needs to be primary arch to accomplish that goal?
18:50:39 <bconoboy> mitr: Also, moving the builds to primary does not require that the installation solution be 100%
18:50:42 <notting> adamw: opinions on how bconoboy's above statement impacts release criteria and fedora QE?
18:50:56 <limburgher> bconoby:  Agree, see rawhide. :)
18:51:08 <pjones> bconoboy: eh, historically it does
18:51:08 * mitr is more worried about the various non-packaged things anaconda does to the target system
18:51:14 <jonmasters> sgallagh: We don't think primary arch needs to be an exclusive x86 club
18:51:15 <sgallagh> Making something primary arch implies a certain level of completeness of packages compared with the other PA arches
18:51:22 <pjones> bconoboy: and that certainly seems like it'd be users' expectations
18:51:36 <mjg59> Hey, sorry I was missing
18:51:49 <pjones> jonmasters: and nobody's going to argue that it should be.
18:51:59 <sgallagh> jonmasters: I'm not disagreeing with you. I'm just not sure we're ready to commit to this as PA *yet*
18:52:01 <mmaslano> I would be +1 for it, but we need to set some criteria
18:52:03 <mjg59> How many platforms are we expecting kernel support for?
18:52:09 <bconoboy> pjones: Moving to primary will put builds in a more reliable environment.  What is the drawback you are concerned about?
18:52:26 <limburgher> Let's look at this from the other side:  How does making it primary help it get to primary readiness?
18:52:29 <jonmasters> pjones: the installation solution for current generation 32-bit systems with ARM is different. Most of these boards are cheap, at a price of $25-$100 and so they are built with cost reduction in mind. This means they have a single storage card that contains everything. To provision, you make a card.
18:53:04 <pjones> bconoboy: there are restrictions on packagers based on an arches primary-ness.  by making something PA we're explicitly stating, for example, that we'll hold back alpha/beta/release of other architectures for it
18:53:09 <bconoboy> sgallagh: We're well-passed 90% package coverage in secondary now. Most of what isn't built at this point is FTBFS.
18:53:09 <nirik> so the big gain for you guys is enterprise buildsystem/infrastructure that comes with primary?
18:53:11 <jonmasters> mjg59: we are planning to limit the kernel platforms to a small number, initial versatile express. Maybe a couple more. The limit is that we don't want to take an unreasonable time to build the kernel package.
18:53:15 <pjones> bconoboy: it effectively makes everything a synchronous operation
18:53:41 <mitr> jonmasters: It seems to me that either the "primary" status is a resource allocation matter (primarily "expecting all maintainers to handle bugs"), in which case exclusiveness is irrelevant, or it is a branding matter ("this is good enough"), in which case the installer etc. should be complete enough before being marked as primary.  Which one are you after?
18:53:51 <bconoboy> pjones: If our arm builds are faster than x86 does that mean x86 should be demoted?  I'm trying to understand the dynamics here.
18:53:55 <jonmasters> mjg59: additional kernels can be trivially compiled. The idea I have proposed is that the kernel SPEC by default only build a smaller number (especially during development of rawhide), then we can build others with a trivial rpmbuild flag
18:54:03 <sgallagh> bconoboy: As I said, I'm still not sure about the much-subtler bugs inherent in ARM's requirement for memory-alignment
18:54:14 <mjg59> jonmasters: And these will only be kernels supported by the upstream? Or are we expecting to have to carry patches?
18:54:15 <jonmasters> mitr: why does the installer matter here?
18:54:19 <nirik> jonmasters: that would result in not much testing of those.
18:54:22 <jonmasters> mjg59: only upstream kernels
18:54:38 <mjg59> jonmasters: Ok. How long does it take to build a kernel on ARM?
18:54:52 <mjg59> And would they be built in parallel somehow?
18:54:56 <pjones> bconoboy: it's not just builds, and I'm sorry if I gave that impression.  It's the whole thing - builds, release composes, QE.  Which is one more reason why it seems strange to me to skip the installation question as a requirement.
18:55:00 <bconoboy> mjg59: Platforms to be supported are in the proposal- offhand it's highbank, armada xp, omap, tegra, imx, plus olpc/pi
18:55:00 <jonmasters> mjg59: in the current configuration, on the development boards (not equivalent to the hardware we will have for PA) it takes 4 hours
18:55:21 <mjg59> jonmasters: Ok. What do the kernel team think about this?
18:55:30 <mitr> jonmasters: Why wouldn't it?  (And in particular, because it creates a _different_ path for creating the root fs, i.e. different set of bugs / more mainteinance work)
18:55:38 <jonmasters> pjones: we have people working on the installation issue, especially for servers. BUT for PA, for ARM, most people won't do a traditional Anaconda install anyway
18:55:50 <mjg59> Er.
18:56:03 <pjones> bconoboy: it seems like punting installation means when alpha 1 QE comes around there's massive QE lag introduced while we try to get it tested.
18:56:07 <mjg59> I think being a PA has a strong expectation of the experience being consistent with other Fedora architectures
18:56:07 <jonmasters> mitr: someone is currently working on the Lorax/media creator stuff. We can gate the acceptance on that if you like
18:56:08 <sgallagh> I'm also curious what the Board has to say on the matter. This is equal parts a political and technical decision.
18:56:11 <bconoboy> pjones: In the proposal we suggest anythign that doesn't build on arm at the time of promotion be marked excludearch. We're trying to make this painfree on packagers.
18:56:25 <pjones> jonmasters: and I'm not saying we have to solve it with anaconda, but that's different than not solving it at all.
18:56:35 <mjg59> davej: What's your opinion on this?
18:56:40 <jonmasters> mjg59: other architecture hardware costs $500+, involves a screen and a keyboard, and a DVD drive
18:56:41 <bconoboy> pjones: We'll help get packages up and running on ARM that are broken now, if we haven't already.  The count that is broken is very small at this point.
18:56:42 <pjones> bconoboy: but that suggestion is the biggest reason we *introduced* secondary arches
18:56:46 <sgallagh> bconoboy: Building is not sufficient. We have to have a minimum level of testing as well
18:56:50 <nirik> proposal: ask qa, rel-eng, kernel and infra teams to provide feedback on the proposal. Ask fesco members to come up with critera that they would want to add.
18:56:59 <nirik> proposal: ask qa, rel-eng, kernel and infra teams to provide feedback on the proposal. Ask fesco members to come up with critera that they would want to add and revisit next week.
18:57:06 <mmaslano> nirik: +1
18:57:06 <mjg59> nirik: +1
18:57:08 <notting> nirik: +1
18:57:12 <jonmasters> sgallagh: we are aware of this. We have a new hire specifically working on the autoqa stuff too now
18:57:18 <bconoboy> sgallagh: Agree that testing is also necessary
18:57:28 <pjones> nirik: +1
18:57:34 <pjones> jonmasters: autoqa is necessary but not sufficient
18:57:35 <nirik> I'll note that we already make a ec2 image thats not a traditional installer, right?
18:57:46 <limburgher> nirik: +1
18:57:52 <davej> mjg59: sorry, I've not been following this channel, it'll take me a minute to read scrollback.
18:57:54 <sgallagh> nirik: +1
18:57:57 <jonmasters> testing is absolutely essential, agreed. A good testing strategy is important. We're not saying "make us primary today", what we're asking for is for what we're getting. Help us define what you need from us.
18:58:01 <mitr> nirik: +1, there's no rush
18:58:04 <t8m> nirik, +1 why not
18:58:10 <notting> nirik: using the assorted image creators for the other images seems logical
18:58:14 <pjones> certainly +1 to asking for more feedback from the listed teams.
18:58:25 <mitr> bconoboy: The idea "this is primary but all build problems are swept under the carpet" is sort of contradictory, btw.
18:58:25 <limburgher> Note that I'm hugely excited for arm to become PA.
18:58:35 * jonmasters too :)
18:58:44 <pjones> mitr: yeah, that's what I was saying above.
18:58:53 <sgallagh> jonmasters: I don't just mean testing to see if what we have is functional. I mean we need to have infrastructure for packagers to be able to test their packages on hardware that they (very likely) do not own.
18:58:54 <bconoboy> mitr: You have to start somewhere.  If the barrier to joining primary is "be as good as x86" there will never be another primary architecture.
18:58:57 <mitr> Also, bring this up on fedora-devel I suppose, to give other people a chance to respond.
18:59:01 <nirik> so, where should we collect feedback? devel list? ticket?
18:59:04 <limburgher> mitr:  I'd rather see inf provided for packagers to fix builds.
18:59:17 <sgallagh> I want to see ARM become PA as well. I just want it not to be a catastrophe when it does :)
18:59:26 <limburgher> mitr: And before PA, to help get to PA.
18:59:27 <pjones> limburgher: I think that's a *minimum* requirement.
18:59:30 <mitr> bconoboy: A large part of "primary architecture" to me is "everyone needs to care".
18:59:36 <mmaslano> jonmasters: statistics of FTBFS would be also nice
18:59:37 <jonmasters> sgallagh: agreed. We'll make boards available. At the end of the day, the hardware is also something that can be acquired for very cheap $$, and we can buy a few boards for folks here and there too
18:59:50 <limburgher> pjones:  Exactly.  Give me a box and a list of my stuff that's FTBFS and I'm off.
18:59:51 <nirik> buy all packagers a rasberry-pi. ;)
19:00:11 <limburgher> nirik: +Eleventykillion
19:00:12 <jonmasters> nirik: well, some, is a reasonable idea
19:00:19 <sgallagh> jonmasters: "can" != "will" :) I'm saying we need to commit to that as part of the decision to go PA
19:00:26 <jonmasters> sgallagh: fine, not a problem
19:00:31 <bconoboy> mitr: Indeed, in the end it will mean more work... but we're endeavoring to make it negligible via standard tools and solutions.
19:00:37 <jonmasters> sgallagh: we've already set that expectation and we can add to the document
19:00:42 <sgallagh> ok, thanks
19:00:47 <nirik> back when ppc was primary, few packagers had one...
19:00:56 <mjg59> jonmasters: I think that right now it's likely that 4 hours for kernel builds is going to be a blocker
19:00:58 <nirik> most of the problems fell on the ppc folks to go fix.
19:00:59 <limburgher> We're at 1 hour, are we about through with ARM?
19:00:59 <jonmasters> nirik: but, ppc cost an order of magnitude more :)
19:01:00 <sgallagh> nirik: And that didn't end too well
19:01:21 <limburgher> mjg59:  Real inf for builds would probably improve that.
19:01:22 <bconoboy> I expect in the next 12 months we'll have enough arm hardware that arm will be able to complete a mass rebuild faster than x86.
19:01:27 <nirik> I'm just pointing out the history. I know there's differences.
19:01:31 <mjg59> jonmasters: So you're going to have to work that out with the kernel team
19:01:42 <jonmasters> mjg59: at the moment, it's 4 on the dev boards we have. The production hardware will be better, we might get that halved.
19:02:05 <pjones> bconoboy: mass rebuild vs kernel build is a throughput vs latency difference, of course.
19:02:05 <mitr> bconoboy: That's sort of impressive, but also not the case that most developers will care about
19:02:09 <mjg59> jonmasters: That number goes up the more platforms you want to support, right?
19:02:28 <mjg59> Or is there some magic to push out the kernel build over multiple machines?
19:02:57 <mitr> mjg59: I thought the two ABIs are in effect separate architectures (a.la "ppc and s390"), is that not so?
19:03:02 <jonmasters> mjg59: per my proposal, the spec would specifically only build a limited number of kernel options. You could specify an rpmbuild option to increase the builds periodically, for releases, or (my preference) we have community maintained kernels for other than a small number of core platforms
19:03:16 <mjg59> mitr: No, it's worse than that
19:03:26 <bconoboy> pjones/mitr: Yep, there is still the per-package build time to be contended with. It's not too bad at this point.  It will be much better with the server hardawre coming down the pipe.
19:03:35 <mjg59> mitr: It's not one kernel per userspace ABI. 32-bit arm is basically one kernel per supported device.
19:03:44 <jonmasters> mitr: the two ABIs we have are separate architectures from our viewpoint. We distinguish armv5 and armv7 as different
19:04:04 <jonmasters> mjg59: that is being actively worked on by Linaro. We know it's an issue. It is improving
19:04:05 <mjg59> mitr: So it's kind of like us having to build a separate kernel for Dell, Lenovo and HP
19:04:14 <mjg59> jonmasters: Absolutely, and I look forward to the brave new world
19:04:16 <mitr> mjg59: Ah, thanks.
19:04:17 <bconoboy> Even so, it's not going to be as fast as x86_64.  Again, we won't be equal to x86_64 in every way, that isn't how ARM (or almost anything else) works relaly.
19:04:28 <jonmasters> mjg59: and a lot of work is going on to ensure ARMv8 won't repeat the experiences of 32-bit
19:04:42 <nirik> so, devel list? who's going to start the thread? :)
19:04:47 <jonmasters> bconoboy: we cost up to 10 times less than x86
19:04:50 <bconoboy> armv8 should be a single kernel.  armv7 will incrementally approach a single kernel.
19:04:57 <bconoboy> jonmasters: easily
19:04:58 <mjg59> bconoboy: The kernel people usually want a fairly good turnaround time on kernel builds. If the length of time it takes to build ARM impacts their workflow then that's a serious problem.
19:05:26 <bconoboy> mjg59: we propose the main kernel build simply be kernel-qemu and that the other boards be supported by separate builds.  We don't want to slow down kernel developers.
19:05:35 <pjones> bconoboy: jonmasters: anyway, I'm -1 to the current plan for reasons I've said above, but I'll try to enumerate some specific feedback and things I'd like to see in the requirements when you guys mail the list for feedback later?
19:05:35 <jonmasters> mjg59: sure, we should get a number from them. Note that we're proposing a pretty crazy number of builders so we'll be able to have many outstanding builds
19:05:44 <jonmasters> pjones: ok
19:05:47 <mjg59> bconoboy: Wait, what?
19:05:52 <mjg59> bconoboy: Separate builds in what way?
19:06:08 <pjones> bconoboy: separate kernel srpm is a non-starter I'm pretty sure.
19:06:19 <mjg59> Yeah, we're certainly only going to have one kernel srpm
19:06:20 <bconoboy> mjg59: same srpm, different koji flags, as I understand it
19:06:25 <jonmasters> mjg59, bconoboy: the proposal is that the main kernel be versatile by default unless you turn on a few flags in the SPEC
19:06:33 <jonmasters> bconoboy: right
19:06:47 <mjg59> So how do those builds get kept in sync?
19:06:48 <jonmasters> that will allow us to reduce the normal kernel compile time as much as possible except for certain builds
19:06:53 * nirik notes you cant change flags passed to a build in koji that I know of.
19:07:09 <pjones> yeah, right now that means rel-eng needs to change koji to support that
19:07:23 <mjg59> I don't think I'm really going out on a limb by saying that there's an expectation that all PAs have exactly the same kernel version
19:07:29 <jonmasters> or it can be done with a simple RPM macro setting
19:08:04 <bconoboy> jonmasters: We should take this back to releng and move on
19:08:07 <pjones> jonmasters: in which case you'd have to put that in a file with a requires: and somehow conditionalize that, in which case you need rel-eng to change koji to support that.  which is the same thing.
19:08:11 <jonmasters> mjg59: we're not disagreeing with that. We're saying there are many options out there for ARM platforms. We want to pick a limited core set, we can build kernels for all of them if you need, but we're suggesting limiting the default kernel builds to a small set
19:08:43 <mjg59> jonmasters: Yes, I understand that
19:08:49 <bconoboy> (does anybody have an outstanding question that jonmasters or myself missed?)
19:08:57 <notting> note that the proposal to collect information and reconvene next week passed. we can certainly continue this discussion, but it could go on indefinitely
19:09:01 <limburgher> Not here.
19:09:14 <jonmasters> ok. bconoboy and I will start a thread on devel, we'll take some actions here
19:09:20 <t8m> i think this is just technical problem for koji/rel-eng
19:09:29 <jonmasters> t8m: right, that's a small issue
19:09:33 <mjg59> jonmasters: But a PA that effectively requires many users to obtain a kernel from some non-canonical source is pretty different to our existing PAs
19:09:50 <limburgher> #agreed ask qa, rel-eng, kernel and infra teams to provide feedback on the proposal. Ask fesco members to come up with critera that they would want to add and revisit next week.  (+8,-:0,0:0)
19:09:59 <jonmasters> mjg59: someone could make a system that wasn't a PC platform with an x86 chip in it and you'd have the same for x86
19:10:07 <mjg59> jonmasters: They could, and we wouldn't be supporting it
19:10:10 <pjones> jonmasters: olpc isn't a giant overhead
19:10:17 <limburgher> #topic Next week's chair
19:10:24 <limburgher> Any volunteers?
19:10:25 <bconoboy> mjg59: right now we do multiple kernels from a single srpm, kernel-tegra, kernel-omap, etc.  You get taht on the rootfs image at install time.  Each of them provide 'kernel'
19:10:26 <mmaslano> I could
19:10:40 <limburgher> #action mmaslano to chair next week.
19:10:40 <jonmasters> pjones: you're right. OLPC isn't. btw, it's moving to ARM. Welcome to the 21st century :)
19:10:44 <limburgher> Thanks!
19:10:49 <pjones> yeah
19:10:50 <limburgher> #topic Open Floor
19:10:51 <mjg59> bconoboy: Yes, I understand that. But that's not the problem.
19:11:06 <mjg59> Anyway, please talk to the kernel people
19:11:12 <bconoboy> mjg59: what is the problem you see from an end user perspective?
19:11:19 <mjg59> bconoboy: From an end-user? None.
19:11:28 <bconoboy> ah, new topic, okay.  thanks for the feedback everybody!
19:11:30 <mjg59> But that's not the only consideration
19:11:32 <jonmasters> fine, I really think the kernel thing is important, but it's a small part of the overall proposal. Thanks for the feedback in general guys, we'll come back with part 2 :)
19:12:00 <mitr> jonmasters, bconoboy: good writeup btw :)
19:12:08 <mmaslano> did we forget the tzdata ticket?
19:12:08 <bconoboy> tnx
19:12:15 <mmaslano> or I missed it?
19:12:16 <nirik> yeah, thanks for being around to answer questions. ;)
19:12:37 <adamw> notting: sorry for belated reply - we would have to make extensive changes to the criteria/validation system for arm, but we were expecting to have to do that anyway. we accept that the current setup is x86-centric and based around deployment methods which don't necessarily make sense on arm.
19:12:45 <pjones> limburgher: mmaslano: btw some of the fedora kernel guys would have been here, but #830 wasn't listed in the emailed agenda.  So I must stress once again that we should deferring items which were submitted too late for the agenda to the following week in the future.
19:13:08 <mmaslano> sure
19:13:12 <pjones> (that goes for everybody else as well, but I felt like addressing current chair and next week's chair directly)
19:13:30 <limburgher> Understood.
19:14:00 <adamw> notting: it's always been my general position that qa should adjust to suit however the engineering ought to be done, not vice versa.
19:14:44 <notting> adamw: sure, but didn't know how much lead time you need to adjust, or if the adjustments are too much to handle with current resources, etc.
19:15:02 <adamw> notting: i'd say f18 ought to be workable on our side.
19:15:36 <jonmasters> adamw: awesome :)
19:15:51 <rbergeron> :)
19:15:55 <mmaslano> what about the tzdata #699
19:15:58 <limburgher> Alright, we're at 75 min, anyone got anything for Open Floor?
19:16:07 <limburgher> .fesco 699
19:16:08 <zodbot> limburgher: #699 (Proposal to remove the package "tzdata" from Critical Path) – FESCo - https://fedorahosted.org/fesco/ticket/699
19:16:28 <jonmasters> and hey, nothing is set in stone, right? We brought this up now to get the discussion going. We're cool with, "yea, nice idea, but we'll have to work toward F19", but if we don't get it going, it forever gets kicked down the road
19:16:33 <sgallagh> I'm +0 on exempting it from the updates policy
19:16:44 * nirik is still -1.
19:17:06 <jonmasters> anyway, I'll leave you to talk about timezones, and btw, go EFF! :)
19:17:08 <bconoboy> I thought we were going to cover 830 as an open floor item to get initial feedback :-)
19:17:27 <limburgher> bconoboy:  Should have, but I goofed. :)
19:17:40 <mmaslano> I'm for whole list of packages, which can't be tested because there will be more than tzdata. Making tzdata exceptional doesn't seem to beright
19:17:40 <jonmasters> limburgher: not a problem, it was useful getting thrown to the Lions :)
19:17:54 <limburgher> jonmasters: :)
19:17:55 * t8m is still -1 as well to giving a single package exception - I'd like to see more general approach with AutoQA involved
19:18:07 <bconoboy> limburgher: I don't mind a bit- good feedback, excellent questions, we'll update the proposal based on today's discussion and send out solicitations for more
19:18:07 <notting> i'm still -1 as well
19:18:08 <limburgher> I agree with mmaslano and t8m
19:18:09 <mmaslano> yeah, so -1 for now
19:19:41 <limburgher> So I see +1 for (ticket), 1:0, and 4 against, is that right?
19:19:47 <mitr> -1, I suppose (although I don't feel strongly about it at all)
19:20:26 <limburgher> pjones?
19:21:07 <sgallagh> On further consideration, -1
19:21:30 <pjones> I think it's a pretty glaring failure of our current plan that we can't get tzdata updates out in time to be relevant.
19:22:06 <sgallagh> pjones: It could be argued that it's the maintainer's job to rustle up testers
19:22:15 <mmaslano> hm
19:22:34 <pjones> sgallagh: it could be argued that you shouldn't get in car accidents too, but I bet you have insurance.
19:22:53 * mmaslano hopes now it's time to end the meeting
19:23:03 <pjones> also I think that'd be a pretty specious argument.
19:23:06 <limburgher> That sounds like -0.5?
19:23:13 <limburgher> Sorry, +0.5?
19:23:27 <pjones> I'm +1 for lack of any better ideas.
19:23:30 <limburgher> Ok.
19:23:43 <limburgher> #agreed Proposal to remove the package "tzdata" from Critical Path is rejected (+2,-:0,0:6)
19:24:06 <limburgher> Anyone else have anything?  If not I'll end this in 3.
19:24:44 <sgallagh> limburgher: Your count is backwards
19:25:11 <limburgher> #undo
19:25:11 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x18d20a50>
19:25:22 <limburgher> <limburgher> #agreed Proposal to remove the package "tzdata" from Critical Path is rejected (+2,-:6,0:0)
19:25:30 <limburgher> Dang.  Good catch. :)
19:25:44 * Viking-Ice feel free to add me to the open topic floor list
19:26:16 <sgallagh> Ah right, Viking-Ice had some comments about systemd-journal
19:27:04 <Viking-Ice> I dont mind journal being rejected but I mind it being rejected without any outlined issues or something that seems to relate to binary logging hatred. What I would like to see from fesco is a more concrete rejection. An project being young does not say anything about it's quality and since there are several months until feature freeze it allows a significant time to work out on issue that might be found in that regard. W
19:27:04 <Viking-Ice> ith my QA hat on I'm well aware that we need to update all documentation to do something like systemd-journalctl -o cat _SYSTEMD_UNIT=foo.service > foo.txt for reporters to attach to reports and again with my QA hat on we would have to ensure application we ship by default like abrt and setroubleshoot would need to be ensured to work journal before it can become default.
19:27:12 <notting> ok, so ... issues
19:27:38 <notting> 1) unlike systemd vs sysvinit/upstart, there are a variety of projects here with no clear path forwards. changing the default at this time seems unwise
19:28:01 <notting> 2) unlike systemd vs sysvinit/upstart, which offered clear sysvinit compatibility for services, this ... doesn't (for users of the old log format)
19:28:07 <mmaslano> Viking-Ice: we had email conversation. I thought it's sure we can't use journald as it is
19:28:15 <limburgher> I'm not sure being anti-binary-logging is irrational.  Today, tons of tools, scripts, and human eyes can parse syslog.
19:28:26 <mitr> * Large impact on users (in the most worrisome case, when th system is broken already) with a negligible benefit
19:28:49 <limburgher> I want to be able to read my syslog if I don't have a system with systemd available.
19:29:01 <mjg59> I have nothing against the journal. I don't see what dropping rsyslog by default currently buys us.
19:29:23 <Viking-Ice> mjg59, it's not about dropping it it's about disabling it
19:29:28 * nirik is with mjg59
19:29:29 <Viking-Ice> by default
19:29:33 <mitr> Viking-Ice: Where's the practical difference?
19:29:59 <mjg59> Viking-Ice: Arguing semantics doesn't really strengthen your case
19:30:01 <mitr> * The authors of journald were quite explicit several times that they don't intend to achieve feature parity with existing syslogs, so "giving the project time" is not that likely to significantly chagne the situation
19:30:12 <limburgher> Additionally, what does journal buy us that completely outweighs the loss of text logging?
19:30:21 <limburgher> mitr: +1
19:30:37 <Viking-Ice> mitr, yes they are not trying to replace rsyslog
19:30:54 <t8m> I see this request just as needless dropping of features
19:31:00 <mjg59> Viking-Ice: Right now people make use of the rsyslog functionality. It therefore makes sense to retain the rsyslog functionality.
19:31:40 <mitr> Frankly, the journal as it is being  advertised now ("just a ring buffer to allow this neat feature in systemctl") should not have been created at all - a) just parsing all of the textual logs would not be too bad performance-wise, and b) even if this _did_ require a binary store, it should have been a patch extending an existing syslog implementation (and maintaining all of the other features, including message transformation, network int
19:31:42 <mitr> eroperability, etc.)
19:31:44 <mjg59> You haven't presented a compelling argument for how to transition everybody to the new way of doing things, and any such argument should also make it clear what the benefits are
19:32:06 <Viking-Ice> mjg59, which user base does that. certanly not the novices kind and the experienced/advanced/enterprise users can be expected to be able to setup and configure rsyslog  by themselves
19:32:39 <Viking-Ice> what do we gain by shipping two logging solution by default?
19:32:51 <mmaslano> Viking-Ice: you are ignoring our answers
19:33:06 <mjg59> Viking-Ice: What do we lose by doing so?
19:33:46 <t8m> Viking-Ice, note that these logging solutions are not really competing
19:33:57 <t8m> Viking-Ice, they play (now nicely) together
19:34:29 <t8m> Viking-Ice, that's like proposing to drop textual login as we have gdm now
19:34:30 <mitr> Viking-Ice: If you want to save memory, stop modem-manager running by default, you'll save twice as much
19:34:49 <Viking-Ice> mitr, disk space as well
19:35:02 <pjones> Viking-Ice: also it's worth noting that the authors of journal haven't been shy about filing their own features in the past when they thought it was appropriate to do so
19:35:11 <mitr> Viking-Ice: Disk space is just too cheap for me to argue about, sorry.
19:35:18 <t8m> pjones, +1
19:35:24 <pjones> Viking-Ice: so the fact that you filed this without them involved kindof suggests they don't think it's ready
19:35:27 <limburgher> But as things are today, I can parse my log with C, Bash, Python, etc.
19:35:56 <Viking-Ice> pjones, not necessarily so
19:36:09 <limburgher> From a livecd of a different distro running on another arch.
19:36:12 <pjones> no, it really does.
19:36:41 <limburgher> I concur with pjones.
19:37:04 <mjg59> Given upstream's active role in Fedora in general, it does seem a little odd that they're not obviously involved with this proposal
19:37:07 <Viking-Ice> pjones, well kay told me he did not want to go through that bureaucracy but I was free to go ahead with it
19:37:52 <limburgher> Viking-Ice: The fact that he was willing to do so for usrmove would indicate a difference in his estimation of the two endeavors.
19:38:18 <mjg59> Viking-Ice: Anyway, fundamentally the reason nobody's in favour of the feature is that you haven't provided any obvious benefits from it
19:38:20 <Viking-Ice> are you accusing me of lying?
19:38:35 <pjones> no, he's interpreting your statement in context.
19:38:35 <limburgher> I don't think anyone is.
19:38:55 <mjg59> And I think that's been explained pretty clearly
19:39:14 <mjg59> So what are you actually asking for?
19:39:20 <limburgher> Kay might think both are worthwhile.  If he thought this was as worthwhile as usrmove, I suspect, as so several of us, that he'd be involved.
19:39:31 <Viking-Ice> anyway if it get's rejected now why should that change in the future?
19:39:49 <pjones> kay hasn't ever had a problem telling the world when he thinks something should be done in the past.
19:40:28 <limburgher> If journal grows into something that is demonstrably a technically compelling syslog implementation, and is intended as such, it should be reconsidered.
19:40:29 <mitr> Viking-Ice: 1) perhaps there really isn't any reason for that to change - just something to consider, and 2) for me, significant adoption of native journald format to the extent that it has clearly become "the" Linux logging solution
19:40:32 <limburgher> It's not there now.
19:40:35 <pjones> Viking-Ice: because... the various things we've pointed out in terms of its feature completeness are likely to change as development progresses?
19:40:37 <mjg59> Viking-Ice: The feature will be rejected up until the point where it makes things better, at which point it'll probably be accepted
19:40:51 <t8m> Viking-Ice, good question perhaps it won't change in future, we can't say that now
19:40:53 <mmaslano> I guess we told our technical reasons. Could we go home now? :)
19:41:03 <t8m> mmaslano, +1
19:41:11 <pjones> yeah, this discussion seems to be pretty much over.
19:41:18 <limburgher> mmaslano: Exellent idea.
19:41:30 <limburgher> Unless there's anything else for open floor in the next minute. . .
19:41:42 <limburgher> s/Exellent/Excellent/
19:42:46 <limburgher> #endmeeting