--- Begin Message ---
===================================
#fedora-meeting: FESCO (2014-02-19)
===================================
Meeting started by t8m at 18:00:18 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2014-02-19/fesco.2014-02-19-18.00.log.html
.
Meeting summary
---------------
* init process (t8m, 18:00:40)
* #1136 F20 System Wide Change: ARM as primary Architecture -
https://fedoraproject.org/wiki/Changes/ARM_as_Primary (t8m, 18:04:15)
* #1178 Fedora 21 scheduling strategy (t8m, 18:05:25)
* AGREED: Defer the ticket for a week to gather info from WGs (+6, -0,
0:0) (t8m, 18:10:05)
* #1179 Interactions of the various Products (t8m, 18:11:04)
* AGREED: FESCo wants Fedora to continue to have a core set of
features that all Products must implement. We'll defer decisions
about who decides on these core features and what those features
cover until after we get more input from Products about how they are
expecting to diverge. (+7, -0, 0:0) (t8m, 18:55:12)
* #1197 Procedure for suggesting/approving different Products and/or
WGs? (t8m, 18:55:28)
* AGREED: Close for now until the current products are released at
least once and/or anyone proposes a new product (+7, -0, 0:0) (t8m,
19:06:43)
* Many FESCo members think that the bar for the new products should be
relatively high (t8m, 19:06:57)
* Spins continue to exist (t8m, 19:07:44)
* #1198 Possible changes to Fedora EOL bug procedure (t8m, 19:08:10)
* AGREED: the new mattdm's proposal for EOL bug procedure is approved
(+6, -0, 0:0) (t8m, 19:11:45)
* ACTION: mattdm to coordinate with bugzilla maintainers to get the
practical parts implemented (mattdm, 19:11:58)
* AGREED: The pre-EOL warning still stays (with appropriate change of
wording) (+7, -0, 0:0) (t8m, 19:14:08)
* #1233 Nonresponsive maintainer: steve (mattdm, 19:21:09)
* AGREED: steve will be changed to comaintainer and the packages
orphaned with the perl-* packages assigned to psabata (+7 -0 0:0)
(t8m, 19:21:42)
* #1234 Close a loophole in the Nonresponsive Maintainer procedure
(t8m, 19:22:34)
* AGREED: cvsadmins should be advised not to reassign packages without
FESCo approval (+8, -0, 0:0) (t8m, 19:25:39)
* ACTION: dgilmore will mail cvsadmins not to reassign packages
without FESCo approval (t8m, 19:26:20)
* #1236: Change process for F21/Fedora.Next (t8m, 19:30:49)
* AGREED: Open up F21 for ordinary Change proposals _now_, and
continue the conversation about adapting the process for .next in
the mean time. (+6, -0, 0:0) (t8m, 19:42:46)
* Next week's chair (t8m, 19:43:46)
* ACTION: nirik will be the chair next week (t8m, 19:45:38)
* Open floor (t8m, 19:45:44)
* AGREED: FESCo expects the Tech specs/docs from working groups by
March 3rd at the latest (+7, -0, 0:0) (t8m, 19:50:38)
* ACTION: t8m will update the weekly reports ticket with this request
(t8m, 19:53:08)
Meeting ended at 19:55:10 UTC.
Action Items
------------
* mattdm to coordinate with bugzilla maintainers to get the practical
parts implemented
* dgilmore will mail cvsadmins not to reassign packages without FESCo
approval
* nirik will be the chair next week
* t8m will update the weekly reports ticket with this request
Action Items, by person
-----------------------
* dgilmore
* dgilmore will mail cvsadmins not to reassign packages without FESCo
approval
* mattdm
* mattdm to coordinate with bugzilla maintainers to get the practical
parts implemented
* nirik
* nirik will be the chair next week
* t8m
* t8m will update the weekly reports ticket with this request
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* t8m (133)
* nirik (98)
* mattdm (71)
* abadger1999 (59)
* mitr (57)
* dgilmore (41)
* pjones (30)
* zodbot (18)
* notting (5)
* drago01 (2)
* pingou (2)
* bconoboy (1)
* sgallagh (0)
* mmaslano (0)
* jwb (0)
--
18:00:18 <t8m> #startmeeting FESCO (2014-02-19)
18:00:18 <zodbot> Meeting started Wed Feb 19 18:00:18 2014 UTC. The chair is t8m. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:25 <t8m> #meetingname fesco
18:00:25 <zodbot> The meeting name has been set to 'fesco'
18:00:32 <t8m> #chair abadger1999 dgilmore mattdm mitr notting nirik pjones t8m sgallagh mmaslano jwb
18:00:32 <zodbot> Current chairs: abadger1999 dgilmore jwb mattdm mitr mmaslano nirik notting pjones sgallagh t8m
18:00:40 <t8m> #topic init process
18:00:40 <pjones> hello.
18:00:41 <mitr> Hello all
18:00:44 <t8m> Hi all
18:00:49 <nirik> morning
18:00:55 <abadger1999> Greetings
18:01:04 <mattdm> good afternoon!
18:01:15 <t8m> good evening :)
18:01:21 <bconoboy> good morning
18:02:24 <mattdm> :)
18:02:43 <t8m> dgilmore, around?
18:03:34 <t8m> as we have too many tickets to process and the quorum is already in we should start
18:03:56 * dgilmore is here
18:04:15 <t8m> #topic #1136 F20 System Wide Change: ARM as primary Architecture - https://fedoraproject.org/wiki/Changes/ARM_as_Primary
18:04:22 <t8m> .fesco 1136
18:04:24 <zodbot> t8m: #1136 (F20 System Wide Change: ARM as primary Architecture - https://fedoraproject.org/wiki/Changes/ARM_as_Primary) – FESCo - https://fedorahosted.org/fesco/ticket/1136
18:04:29 * dgilmore honestly thought this was all done
18:04:33 <mattdm> I mostly wanted to make sure that we hadn't missed anything here.
18:04:46 <t8m> mattdm, I suppose we hadn't
18:04:48 <mattdm> From the first time we had a discussion I expected a final review and rubber-stamping
18:04:48 <nirik> I don't think we did.
18:05:08 <mattdm> if we feel like that's not necessary (and I guess that's the consensus), then, yeah, movin on :)
18:05:14 <t8m> ok moving on
18:05:23 <t8m> I'll close the ticket
18:05:25 <t8m> #topic #1178 Fedora 21 scheduling strategy
18:05:30 <t8m> .fesco 1178
18:05:31 <zodbot> t8m: #1178 (Fedora 21 scheduling strategy) – FESCo - https://fedorahosted.org/fesco/ticket/1178
18:05:55 <nirik> I don't know what we can really do here yet... we still don't have sufficent info IMHO.
18:05:57 <mattdm> sgallagh had a draft message
18:06:11 <mattdm> i think right now, we are waiting for that draft to go out
18:06:11 <dgilmore> we can set a release date
18:06:19 <dgilmore> and do what can be done in that time
18:06:44 <mitr> No
18:06:46 <nirik> dgilmore: I'd hate to do that and have some product be unable to do much because lack of time tho
18:06:46 <mattdm> in the individual working groups (at least in cloud) we are slowly forming an unordered list into a useful one
18:06:58 <dgilmore> nirik: sure, not saying its ideal
18:07:03 <dgilmore> its just an option
18:07:05 <t8m> dgilmore, it's too premature as we do not really have input from WGs on timing of their needed change
18:07:08 <t8m> changes
18:07:30 <nirik> so, proposal: defer this and hope to gather useful info from working groups soon on scope of changes.
18:07:36 <t8m> nirik, +1
18:07:39 <mattdm> I think sgallagh is on vacation until tomorrow?
18:07:41 <dgilmore> nirik: +1
18:07:47 <nirik> mattdm: yeah, he's out today at least
18:07:50 <mattdm> nirik +1
18:07:51 <t8m> nirik, defer for a week?
18:08:03 <mitr> t8m: if we haven't even sent that email, probably more
18:08:12 <t8m> mitr, I'd say so
18:08:13 <nirik> sure, I think we should revisit it often, perhaps we will have some glimmers next week
18:08:15 <pjones> nirik: +1
18:08:21 <abadger1999> if sgallagh sends the email tomorrow we could get back to it next week.
18:08:22 <mattdm> mitr: well, everyone *should* be _expecting that mail
18:08:30 <mattdm> +1 next week and we'll see where we area
18:08:33 <mattdm> are
18:08:34 <t8m> ok
18:08:51 <dgilmore> we will need a week after the WG's get their changes in for qa and releng at least to see whats doable
18:08:53 <nirik> I'll note that we are past the orig deadline we set for list of deliverables/changes in process. ;)
18:09:02 <mattdm> maybe we could also add a "hey, what do you think the ideal release date would be?"
18:09:04 <dgilmore> probbly will need infra, marketing and websites also
18:09:07 <abadger1999> mattdm: +1; we'll keep discussing it until we've resolved it anyhow :-)
18:09:10 <nirik> dgilmore: yeah, and all the other groups too.
18:09:29 <mattdm> i know workstation for example would probably like to coordinate with the gnome 3.14 release
18:09:45 <abadger1999> mattdm: not sure about asking for an ideal release date, thouhg... there's a lot of manpower needs outside of the working groups to make things happen.
18:09:59 <abadger1999> So schedule is likely more being set by teams outside of the working groups.
18:10:05 <t8m> #agreed Defer the ticket for a week to gather info from WGs (+6, -0, 0:0)
18:10:18 <mattdm> abadger1999 that makes sense too
18:10:22 <t8m> with implicit nirik's +1
18:10:31 * nirik nods
18:10:53 <t8m> let's move on
18:11:04 <t8m> #topic #1179 Interactions of the various Products
18:11:09 <t8m> .fesco 1179
18:11:10 <zodbot> t8m: #1179 (Interactions of the various Products) – FESCo - https://fedorahosted.org/fesco/ticket/1179
18:12:18 * mattdm rereads ticket
18:12:43 <mattdm> So toshio asked a question: "One thing to talk about is whether we want to have somethings that are necessary for all Fedora Products (SELinux on; systemd as the init system; running syslog, cron, and smtp daemons; linux kernel; etc). And if so, whether we want the Base Design WG to do that."
18:12:45 <t8m> So, do we have any concrete proposal to vote on this? I suppose not yet. Any volunteers to create for example a wiki page where they could be gathered?
18:12:52 <mattdm> I think the answer is "yes, that is what the base design is for"
18:13:17 <mitr> I think there was a strong consensus to minimize deviations in configuration, which is sort of a "default answer".
18:13:26 * pingou thought base was the mandatory bits that every product is based upon
18:13:53 <mitr> And yes, base would be the right place to shepherd new functionality and resolve conflicts in that area.
18:13:59 <t8m> pingou, sure, but the base bits probably could be configured differently if really needed for different products
18:14:34 <t8m> for example we might want rsyslog on in server, perhaps not so much in workstation or cloud
18:14:37 <pingou> t8m: true but if base end up not being used by all products, then I don't understand why it exists at all
18:14:47 <pjones> mattdm: yeah, I think you're right.
18:14:51 <t8m> pingou, it will be used by all products
18:14:54 <abadger1999> mattdm: Cool. We should approve something about that and pass the mandate on to the base WG then... jwb felt that we hadn't mentioned that as something we wanted Base to do.
18:15:15 <nirik> I think we are just going to have to feel out way along here...
18:15:22 <mattdm> +1 nirik
18:15:35 <nirik> some things will need to be decided by base folks, but others could be different in the products...
18:15:46 <mattdm> I have the expectation that if the base "mandates" soemthing, and that doesn't meet the needs of the product, we'll work something out.
18:15:49 <nirik> workstation is also talking (on list) about not having a firewall...
18:16:14 <mattdm> cloud is *already* not wanting a firewall.
18:16:16 <dgilmore> cloud has turned iptables off, which I dont like
18:16:18 <nirik> but some things definitely would be base... kernel, systemd, etc.
18:17:14 <abadger1999> mattdm: Would it be okay for that to be something that cloud and workstation present to base and base figures out if it's okay, and if so, to what extent?
18:17:22 <dgilmore> im pretty sure iptables is in base
18:17:33 <nirik> firewalld is likely too
18:17:35 <dgilmore> but configuration can be done outside of it
18:17:38 <nirik> anaconda requires it
18:17:42 <dgilmore> yeah
18:18:09 <mattdm> nirik anaconda as of f18/f19 required firewalld. but it doesn't in f20
18:18:28 <mattdm> if the firewall is disabled and you don't include that package, it will let you.
18:18:29 <abadger1999> dgilmore: sure... but htere's "Base -- the minimal set of packages and services that other Fedora Products are based on" and "Base Design -- the minimal guarantees we make about what a Fedora system has"
18:18:29 <pjones> I think we may be getting a bit too caught up on the present here.
18:18:34 <nirik> oh really?
18:18:39 <nirik> yeah.
18:18:43 <nirik> pjones: +1
18:18:45 <mattdm> pjones yes
18:18:51 <t8m> pjones, +1
18:18:54 <abadger1999> pjones: +1
18:19:10 <mattdm> i can go on about firewalld all day and probably shouldn't :)
18:19:18 <dgilmore> firewalld is in anaconda-tools group in comps
18:19:36 <dgilmore> abadger1999: sure
18:20:02 <t8m> Any concrete proposal to vote on?
18:20:09 <nirik> so where do we go from here? just see docs from working groups and ask them to shunt some to base that make sense?
18:20:50 <t8m> nirik, who will do that review, FESCo members?
18:20:53 <abadger1999> For my Base question specifically, I think we need to tell Base that this is something that we want them to be in charge of.
18:21:28 <mattdm> abadger1999 okay :)
18:21:30 <nirik> t8m: dunno. I guess.
18:21:37 <abadger1999> since the question came up already.
18:21:40 <mitr> I have started that ticket with a goal that "application development for Cloud and Server happens on Workstation", and trying to define what was necessary for _that_. There wasn't consensus that we need to be explicitly designing this interaction IIRC.
18:21:44 <nirik> abadger1999: so do we want some specific list?
18:22:48 <mitr> I think it makes more sense now to just deal with common items as they come up (using the liaison reports), and not try to draft any kind of intended-to-be-completed list now.
18:23:24 <abadger1999> nirik: Are you thinking with entries like: "Base Design is in charge of determining * what services are allowed to be enabled by default when they are installed" "* what services must be installed and running on any Fedora system"
18:23:28 <t8m> mitr, +1
18:24:00 <nirik> abadger1999: I guess...
18:24:30 <abadger1999> If that's what we'd like to vote on, I can write something up this week.
18:25:26 <mattdm> I'm good with that with the understanding that the idea is to keep Fedora generally cohesive while serving the needs of the products. If this becomes an area of _conflict_ between base & products, soemthing is going wrong.
18:25:56 <pjones> mitr: +1
18:26:28 <pjones> mitr: since it seems there's literally 0% chance we'd get it right at this stage, it seems like that shouldn't be something we try to make concrete rules for yet.
18:26:36 <nirik> abadger1999: not sure we are at that point yet tho... like for example with 'enabled by default' we could well have different systemd presets per product.
18:27:28 <abadger1999> nirik: <nod> So -- my thinking is that Base might specify that as well.
18:27:29 <mitr> pjones: Well, the Workstation WG did https://fedoraproject.org/wiki/Workstation/Technical_Specification ; having something like that from the other products might actually make sense (... but we don't have that now).
18:27:41 <mattdm> mitr yeah, that's nice
18:27:54 <pjones> mitr: opposite direction though - that's the projects doing it, not us
18:28:42 <abadger1999> they might decide that Products can choose to enable/disable whatever services they want by default. They might decide that that's the general case but X, Y, Z specific services must be enabled/disabled
18:28:51 <pjones> which is to say it's something that provides useful form for them to go about their work, rather than something to limit them from outside.
18:28:59 <nirik> I guess I would feel better if we had specs from all the products before deciding what we should ask base to manage from that
18:29:05 <abadger1999> Or they might decide that Base needs to approve everything.
18:30:44 <mitr> I guess, Proposal: Close ticket. Rely on liaisons to highlight technical decisions that extend from their WGs, and for now expect to deal with interactions one issue at a time.
18:30:47 <mitr> (We can revisit if all products prepare technical specifications.)
18:31:13 <abadger1999> nirik: okay... Would it hurt to tell Base that htis is something we want them to do in the future but we want them to start thinking about it after Products have some desires to present to them?
18:31:30 <t8m> mitr, +1
18:31:32 <nirik> abadger1999: I surely wouldn't think so... ;)
18:31:42 <pjones> mitr: +1
18:32:24 <mattdm> mitr +1, along with abadger1999's note to base
18:32:26 <nirik> mitr: s/if/when/ ? we should get specs from all products... :)
18:32:31 <mitr> (an reasonable alternative position: ask WGs to prepare technical specifications by $date, use that to figure out the interactions)
18:32:52 <nirik> we have already done that, but need to push the date out.
18:32:56 <abadger1999> nirik: My thought is that right now it seems that Products seem to think that they can diverge on these points but we probably do want to have some core things that are "a Fedora system implements X". So we want to warn everyone that this is something that we see Base as deciding upon.
18:33:35 <dgilmore> mitr: +1
18:34:10 <mitr> abadger1999: Structurally, Base WG "owns" the design and implementation of the base. I think FESCo "owns" the authority to decide which parts are the Base and which parts are not; it would be somewhat strange for Base to just claim an area.
18:34:53 <mitr> (considering the already discussed Base mission statement as FESCo approved or something)
18:34:54 <abadger1999> mitr: I might agree with that... I'm not sure I understand it fully though :-)
18:35:14 <t8m> mitr, I'd agree with this, FESCo should have the authority to choose what Base WG owns
18:35:44 <mitr> (honestly "ownership" is a side issue... but cross-product interactions are clearly a FESCo matter.)
18:35:46 <nirik> abadger1999: I think I'm ok with that, but it should really be base stuff...
18:37:00 <abadger1999> mitr: I'm more saying that everyone seems to accept that Base is building something that the other Products can build on top of. But we aren't all on the same page about whether some parts of Base are modifiable by the products and other parts of Base must be implemented as is in the Products.
18:37:10 <t8m> I am counting +4 for Proposal: Close ticket. Rely on liaisons to highlight technical decisions that extend from their WGs, and for now expect to deal with interactions one issue at a time.
18:37:44 <mitr> abadger1999: My "default" view is that Fedora products all use a single set of technologies, and Products primarily choose which to include/omit. (Too simplistic, sure. Configurations will differ, there are different desktop stacks, we don't worry about having umpteen string libraries. But in the higher-level view I think it's roughly correct.)
18:37:46 <nirik> abadger1999: it's really hard to answer that question until we have the tech specs for all the products... I mean, we don't know what kinds of things they want to do fully.
18:38:41 <nirik> I hope base will also be responsive to products... 'you choose foo, but we need bar, is it ok to add bar on? or can you switch to bar? or do we need bar and foo both?'
18:38:57 <mattdm> nirik +1
18:39:43 <t8m> #proposal Postpone until WGs prepare technical specifications of the products
18:40:25 <nirik> +1
18:40:31 <abadger1999> nirik: I don't think that the basic concept is hard to answer.
18:40:53 <nirik> abadger1999: can you put it into a proposal?
18:40:59 <abadger1999> the basic concept is "Do we want Fedora to have a core set of features that everyone must implement"
18:41:02 <mitr> t8m: is that "indefinitely", or "... and we will ask WGs to do so"?
18:41:17 <abadger1999> and from that, "Do we want the Base Working Group to determine those Features"
18:41:27 <t8m> mitr, yeah we should ask them to do so :)
18:41:57 <abadger1999> Deciding what those features are is where I agree with you that we should wait for more input from the WG's about what they want to do.
18:41:58 <nirik> ok, sure. I am +1 to both those.
18:42:10 <t8m> abadger1999, +1 to first, not so sure about the second
18:42:33 <nirik> I would hope it would be a small list of musts...
18:42:34 <abadger1999> +1 to the first. Willing to discuss the second :-)
18:42:56 <t8m> the base group should work on those features but they should be probably chosen/approved by FESCo
18:43:06 <t8m> IMO
18:43:44 <pjones> t8m: oh god, why? We appointed these people to do the job, why can't we let them?
18:44:34 <pjones> If we don't trust them to at least try and make good, informed decisions, why don't we just jettison the base WG and do it ourselves?
18:44:35 <nirik> yeah, I don't see any reason to micromanage... if they make some bad decision we can override them, no?
18:44:50 <nirik> or convince them to revisit
18:44:52 <mitr> pjones: I don't think "approved" is a must, it's just that FESCo is the place where the products actually meet to interact
18:44:54 <pjones> nirik: yeah, and before that we can, you know, talk to them.
18:44:59 <nirik> right
18:45:03 <t8m> pjones, so Base group is being the people who define what it means that some product is Fedora?
18:45:06 <abadger1999> t8m: okay... so in your view, it would be up to fesco to say things like "All Products must have selinux enabled" and it would be up to Base to make sure that SELinux works for all packages that the products are shipping?
18:45:17 <t8m> abadger1999, yes
18:45:59 <mitr> abadger1999: Or it might be "all products will use the same SELinux setting" and leave it up to base to choose one
18:46:18 <abadger1999> I think I'm with pjones that I'd rather see Base do the decision making. And packagers/Feature Owners do the work to make sure they work as expected.
18:46:22 <mitr> Really, I don't think we don't need to prepare a hypothetical plan for these things.
18:46:31 <t8m> mitr, +1
18:46:58 <dgilmore> lets wait till we get real issues come up to solve
18:47:05 <nirik> I think it might be nice for base to have a set of musts... we just mostly assume them now, but if we have a place for them they could even be revisited or changed sometimes.
18:47:10 <mitr> At this point we really have nothing to work with, and we're certainly not going to complete the list of concerned areas within this meeting.
18:47:40 <t8m> #proposal close the ticket for now
18:47:41 <abadger1999> I'm just responding to something jwb said in the workstation PRD ticket -- that he didn't think the Base WG thought that this was something we wanted from them.
18:47:56 <mitr> t8m: reiterating a +1
18:48:01 <abadger1999> And it sounds like fesco needs to decide on whether we want them to be in charge of this.
18:48:39 <mitr> Our options _this minute_ are a) close and plan to deal with it individually, b) find someone willing to work on a propose a list, and defer until then, c) ask WGs to give us input to create/collate the list, and defer until then. Anything else?
18:49:19 <abadger1999> because as it is now we've just made it more confusing for someone from the WGs who reads the logs to know whether we expect Base to make these decisions or not.
18:49:37 <mattdm> abadger1999 yes _that_ is true. :)
18:49:38 <pjones> abadger1999: hence what mitr is saying :)
18:50:18 <nirik> mitr: d) ask base to come up with a list?
18:50:51 <dgilmore> abadger1999: I think it will be clearer what is bases domain when we get all the Product info in
18:51:32 <mitr> nirik: Actually they sort of already did in https://fedoraproject.org/wiki/Base:
18:51:35 <mitr> The experience from functionalities provided by Base are expected to be consistent across different Fedora products
18:51:37 <mitr> Definition of the Base: Installer, compose tools, minimal install (for some definition there), and functionality the majority products want to use
18:51:47 <dgilmore> it should be assumed that base is responsible for the core pieces, which are not totally clear right now. with FESCo being an escallation point
18:51:54 <nirik> mitr: yeah, but what about things like:
18:52:01 <abadger1999> mitr: <nod> How about this compromise: Proposal: FESCo wants Fedora to continue to have a core set of features that all Products must implement. We'll defer decisions about who decides on these core features and what those features cover until after we get more input from Products about how they are expecting to diverge.
18:52:05 <mitr> nirik: "majority products want to use" is an implicit list, but close enough as a guideline.
18:52:08 <nirik> selinux enforcing, linux kernel, systemd, rpm?
18:52:23 <nirik> abadger1999: sure. +1
18:52:50 <t8m> abadger1999, I can definitely be +1 to this
18:53:12 <abadger1999> nirik: depsolver (dnf/yum/alternative), sshd,
18:53:22 <dgilmore> abadger1999: sure
18:53:26 <mitr> abadger1999: *shrug*, +1 I suppose, that's about equivalent to closing the ticket and waiting for someone to raise an issue :)
18:53:53 <pjones> abadger1999: sure, +1
18:53:58 <nirik> abadger1999: security policy, sudo/wheel, yeah, the list goes on. ;)
18:54:12 <t8m> dgilmore, is that +1?
18:54:15 <mattdm> also sure +1
18:54:26 <dgilmore> t8m: yes
18:54:34 <abadger1999> mitr: the important part for me is that we're telling products that there's certain things that we're going to ocnsider to be "must implement" and "must not implement" for all fedora products.
18:54:36 <t8m> abadger1999, are you +1 on yourself?
18:54:39 <abadger1999> +1
18:55:12 <t8m> #agreed FESCo wants Fedora to continue to have a core set of features that all Products must implement. We'll defer decisions about who decides on these core features and what those features cover until after we get more input from Products about how they are expecting to diverge. (+7, -0, 0:0)
18:55:28 <t8m> #topic #1197 Procedure for suggesting/approving different Products and/or WGs?
18:55:28 <mattdm> (And if some people would like to go outside of that, there's certainly room for a remix.)
18:55:32 <t8m> .fesco 1197
18:55:33 <zodbot> t8m: #1197 (Procedure for suggesting/approving different Products and/or WGs?) – FESCo - https://fedorahosted.org/fesco/ticket/1197
18:56:55 <t8m> So I don't really see a concrete proposal but I might have overlooked it in the lengthy discussion in the ticket
18:57:42 <t8m> I mostly agree with abadger1999's last comment there
18:59:02 <nirik> yeah, I'm not sure where we go from here... perhaps someone could write up a more concrete proposal on how to promote a new thing to a product?
18:59:18 <nirik> it sounds like most of us are on board with spins just staying spins and not being a product really.
18:59:27 <t8m> #proposal Postpone/close until anybody comes up with concrete proposal for a new product
18:59:34 <mattdm> nirik yes, I think the spins part is decided
18:59:35 <abadger1999> Do we agree on the vision?
18:59:42 <mitr> I do see a definite difference between spins and products (without either being "less").
18:59:48 <abadger1999> (In the future there may be *many* products)
18:59:59 <mitr> t8m: +1. Or alternatively, ... until anyone proposes a product. YAGNI and all that.
19:00:05 <abadger1999> I think that gives people a starting point.
19:00:07 <mattdm> I further think that there's general consensus that there should be a relatively high bar for more products.
19:00:30 <mattdm> the main question is whether that bar should be resourcing-based or, um, story-based
19:00:36 <mitr> (Jóhann mentioned proposing a product, and I'm not actually sure whether he thinks he has already put a proposal to FESCo.)
19:00:37 <t8m> mitr, yeah that's better and more simple wording :)
19:00:47 <pjones> mattdm: I agree, and I also think we need to get this batch working before we start adding more, no matter how high or low the bar is
19:00:54 <nirik> pjones: +1
19:00:56 <abadger1999> mattdm: I think I agree with that pair of statements :-)
19:01:09 <t8m> pjones, +1
19:01:14 * mattdm nods
19:01:17 <abadger1999> pjones: +1 getting the first release w/ products out the door should be our priority
19:01:51 <mitr> abadger1999: I don't expect *many* products. There are only so many general operating systems one would want to use, and specialized niche systems frequently don't need the tight product-like coordination.
19:02:08 * nirik also agrees with mattdm there.
19:02:33 <nirik> It might need to be both things/case by case... based on all the data we can gather would this new thing be good to make a product.
19:02:38 <t8m> #proposal Close for now until the current products are released at least once and anyone proposes a new product
19:02:58 <nirik> t8m: sure, +1
19:03:00 <dgilmore> +1
19:03:01 <mattdm> sure +1
19:03:07 <abadger1999> mitr: I tentatively agree with you... but for me, that means that we provide some non-product-based resources for the niche systems.
19:03:09 <mitr> t8m: +1 (could go with either "and" and "or")
19:03:24 <mitr> abadger1999: Spins continue to exist, yes.
19:03:27 <mattdm> abadger1999 and I think there's agreement that we do and will continue to
19:03:34 <abadger1999> t8m: s/and/or/ ?
19:03:55 <nirik> abadger1999: yeah, we definitely should/are.
19:03:57 <abadger1999> t8m: +1, though
19:03:59 <mattdm> I think we should also note the thing I said about high bar to anyone who floats the idea of proposing a product
19:04:21 <nirik> for example some of the 10,000 rpms we have in our collection are not likely to be in any of our products. ;) yet, we still build and distribute and test them.
19:04:30 <t8m> mattdm, I'd wait for the proposal
19:05:25 <t8m> but I can add a note to the ticket that many FESCo members think that the bar for the new products should be relatively high
19:05:44 <t8m> myself is +1 to my proposal
19:05:46 <dgilmore> nirik: rawhide has armhfp: 70k rpms i386: 72k rpms x86_64: 85k rpms
19:06:04 <pjones> Alright, well, right now we're averaging 3 lines of discussion per minute on this. Do we want to note that in the ticket and move on?
19:06:05 <nirik> cool. :) was thinking srpms, but we are over 10k on that too.
19:06:07 <t8m> #agreed Close for now until the current products are released at least once and/or anyone proposes a new product
19:06:15 * pjones +1 to the proposal
19:06:19 <dgilmore> chances are high a lot of them wont make it to products
19:06:25 <mattdm> t8m my concern is that I don't want something that is unlikely to meet _either_ bar to start something up that doesn't go anywhere, leading to confusiona nd frustration.
19:06:26 <t8m> #undo
19:06:26 <zodbot> Removing item from minutes: AGREED by t8m at 19:06:07 : Close for now until the current products are released at least once and/or anyone proposes a new product
19:06:43 <t8m> #agreed Close for now until the current products are released at least once and/or anyone proposes a new product (+7, -0, 0:0)
19:06:57 <t8m> #info Many FESCo members think that the bar for the new products should be relatively high
19:07:03 <mitr> mattdm: I'd expect mailing list conversations to happen before a large effort is put into a FESCo ticket (but I might be mistaken)
19:07:28 <dgilmore> mitr: I agree
19:07:44 <t8m> #info Spins continue to exist
19:07:51 <dgilmore> I dont think a proposal will come out of the air and blind side us
19:07:51 <t8m> moving on
19:07:56 <mattdm> and maybe this *should* without saying, but I think anyone should expect almost-zero-effort proposals to not go anywhere.
19:08:10 <t8m> #topic #1198 Possible changes to Fedora EOL bug procedure
19:08:15 <t8m> .fesco 1198
19:08:17 <zodbot> t8m: #1198 (Possible changes to Fedora EOL bug procedure) – FESCo - https://fedorahosted.org/fesco/ticket/1198
19:08:47 * nirik voted in ticket here I think.
19:09:28 <t8m> #proposal 1. New "CLOSED:EOL" resolution added. 2. Only the EOL script will be able to put things into CLOSED:EOL 3. Script will be run immediately when a release hits end of life. (Message needs to be adjusted.) 4. Any user will be able to reopen bugs which are CLOSED:EOL, but without special privileges will be made to select a new, open Fedora version
19:09:38 <mattdm> +1
19:09:39 <mitr> +1
19:09:41 <t8m> +1
19:09:52 <nirik> right, +1
19:10:05 <mattdm> notting was +1 in the ticket
19:10:58 <t8m> #agreed the new mattdm's proposal for EOL bug procedure is approved (+5, -0, 0:0)
19:11:12 <nirik> I guess we didn't specifically ping qa folks for input... but they can reopen or open new with further ideas.
19:11:25 <pjones> eh, sure, +1
19:11:36 <mitr> nirik: This seems to be a mechanism change that doesn't affect QA workload
19:11:36 <t8m> #undo
19:11:36 <zodbot> Removing item from minutes: AGREED by t8m at 19:10:58 : the new mattdm's proposal for EOL bug procedure is approved (+5, -0, 0:0)
19:11:45 <t8m> #agreed the new mattdm's proposal for EOL bug procedure is approved (+6, -0, 0:0)
19:11:58 <mattdm> #action mattdm to coordinate with bugzilla maintainers to get the practical parts implemented
19:11:59 <nirik> mitr: there was talk about reviving a triage type group... it may affect them... hard to say
19:12:09 <mitr> nirik: Yes; not part of the proposal
19:12:12 <nirik> right.
19:12:35 <nirik> and also unrelated, but exciting... I am sure looking forward to bugzilla fedmsgs. ;)
19:12:41 <t8m> #proposal The pre-EOL warning still stays
19:12:52 <t8m> +1
19:12:59 <mitr> +1
19:13:07 <dgilmore> +1
19:13:07 <mattdm> t8m +1. wording change as appropriate, of course.
19:13:12 <t8m> sure
19:13:19 <nirik> sure, +1
19:13:31 <abadger1999> +1
19:13:49 <mattdm> notting was also baseically +1 in the ticket
19:13:58 <notting> Yup
19:13:58 <mattdm> ("I don't see why it hurts, if it's simple enough to do.")
19:14:08 <t8m> #agreed The pre-EOL warning still stays (with appropriate change of wording) (+7, -0, 0:0)
19:14:13 <t8m> let's move on
19:14:25 <t8m> #topic #1221 Product working group activity reports
19:14:29 <t8m> .fesco 1221
19:14:30 <zodbot> t8m: #1221 (Product working group activity reports) – FESCo - https://fedorahosted.org/fesco/ticket/1221
19:14:53 <mattdm> no one added anything to the ticket
19:15:08 <mitr> t8m: I think those are supposed to be bi-weekly and we've had reports last week
19:15:19 <t8m> ah ok
19:15:20 <nirik> yeah, I suspect lots of people were getting over the flu/travel doom...
19:15:22 <t8m> moving on
19:15:38 <t8m> #undo
19:15:38 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x2d1ceb10>
19:15:45 <t8m> #topic #1233 Nonresponsive maintainer: steve
19:15:51 <t8m> .fesco 1233
19:15:53 <zodbot> t8m: #1233 (Nonresponsive maintainer: steve) – FESCo - https://fedorahosted.org/fesco/ticket/1233
19:16:19 <dgilmore> I am okay with finding new primary maintainers and having him be a comaintainer
19:16:23 <nirik> I didn't get anything back from steve unfortunately.
19:16:28 <t8m> So I don't see any activity from steve
19:16:40 <nirik> or did I... let me doublecheck
19:16:45 <mattdm> as noted in the ticket, I got a response from him on google+
19:16:54 <mattdm> he says that he's been very busy with work. He'd like to find new primary maintainers for his packages and still be a comaintainer.
19:16:56 <nirik> oh right, I did.
19:17:08 <mattdm> and nirik had a proposal
19:17:09 <nirik> yeah. ditto
19:17:14 <mattdm> to which I am +1
19:17:18 <pjones> that sounds just fine.
19:17:28 <mattdm> ftr...
19:17:36 <nirik> have the perl ones been reasigned yet?
19:17:39 <t8m> +1 to the proposal
19:17:44 <t8m> nirik, not yet afaik
19:17:50 <dgilmore> +1 from me
19:17:59 <mitr> +1
19:18:04 <mattdm> #proposal steve looking for comaintainers for all his packages. we'll make an annoucement and use the fesco ticket to coordinate
19:18:17 * pjones +1
19:18:34 <notting> +1
19:18:41 <nirik> ok. I think it might be good to do the perl ones before any announcement... just so there's less chaos.
19:18:42 <t8m> mattdm, that is not the same as in the ticket
19:19:10 <nirik> I can ping psabata about that.
19:19:10 <t8m> mattdm, I read that he wants to be only comaintainer and give up the primary maintainership
19:19:34 <dgilmore> t8m: agree
19:19:51 <dgilmore> that was my reading also
19:20:09 <mattdm> oops yes you are right.
19:20:12 <abadger1999> +1 nirik's proposal
19:20:13 <nirik> right, which takes a scmadmin to swap them...
19:20:33 <mattdm> #undo
19:20:33 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x2ca60e50>
19:20:54 <mattdm> oops that undid the topic. nice.
19:21:03 <abadger1999> I don't think proposals are actually meetbot commands :-)
19:21:07 <mattdm> i guess not. :)
19:21:09 <mattdm> #topic #1233 Nonresponsive maintainer: steve
19:21:14 <mattdm> soo.
19:21:42 <t8m> #agreed steve will be changed to comaintainer and the packages orphaned with the perl-* packages assigned to psabata (+7 -0 0:0)
19:21:44 <mattdm> #proposal steve looking for new maintainers and would like to remain comaintainer for his packages. We'll make an annoucement and use the fesco ticket to coordinate.
19:21:53 <mattdm> blah blah nevermind. :)
19:22:10 * mattdm is just trying to make the minutes look pretty
19:22:16 <t8m> OK :)
19:22:21 <nirik> shall we move on?
19:22:23 <t8m> yes
19:22:34 <t8m> #topic #1234 Close a loophole in the Nonresponsive Maintainer procedure
19:22:38 <t8m> .fesco 1234
19:22:39 <zodbot> t8m: #1234 (Close a loophole in the Nonresponsive Maintainer procedure) – FESCo - https://fedorahosted.org/fesco/ticket/1234
19:23:19 * abadger1999 agrees with notting
19:23:32 <mattdm> +1 that
19:23:33 <t8m> #proposal cvsadmins should be advised not to reassign packages without FESCo approval
19:23:43 <nirik> there's a case tho that's different...
19:23:48 * pjones +1
19:23:53 <abadger1999> +1
19:23:53 <mitr> Was this actually a systematic problem? I've had a cvsadmin ask for confirmation on a change recently.
19:23:58 <nirik> EPEL branches where the Fedora maintainer doesn't respond in a week. ;)
19:24:24 <mitr> +1 anyway, "advising" doesn't hurt
19:24:25 <nirik> mitr: I don't think it's at all widespread. There was another case a few years ago that some folks got mad about...
19:24:30 <pjones> mitr: I think it happened the once? But it's not like this proposal is a giant policy change.
19:24:31 <t8m> nirik, adding new branch is not reassignment
19:24:43 <dgilmore> nirik: right. I think a longer term way to do it is to have the logic in an app that takes the human error out
19:24:44 <nirik> t8m: true...
19:24:45 <nirik> +1
19:24:51 <t8m> +1
19:25:23 <dgilmore> im +1 to the proposal
19:25:23 <t8m> #agreed cvsadmins should be advised not to reassign packages without FESCo approval (+7, -0, 0:0)
19:25:32 <t8m> #undo
19:25:32 <zodbot> Removing item from minutes: AGREED by t8m at 19:25:23 : cvsadmins should be advised not to reassign packages without FESCo approval (+7, -0, 0:0)
19:25:38 <nirik> is someone going to mail them about this? ;)
19:25:39 <t8m> #agreed cvsadmins should be advised not to reassign packages without FESCo approval (+8, -0, 0:0)
19:25:51 <dgilmore> nirik: I can mail them
19:25:52 <t8m> (notting +1 from ticket)
19:26:20 <t8m> #action dgilmore will mail cvsadmins not to reassign packages without FESCo approval
19:26:21 <nirik> dgilmore: cool. and perhaps close that releng ticket related to this?
19:26:30 <dgilmore> nirik: yep
19:27:03 <t8m> we have two more open tickets that were without the meeting keyword so I forgot to add them to agenda, do we want to discuss them<
19:27:35 * abadger1999 has time if others have the will ;-)
19:28:09 <nirik> sure?
19:28:22 * pjones in general says defer
19:28:24 <t8m> on the other hand I don't know if the interested people for for example the Gnome update are here
19:28:45 <pjones> abadger1999: it's not about having time, it's about interested parties having a chance to voice their point of view in the meeting.
19:28:53 <abadger1999> <nod>
19:28:59 <abadger1999> no worries there.
19:29:09 <nirik> the gnome update one I would personally defer anyhow.
19:29:13 <mattdm> discussion on the mailing list indicates that the gnome ticket should be deferred
19:29:14 <nirik> it's not even released yet
19:29:29 <t8m> ok, let's skip the gnome one
19:29:42 <mattdm> (there isn't sig consensus on whether that's even a think they want, yet)
19:30:09 <t8m> what about the change of the change process for Fedora.next?
19:30:33 <pjones> What's the ticket number we're talking about?
19:30:49 <t8m> #topic #1236: Change process for F21/Fedora.Next
19:30:59 <t8m> .fesco 1236
19:31:00 <zodbot> t8m: #1236 (Change process for F21/Fedora.Next) – FESCo - https://fedorahosted.org/fesco/ticket/1236
19:31:42 <mattdm> pjones it was https://fedorahosted.org/fesco/ticket/1235
19:31:50 <nirik> IMHO, we should wait on that until the tech spec documents, once we hash those out we should file changes for the ones we are actually hoping to do, etc.
19:32:14 <nirik> and ask for any other non product/next groups to file as well.
19:32:16 <mitr> There actually already are non-Product Change proposals queued; dealing with them reasonably timely would make sense I think.
19:32:19 <nirik> (well, they could anytime I guess)
19:33:02 <dgilmore> I really don't think it hurts to have the Change request to have considerations for products
19:33:15 <dgilmore> i.e. they expect to to effect one product only
19:33:49 <dgilmore> or its a more wide reaching change and will effect all
19:33:50 <mitr> Structurally I think the current Change process is quite fine; the existence of product WGs would make "self-contained" (within a Product) Changes more frequent, with FESCo acking them by default, which is what we want anyway.
19:34:31 <mitr> As for expanding them to QA/releng/websites, no opinion.
19:34:46 <nirik> the only thing we might adjust is perhaps if a change is 'product specific' (new type), it just goes to that WG to get discussed/approved and we ack it like any selft contained.
19:34:56 <t8m> mitr, is within a product really self-contained? shouldn't it be approved by a product wg
19:35:07 <t8m> nirik, +1
19:35:20 <mitr> t8m: "self-contained" = "everyone affected by the Change is involved in doing it".
19:36:04 <abadger1999> nirik, t8m: +1
19:36:09 <t8m> mitr, but within product != "everyone affected by the Change is involved in doing it"
19:36:18 <t8m> necessarily
19:36:20 <notting> From reading the ticket, what would be a "blocks fedora.next" change? We haven't had things denoted that way on the past, even if they end up that way in practice
19:36:21 <mitr> t8m: yes
19:36:25 <mitr> t8m: So I would expect them to be self-contained, and we would probably want to exercise more restraing in overruling the WGs - but we do want even intra-WG Changes to be announced to _everyone_ on -devel.
19:36:38 <t8m> yes
19:36:40 <nirik> yep
19:36:47 <nirik> I think that part of things has worked well.
19:36:51 <mitr> notting: that's unclear to me as well.
19:37:12 <abadger1999> nirik: going to be interesting for a little while though -- we're going to have changes that are part of product development that affect packages not in any official product at first.
19:37:26 <abadger1999> but we'll figure that out as we go along.
19:37:30 <nirik> yeah.
19:37:38 <nirik> as we always do... muddle along as best we can.
19:37:41 <mitr> abadger1999: s/at first/always/
19:38:09 <abadger1999> mitr: I think eventually we might figure out a way to have alternative repositories to draw from.
19:38:29 <abadger1999> but... that's a contingency plan for another discussion ;-)
19:38:31 <mitr> abadger1999: Maintainers of these repositories will still need to be told about changes.
19:38:41 <dgilmore> notting: something like the anaconda re-write that blocks the whole release
19:38:55 <t8m> #proposal defer to next week
19:39:45 <mitr> Proposal: Open up F21 for ordinary Change proposals _now_, and continue the conversation about adapting the process for .next in the mean time.
19:40:01 <dgilmore> mitr: +1
19:40:06 <notting> mitr: +1
19:40:09 <pjones> mitr: sure, we can take proposals any time, +1
19:40:16 <pjones> the question is when we can accept them :P
19:40:30 <t8m> mitr, +1
19:40:33 <nirik> sure. I thought we were already open as we already approved some. :)
19:40:42 <mitr> pjones: I meant "start FESCo acking/naking them now", to be clear.
19:41:20 <drago01> I somehow doubt this "everything is different we can't do anything" thing ... because I doubt that for f21 stuff will be *that* different
19:41:25 <abadger1999> +1
19:41:35 <mitr> (Note that this does not come with a proposed submission deadline; we can set one up later as well.)
19:41:36 <pjones> mitr: and by "ordinary" you mean self-contained changes, or everything?
19:41:51 <t8m> mitr, are you +1 for yourself?
19:41:56 <abadger1999> drago01: +1. If we try to take too big of a step, we won't ever get an f21 out ;-)
19:41:58 <mitr> t8m: yes, for the record
19:42:06 <drago01> abadger1999: exactly
19:42:06 <pjones> (I'm actually +1 either way, but I'd like some clarity in the proposal.)
19:42:46 <t8m> #agreed Open up F21 for ordinary Change proposals _now_, and continue the conversation about adapting the process for .next in the mean time. (+6, -0, 0:0)
19:43:01 <mitr> pjones: I'd actually be fine with discussing absolutely everything now; I thought it would make sense to hold on with things that would obviously be affected by the Product-specific process changes (... which is I suppose unclear).
19:43:46 <t8m> #topic Next week's chair
19:43:54 <t8m> anybody wants it?
19:44:34 <nirik> I guess I've not done it for a bit...
19:45:38 <t8m> #action nirik will be the chair next week
19:45:44 <t8m> #topic Open floor
19:45:58 <t8m> Anything for open floor?
19:46:14 * nirik has nothing.
19:46:28 <mattdm> also nothing
19:46:29 <nirik> oh... did we want to come up with a new deadline for tech specs/docs from working groups?
19:47:07 <t8m> nirik, do you have some concrete date in mind?
19:47:54 <nirik> Mar 3rd?
19:48:48 <t8m> #proposal FESCo expects the Tech specs/docs from working groups by March 3rd.
19:49:22 <nirik> Or I guess we could just say "as soon as possible"... dunno what works best.
19:49:30 <nirik> +1
19:49:33 <t8m> +1
19:49:44 <notting> +1
19:49:51 <abadger1999> +1
19:50:02 <abadger1999> and +1 to the asap comment too ;-)
19:50:07 <mitr> +1
19:50:24 <dgilmore> +1
19:50:37 <mattdm> +1 to both
19:50:38 <t8m> #agreed FESCo expects the Tech specs/docs from working groups by March 3rd at the latest (+7, -0, 0:0)
19:51:05 <nirik> will someone tell all the liasons that?
19:51:16 * pjones +1
19:51:30 <t8m> I'd expect the liaisons to read the FESCo meeting minutes :)
19:52:32 <nirik> how about we update the ticket for weekly reports? as they are all on it. ;)
19:52:50 <t8m> nirik, OK, I can do that
19:52:56 <nirik> cool. thanks
19:53:08 <t8m> #action t8m will update the weekly reports ticket with this request
19:53:31 <t8m> if nothing else comes up in a minute I'll close the meeting.
19:55:10 <t8m> #endmeeting
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--- End Message ---
