14:00:12 <bcotton> #startmeeting Council (2019-06-05)
14:00:12 <zodbot> Meeting started Wed Jun  5 14:00:12 2019 UTC.
14:00:12 <zodbot> This meeting is logged and archived in a public location.
14:00:12 <zodbot> The chair is bcotton. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:12 <zodbot> The meeting name has been set to 'council_(2019-06-05)'
14:00:13 <bcotton> #meetingname council
14:00:13 <zodbot> The meeting name has been set to 'council'
14:00:21 <bcotton> #chair jonatoni bexelbie contyk dgilmore dperpeet langdon mattdm sumantrom tyll bcotton pbrobinson stickster
14:00:21 <zodbot> Current chairs: bcotton bexelbie contyk dgilmore dperpeet jonatoni langdon mattdm pbrobinson stickster sumantrom tyll
14:00:22 <bcotton> #topic Introductions, Welcomes
14:00:43 <bcotton> who's here today?
14:00:46 <bexelbie> .hello bex
14:00:50 * pbrobinson is not really here
14:00:50 <zodbot> bexelbie: bex 'Brian (bex) Exelbierd' <bexelbie@redhat.com>
14:00:53 <langdon> .hello2
14:00:54 <zodbot> langdon: langdon 'Langdon White' <langdon@redhat.com>
14:01:14 <asamalik> .hello2 (in case my objective proposal is discussed)
14:01:15 <zodbot> asamalik: asamalik 'Adam Samalik' <asamalik@redhat.com>
14:01:17 <langdon> I'm on mobile for five or so minutes.. so not wanting to type much
14:03:21 <mattdm> I'm here! Thanks bcotton
14:03:35 <contyk> .hello psabata
14:03:36 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
14:03:41 <mattdm> pbrobinson: here enough to give a brief update?
14:03:47 <mattdm> asamalik: yes let's discuss it :)
14:03:52 <tyll> .hello till
14:03:53 <zodbot> tyll: till 'Till Maas' <opensource@till.name>
14:04:06 <pbrobinson> mattdm: maybe, I feel pretty sick and i'm trying to run the iot meeting too
14:04:27 <mattdm> pbrobinson: ok. can you email an update to the list when you get a chance and are feeling better?
14:04:27 <langdon> back at a keyboard
14:04:57 <dgilmore> I'll be back in about 10 minutes, I have to run my daughter to summer camp
14:05:30 <mattdm> dominik doesn't seem to be online either
14:05:41 <mattdm> stickster: you around?
14:06:01 <contyk> mattdm: he's in a call with me :)
14:06:19 <asamalik> :)
14:06:33 <contyk> if we could do other topics/objectives first, that would be good
14:07:05 <mattdm> ok, well that looks like langdon then :)
14:07:13 <mattdm> #topic Modularity
14:07:22 <mattdm> Hey langdon, is modularity done yet? :)
14:07:23 <langdon> ha.. i don't have very much to update on..
14:07:55 <langdon> well.. so.. we are still rolling along.. i would say the biggest blocker is the modules in the buildroot problem.. which is being worked on.. but slowly
14:08:25 <langdon> we have more "strategy" discussions still happening in the modularity team meeting (see the modularity pague repo for topics)..
14:08:30 <mattdm> Do we have a refreshed objective proposal?
14:08:36 <langdon> we still need to close out this objective and write a new one
14:08:40 <langdon> no.. not yet
14:08:45 <mattdm> yes, that's where I'm going with this :)
14:09:01 <mattdm> What can we do to help that happen?
14:09:11 <mattdm> I'm really starting to think we needed that writing hackfest
14:09:13 <langdon> extend the number of hours in the day?
14:09:20 <langdon> mattdm: no comment
14:09:25 <mattdm> Done! Days are now 27 hours long.
14:09:33 <langdon> phew.. that was easy
14:09:48 <mattdm> Each hour will be 53 minutes and 20 seconds long.
14:09:58 <langdon> was the lag you doing the math?!?! :)
14:10:05 <mattdm> mayyyybe
14:10:30 <mattdm> In seriousness, we do need to wrap this up, and I *hope* we have something as a followup
14:10:38 <langdon> so.. we had a whole mess of interns start and summit.. but that is starting to settle down.. so.. let's table a deadline til the next meeting so i can figure out how my time looks
14:10:54 <mattdm> Imma file a ticket.
14:10:56 <mattdm> Right now.
14:11:04 <langdon> we are referring to it as the "intern tsunami"
14:12:13 <mattdm> #link https://pagure.io/Fedora-Council/tickets/issue/254
14:12:33 <mattdm> ok moving on then...
14:12:43 <mattdm> #topic Proposed Fedora Minimization Objective
14:12:48 <mattdm> #link https://pagure.io/Fedora-Council/tickets/issue/253
14:13:11 <bcotton> oh yes, this thing that i have starred to read in my inbox
14:13:16 <mattdm> My concern about this is that it's not very concrete
14:13:25 <mattdm> It all seems 100% good, just hard to know if it's working.
14:13:52 <bcotton> asamalik: does this supersede stickster's lifecycle objective?
14:14:00 <langdon> i also wonder why fedora-minimal isn't mentioned (as far as I can tell)
14:14:14 <mattdm> langdon: it's the title! :)
14:14:15 <bexelbie> one option here would be to suggest a revisit after phase 2
14:14:25 <bexelbie> if we don't get to experiments and ones worth moving forward with we can redirect at that point
14:14:26 <langdon> mattdm: what?
14:14:37 <asamalik> mattdm: so I had a chicken and egg problem.. do I do the discovery phase first and then submit it, or submit it to do the discovery phase? I expect the next phases to get more and more specific over time
14:14:40 <mattdm> "fedora minima[l] objective"
14:14:45 <bexelbie> AIUI langdon we don't want to redefine UBI, we want to fix apps on it and offer impovements
14:14:54 <langdon> mattdm: no.. i meant the fedora-minimal base image
14:14:56 <mattdm> asamalik: I understand the problem :)
14:14:57 <langdon> i use it all the time
14:15:04 <asamalik> bcotton: I'd say it forked out of that one? but I'm not sure otherwise
14:15:19 <mattdm> So, I propose two things.
14:15:31 <bexelbie> bcotton, my read from last meeting is that it does
14:15:32 <bcotton> asamalik: we need to be clear if we're adding another objective or if we're kicking paul out and replacing him with you :-)
14:15:45 <mattdm> 1. We consider this + the CI work as subsuming (replacing) the Lifecycle objective
14:15:57 <bcotton> bexelbie: mine, too, but i want that to be explicit, especially since it would involve removing a council member
14:16:00 <asamalik> bcotton: ah :) I think stickster should make that call
14:16:27 <mattdm> 2. We accept this objective through phase one, but explicitly ending at the end of phase one if we we do not renew it in September.
14:16:47 <mattdm> and yes, let's wait until stickster and contyk are available in 14 minutes to make the call on #1
14:16:55 <asamalik> mattdm: point 2 seems fair
14:17:14 <mattdm> I'm going to propose that in the ticket and call for votes.
14:17:32 <langdon> i would argue that we need at least some of phase 2... or something concrete..
14:17:38 <bexelbie> if we go with point 2 - langdon I encourage you to write a new objective with a similar timeframe
14:17:41 <bexelbie> that may be easier
14:17:44 <langdon> maybe phase-1 + one use case implemented
14:17:55 * bexelbie would prefer to see Phase 1 and 2 approved
14:18:00 <bexelbie> but I can live with just Phase 1 approved
14:18:28 <langdon> i also am a bit confused about the steps 0-2 vs the phases 1-4
14:18:47 <mattdm> maybe we can write that as "phase one acceptance criteria"?
14:19:01 <langdon> thats sound very project management-y!
14:19:24 <langdon> bexelbie: sure.. as in "end of summer" or just match whatever the timeline asamalik lands on?
14:19:36 <asamalik> langdon: yeah we might not need the "step x" part in those paragraphs...
14:19:40 <bcotton> projectmanagement++
14:19:43 <bexelbie> langdon, as in a 3-5 months
14:19:43 <langdon> and by "summer" i mean "north american" .. :)
14:19:45 * asamalik was staring at the docs maybe for too long :)
14:19:59 <asamalik> langdon: european!
14:20:10 <asamalik> and we package in centimetres!
14:20:10 <langdon> asamalik: or move the "content" of the steps in to the phases
14:20:19 <langdon> i only use centimeters
14:21:01 <langdon> actually as i re-read.. i think it would make much more sense if "tech strategy" was only your bottom two bullets
14:21:05 <asamalik> langdon: I think you need a programme manager
14:21:15 <langdon> lol
14:21:29 <dgilmore> back
14:22:52 <dgilmore> I am with bexelbie we should approve phase 1 and 2
14:23:12 <dgilmore> doing some exploration will help with discovery
14:23:19 <tyll> +1
14:23:21 <asamalik> langdon: maybe? is that too specific to be in strategy?
14:24:01 <asamalik> and yes phases 1 and 2 make more sense — that will be the point to make a more specific plan probably
14:24:12 <langdon> asamalik: i think those last two bullets "usefulness..." & "images..." are exactly what you want in the tech strat.. as in ... thats how you will approach the goal technically
14:24:32 <cverna> Is the objective only focused on the container base image ?
14:24:45 <langdon> cverna: it explicitly says "no"
14:24:46 <mattdm> Okay, let's take that to the ticket? If we approve phases 1 & 2 I'd still definitely like a checkpoint at the end of 1
14:24:47 <asamalik> cverna: it's only focused on RPMs
14:25:13 <cverna> ok I dig a quick read through :)
14:25:17 <mattdm> the container base image size is a ... second-order derivative
14:25:17 <langdon> i would much rather tighten phase 2 if possible.. do 1 use case .. or something.. else we are talking a long time before progress
14:25:17 <cverna> did*
14:25:17 <asamalik> but looking at images as a feedback
14:25:34 <asamalik> and *enabling* us to build smaller images if we decide to
14:25:43 <cverna> because the container SIG would love to have more people involve :)
14:25:51 * cverna is feeling lonely there
14:25:54 <langdon> i do want to get back to "fedora-minimal" though before we close this
14:26:01 <bcotton> i'd still like the proposal to say explicitly that it replaces the lifecycle proposal so that the council is making an intentional decision on that
14:26:03 <asamalik> cverna: ah! well I might reach out!
14:26:20 <bcotton> (and the decision might be: no, we are keeping lifecycle)
14:26:37 <cverna> asamalik: sure :)
14:27:11 <mattdm> bcotton: yes but let's get stickster to weigh in on that?
14:27:17 <cverna> asamalik: https://teams.fedoraproject.org/project/cverna-container-sig/wiki/home :)
14:27:17 <mattdm> theoretically in 3 minutes?
14:27:25 <bcotton> mattdm: i mean he gets a vote, too :-)
14:27:36 <asamalik> cverna: thanks!
14:28:04 <langdon> cverna: i read this "Images are not our direct goal:... " to mean "not just containers" .. but on re-read.. i am not 100% sure what "image" meant here
14:28:33 <bcotton> mattdm: i just don't want it to be a case of the entire council says "yes, this replaces an existing objective" and the existing objective owner says no, and so it doesn't happen
14:28:47 <langdon> bcotton: you have lost all sense of fun
14:29:11 <bcotton> (this isn't anything related to stickster specifically, just the general case of it's the council's decision, not an objective owner's)
14:29:16 <asamalik> langdon: so about images... I want to enable us to build smaller images by minimizing dependency trees... I don't want to have discussions about "do we ship package X in an image or not?" because that's an entirely different problem
14:29:19 <bcotton> langdon: i never had one
14:29:19 <mattdm> bcotton: well, let's cross that bridge in a minute?
14:29:32 <mattdm> asamalik++
14:29:35 <bexelbie> asamalik++
14:29:35 <zodbot> bexelbie: Karma for asamalik changed to 8 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:29:50 <asamalik> \o/ I guess!
14:30:01 <bexelbie> Ideally this work is valuable to a user of any base image upon which Fedora spec'ed rpms can be layered or which is composed from them
14:30:03 <langdon> can we, in mattdm's proposed checkpoint, ask for 1-2 to use cases identified in phase 1 to be the target for phase 2? to be sure we have something concrete in phase 2?
14:30:18 <bexelbie> langdon++ :)
14:30:18 <zodbot> bexelbie: Karma for langdon changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:30:23 <bexelbie> I like scoping smaller there
14:30:26 <langdon> bcotton: ;)
14:31:03 <contyk> so stickster can't make it and will provide an update later
14:31:07 <bcotton> langdon++
14:31:07 <zodbot> bcotton: Karma for langdon changed to 5 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:31:13 * contyk reads the backlog
14:31:13 <langdon> asamalik: sorry.. but maybe i haven't had enough coffee... how do you minimize a dependency tree without knowing what "features" are required (which in turn require the deps)?
14:32:00 <mattdm> stickster: assuming you see this then, can you please weigh in on the list about 1) the current status of the objective and 2) the idea of retiring it?
14:32:22 * langdon notes his coffee is now empty.. and he is sad
14:32:38 * bexelbie sends langdon for two coffees and happiness :D
14:32:40 <mattdm> langdon: there is a lot of low hanging fruit and large dependency blocks pulled in unconditionally. those can be made conditional.
14:33:01 <asamalik> langdon: it might not be just one answer... I can give you recommendations even... like "package A drags in this, so leaving it out means we save 70 MB but loose feature B, so consider that when making images"
14:33:10 <bexelbie> it also sounds like from the intial research that we have multiple dependency providers in some cases and the solver choices may not be optimal
14:33:40 <bexelbie> where optimal is defined as size for the target app, not a feature that happenstance drags in
14:33:56 <bexelbie> or where reuse is unlikely in a container
14:33:58 <asamalik> bexelbie: yes we definitely have those cases... not sure about optimal/non-optimal but we have choices to do!
14:34:05 <asamalik> ah, yes
14:34:36 <langdon> ok... that makes sense i think... however, I don't think you will get agreement on if "losing B" is ok across the distro.. so maybe the objective is developing the tooling that a "team" (e.g. workstation wg) can decide for themselves? is that what I should be reading it as?
14:35:12 <langdon> final "it" == objective proposal/outcome
14:35:29 <asamalik> langdon: re agreement: that's exactly the point... that's why I'm not doing images
14:35:49 <langdon> ok.. sorry.. i was reading that as "not doing the images *yet*"
14:35:53 <langdon> i like this approach..
14:36:01 <bexelbie> I don't think we need that kind of agreement
14:36:03 <asamalik> cool!
14:36:07 <bexelbie> for example, the editions are unaffected by this
14:36:14 <langdon> bexelbie: how so?
14:36:24 <bexelbie> if a change in rpms splits a feature across two rpms - they just install both and are back to where they wanted to be
14:36:31 <bexelbie> or they get the module that has the feature and skip the one that doesn't
14:36:46 <langdon> ok.. so.. "unaffected unless they opt in" .. .
14:36:48 <langdon> ??
14:37:01 <asamalik> yeah we can get different *installations* from the same repo because of the choices..
14:37:02 <bexelbie> if the outcome is a new module
14:37:08 <langdon> because the workstation (for example) may be getting a bunch of stuff they don't want because of deps
14:37:18 <bexelbie> langdon, and they can opt in
14:37:25 <langdon> right.. then i agree
14:37:28 <bexelbie> or they can build their own module/whatever that gets them what they need
14:37:37 <bexelbie> Apparently we have a modularity objective ... :P
14:37:44 <langdon> who knew?
14:37:48 <contyk> still?
14:37:53 <langdon> contyk: :P
14:37:53 <contyk> wasn't it supposed to be done in f26?
14:37:59 <bexelbie> f6
14:37:59 <bexelbie> :P
14:38:05 <mattdm> ouch :0
14:38:17 <bexelbie> but in all seriousness, for example slimming down the apache dep tree is a huge win
14:38:20 <langdon> if we had just done it in f6.. we wouldn't be having so much trouble now
14:38:21 <langdon> :)
14:38:22 <bexelbie> no matter what I put apache on top of
14:38:59 <langdon> so.. can i go back to fedora-minimal?
14:39:13 <asamalik> bexelbie: ha, httpd is one of the things I want to focus on actually :)
14:39:25 <bexelbie> langdon, only if you define what you mean by that first
14:39:30 <bexelbie> imho
14:39:37 <bexelbie> I think it is a confused term
14:39:41 <langdon> the fedora base image.. that we ship.. it is called fedora-minimal
14:40:01 <bexelbie> I think defining it is out of scope for this objective
14:40:01 <langdon> docker/podman pull fedora-minimal
14:40:04 <contyk> I'd like "fedora" to be the minimal one
14:40:21 <contyk> and it is indeed out of scope
14:40:22 <bexelbie> if we want to change it around, we should get an objective on that
14:40:25 <contyk> the objective explicitly says so
14:40:32 <bexelbie> I don't read this objective as affecting that image's contents
14:40:51 <bexelbie> I see this objective as explicitly looking at apps on top of UBI/fedora-minimal/whatever
14:40:53 <langdon> my point i guess is a) shouldn't there be mention in this objective of using it as a starting point b) i woudl think a great example for phase 2 would be "here is how you make fedora-minimal from the tools"
14:41:13 <bexelbie> I think building fedora-minimal is WAY out of scope
14:41:20 <contyk> I think it's approaching the problem from the other side
14:41:21 <asamalik> yay image discussions :) so that's a next topic I suppose? :P
14:41:24 <bexelbie> and I think that we should use UBI as the starting point
14:41:35 <bexelbie> in addition to or instead of fedora-minimal
14:41:36 <contyk> identify apps, see what deps they have in common, minimize those dep chains while preserving core features in the defined workflows etc
14:41:44 <bexelbie> but either way the app is really the starting point aiui
14:41:52 <contyk> and then you can see what they have in common and make that set the base image
14:42:03 <contyk> if you do all the work, it's likely going to be small as a side effect
14:42:23 <langdon> ok... im deeply confused then.. didn't we say above the goal is to make tooling so that a team, in this case the fedora-minimal team, can develop "images" (container, iso, whatever) that only have the features and deps they really need?
14:42:29 <bexelbie> I really think trying to boil the "define the base" ocean again is a bad idea
14:42:37 <asamalik> contyk++
14:42:39 <zodbot> asamalik: Karma for psabata changed to 6 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:43:07 <contyk> the objective says the base image itself isn't the goal
14:43:12 <bexelbie> I thought the tooling was for packagers other others to be able to slim dep trees and make good decisions
14:43:16 <langdon> ubi and fedora-minimal are highly unrelated.. all the fedora content is available to anyone .. ubi is a specific use case red hat wants to enable.. why would fedora be limited to those use cases?
14:43:20 * bexelbie wonders if it has changed since his last read
14:43:31 <bexelbie> langdon, we aren't limited to UBI
14:43:46 <bexelbie> but if we start with either and go above them we are making real change in an area we can affect
14:43:53 <bexelbie> redefining the base is a never ending story, imho
14:44:10 <langdon> i don't understand why anyone here thinks i am proposing defining the base
14:44:18 <bexelbie> Right now, aiui, if I slim the base image to literally 1 KB, it will all just get dragged in by the first app I want to use
14:44:23 <mattdm> langdon: I think it would be *useful* (in the sense of "Red Hat encouraged to continue funding the effort") if what we come up with for fedora-minimal makes a good upstream for future UBI
14:44:48 <langdon> the objective says it wants to enable teams to define their artifacts.. one of those teams and artifacts is fedora-minimal.. so why wouldn''t it be a use case?
14:45:13 <bexelbie> assuming it is a valid use-case - why does it have to be one of the first ones?
14:45:24 <langdon> because it is small and well defined
14:45:35 <bexelbie> then it is already minimal
14:45:40 <bexelbie> so no work is needed to minimize it
14:45:45 <bexelbie> now about httpd on that ...
14:45:45 <langdon> right.. hence a good test of the tooling
14:46:11 <bexelbie> I'm confused now - so I'll stop typing for a bit
14:46:20 <langdon> as am i
14:46:40 <langdon> maybe other people are reading the entire focus of the objective being on packagers?
14:47:33 <cverna> I thought so to, basically provide a way to make sure the RPMs dependencies are optimal
14:47:38 <mattdm> I think I understand what you're both saying but am not sure how to untangle it :)
14:47:41 <cverna> s/to/too/
14:47:56 <langdon> "Images are not our direct goal: We will not create smaller base images directly as a part of this very objective. Instead, we use the data we collect when optimizing the apps and runtimes we focus on and make suggestions backed by data to the people maintaining the images." < is what i am saying fedora-minmal would be a good group "maintaining the images" to start with
14:48:02 <contyk> mattdm: just say something silly
14:48:51 <mattdm> The problem isn there's not _really_ a group actively working on that
14:49:21 <contyk> indeed
14:49:32 <bexelbie> Wait, we are in a rabbit hole over defining who the objective talks to when they have an idea that is secondary to their work?
14:49:41 <contyk> and while you could say fedora-minimal is a use case / scenario, it's really not
14:49:57 <contyk> so not sure I would be investing any effort in that
14:50:40 <langdon> ok.. so i don't think i understand what the objective will be producing.. i was thinking something along the lines of weldr.. with guidance.. but maybe im completely mising the point
14:51:32 <contyk> so people have specific needs and workloads, such as installing httpd and then running their app
14:51:40 <contyk> or a database or a forward proxy or whatnot
14:51:44 <asamalik> yes, images are not use cases... for example a web server is a use case... on top of various things such as the fedora-minimal
14:51:48 <bexelbie> can we all agree that letting a discovery phase actually happen before we define the phase 2 is useful?
14:51:53 <contyk> currently they get a large base and then double the size by installing the app
14:51:54 <bexelbie> we are going to checkpoint then
14:52:03 <contyk> the goal here is to identify these workloads and optimize them
14:52:06 <contyk> not the base, the workloads
14:52:12 <asamalik> contyk: yes! :D
14:52:30 <contyk> +1 to discovery
14:52:38 <mattdm> I think the output will be: changes to packages so that it is possible to install smaller subsets such that application containers are smaller in the end.
14:52:46 <langdon> ok.. that makes sense to me as that is also kinda the point of modularity... i definitely don't think this objective doc says that
14:52:51 <asamalik> mattdm: exactly
14:53:11 <bexelbie> if that is a goal of modularity - I have missed where that is documented/stated
14:53:18 <mattdm> modularity is an enabler. it may be that some of the answer will be module streams with pared-down deps
14:53:59 <langdon> bexelbie: modularity has always been about "you care about the application" not the deps or the base or their lifecycles
14:54:27 <bexelbie> langdon, yes and you can now have multiple versions to choose from (not in parallel)
14:54:38 <bexelbie> and maybe in a distant future you could see modules built defining features provided
14:54:52 <langdon> bexelbie: and.. if it wasn't clear.. by "point of modularity" was the part about caring about workloads.. not the minimization bit
14:54:54 <bexelbie> but I have never read that the modularity objective included minimizing dependency trees
14:55:42 <bexelbie> yes, it is about versions of software, in practice today, aiui, and about workloads in a broader sense
14:55:46 <bexelbie> but a module runs on something
14:55:57 <bexelbie> and AIUI Adam is proposing to take those workloads on container and minimize them
14:56:00 <bexelbie> probably using modules
14:56:02 <langdon> bexelbie: let's table this..  almost out of time
14:56:07 <bexelbie> and definitely winning for the entire ecosystem
14:56:35 <langdon> so.. this sounds like a worthy goal.. in general.. but I would definitely like to see some changes to the language to capture more of what contyk said above.. would you (asamalik et al) like to do that? or would you like some proposals?
14:57:01 <mattdm> langdon: proposals please ;)
14:57:38 <langdon> ok... i may do them "not in the ticket" so changes can be tracked.. but ill see what i can do
14:57:58 <contyk> over email
14:58:07 <langdon> one per paragraph
14:58:11 <contyk> or blockchain
14:58:26 <mattdm> ouch
14:58:28 <langdon> that should definitely be a requirement
14:58:32 <mattdm> i think that means "time to end meeting"
14:58:49 <langdon> is that the trick? just say "blockchain" and the meeting will end?
14:59:35 <bexelbie> he said "blockchain" you know what the music means :D
15:00:25 <asamalik> blockchain-ai-ops is definitely part of the proposal :)
15:00:39 <mattdm> yes.
15:00:40 <langdon> ha
15:00:41 <mattdm> #endmeeting