===================================
#fedora-meeting: FESCO (2012-08-20)
===================================
Meeting started by mjg59 at 17:02:31 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2012-08-20/fesco.2012-08-...
.
Meeting summary
---------------
* init process (mjg59, 17:02:37)
* #888 F18 Feature: UEFI Secure Boot -
https://fedoraproject.org/wiki/Features/SecureBoot (mjg59, 17:05:17)
* AGREED: close, no longer a fesco issue (mjg59, 17:14:24)
* #934 Exception request F18 Feature: rngd default-on -
https://fedoraproject.org/wiki/Features/rngd_default_on (mjg59,
17:14:30)
* AGREED: exception granted for rngd default-on (+1 9, 0 0, -1 0)
(mjg59, 17:18:09)
* #937 Fedora 18 Feature Freeze Exception: Simplified crash
reporting via ABRT Server -
https://fedoraproject.org/wiki/Features/SimplifiedCrashReporting
(mjg59, 17:18:14)
* AGREED: - exception granted for ABRT improvements (+1 7, 0 0, -1 0)
(mjg59, 17:23:51)
* #938 Fedora 18 Feature Freeze Exception: GNOME 3.6 -
https://fedoraproject.org/wiki/Features/Gnome3.6 (mjg59, 17:24:00)
* AGREED: exception granted for GNOME 3.6 (+1 7, 0 0, -1 0) (mjg59,
17:25:28)
* AGREED: non-persistent service permission grant should be reworded
(mjg59, 17:33:47)
* #932 F18 Features - progress at Feature Freeze (mjg59, 17:36:52)
* LINK:
https://fedorahosted.org/fesco/ticket/932#comment:4 is the
updated list (mjg59, 17:38:52)
* AGREED: Happy with current state of feature process (mjg59,
17:50:16)
Meeting ended at 18:30:41 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* mjg59 (108)
* limburgher (44)
* nirik (40)
* mitr (37)
* pjones (32)
* notting (22)
* jwb (17)
* zodbot (10)
* jreznik (8)
* gholms|pto (6)
* hpa (6)
* dwa (4)
* kushal (2)
* sgallagh (1)
* abadger1999 (1)
* Southern_Gentlem (1)
* mmaslano (0)
* t8m (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`:
http://wiki.debian.org/MeetBot
17:02:31 <mjg59> #startmeeting FESCO (2012-08-20)
17:02:31 <zodbot> Meeting started Mon Aug 20 17:02:31 2012 UTC. The chair is mjg59.
Information about MeetBot at
http://wiki.debian.org/MeetBot.
17:02:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:02:35 <notting> limburgher: game time?
17:02:36 <mjg59> #meetingname fesco
17:02:36 <zodbot> The meeting name has been set to 'fesco'
17:02:36 <mjg59> #chair notting nirik mjg59 mmaslano t8m pjones mitr limburgher jwb
17:02:36 <zodbot> Current chairs: jwb limburgher mitr mjg59 mmaslano nirik notting
pjones t8m
17:02:37 <mjg59> #topic init process
17:02:40 * notting is here
17:02:42 * limburgher here
17:02:43 <pjones> morning.
17:02:46 * nirik is here.
17:02:57 <mitr> Hello
17:03:07 <mjg59> jwb: Here?
17:03:11 * hpa is lurking
17:03:32 <mjg59> I think mmaslano said she'd be on holiday?
17:03:38 <limburgher> I seem to recall such.
17:03:58 <mjg59> And t8m, maybe?
17:04:11 <jreznik> mjg59: yep, she's on holiday
17:04:35 <jreznik> t8m is not available today too if I remember it correctly
17:05:02 <jwb> mjg59, i am, sorry
17:05:07 <mjg59> Ok, cool
17:05:13 <mjg59> So, followups:
17:05:17 <mjg59> #topic #888 F18 Feature: UEFI Secure Boot -
https://fedoraproject.org/wiki/Features/SecureBoot
17:05:20 <mjg59> .fesco 888
17:05:22 <zodbot> mjg59: #888 (F18 Feature: UEFI Secure Boot -
https://fedoraproject.org/wiki/Features/SecureBoot) – FESCo -
https://fedorahosted.org/fesco/ticket/888
17:05:32 <mjg59> I think we're still waiting on the board for this
17:05:48 <nirik> do we even need this open? or was there something more for fesco
here?
17:05:58 <pjones> What, exactly, are we waiting for?
17:06:00 <jwb> not fesco, no
17:06:13 <mjg59> Yeah, fair enough
17:06:17 <mjg59> I'll close this, then
17:06:21 <nirik> I think there were questions to the board if XYZ would meet their
requests
17:06:44 <limburgher> KK.
17:06:46 <mjg59> Ok. How about we go through the exception requests and things
first, and feature freeze progress at the end?
17:07:05 <limburgher> <nod>
17:07:06 <mitr> I'd prefer keeping this open - AFAICS it's undecided whether
we will be able to do this for F18, and the rel-eng impact is non-trivial and perhaps woth
tracking?
17:07:33 <mitr> OTOH "leave it to rel-eng" works as well, the contingency
plan is probably not very risky
17:07:42 <mjg59> mitr: We're doing it for F18 unless the board explicitly says
we're not
17:07:43 <pjones> mitr: care to make a comment to that effect on trac so that next
time this comes up we remember why it's there?
17:07:46 <mjg59> I don't think it's a fesco issue
17:08:41 <notting> as much as fesco is oversight for eng/qa/releng, it is. but not
without specific items that require fesco to intervene there
17:08:59 <mjg59> Moving on, unless anyone has anything else on this?
17:09:18 <mitr> mjg59: Is my reading of "the board would be illing to approve
if ..." as an implicit prohibition incorrect?
17:09:29 <mjg59> mitr: It's not something the board needs to approve
17:09:55 <mjg59> mitr: It's something the board can prohibit in the sense that
they're in a position of oversight over everyone else in the project
17:10:21 <nirik> I think feature owners will work with the board to implement it in
a way that they will approve of it...
17:10:40 <mjg59> mitr: But the board don't need to say yes, they merely need not
to say no
17:10:41 <nirik> if thats not done in time or causes too much issue, we can bring it
back up in fesco?
17:11:09 <mjg59> nirik: I think we'd bring it back to fesco if there's
anything relevant to fesco
17:11:20 <mjg59> The contingency plans are clear
17:11:22 * nirik nods.
17:11:44 <mitr> mjg59: I'm mostly concerned about timing - this should really be
settled by beta. Intuitively, having a ticket open to track that this "needs to
happen" seems right, OTOH that ticket is not directly associated with any action,
so... meh
17:11:56 <mjg59> mitr: Well, it's the same as any other feature
17:12:02 <mjg59> If it's not finished in time, it's not finished in time
17:12:17 <mitr> fair enough
17:12:28 <nirik> yeah, we don't normally have tickets pending for each
feature...
17:12:40 <pjones> The worst case is exactly the same as having done nothing, so if
it doesn't make it, the contingency solves itself.
17:12:52 <pjones> (it's just awful is all.)
17:13:25 <mjg59> So I'll close this for now?
17:13:35 * nirik thinks thats best...
17:13:39 <mitr> ok
17:14:08 <limburgher> Least worst.
17:14:24 <mjg59> #agreed close, no longer a fesco issue
17:14:30 <mjg59> #topic #934 Exception request F18 Feature: rngd default-on -
https://fedoraproject.org/wiki/Features/rngd_default_on
17:14:34 <mjg59> .fesco 934
17:14:35 <zodbot> mjg59: #934 (Exception request F18 Feature: rngd default-on -
https://fedoraproject.org/wiki/Features/rngd_default_on) – FESCo -
https://fedorahosted.org/fesco/ticket/934
17:14:46 <mjg59> I spoke to hpa about this and all my concerns were dealt with, so
I'm +1
17:14:56 <jwb> mine as well, so +1
17:15:00 <pjones> likewise, +1
17:15:09 <mitr> +1 - it's kind of sad that the kernel can't do this
internally, but that's what it is...
17:15:15 * nirik was +1 last time I think... again, I don't like adding default
running stuff, but... oh well.
17:15:16 <mjg59> And we're +3 in the ticket
17:15:36 <hpa> mitr: some pressure from distros might allow that path to be
optionally enabled
17:15:59 <mjg59> limburgher ?
17:16:11 <mitr> One concern that popped up around here is that rngd should ideally
be started earlier than the random encryption key for swap is generated - OTOH running
rngd at all is a clear improvement
17:16:14 <hpa> mitr: for the lack of "customer" demand, it's not going
to happen
17:16:30 <hpa> mitr: yes, the earlier it is started the better
17:17:07 <mitr> hpa: Looking at the comments in
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f...
... would distro demand override that?
17:17:44 * mjg59 wonders where limburgher got to
17:17:45 <limburgher> +1
17:17:47 <mjg59> Cool
17:18:09 <mjg59> #agreed exception granted for rngd default-on (+1 9, 0 0, -1 0)
17:18:14 <mjg59> #topic #937 Fedora 18 Feature Freeze Exception: Simplified
crash reporting via ABRT Server -
https://fedoraproject.org/wiki/Features/SimplifiedCrashReporting
17:18:15 <hpa> mitr: I don't know. I can tell you that without distro demand it
won't happen.
17:18:18 <mjg59> .fesco 937
17:18:20 <zodbot> mjg59: #937 (Fedora 18 Feature Freeze Exception: Simplified crash
reporting via ABRT Server -
https://fedoraproject.org/wiki/Features/SimplifiedCrashReporting) – FESCo -
https://fedorahosted.org/fesco/ticket/937
17:18:28 * hpa disappears
17:18:40 <nirik> thanks hpa
17:19:02 <mjg59> So this is already deployed and in F18
17:19:06 <limburgher> Pretty close, what's left?
17:19:23 <mjg59> Unclear
17:19:33 <mjg59> So given that it's done, I can't see any reason not to
grant
17:19:36 <limburgher> Maybe it should be 100%
17:19:38 <limburgher> ?
17:19:40 <mitr> +1
17:19:43 <limburgher> +1
17:19:50 <mjg59> +1
17:19:56 <nirik> +1 if it's done I suppose. any improvemts on abrt welcome
17:20:00 <mitr> Note that this does change the developer experience significantly -
no backtraces with variable values any more.
17:20:22 <notting> +1. it also implies that it's not reporting to bugzilla any
more?
17:20:39 <jwb> +1 i guess
17:20:44 <mitr> notting: reportedly the stand-alone server will forward to bugzilla
17:21:10 <mitr> forward agglomareted data, that is
17:21:19 <jreznik> and hopefully no dupes any more...
17:21:44 <mjg59> pjones: ?
17:21:50 <mitr> We'll see how it goes...
17:22:22 <limburgher> jreznik: From your client to root's client. . .
17:22:51 <pjones> yeah, I'm +1
17:23:51 <mjg59> #agreed - exception granted for ABRT improvements (+1 7, 0 0, -1
0)
17:24:00 <mjg59> #topic #938 Fedora 18 Feature Freeze Exception: GNOME 3.6 -
https://fedoraproject.org/wiki/Features/Gnome3.6
17:24:03 <mjg59> .fesco 938
17:24:04 <zodbot> mjg59: #938 (Fedora 18 Feature Freeze Exception: GNOME 3.6 -
https://fedoraproject.org/wiki/Features/Gnome3.6) – FESCo -
https://fedorahosted.org/fesco/ticket/938
17:24:05 <mjg59> +1
17:24:11 <pjones> +1
17:24:13 <limburgher> +1
17:24:22 <nirik> yeah, +1, seems just a clerical error. ;)
17:24:23 <jwb> +1
17:24:27 <mitr> +1
17:24:38 <notting> +1
17:25:28 <mjg59> #agreed exception granted for GNOME 3.6 (+1 7, 0 0, -1 0)
17:25:34 <mjg59> #936 Clarify non-persistent service permission grant
17:25:34 <mjg59> .fesco 936
17:25:36 <zodbot> mjg59: #936 (Clarify non-persistent service permission grant) –
FESCo -
https://fedorahosted.org/fesco/ticket/936
17:26:29 <mjg59> I think talking about the network here was pretty clearly intended
to mean *listening* to the network
17:26:35 <mjg59> So I've no objection to clarifying this
17:26:50 <notting> yes, that works for me
17:26:55 <nirik> yeah.
17:27:00 <limburgher> Dittto
17:27:05 * nirik is happy to add wording to note listening...
17:27:22 <pjones> likewise, I'm okay with that.
17:27:25 <jwb> sure
17:28:18 <nirik> thats the proposal in comment #6?
17:28:42 <mjg59> Yeah
17:28:48 <mjg59> mitr: You agree with that?
17:29:22 <mitr> I have some trouble thinking of an useful example covered by this
case - as mentioned in the ticket, even if cloud-init technically fulfilled the suggested
criteria it shouldn't run by default IMHO.
17:29:55 <mitr> OTOH, in practice it was up to maintainers without any explicit
FESCo oversight whether to start services by default or not, so relaxing the rules to be
closer to the earlier state is fine with me.
17:30:33 <mjg59> Ok, so:
17:30:58 <mitr> (re: useful example: if it can't listen, it can only initiate
the connection, and if it must not require configuration, what does it connect to?)
17:31:09 <Southern_Gentlem> noname64
17:31:31 <mjg59> #proposal reword the requirements to indicate that network access
is acceptable, but not network listening
17:31:37 <mjg59> Southern_Gentlem: That's a dreadful password
17:32:03 <mjg59> Any objections to that?
17:32:13 <nirik> +1 here.
17:32:23 <mitr> +1.
17:32:34 <notting> +1
17:32:42 <limburgher> +1
17:32:45 <mjg59> +1
17:32:51 <jwb> +1
17:33:24 <mjg59> pjones: ?
17:33:26 <mitr> How much do we care about "full installs" /
"stateless images" that contain a lot of software, not all necessarily used? Do
we want to particularly emphasize that "installing a package" does not
necessarily mean that the actual user wants to use it? (or perhaps the other way, assume
that installing a package does convey such an intent?)
17:33:33 <pjones> +1
17:33:47 <mjg59> #agreed non-persistent service permission grant should be reworded
17:33:54 <mjg59> Anyone want to take responsibility for doing that?
17:34:02 <pjones> mitr: that's /always/ been the assumption before
17:34:32 <mitr> pjones: which "that"?
17:34:35 <pjones> though it's a little tricky to assume intent (either way) in
the face of our constant dependency expansion
17:34:53 <pjones> mitr: we've always assumed that having it installed means you
intend to use it
17:35:02 <notting> well, the preset policy changes that, some
17:35:07 <pjones> yes.
17:35:46 <mitr> pjones: I was thinking it's always been the opposite,
interesting.
17:36:00 <pjones> huh.
17:36:22 <pjones> Well, the thing about assumptions.
17:36:51 <mjg59> Ok
17:36:52 <nirik> shall we move on?
17:36:52 <mjg59> #topic #932 F18 Features - progress at Feature Freeze
17:36:52 <mjg59> .fesco 932
17:36:53 <pjones> Anyway, I think given how we tend to have things packaged such
strictness is probably outdated anyway
17:36:54 <zodbot> mjg59: #932 (F18 Features - progress at Feature Freeze) – FESCo -
https://fedorahosted.org/fesco/ticket/932
17:37:35 <mjg59> So we have a new list
17:37:39 <abadger1999> From FPC side, it's always been the opposite...
17:38:22 <mjg59> Which of these do we think are especially concerning?
17:38:52 <mjg59>
https://fedorahosted.org/fesco/ticket/932#comment:4 is the updated
list
17:38:55 <mitr> initial experience, package groups - interact with the larger F18
installer changes?
17:39:57 <mjg59> mclasen just got back from PTO so probably hasn't updated this
17:39:57 <notting> package groups has landed in both yum and anaconda, it's just
not built yet in anaconda (unless anaconda was built sometime between last friday and
now)
17:40:55 * sgallagh is around to discuss KRB5 DIR if needed
17:41:02 * nirik notes some owncloud stuff passed review last night.
17:41:28 <jreznik> mjg59: yep, he replied, he's going to update it once he
collects info...
17:41:38 <mjg59> It looks like there's some stuff here which might not land, but
it doesn't seem obvious that there's anything that's destined to fail and
which will hit anyone else in the process
17:41:52 <mjg59> So I'm inclined to say that things are going ok at the moment?
17:42:06 <mitr> seems so to me as well
17:42:12 <jwb> i don't think the PPC items even need to be listed
17:42:32 <jwb> i mean, good for them for following the feature process, but...
17:43:04 <nirik> yeah, most of the things still in this state are kind of
standalone...
17:43:36 <jreznik> jwb: it's quite important feature for desktop on ppc64...
17:43:53 <mjg59> jreznik: Which isn't a primary arch?
17:44:03 <jreznik> mjg59: you're right
17:44:07 <jwb> jreznik, great. are they releasing in lock-step with the primary
arch? if not, then it doesn't matter in the slightest how far they are along
17:44:37 <jwb> again, good for them and i commend them for filing, but it isn't
a fesco concern
17:45:56 <nirik> so, any of the features we want to drop at this point? or ?
17:46:04 <mjg59> I'm inclined to leave them all at this point
17:46:07 <nirik> sugar at 0% is pretty worrysome...
17:46:24 <mjg59> Yeah, I'd imagine that that'll need at least an exception
17:46:33 <jreznik> nirik: I talked to pbrobinson, he promised to update it by Monday
but...
17:46:35 <mjg59> But if we drop it then there's just no sugar update, so, eh
17:46:37 <jwb> aside from sugar, the rest seem fine
17:46:37 <limburgher> Can that be accurate?
17:46:43 <jreznik> he believes he can make it with exception granted
17:47:03 <nirik> ok... I look forward to seeing the request. ;)
17:47:41 <mitr> Well, if we drop it, then it isn't a feature, that doesn't
necessarily mean that it doesn't get done - only the freeze policies are a real
restriction
17:47:47 <mjg59> Yeah
17:48:08 <pjones> yeah, I don't think we really need to drop it at this point if
he still thinks he can make it
17:48:16 <mjg59> Anyone object to just noting that this is the current state of
everything and that we're not too concerned yet?
17:48:34 <mitr> So the real concern is "will it get tested", and, well...
17:48:47 <mitr> No, sounds reasonable.
17:49:16 * nirik is ok with that for now.
17:49:41 <limburgher> Ok for leave nodes, for sure.
17:49:59 <limburgher> s/leave/leaf/
17:50:11 <limburgher> Sorry for my broken English, I'm an American.
17:50:16 <mjg59> #agreed Happy with current state of feature process
17:50:18 <mjg59> Ok
17:50:26 <mjg59> .topic Open Floor
17:50:39 <mjg59> Anyone have anything they'd like to bring up?
17:51:04 <limburgher> Did anyone see
https://fedorahosted.org/fpc/ticket/204 besides
me?
17:51:19 <limburgher> We don't have a Trac for it just, but I thought I'd
mention it.
17:51:46 <mjg59> Ugh that looks pretty awful
17:52:03 <pjones> yeah, it really does
17:52:09 <notting> limburgher: given that it's a fpc ticket, no, i didn't
see it
17:52:12 <nirik> I asked him not to do that... but then the owner of the other repo
said they updated and it should be fine.
17:52:25 <mitr> What does "renamed or of a higher release than upstream"
mean?
17:52:28 <mjg59> So there are components being pushed into F17 which are of a
greater version than a third party repo, and he's only doing it piecemeal rather than
having the entire stack ready?
17:52:36 <limburgher> notting: No, but it was on the packaging list too, I think.
17:52:40 <mjg59> mitr: I assume that upstream have their own third party repo
17:53:00 <jwb> limburgher, there's a packaging list?
17:53:09 <mjg59> nirik: Did you get a response from him?
17:53:37 <limburgher> jwb: there is, and It wasn't on it. My mistake.
17:53:44 <nirik> yes, he seemed to agree not to do that... but as I said, the other
upstream/3rdparty repo guy said they updated and it wouldn't matter anymore... so
perhaps thats why he resumed.
17:54:04 <nirik> I don't understand why you would want to push them one at a
time anyhow personally.
17:54:11 <limburgher> Ok, so it may not even be our issue yet.
17:54:27 <mitr> In general I don't think third-party repos should block any
packaging work in Fedora
17:54:30 <notting> nirik: i suspect it's either that or maintain a forest of
build overrides.
17:54:38 <limburgher> nirik: Right, I mean what if you got 75% percent of the way
through and found out it wasn't do-able? You'd have a pile of unusable stuff out
there.
17:54:38 <pjones> mitr: yeah, pretty hard to argue that they should
17:54:47 <limburgher> mitr: Agreed.
17:54:58 <mjg59> mitr: I agree, but if you're pushing stuff into stable then you
should be doing it for good reason
17:55:04 <nirik> notting: sure, but is that really that much harder than doing that
and updates?
17:55:21 <mitr> mjg59: "i just packaged this awesome tarball" is generally
a good enough reason, when the package in question wasn't in the distribution before.
17:55:23 <mjg59> mitr: If you're providing a subset of components that are only
useful when used with a third party repo, you shouldn't be breaking that
17:55:35 * nirik also would personally build it in rawhide first, then go back to stable
releases. But perhaps thats just me
17:55:45 <limburgher> nirik: No. :)
17:55:48 <notting> nirik: it's probably less documented. but i would still
recommend against piecemeal pushing, yes.
17:56:12 <mitr> There are the end users to think about - is there some kind of yum
magic upstream could recommend to their users so that the Fedora packages would be
excluded for users that want to use the upstream repo?
17:56:13 <nirik> mitr: there's no hard guideline against it, but it would seem
like it would alienate your users...
17:56:43 <limburgher> mitr: Not viable, if the 3rd party RPMs have Fedora Requires.
. .
17:56:52 <pjones> mitr: yes - the magic is "you should be maintaining your
packages in fedora if possible"
17:56:59 <notting> mitr: i can't even find the repo in question, but i may be
looking in the wrong place.
mate-desktop.org seems to just have arch/debian/ubuntu
17:57:04 <limburgher> pjones: BLASPHEMY!
17:57:07 <notting> mitr: oh how cute. random dropbox URL.
17:57:24 <pjones> limburgher: then I guess I'll burn :)
17:57:37 <nirik> notting: yes, it's a dropbox url. ;)
17:57:57 <mitr> While I'm generally concerned about various interpersonal
conflicts that seem to appear around mate at an alarming rate, I'm not sure that there
is anything we can or should do in this case.
17:57:58 <limburgher> pjones: Only if you weigh the same as a duck.
17:58:02 <nirik> anyhow, if you like I can try and talk with him again... or we
could ask rdieter (his sponsor) to do so...
17:58:06 <pjones> limburgher: howard?
17:58:32 <limburgher> pjones: I assume any duck would suffice for this purpose.
17:58:37 <limburgher> mitr: Well put.
17:59:00 <pjones> mitr: +1
17:59:08 <mjg59> Yeah, I don't think there's anything we should explicitly
do here
17:59:15 <nirik> I suppose it comes down to: should we ask him not to push parts of
the stack to stable before the entire thing is done, or do we want to not micromanage or
dictate that?
17:59:19 <notting> pjones: howard is from cleveland, and we do know that some things
from cleveland are more flammable than you may expect.
17:59:38 <mjg59> I think this is inconsiderate behaviour, and it's not a good
indicator that it'll be well maintained when it's complete
17:59:38 <limburgher> mjg59: Fine by me, I just wanted to make sure we were all
aware.
17:59:39 <pjones> notting: just the lake and the river, right?
17:59:59 <kushal> jokes are going above my head :(
18:00:20 <mjg59> But it's not breaching any rules we've put in place and
it'd be difficult to work out how to forbid this without also forbidding more
reasonable breakage of third-party repositories
18:00:22 <limburgher> kushal: Sorry, Monty Python and the Holy Grail, the Howard
the Duck.
18:00:22 <notting> i'm fine with telling him "you may not want to do it
this way" ,but unsure whether that needs done with the Voice Of FESCo
18:00:23 <pjones> nirik: we could... send him a polite note saying that his package
management style is unusual?
18:00:34 <limburgher> notting: <nods>
18:00:39 <mjg59> nirik: I think if you talk to him and rdieter, that'd be fine
18:00:51 <kushal> limburgher, thanks for the hints
18:00:58 <limburgher> kushal: NP.
18:01:05 <nirik> sure, I'll ask them again... as a suggestion.
18:02:29 <mjg59> Ok, sounds good
18:02:42 <gholms|pto> What happened with the cloud-init ticket? Any questions I can
answer (albeit on a phone keyboard)? My plane just touched down, so I missed that
conversation. :-\
18:04:04 <mjg59> gholms|pto: No, rewording the requirements was approved
18:04:14 <mjg59> gholms|pto: Although there's still some concern about whether
enabling it by default is a good idea
18:04:40 <gholms|pto> Understood. Anything I can do to help address that?
18:05:24 <mjg59> mitr: ^
18:07:05 <mitr> gholms|pto: see
https://fedorahosted.org/fesco/ticket/936#comment:6
18:07:31 <mitr> I'm going just bu what somebody else posted on a mailing list,
it might not be accurate.
18:07:52 <gholms|pto> Ok. I can respond in the ticket.
18:07:59 <gholms|pto> Tjanks, all
18:08:05 <gholms|pto> *Thanks
18:08:17 * gholms|pto boards another plane
18:08:21 <dwa> I've got one quick note, re. what jwb said about PPC features. We
(fedora for power) had been asked to follow the feature process as closely as possible, so
if that's something that fesco finds annoying/unnecessary it's probably worth a
discussion with dgilmore & I to see what fesco wants from secondary arches who have
features that (might) impact primary in some way.
18:09:09 <jwb> there's nothing wrong with what you've done. i simply said
it making release or not wasn't a fesco concern at this point
18:09:36 <limburgher> dwa: It's always good for us to be aware of that sort of
thing.
18:10:11 <nirik> perhaps something else to consider in a features rework world...
18:10:20 <dwa> jwb: limburgher: nod. and we are trying to stick to primary's
schedule especially for Features vs. arch-specific bugfixes.
18:10:22 <nirik> seperate out or note differently the secondary arch features.
18:12:00 <mitr> nirik: I think that will be usually automatically handled by
treating "self-contained" features in a light-weight way.
18:12:11 <nirik> yeah, quite possible
18:12:41 <dwa> nirik: also probably worth contemplating how much fesco cares about
features that are mostly secondary-arch specific but have the potential to impact primary
as well
18:12:56 <nirik> sure
18:13:40 * dwa is done
18:13:44 <mjg59> Anything else?
18:14:12 <nirik> chair for next week?
18:14:36 <pjones> A bunch of us probably won't make it next week - lots of
flying to san diego
18:14:39 <mjg59> I'm going to be out next week
18:14:50 <pjones> (and the week after that is a US holiday)
18:14:56 <notting> i can chair next week
18:15:08 <nirik> will we have quorum? I should be around.
18:15:22 <jwb> i may or may not be around
18:15:35 <limburgher> I should be here next week, not the following.
18:16:50 <mitr> I won't be here next time.
18:18:08 <notting> that's three definitely out, and one maybe
18:19:50 <notting> limburgher: whatever happened with the potential reschedule?
18:21:22 <limburgher> notting: Thanks! I completely forgot!
18:21:31 <limburgher> We had one time we all said we could make it.
18:21:49 <pjones> And it was?
18:22:39 <limburgher> Sorry, fetching. :)
18:22:54 <limburgher> 1700 UTC.
18:22:59 <limburgher> On wednesdays
18:23:29 <nirik> so that would be the day after all our deadlines instead of the day
before... but sure.
18:23:38 <mjg59> So 1300 EDT?
18:23:44 <jwb> yes
18:23:57 <pjones> Well, okay.
18:23:57 <mjg59> Sure, that works
18:24:19 <pjones> I still won't make next week, but that's nice in general
as it has less US holiday collision chances
18:24:27 <notting> do we want to do wednesday?
18:24:30 <mjg59> Yeah, I'll still also be out
18:24:32 <limburgher> So next meeting is 29th at 1700 UTC?
18:24:36 <jwb> if we move to wed next week, i'll definitely be out
18:24:46 <notting> yeah, i'm conferencing then too
18:25:09 <mjg59> So maybe skip next week?
18:25:48 <pjones> yeah, we could make the next meeting Sept 5
18:25:54 <limburgher> 9/5? Ok.
18:26:14 <mjg59> Works for me
18:26:21 <mjg59> Any objections?
18:26:25 <mjg59> And who's going to chair?
18:26:29 <notting> i can
18:26:39 <mjg59> Great
18:27:27 <mjg59> Anything else?
18:27:35 <mjg59> If not I'll close in 3 minutes
18:30:39 <mjg59> Ok, thanks everyone
18:30:41 <mjg59> #endmeeting
--
Matthew Garrett | mjg59(a)srcf.ucam.org