15:00:42 <pknirsch> #startmeeting Fedora Base Design Working Group (2014-04-11)
15:00:42 <zodbot> Meeting started Fri Apr 11 15:00:42 2014 UTC.  The chair is pknirsch. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:42 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:48 <pknirsch> #meetingname  Fedora Base Design Working Group
15:00:49 <zodbot> The meeting name has been set to 'fedora_base_design_working_group'
15:01:06 <pknirsch> Welcome to a wonderful and warm Friday afternoon/evening in Europe :)
15:01:19 * notting is here
15:01:24 <pknirsch> heya bill!
15:01:28 <pknirsch> #topic Role call
15:01:36 <pknirsch> #chair notting
15:01:36 <zodbot> Current chairs: notting pknirsch
15:01:44 <pknirsch> i saw jreznik earlier, too!
15:01:45 <jreznik> pknirsch: not warm here :(
15:01:50 <pknirsch> :(
15:01:55 <pknirsch> #chair jreznik
15:01:55 <zodbot> Current chairs: jreznik notting pknirsch
15:02:35 <pknirsch> anyone else so far?
15:02:43 <jreznik> but weekend looks promising, forecast says it's going to rain, I hope not - we're going to plant our christmas tree tomorrow :)
15:03:15 <Southern_Gentlem> jreznik,  well the rain will help it
15:03:20 <pknirsch> heh
15:03:35 <pknirsch> I'm most likely going to do a lot of gardening over the weekend.
15:03:40 <pknirsch> :)
15:04:48 <pknirsch> dgilmore, haraldh, masta, jwb: you guys around?
15:06:23 <dgilmore> yep
15:07:18 <pknirsch> ok, lets get rolling then
15:07:34 <pknirsch> i hope you got some more sleep after heartbleed, dgilmore :(
15:07:54 <jwb> hello
15:08:11 <pknirsch> #chair dgilmore jwb
15:08:11 <zodbot> Current chairs: dgilmore jreznik jwb notting pknirsch
15:08:12 <jreznik> #chair dgilmore jwb
15:08:12 <zodbot> Current chairs: dgilmore jreznik jwb notting pknirsch
15:08:17 <pknirsch> heh
15:08:30 <jreznik> hey jwb
15:08:51 <dgilmore> pknirsch: still catching up
15:09:04 <pknirsch> dgilmore: alright, i'll try to keep the meeting short then today ;)
15:09:13 <pknirsch> ok, first topic i had for today:
15:09:41 <pknirsch> #topic Recap + summary from topics of last week
15:10:29 * jreznik missed last week's meeting due to on-site meeting with Akademy guys we organize this year in Brno
15:11:18 <pknirsch> Looking at the responses on the ML i agree with jwb's summary: Proactive weeding out is certainly something we can/should look at, especially for the base components. that imho correlates to more of the janitorial work i've already mentioned before
15:12:15 <pknirsch> And the later (driving the package reviews) i think is a bit over the top for us to do. One thing thats possible is to send out reminders to the package owners that these reviews are still pending.
15:13:20 <jreznik> pknirsch: could you give me more context fot that package reviews topic?
15:13:35 <haraldh> <#
15:13:44 <jwb> merge reviews
15:13:50 <jreznik> ok, merge reviews, I got it now
15:14:01 * pknirsch nods
15:14:08 <pknirsch> #chair haraldh
15:14:08 <zodbot> Current chairs: dgilmore haraldh jreznik jwb notting pknirsch
15:14:38 <jreznik> I can take a look on reminders - some of my BZs scripts should do the work
15:14:40 <pknirsch> jreznik: basically a reminder for http://tinyurl.com/fedora-pkg-reviews
15:15:03 <pknirsch> great, thanks jreznik !
15:15:13 <jreznik> pknirsch: yes, I understand it now - I was a bit surprised we would want to drive all package reviews
15:15:30 <jreznik> even I can imagine a lot of changes how to make that process more appealing and faster going
15:15:35 <pknirsch> #action jreznik sending out reminders for merge reviews as per http://tinyurl.com/fedora-pkg-reviews
15:15:40 <pknirsch> mhm
15:15:52 <dgilmore> merge reviews I think we can get done in a day
15:16:24 <jwb> we could get them done in 30 seconds if we just closed them all
15:16:38 * dgilmore is tasked by fesco to organise a vfad and to let provenpackagers that they can step up and get them done and fixed
15:16:57 * dgilmore is tasked by fesco to organise a vfad and to let provenpackagers know that they can step up and get them done and fixed
15:17:04 <jreznik> dgilmore: ok, I can help you
15:17:31 <dgilmore> jreznik: cheers
15:17:46 <pknirsch> thanks guys!
15:18:02 <jreznik> it should be pretty fast to make it done, some could be even closed immediatelly
15:18:47 <jreznik> dgilmore: ping me to sort out details and let organize it
15:18:55 <dgilmore> jreznik: willd o
15:18:59 <dgilmore> willd o
15:19:30 <pknirsch> :)
15:20:11 <dgilmore> i can't type
15:20:24 <pknirsch> no worries dgilmore
15:20:57 <pknirsch> so regarding the deprecating of legacy/old cruft, any ideas how we could tackle that?
15:21:01 <jreznik> it's Friday afternoon but my brain still can read it and understand it - so it's not as bad as it looks
15:21:48 <notting> pknirsch: well, we could remove @base entirely
15:21:58 <pknirsch> :)
15:22:06 <notting> (or @standard, as the case may be)
15:22:24 <dgilmore> the minimal install on arm takes up 1.3G
15:22:35 <dgilmore> making taht smaller would be nice
15:22:41 <jwb> notting, no no.  we could make all of those things be subpackages of the systemd SRPM
15:22:44 <notting> dgilmore: given the size of the cloud image... that seems wrong
15:23:04 <pknirsch> jwb: and package them as a docker image?
15:23:10 <dgilmore> notting: we have not excluded a ton of stuff like cloud has
15:23:19 <dgilmore> notting: maybe we should
15:23:46 <jwb> pknirsch, docker is too old school now.  need something new
15:23:57 <dgilmore> new shiny ;)
15:23:58 <pknirsch> jwb: right. Atomic docker? :)
15:24:26 <jwb> sure!
15:24:43 <jwb> anyway, deprecating old stuff is a decent goal, but it requires new stuff to be in place
15:25:04 <jwb> so if we're going to do that, an evaluation of new equivalents would be the first step
15:25:10 <notting> jwb: eh, it depends. not everything needs it
15:25:27 <notting> dgilmore: install @base kernel for x86_64/rawhide yields:
15:25:35 <jwb> notting, right.  hence identifying and evaluating things that do have a new equivalent
15:25:44 <notting> (sorry, @core, not @base)
15:25:48 <dgilmore> maybe some stuff shouldbe moved to @core-legacy and @standard-legacy
15:25:50 <notting> Install  43 Packages (+186 Dependent packages)
15:25:51 <notting> Total download size: 154 M
15:25:51 <notting> Installed size: 589 M
15:25:54 <jwb> notting, i mean, i don't expect us to go replacing util-linux with something that doesn't exist, etc
15:26:16 <dgilmore> notting: we have @core @standard @dial-up @hardware-support and kernel
15:26:27 <jwb> dial-up...
15:26:31 <notting> dgilmore: then that's not the minimal install.
15:26:46 <jwb> guys... why are we aruging about minimal install on arm?
15:26:55 <dgilmore> jwb: we are not
15:26:57 <jreznik> well, I'd say that pro-activity could be also in the way not looking for things to deprecate but to follow new stuff coming (to devel list etc)
15:27:32 <pknirsch> and we certainly don't need to do it very often, maybe once a release
15:27:57 <jwb> jreznik, that's required for deprecating anyway.  we're already pretty good at jumping on the new things.  we're not so great at getting rid of the old things they replace
15:28:08 <pknirsch> yep
15:28:09 <notting> there's also the question of formal deprecation "<thing> will be removed entirely" vs informal "<thing> just won't be installed by default any more"
15:28:20 <pknirsch> often old stuff just keeps staying around forever
15:28:24 <jreznik> jwb: well, let's be better for the second part of equation
15:28:51 <jwb> jreznik, which is what we're supposed to be talking about...
15:29:26 <jwb> notting, yeah.  maybe for the first round, we do the informal thing and see what happens
15:29:36 <jwb> if that goes well, we move to a formal deprecation model
15:30:05 <pknirsch> mhm, a bit like languages like Java do: Deprecate for one version, and remove for the next (obsolete iirc they call it)
15:30:11 <jreznik> jwb: well, initially I understood it more in the way Base would go actively through the all packages we have looking for deprecated stuff - it's not doable, but being more strict when it comes to that something new comes, let's take a look on it...
15:30:45 <jwb> it's doable within the context of Base
15:30:50 <jreznik> jwb: how would that formal model looks like? do you have any specific idea?
15:31:37 <jwb> jreznik, we announce package X won't be installed by default in release M.  if there are no unforeseen problems that arise, we say package X will be removed in release N.
15:31:42 <jwb> basically what pknirsch just said
15:31:59 <pknirsch> and we could do that in a report to fedora-devel each release
15:32:24 <pknirsch> Like: "These packages are deprecated for the next release and will be removed in the one after that."
15:32:30 <pknirsch> following a list
15:32:47 <pknirsch> and a list of pending removals for the next release
15:33:06 <jreznik> as far as I know we do have such list in release notes
15:33:06 <jwb> right
15:33:40 <jwb> i've seen that in RHEL release notes.  if we've done it _consistently_ in Fedora, it's escaped me
15:33:57 <jreznik> (or it was done before)
15:34:12 <notting> because in fedora it's mostly all individual developer driven
15:34:20 * pknirsch nods
15:34:39 <pknirsch> there is no single instance/group/person who does it iirc.
15:35:14 <jreznik> at least partially, it should be able to get this info from changes
15:36:03 <jreznik> it's the reason why we do have changes process in place, just that list is missing and some changes does not go through the process... with formal deprecation process, we could enforce it
15:36:28 <notting> (speaking of that, should base be promulgating official Opinions on certain changes, or collecting them before they go to the change wrangler?
15:36:29 <pknirsch> and it doesn't need to be perfect i guess
15:36:33 <notting> as an example, the securetty one
15:37:24 <jreznik> notting: you don't know about coming changes before it reaches me (as I don't know it neither)
15:39:22 <jreznik> but that securetty was one I really wasn't sure at all what to do with (asked a few folks for hint and it was - announce it, announcements are for it)... and during that time, author announced it on his own
15:39:53 <jwb> i think notting was asking if Base, as a group, should weigh in on changes before they get to FESCo
15:39:56 <jreznik> but I can do whatever you ask me
15:40:19 <jwb> oh, no.  he said change wrangler.  maybe before they go to FESCo makes more sense
15:40:27 <jreznik> jwb: "before they go to the change wrangler" - I can't imagine it, before FESCo, yes
15:40:51 <notting> i.e., if we're supposed to be having a Base Design WG, they likely should weigh in on at least *some* System Wide changes
15:41:43 <jreznik> notting: I agree (I was just confused by that before they go to change wrangler" - I  really think you thought FESCo)
15:42:25 <pknirsch> so whats the proposal then? Run system wide changes past us first prior to wrangler ready?
15:42:44 <jreznik> as review before review time sounds a bit weird and gives more bureaucracy I don't want at all :)
15:43:14 <jreznik> pknirsch: ideally each WG members should read that announcements and come to the meeting if they think something is worth discussion
15:43:20 <dgilmore> i think that maybe what we need is a check like we have for releng to run the change by base wg
15:43:41 <notting> pknirsch: hm. probably want to run whatever we do by fesco. maybe just 'base WG will look at system-wide changes and raise any concerns with fesco' for now
15:43:48 <dgilmore> or at least have the change look at the effect of teh base wg
15:43:55 <jreznik> notting: exactly
15:43:57 <pknirsch> notting: yea, that sounds better
15:44:12 <dgilmore> notting: +1
15:44:18 <pknirsch> notting: +1
15:44:26 <haraldh> +1
15:45:04 <jwb> sure
15:45:16 <jreznik> actually pknirsch added current ChangeSet on agenda and I wanted to ask, if we want to discuss already accepted changes or upcoming
15:45:30 <jreznik> I was just waiting for the time on today's agenda
15:45:55 <pknirsch> #agreed Base WG will look at system-wide changes and raise any concerns with fesco (4,0,0)
15:46:15 <pknirsch> yea, basically a subset of my next topic, jreznik ?
15:46:49 <pknirsch> we've only got 15 minutes left anyway, so lets move to that.
15:46:56 <pknirsch> wanna take the helm, jreznik ?
15:48:02 <jreznik> well, I'd say - is there any change you'd like to raise today? I think securetty is a good one as notting said above
15:49:20 <pknirsch> ok, lets change the topic then though
15:50:13 <pknirsch> #topic Discussion of specific F21 changes: https://fedoraproject.org/wiki/Releases/21/ChangeSet
15:50:51 <notting> imo, mattdm's counter-proposal (remove securetty file & pam_securetty) makes more sense than the proposed empty securetty file change
15:51:10 <jwb> remind me what that does?
15:51:21 <jreznik> #link https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default
15:51:53 <jreznik> notting: isn't it more like implemenation detail (and better looking solution?)
15:53:39 <notting> jwb: securetty empty by default means root can't log in anywhere without administrator reconfiguration. no securetty at all means root isn't prohibited where it can log in. (and removing pam_securetty from pam stack means securetty is never checked)
15:55:06 <jwb> notting, the latter being more equivalent to today's behavior plus making it the only behavior
15:55:07 <pknirsch> but isn't the point exactly to prevent root from logging in directly?
15:55:11 <pknirsch> aye
15:55:25 <jwb> notting, as opposed to the Change submitted making the behavior different
15:55:27 <dgilmore> with root being unable to log in by default my typical setup wont work at all
15:55:28 <notting> jreznik: not exactly - the filed feature is to prevent root logging in certain ways, and the counter proposal is to not prevent it anywhere
15:55:56 <jreznik> I get it now
15:56:03 <jwb> honestly, i don't like either of those
15:56:06 <pknirsch> well, the following ones would still work:  su, sudo, ssh, scp, sftp
15:56:09 <jreznik> jwb: yep
15:56:30 <dgilmore> i use free ipa, I set a root password at install then log in and join to my ipa server
15:56:50 <dgilmore> there is no local users
15:56:56 <jwb> preventing local root login (the submitted Change) requires anaconda (or something) to create a local user
15:57:04 <pknirsch> mhm
15:57:08 <mattdm> the current file is configured by default to allow a ridiculously long list of potential ttys, and it keeps growing
15:57:20 <mattdm> as lennart points out, it doesn't map well to dynamic devices
15:57:25 <jwb> the counter proposal elminiates the possibility of a sysadmin enforcing no root login, outside of the password thing
15:57:28 <dgilmore> jwb: right which seems kinda silly when using network login services
15:57:49 <mattdm> jwb no, we wouldn't drop securetty from the distro, just not put it in the pam config by default
15:58:05 <jwb> mattdm, ah!
15:58:17 <jwb> ok.  i guess i would prefer that counter proposal then
15:58:37 <jwb> least amount of impact, still lets people wear tinfoil if they want
15:58:59 <dgilmore> the change proposal guy seems to want to do it one way because thats how he configures his systems. but he can achive that in %post of a kickstart
15:59:28 <mattdm> exactly. and there probably _are_ some cases where it is legitimately useful still
15:59:30 <dgilmore> i think id prefer mattdm's proposal
15:59:36 * pknirsch nods
16:00:03 * mattdm goes back to writing fedora magazine post. ping if needed :)
16:00:11 <pknirsch> :)
16:00:13 <dgilmore> mattdm: ping
16:00:16 <pknirsch> thanks mattdm !
16:00:18 <dgilmore> wait never mind :P
16:00:22 <pknirsch> hahaha
16:01:46 <jreznik> so it seems like base wg is in favour of that counter proposal, right?
16:01:50 <pknirsch> ok, so whats the next step then?
16:01:54 <pknirsch> +1
16:01:55 <pknirsch> :)
16:01:57 <dgilmore> jreznik: yeah
16:02:14 <haraldh> +1
16:02:42 <jreznik> anyone to comment it on the announcement or do you want me to do it? +note in the fesco ticket (I'll take care of it)
16:03:42 <notting> i'm fine with jreznik doing it
16:03:46 <pknirsch> same :)
16:03:49 <pknirsch> thanks jreznik !
16:03:50 <pknirsch> :)
16:04:11 <jreznik> ok :)
16:04:20 <dgilmore> thansk jreznik
16:05:21 * jwb needs to go afk for a minute
16:05:39 <dgilmore> pknirsch: anything else to go over?
16:05:44 <pknirsch> any concerns regarding  PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services ?
16:05:54 <pknirsch> #link https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork
16:06:17 <pknirsch> i've followed the discussion a bit there, but unsure if thats going to be problematic
16:06:33 <jreznik> pknirsch: it was already accepted, I think notting had a question and lennart already answered it on the devel list (my accepted changes summary)
16:06:41 <pknirsch> alright
16:06:52 <pknirsch> just wondered if there were any open questions left on that
16:07:01 <dgilmore> I voted for it in FESCo if the service doesnt really need network or device access then I dont see any issue making sure it can not access them
16:07:03 <jreznik> #link https://lists.fedoraproject.org/pipermail/devel/2014-April/197566.html
16:07:14 <pknirsch> mhm
16:07:16 <pknirsch> true
16:07:19 <notting> my concerns are mostly about whether we can give good clear guidance to people on who can use those options, which is not an issue with the proposal itself
16:07:29 <pknirsch> alright
16:07:56 <dgilmore> notting: right, I think people will tend to be fairly cautious
16:08:15 <dgilmore> and some services that can use it wont
16:08:45 <haraldh> the admin can always opt out/in anyway per dropin config
16:09:08 <pknirsch> #action jreznik following up on the https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default announcement and submit and support mattdm's counterproposal
16:09:16 <dgilmore> haraldh: sure, probably need to make sure that makes the release notes
16:09:28 <dgilmore> how to do so
16:10:29 <Viking-Ice> my concerns is that neither three of those actually do the necessary work required to properly integrade this into the distribution
16:11:10 <Viking-Ice> they will need to go over 700 units as is and spend on average 30 minutes to full hour to patch and test it
16:14:59 <pknirsch> Isn't the proposal to have it off by default and Lennart & co. will open bugs for important packages where they thing this needs to be done?
16:15:10 <pknirsch> see the #Scope section
16:15:43 <pknirsch> It might be good to have that list of packages though in there
16:19:09 * jreznik has to leave
16:19:21 <pknirsch> ups, ye, same here!
16:19:45 <pknirsch> but that's all folks, thanks for joining today's meeting and have a fantastic weekend!
16:20:39 <jreznik> thanks pknirsch! enjoy your work on the garden!
16:20:40 <haraldh> PTO! :)
16:20:46 <haraldh> \o/
16:20:54 <pknirsch> gz haraldh :)
16:20:59 <pknirsch> thanks jreznik :)
16:21:02 <pknirsch> #endmeeting