14:15:56 <haraldh> #startmeeting Fedora Base Design Working Group (2015-09-14)
14:15:56 <zodbot> Meeting started Mon Sep 14 14:15:56 2015 UTC.  The chair is haraldh. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:15:56 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:16:00 <haraldh> #meetingname  Fedora Base Design Working Group
14:16:00 <zodbot> The meeting name has been set to 'fedora_base_design_working_group'
14:16:05 <haraldh> #chair haraldh msekleta jreznik dgilmore vpavlin masta lnykryn
14:16:05 <zodbot> Current chairs: dgilmore haraldh jreznik lnykryn masta msekleta vpavlin
14:16:25 <haraldh> bconoboy, want to continue from last time?
14:16:42 <bconoboy> howdy
14:16:44 <masta> hey folks
14:16:49 <lnykryn> hello
14:16:49 <haraldh> hi
14:16:53 * masta grabs coffee - brb
14:16:57 <msekleta> hi!
14:17:17 <bconoboy> we are talking ring 0?
14:17:21 <haraldh> yep
14:17:43 <bconoboy> Sure...
14:17:55 <bconoboy> So, since the last meeting 2 weeks ago we had a little thread on devel@fp.o
14:18:05 <bconoboy> "Fedora Ring 0 definition"
14:18:41 <bconoboy> I still have a couple messages from last week to reply to, but thusfar the primary reply seems to be a combination of two questions:
14:18:48 <linuxmodder> linuxmodder
14:18:57 <bconoboy> 1: How does this interact with $EXISTINGAGREEMENT
14:19:18 <bconoboy> (Where that might be decisions made by base earlier, critical path, etc)
14:19:31 <vpavlin> Hi
14:19:48 <bconoboy> 2: Why do this?  In other words, please don't define this in isolation of what policies you'd like to see changed, take them at the same time.
14:20:08 <bconoboy> These are both great questions/observations
14:20:50 <bconoboy> So I thought it might be helpful to imagine what possibilities open up if you have 2 rings instead of 1
14:21:25 <bconoboy> Hopefully you all have some ideas on this
14:21:28 <bconoboy> I have a few..
14:22:09 <bconoboy> For me, I'd like to see a Base compose, for all architectures
14:22:31 <bconoboy> x86_64, i686, armhfp, aarch64, ppc64, ppc64le, s390x
14:22:39 <bconoboy> With a minimal install image
14:23:09 <bconoboy> The schedule for this compose would be ahead of the existing Fedora schedule
14:23:38 <bconoboy> Let's say, hypothetically speaking, the base compose gets completed 2 weeks ahead of each of the traditional milestones (alpha/beta/ga)
14:24:20 <bconoboy> In this way all the editions have a little extra time to handle their edition-specific bugs sitting atop a stable platform.
14:25:08 <bconoboy> If we do this for a couple releases and it goes well a few other interesting possibilities become more realistic
14:25:18 <bconoboy> Like having the base release live longer than the editions
14:25:34 <bconoboy> instead of 2 releases + 1 month, maybe we go 3 releases
14:25:36 <bconoboy> or 4
14:26:07 <bconoboy> Would take a lot of discussion, but it's a *much* lower cost to support ring 0 long term than the entire stack
14:26:12 <haraldh> That's a lot of maintenance burden for base
14:26:37 <bconoboy> could be- depends on policy and what people actually want
14:26:39 <haraldh> because if we don't reuse base for the other spins
14:26:54 <haraldh> a lot of parallel versions of base are to be maintained
14:27:06 <bconoboy> why wouldn't we use base for the other spins?
14:27:24 <bconoboy> the idea here is that base is a stable thing which spins can use, rely upon
14:27:26 <haraldh> reuse old base version for new spins
14:27:46 <haraldh> say base is on a 2 year cycle and spins on a half year fast paced one
14:28:04 <haraldh> spins = variant of base + stuff
14:28:08 <bconoboy> right
14:28:26 <bconoboy> the main idea here is that the base is supported for as long as longest spin/edition
14:28:45 <haraldh> and that would be a burden for fedora base
14:28:57 <masta> hrm...
14:29:03 <haraldh> if it would release as often as the other spins
14:29:15 <masta> I'm thinking of how to push updates for only base, but stop for everything else.
14:29:35 <haraldh> still you have to backport
14:29:45 <bconoboy> this is part of why you want the base to be really small
14:29:50 <haraldh> and not change API/ABI
14:30:04 <haraldh> sure
14:30:12 <haraldh> _but_
14:30:34 <haraldh> wouldn't it make sense to do base releases on a longer cycle?
14:30:45 <haraldh> then?
14:30:47 <bconoboy> Anyway, the main idea here is to move from a 2 release + 1 month support term for everything to a more flexible model by consensus of the community
14:31:25 <bconoboy> Yeah, that's certainly a possibility- I guess it really depends on whether it's useful to have the base be rebased twice a year or if we're doing that for the benefit of further up the stack
14:31:26 <masta> right now I'm not sure rel-eng has the facilities to just updates base, and ignore the remaining parts that would suspend support after say 6 months.
14:31:30 <bconoboy> certainly gcc is on a 1 year cycle
14:31:54 <masta> perhaps it could be made to work, will have to get back to you folks about that
14:32:03 <bconoboy> masta: lots of retooling needed for ideas like this
14:32:45 <bconoboy> It's probably a good question to send back to E&S: Do we need a 6 month release cycle for base?
14:33:32 <bconoboy> We've been on a 6 month cycle for a really, really long time- who is benefiting and suffering from it is not at all clear
14:33:55 <bconoboy> In any case, you create 2 rings, you open up the possibility of running them on separate schedules
14:34:35 <haraldh> I can see e.g. base being on a 9 month cycle and the rest on a 6 month
14:35:11 <bconoboy> that'd be pretty interesting, like 4x8 plywood with 16 on center stud spacing
14:35:25 <bconoboy> So, what do you all think? Other opportunities 2 rings opens up?
14:35:32 <haraldh> or 6 and 4, if you want to live faster
14:35:33 <masta> or even different schedules for the 2nd rings
14:35:48 <masta> say a longer life for a server variant
14:36:01 * vpavlin got disconnected without noticing it:/ Will have to read logs later..
14:36:02 <bconoboy> server could be slower, desktop faster
14:36:17 <bconoboy> the core requirement is that base live as long as the longest living official edition
14:36:33 <bconoboy> can't have server living longer than base for instance- what if there's a bug in glibc?
14:36:47 <masta> makes sense
14:36:50 <haraldh> so, we would have to know the duration of the longest living edition
14:37:01 <haraldh> then we have the base lifetime
14:37:11 <haraldh> then support that *3
14:37:18 <bconoboy> currently the longest living edition is 2 releases + 1 month ;-)
14:37:23 <bconoboy> So it's not really a question yuet
14:37:25 <bconoboy> er yet
14:38:29 <bconoboy> I could easily see the workstation crew wanting a < 13 month support window
14:38:46 <haraldh> sure... we don't care :)
14:39:05 <haraldh> it's only about the long variants
14:39:32 <masta> Well, there is a care in terms of hosting so much stuff. The mirrors feel the pressure hosting so much content.
14:39:49 <masta> and the churn of the content
14:39:54 <bconoboy> On the other hand, how many features are going into what would be the base compose where folks higher up the stack or relying upon some rebased functionality?  Because I'm picturing the base (ring 0) compose having more restrictions on rebasing post-release
14:40:24 <haraldh> systemd?
14:40:28 <haraldh> kdbus maybe?
14:40:49 <bconoboy> Yeah
14:41:13 <bconoboy> Probably just need policy with regard to api/abi breakage.  Hopefully tooling like libabigail can help with this
14:41:28 <haraldh> don't forget dbus interfaces
14:41:50 <bconoboy> do we have a regression checker for those?
14:42:34 <haraldh> not that I know of
14:42:48 <bconoboy> pity
14:43:03 <bconoboy> Anyway, that's my brain dump of the morning.
14:43:11 <haraldh> I mean, the interface can easily be introspected
14:43:23 <haraldh> names, arguments, type of arguments
14:43:28 <bconoboy> It would be helpful to discuss next steps though- just talking about it on the mailing list won't get us further
14:43:31 <haraldh> but of course not the functionality
14:43:40 <haraldh> yes
14:43:43 <masta> ok, well thanks Brendan. It's good to share the vision =)
14:44:16 <haraldh> next steps, set the definition of ring 0 in stone via a wiki page
14:44:32 <masta> haraldh: yuck
14:44:40 <masta> haraldh: I mean, great!
14:45:09 <bconoboy> I think we also need to get commentary on the impact of ring 0 to existing policy
14:45:20 <bconoboy> We touched on a couple already:
14:45:36 <bconoboy> 1. Critical path definition/packages (Are we saying "base should own these"?)
14:45:48 <masta> so where do tool-chain things go in relation to ring-0? the things needed to build ring-0 ?
14:45:54 <bconoboy> 2. Release cadence/coupling
14:46:25 <bconoboy> toolchain (gcc) is definitely ring 0
14:46:32 <haraldh> haven't we already agreed that https://fedoraproject.org/wiki/Critical_path_package is to broad for base?
14:47:10 <bconoboy> we've agreed on lots of things- defining ring 0 breaks existing agreements
14:47:12 <masta> haraldh: looking at a graph of what is required to build the kernel, it's distressingly too much for ring-0
14:47:18 <bconoboy> for instance, critical-path-kde, we don't want that
14:47:28 <bconoboy> critical-path-base we do
14:47:29 <haraldh> masta, yes, that was my point of creating it :)
14:47:32 <bconoboy> but is it enough?
14:48:18 <bconoboy> Remember last time we talked about this, ring 0 can use packages in ring 1 to build, but needs to be able to install with just ring 0 packages
14:48:29 <bconoboy> Oh, that reminds me, something else from the list discussion:
14:48:59 <bconoboy> Ring 0 policy needs to be at the source rpm level, which is relevant for packages that have many sub packages
14:49:38 <bconoboy> But the question came up, what about the case where some subpackages require a huge breadth of other packages that wouldn't normally be in ring 0?
14:50:10 <haraldh> like php/java
14:50:21 <bconoboy> The way this could be sorted out is by having the ring 0 compose include some but not all sub-packages
14:50:55 <masta> hum...
14:51:10 <bconoboy> Some sub-packages of a ring 0 source rpm might not be in the ring 0 compose.  We could call it ring 0 prime (langdon), ring 0 optional, or just stuff it into ring 1
14:51:18 <masta> so that means there is two ring-0's, one from source package perception, and another from compose.
14:51:33 <bconoboy> Because the core requirement is that the ring 0 compose pass repoclosure
14:51:33 <masta> the compose case is then really what defines ring-0
14:51:43 <bconoboy> That's half of it
14:51:52 <bconoboy> there's also the source rpm policy
14:51:56 <bconoboy> It really needs to be both
14:52:05 <bconoboy> But the handling is slightly different
14:52:06 <haraldh> wouldn't the new rpm weak dependencies help here?
14:52:13 <bconoboy> maybe?
14:53:06 <haraldh> I mean, in theory we could make it that way.. but does it make sense?
14:53:10 <bconoboy> I don't think so though- recommends isn't strong enough if the package really doesn't work without the recommended package
14:53:24 <haraldh> only for the sake of repoclosure on all ring0 subpackages?
14:53:26 <bconoboy> So you *could* use weak dependencies, but you'd have to lie
14:53:41 <haraldh> exactly
14:53:50 <bconoboy> Not a good starting point for ring 0 definition :-)
14:53:55 <haraldh> :)
14:54:11 <masta> hrm... repoclosure in situation where sub-packages are pruned, it can probably work if only leaf nodes are removed.
14:54:11 <bconoboy> Have to step away from the keyboard for a minute, brb
14:56:01 <masta> we run repoclosure as part of the compose
14:56:42 <masta> at least in pungi4 case, the new compose tool.
14:57:07 <bconoboy> back
14:58:26 <bconoboy> Right, so, that's something we'll have to sort out
14:59:01 <bconoboy> Going back to the beginning, there's a real question of "why define ring 0 separate from ring 1?" that needs answers
14:59:27 <bconoboy> Some answers include having a base compose with a different schedule that provides a more reliable foundation for spins/editions
15:00:12 <bconoboy> Likewise having a new threshold for a minimal secondary arch acceptability state- reinforcing the secondary/primary as an aspect of each spin/editions
15:02:01 <bconoboy> I have another conference starting now so I need to drop- thanks all
15:02:08 <haraldh> thanks bconoboy
15:02:08 <haraldh> !!
15:02:48 <masta> bconoboy: ok, I'll talk to releng about some of these ideas, and the implications on our tooling (what would need changing), and try to scope it out.
15:02:59 <masta> thanks dude
15:03:57 <masta> longer lasting releases will cause more work for rel-eng, but I suppose work always increases =(
15:05:05 <bconoboy> it's really just pushing updates for a bit longer
15:05:24 <bconoboy> if base releases come out with less frequency there is possibly less work for rel-eng
15:05:26 <masta> We probably will need to look over using crit-path or something else to cover ring-0, not sure it needs it's own special term
15:06:47 <masta> yep, and hopefully things in the base/ring-0 don't churn too much
15:10:01 <lnykryn> by the way is this against whole "first" motto of fedora. If we release ring 0 not that often and support it for longer, than I will be stuck for example with old systemd and missing cool new features
15:10:33 <bconoboy> really depends on the rebase policy- systemd might be in a position to update post-release
15:10:44 <masta> lnykryn: yes and no, there will still be a 6 month new-hotness for ring-0
15:11:50 <masta> if there is no abi break, I'm sure things can update.
15:12:38 <masta> we have a few more minutes to go, and seem to be fizzling out.
15:12:53 <masta> haraldh: thanks for hosting the meeting! :)
15:12:57 * masta wonders off
15:13:10 <haraldh> still, we need a mechanism to ensure backwards compat
15:13:16 <haraldh> for e.g. new systemd
15:13:23 <haraldh> dbus interfaces, etc.
15:13:50 <haraldh> critical
15:19:19 <msekleta> haraldh, any idea what that would be?
15:19:40 <haraldh> hm?
15:19:44 * msekleta would love to have easy way how to write integration tests for fedora components
15:20:07 <msekleta> haraldh, I mean "mechanism to ensure backwards compat"
15:20:19 <haraldh> libabigail
15:20:32 <haraldh> and a tool, which records all dbus interfaces
15:20:36 <haraldh> and compares it
15:20:45 <haraldh> like rpmdifftool for dbus
15:22:22 <msekleta> it makes sense to have something along the lines of rpmdiff for critical components
15:22:39 <haraldh> yep
15:23:01 <tflink> fwiw, there is an abidiff task in progress for taskotron
15:23:05 <msekleta> could be integrated with bodhi
15:23:53 <msekleta> tflink, is it enabled by default, I mean as part of AutoQA?
15:23:56 <tflink> we're waiting on the libabigail folks for the actual tool to run ATM
15:24:13 <tflink> msekleta: the current plan is to run it on all builds in taskotron, yes
15:25:35 <msekleta> haraldh, btw do you know how to gather introspection data of dbus service which uses sd-bus?
15:25:49 <msekleta> without actually running the thing, of course
15:25:58 <haraldh> without? no
15:31:08 <haraldh> #endmeeting