1:26 p.m.
Following is the list of topics that will be discussed in the FESCo
meeting tomorrow at 19:30UTC (3:30pm EDT) in #fedora-meeting on
irc.freenode.net.
= Followups =
#topic Updates policy
#351 Create a policy for updates - status report on implementation
https://fedorahosted.org/fesco/ticket/351
#382 Implementing Stable Release Vision
https://fedorahosted.org/fesco/ticket/382
#topic #467 Make Feature Freeze happen sooner.
https://fedorahosted.org/fesco/ticket/467
= New business =
#topic #473 new meeting time (redux)
https://fedorahosted.org/fesco/ticket/473
#topic #472 About Mozilla's decision to not allow using the system's libvpx
https://fedorahosted.org/fesco/ticket/472
= Fedora Engineering Services tickets =
https://fedorahosted.org/fedora-engineering-services/report/6
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic.
kevin
4:20 p.m.
New subject: Summary/Minutes for today's FESCo meeting (2010-10-05)
===================================
#fedora-meeting: FESCO (2010-10-05)
===================================
Meeting started by nirik at 19:30:01 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2010-10-05/fesco.2010-10-...
Meeting summary
---------------
* init process (nirik, 19:30:01)
* mclasen will not be able to attend today due to a backhoe incident.
(nirik, 19:30:48)
* cwicket will also be unable to attend. (nirik, 19:30:59)
* kylem is also unable to attend. (nirik, 19:31:13)
* #473 new meeting time (redux) (nirik, 19:33:54)
* LINK: https://fedorahosted.org/fesco/ticket/473 (nirik, 19:33:54)
* ACTION: make sure cwickert is updated, revisit next week. (nirik,
19:46:09)
* reminder: you can vote in tickets if unable to attend the meeting.
(nirik, 19:46:22)
* Updates policy / Vision implementation status (nirik, 19:46:48)
* ideas wanted to improve stable N-1 wording/distinction. (nirik,
19:57:04)
* LINK: http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs
<-- only shows formatting rules, so some recommendations for their
content might be nice. (gholms, 20:08:46)
* AGREED: will asking testers/qa to be on the lookout for things not
following the update_policy and notify us via a ticket for further
discussion. (nirik, 20:09:54)
* AGREED: will see if FPC is willing/able to expand on the changelog
guidelines. (nirik, 20:12:47)
* #472 About Mozilla's decision to not allow using the system's libvpx
(nirik, 20:14:40)
* LINK: https://fedorahosted.org/fesco/ticket/472 (nirik, 20:14:40)
* LINK: https://fedorahosted.org/fesco/ticket/472 (nirik, 20:30:41)
* AGREED: will vote on proposals in ticket. (nirik, 21:05:11)
* Open Floor (nirik, 21:05:43)
* LINK: https://fedorahosted.org/rel-eng/ticket/4149 (gholms,
21:07:13)
Meeting ended at 21:18:39 UTC.
Action Items
------------
* make sure cwickert is updated, revisit next week.
Action Items, by person
-----------------------
* cwickert
* make sure cwickert is updated, revisit next week.
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* nirik (145)
* pjones (69)
* mjg59 (56)
* notting (39)
* gholms (31)
* ajax (23)
* hicham (22)
* abadger1999 (17)
* spot (10)
* Oxf13 (10)
* zodbot (8)
* mdomsch (8)
* mcepl (1)
* rdieter (1)
* SMParrish (0)
* kylem (0)
* mclasen (0)
* cwickert (0)
--
19:30:01 <nirik> #startmeeting FESCO (2010-10-05)
19:30:01 <zodbot> Meeting started Tue Oct 5 19:30:01 2010 UTC. The chair is nirik.
Information about MeetBot at http://wiki.debian.org/MeetBot.
19:30:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:30:01 <nirik> #meetingname fesco
19:30:01 <zodbot> The meeting name has been set to 'fesco'
19:30:01 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert
mjg59
19:30:01 <nirik> #topic init process
19:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik
notting pjones
19:30:06 * notting is here
19:30:36 * ajax waves
19:30:48 <nirik> #info mclasen will not be able to attend today due to a backhoe
incident.
19:30:56 * pjones throws a trout at ajax
19:30:59 <nirik> #info cwicket will also be unable to attend.
19:31:12 <gholms> A backhoe incident? Ouch.
19:31:13 <nirik> #info kylem is also unable to attend.
19:31:21 <nirik> gholms: took out his home internet it seems.
19:31:30 <gholms> Ok, that's not *so* bad.
19:31:52 <notting> and kylem will not be here
19:32:19 <nirik> SMParrish: / mjg59: you guys here?
19:33:15 <mjg59> Afternoon
19:33:27 <nirik> Hello. :) Thats 5.
19:33:45 <nirik> Shall we start with meeting time?
19:33:54 <nirik> #topic #473 new meeting time (redux)
19:33:54 <nirik> https://fedorahosted.org/fesco/ticket/473
19:34:09 <nirik> has everyone updated their
http://whenisgood.net/ee8prq/results/z5binx entry?
19:34:15 <ajax> i have
19:34:25 * nirik 's didn't really change any
19:35:04 <nirik> so, currently we have 0 times everyone can attend. ;)
19:35:18 <pjones> yeah :/
19:35:22 <nirik> a few times with 1 person left out, but everyone else...
19:35:31 <pjones> and excluding one person doesn't really help that much
19:36:11 <nirik> I guess we need to confirm that everyone updated before we do
anything else?
19:36:24 <notting> although one of the times where mclasen is the only holdout his
update info says will become available in a couple of weeks
19:37:01 <nirik> oh?
19:37:12 <mjg59> Wait. I'm suddenly worried by the timezones here.
19:37:15 <nirik> wed 1-2?
19:37:17 <pjones> So can we move to that time and then hope that he can make do
responding to trac until then? sounds not that great.
19:37:27 <nirik> mjg59: yeah, the site is confusing.
19:37:28 <pjones> mjg59: yeah, the site's representation of timezones is weird.
19:37:30 <notting> nirik: 2-3 your time. unless i'm forgetting what your time
is
19:37:31 <nirik> I think it's in my local time.
19:37:39 <pjones> nirik: right.
19:37:41 <pjones> it's in mountain
19:37:49 <nirik> yeah.
19:38:04 <notting> nirik: he says 5-6PM e(d|s)t will become available for him in
mid-ocyt
19:38:06 <pjones> but on the individual pages you can set it to a different local
time.
19:38:10 <gholms> whenisgood allows you to set time zones.
19:38:54 <mjg59> notting: I don't think that actually helps
19:38:55 <nirik> I see 1-2my time on wed being just him unable to attend... so one
hour of that would work. (Althought thats sure late for you guys)
19:38:56 <pjones> notting: uh, pretty sure I didn't have 5-6pm EST5EDT selected
as okay
19:39:16 <pjones> (given that the meeting often takes two hours, I didn't select
anything after 3)
19:39:22 <notting> pjones: i may have been confusing the displayed TZ as PDT
19:40:18 <nirik> so, everyone here has updated? and I am pretty sure mclasen has and
I know kylem has.
19:40:30 <nirik> that leaves cwickert and SMParrish as unknowns?
19:40:49 <notting> SMParrish did
19:40:55 <notting> (mouse over their names)
19:41:09 <nirik> ah yes.
19:42:32 <nirik> so, make sure cwickert updated and then go from there? and/or ask
everyone else to doublecheck that they can't be available more times?
19:43:04 <mjg59> nirik: I've left the entire working day other than lunchtime
19:43:23 <mjg59> So I think I'm relatively unable to add more at this point :)
19:43:38 <nirik> tue 11-12 has either cwickert or kylem unavailable... if we do that
block they could both attend, just not for the entire time. ;)
19:44:27 <nirik> mjg59: yeah, mostly me too.
19:44:42 <notting> and, of course, we'll have elections in about a months time
19:44:46 <nirik> so, how much time is left in this term.
19:44:47 <nirik> yeah.
19:45:28 <nirik> so, let me make sure cwickert updated, and then see if we can get
any times then? revisit next week?
19:45:42 <mjg59> Ok
19:45:59 <nirik> any objections?
19:46:08 <ajax> nope
19:46:09 <nirik> #action make sure cwickert is updated, revisit next week.
19:46:22 <nirik> #info reminder: you can vote in tickets if unable to attend the
meeting.
19:46:46 <nirik> ok, moving on.
19:46:48 <nirik> #topic Updates policy / Vision implementation status
19:46:48 <nirik> .fesco 351
19:46:48 <nirik> .fesco 382
19:46:49 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac -
https://fedorahosted.org/fesco/ticket/351
19:46:53 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac -
https://fedorahosted.org/fesco/ticket/382
19:46:59 <nirik> Our fun updates tickets. :)
19:47:09 <nirik> So, I have several things here:
19:48:11 <nirik> There was a suggestion made to add/clarify
https://fedoraproject.org/wiki/Updates_Policy about stable release N and stable release
N+1
19:48:29 <nirik> currently it's just "stable releases"
19:48:46 <nirik> do we want to specifically say N+1 should be treated any
differently than N ?
19:49:22 <nirik> Thoughts?
19:49:28 <ajax> i do, but the impression i got from the list was... disappointing
19:49:56 <nirik> what would we do differently?
19:50:28 <nirik> The suggestion I got was to say that N+1 should get 'less'
updates... but didn't say how.
19:50:33 <ajax> right.
19:51:04 <ajax> what i was hearing was "that doesn't make any sense",
which is just bizarre to me
19:51:07 <gholms> Should it?
19:51:23 <ajax> since all my experience says that eventually you stop being able to
fix things in place without massive upheaval
19:51:42 <ajax> so the amount that you _can_ fix in older releases naturally falls
off
19:51:50 * nirik nods.
19:52:09 <ajax> but apparently that's just, like, my opinion, man.
19:52:12 <pjones> yeah, that's pretty much how I see it as well
19:52:16 <nirik> not just yours... ;)
19:52:48 <nirik> so, is there any way to codify this into the policy aside from the
"The update rate for any given release should drop off over time, approaching zero
near release end-of-life." sentence?
19:53:17 <pjones> I hope so; I don't imagine a statement like that will have any
credence.
19:54:03 <ajax> yeah, i just can't think of a better way to word it
19:55:12 <nirik> updates to N+1 releases should only fix serious bugs or security
issues. updates to N releases could additionally fix more minor bugs if all the other
criteria are met?
19:55:20 <notting> ... surely you mean n-1
19:55:27 <nirik> right, sorry.
19:55:30 * nirik fails math
19:55:48 <pjones> notting: somehow I was assuming that the whole time without saying
anything. Yeah, obviously n-1
19:56:12 <nirik> anyhow, not sure we can/will decide this today. I guess I will ask
for more input from the people who asked for this and try and get a concrete wording.
19:57:04 <nirik> #info ideas wanted to improve stable N-1 wording/distinction.
19:57:31 <nirik> So, the next thing I had: we have an updates policy. Yea! What do
we want to do about enforcing/educating maintainers about it?
19:58:07 <gholms> Another round of package reviews! :P
19:58:12 * gholms runs
19:58:17 <nirik> riiiight.
19:58:46 <nirik> I was thinking a first easy step would be to ask proventesters to
look out for things that don't fit the stable release policy and bring them to our
attention.
19:59:02 <nirik> some things it's hard to tell though.
19:59:38 <nirik> some examples: dracut was updated in f12/13 with a bunch of
patches. Were those all bugfixes?
19:59:59 <pjones> if it's hard to tell, that means either a) we need to think
about how to make a generic exemplar of that case, or b) the packager needs to be telling
us more about the update
20:00:07 <nirik> NetworkManager rebases to a git snapshot in all of
f12/f13/f14/rawhide at the same time.
20:00:19 <pjones> And I think both of those are "b" there.
20:00:59 <nirik> right, so more education...
20:01:12 <mjg59> Ideally we'd have some means of identifying this
20:01:14 <pjones> (obviously, there could be more classes of things; feel free to
bring them up if they're of consequence)
20:01:28 <mjg59> But insisting that all changelog elements be flagged with a bug
just encourages people not to mention things in changelogs
20:01:46 <nirik> yeah.
20:02:05 <pjones> mjg59: If your changelog looks like this, it's "b"
in my list:
20:02:07 <pjones> * Wed Sep 22 2010 Harald Hoyer <harald(a)redhat.com> 005-4 -
backported a lot of bugfixes from git
20:02:31 <pjones> insisting that there's an actual changelog might be a start?
;)
20:02:51 <mjg59> pjones: Yeah, but how? Name and shame?
20:03:00 <pjones> this specific case is obviously bad regardless of the updates
policy - how would a user know if they should update it?
20:03:01 <mjg59> It doesn't seem obvious how to do this in an automated way
20:03:10 <nirik> yeah, automating this is doomed.
20:03:10 <pjones> no, it's really not obvious how to automate it.
20:03:14 <hicham> would have been best to list the bugs at least
20:03:38 <mjg59> Well, we can certainly insist that the update request has something
in the update description that isn't just a cut and paste of the changelog
20:04:20 <pjones> so it looks like we need to focus some on changelog quality as
well as update request text quality
20:04:49 <notting> but for now, just... raise exceptions to fesco?
20:04:59 <mjg59> Guess so
20:05:13 <nirik> of course after something is found, what do we do?
20:05:40 <nirik> unpush it?
20:05:41 <mjg59> Ask people not to do it again?
20:05:57 <mjg59> I don't think there's a hard and fast rule
20:06:00 <pjones> educate them? (a clockwork orange style?)
20:06:02 <mjg59> In some cases unpushing may be worse
20:06:10 <mjg59> It's partially a social expectations change
20:06:26 <mjg59> We need people to be more aware of what they're doing
20:06:43 <nirik> ok, so any objections to me asking testers/qa to be on the lookout
and let us know via a ticket for now?
20:07:03 <pjones> that seems like a good start.
20:07:05 <ajax> sure
20:07:08 <gholms> As a packager I would appreciate some documentation on *what*
should go in changelogs. It varies enough between people that I don't know what would
be best to do.
20:07:30 <nirik> Changelog in the package should be changes to the packaging.
20:07:35 <pjones> gholms: good point
20:07:41 <nirik> ie, updated to version 10 added patch for foo, etc
20:08:46 <gholms> http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs
<-- only shows formatting rules, so some recommendations for their content might be
nice.
20:08:53 <nirik> yeah.
20:09:11 <nirik> Note that the update could have more info about the update rather
than just package changes.
20:09:54 <nirik> #agreed will asking testers/qa to be on the lookout for things not
following the update_policy and notify us via a ticket for further discussion.
20:09:58 <nirik> ok, shall we move on?
20:10:11 <nirik> gholms: perhaps we should ask FPC to clarify contents there.
20:10:42 <gholms> I would certainly appreciate that. It's up to you folks what
to do.
20:11:05 <pjones> I'm +1 to asking FPC to expand that section to be more
instructive.
20:11:24 * nirik is +1 to them looking into it if they can.
20:12:19 <nirik> any other votes/comments on that?
20:12:24 <ajax> fine with me
20:12:28 <notting> wfm
20:12:47 <nirik> #agreed will see if FPC is willing/able to expand on the changelog
guidelines.
20:13:20 <nirik> ok, on ticket #467 Make Feature Freeze happen sooner, I don't
see any new info... should we skip it this week?
20:14:25 <ajax> sure
20:14:32 <nirik> I can ping on the ticket again.
20:14:40 <nirik> #topic #472 About Mozilla's decision to not allow using the
system's libvpx
20:14:40 <nirik> https://fedorahosted.org/fesco/ticket/472
20:15:03 <ajax> i do love how people can only see code duplication when it's
named /lib.*/
20:15:03 * pjones sighs.
20:15:08 <pjones> ajax: no shit
20:15:34 <pjones> I'm still +1 to letting this skate for now, though with a bit
more nuance than what I said in the ticket.
20:15:53 * nirik is wanting more info I think...
20:15:59 <nirik> do we have any of the firefox maintainers here?
20:17:02 <pjones> I guess the real question is: what's the holdup on the libvpx
side?
20:17:14 <pjones> --- [blizzard] idle 135:15:48, signon: Thu Sep 23 14:03:32
20:17:17 <pjones> well, that won't help.
20:17:45 <nirik> yeah, and can we not use the system version in fedora if they can
temp have their patches against it? what else in the repo uses it?
20:18:01 <hicham> gstreamer
20:18:17 <nirik> and is this going to be fixed by f15? or go longer?
20:18:33 <mjg59> I think approaching this discussion in this manner isn't really
helpful
20:18:46 <mjg59> The real question is "Does Mozilla matter to us more than the
bundling policy"
20:19:08 <hicham> i think it does matter a lot, as stransky said
20:19:21 <mjg59> And that's what we should answer, rather than trying to argue
that Mozilla kind of adheres to the bundling policy in spirit if not in reality if we take
a sufficiently holistic view
20:19:39 <pjones> mjg59: I wasn't arguing that. At all.
20:19:46 <mjg59> I'm going to say that Mozilla matters to us more, and we should
just leave it at that
20:19:52 <gholms> Enough so that your answer would be different if this happened to
a less prominent package?
20:19:59 <hicham> if our libvpx matches mozilla's copy, I don't see where is
the problem
20:20:15 <mjg59> gholms: Yes. I have no qualms at all about saying that Mozilla gets
to follow different rules, just like the kernel does.
20:20:33 <notting> of note is that (afaik) all the bundled libs in mofoco sw are
*modified* ones
20:20:37 <mjg59> In the same way that finding a licensing problem with glibc
doesn't result in us dropping glibc
20:20:53 <notting> the ones where they aren't modified they have
--enable-system-<foo> and we use that (hey, that's why we keep updating nss)
20:21:14 <Oxf13> also, those modifications might not be suitable for all other
consumers of said bundled libraries
20:21:17 <mjg59> And given that our Mozilla maintainers have indicated that they
have no interest in maintaining a fork, and nobody else has demonstrated that they'd
be able to provide sufficient support for a fork, I really don't see the point in
arguing the case
20:21:27 <Oxf13> so just taking those modifications and throwing at our system
libraries isn't exactly the best course of action.
20:21:29 <mjg59> We ship Mozilla even though it has bundled libraries. End of
story.
20:21:39 <hicham> I don't see another solution than to grant an exception since
mozilla folks refused for now
20:21:40 <mjg59> The alternatives are all dreadful.
20:21:41 <nirik> Oxf13: could be... I don't know what changes they have made...
20:22:02 <pjones> the real question is if splitting out their library changes and
making them work in the system libraries is more trouble than it's worth. I think the
answer is almost certainly "yes".
20:22:20 <hicham> i am against shipping an unbranded firefox or ice<***> for
this reason
20:22:21 <pjones> since, you know, that's exactly what mozilla upstream is
working on.
20:22:37 <Oxf13> nirik: by and large, I would assume that if the changes were
suitable for all consumers, those changes would be upstream, like previous cases with
mozilla.
20:22:52 <nirik> Oxf13: they specifically mentioned "security fixes"
20:22:58 <nirik> which seems very odd to me.
20:23:19 <hicham> so their patches are not upstreamed yet
20:23:19 <pjones> Oxf13: isn't this the nature of the problem? that seems to be
obviously the case but there are some upstream maintainers dragging their feet?
20:23:31 <nirik> " We prefer to ship our own copies of the media
20:23:31 <nirik> libraries, as if necessary we can cherry-pick a critical security
fix and push
20:23:31 <nirik> out a release quickly, rather than relying on the distros to update
their
20:23:31 <nirik> libraries. We can guarantee the safety and stability of our
libraries this way."
20:23:41 <Oxf13> nirik: a security fix that works for Mozilla's narrow use case
may not be suitable for other use cases.
20:23:58 <pjones> I think you're in the weeds with that one.
20:24:09 <nirik> who me?
20:24:14 <pjones> no, Oxf13
20:24:25 <notting> nirik: they're doing the right thing as application
developers
20:24:33 <pjones> I mean, there's a remote chance, but.
20:24:40 <nirik> notting: right, but they aren't letting us as distributors do
what we think is right.
20:24:46 <pjones> notting: yeah, that's the conclusion I came to as well - but
it sortof sucks for us.
20:25:06 <Oxf13> pjones: fair enough.
20:25:08 <notting> nirik: is 'use a library version they don't develop,
ship, or test against' right?
20:25:16 <nirik> ie, if this was a normal case, the fedora maintainer would unbundle
and be responsible for getting the unbundled thing in fedora updated
20:25:57 <pjones> nirik: (with apologies to kde) there's something to be said
for the size of the project here.
20:26:00 <nirik> notting: no. But they are developing it in this case right?
it's their internal fork?
20:26:12 <ajax> normal apps have neither the complexity nor the visibility of
firefox.
20:26:20 <ajax> i don't have any problem saying ff is more equal.
20:26:37 <notting> nirik: i believe it's a vendor branch, in SCM parlance
20:27:45 <nirik> well, on the plus side it sounds like they are heading the right
way.
20:28:35 <nirik> so, what do we want to do here? vote on something? or gather more
info? or ?
20:29:53 <pjones> we could vote on letting them bundle it; I think most of us are
widely in support of it, and we're discussing reasoning more than anything else here.
20:29:56 <notting> i'm surprised... where are the opposing viewpoints?
20:30:17 <nirik> notting: our FPC folks are against the exception.
20:30:24 <pjones> nirik: oh?
20:30:36 <nirik> see ticket, toshio and spot
20:30:41 <nirik> https://fedorahosted.org/fesco/ticket/472
20:30:42 <pjones> (I mean, yes, I see that in the thread, but... where are they? ;)
20:30:49 <pjones> it's not like toshio doesn't know where our meetings are.
20:31:09 <nirik> spot is in channel, not sure if he's around.
20:32:54 <nirik> I kinda wish we had more info... like if there's a timeline on
when they would use system, the security thing seems weak to me.
20:33:04 * nirik summoned abadger1999
20:33:11 * abadger1999 here
20:33:27 * abadger1999 notes that spot is the one that corresponded with mozilla... and
the libvpx package maintainer.
20:33:47 <gholms> Well, look at how long other media libraries have remained
forked.
20:34:11 <nirik> gholms: sure, but note in the ticket that they say they are close
to unbundling those.
20:34:31 <nirik> abadger1999:
http://meetbot.fedoraproject.org/fedora-meeting/2010-10-05/fesco.2010-10-...
has the log/backscroll.
20:34:33 <gholms> If that's the case then you know about how long to expect.
20:34:45 <abadger1999> nirik: not all of them.
20:34:48 <nirik> not really. I don't know if this is the same sort of case.
20:35:26 * nirik notes we are over 15min... votes to continue?
20:35:29 * abadger1999 tries to find tickets with some info
20:35:36 <nirik> +1 from me. I would like to hear from abadger1999.
20:36:38 <abadger1999> Hmm... so should ask spot since blizzard's quoted reply
doesn't say which libraries are close to being unbundled.
20:37:07 <abadger1999> I do know that mozilla has extended libpng in their copy so
that's unlikely to be pushed to the system for a while.
20:37:25 <pjones> maybe we should put this off for a week and invite blizzard to
come here and talk to us directly.
20:37:30 <pjones> since this sounds a lot like playing telephone.
20:37:32 * nirik would like that.
20:38:44 <notting> if we can't get everyone here today... who wants to do
herding for next week?
20:40:42 <pjones> I'm not against putting it to a vote now, but nirik sounded
like he wants more info first.
20:41:04 * abadger1999 finishes reading logs
20:41:13 <abadger1999> pjones: +1 to inviting others.
20:41:24 <nirik> I kinda do, but if no one else wants to, we can vote I suppose.
20:41:25 <abadger1999> i'd like spot and blizzard if possible.
20:42:02 <ajax> sure, let's have a party.
20:42:30 <hicham> invite kkofler also
20:42:35 <abadger1999> Since they're the two that have been doing the
communication in the background.
20:42:59 <nirik> hicham: I don't think that would be productive.
20:43:08 <gholms> ...
20:43:37 <hicham> so no decision for today ...
20:43:57 <hicham> I thought that gecko-maint would be here
20:44:22 <nirik> I can invite people, but if someone else knows/talks to those
involved, they could do that and I would be happy. ;)
20:44:50 <abadger1999> notting: So I don't 100% agree with your thought that
they're doing what's best for app development. But it's pretty nuanced so we
might just be coming at the same ideas from different angles.
20:45:49 <hicham> nirik : what are the possible solutions for this case ?
20:46:17 <abadger1999> basically, When you as a developer are releasing an app to a
platform, then you do want to have control over what is being used.
20:46:38 <mjg59> Well, options seem to be "Grant Mozilla a broad
exemption", "Grant Mozilla a limited exemption", "Don't grant
Mozilla an exemption"
20:46:48 <nirik> right.
20:47:01 <pjones> and the latter two make a lot of work for somebody.
20:47:03 <hicham> mjg59: I don't think the third one is possible
20:47:04 <mjg59> With the third of those meaning "Remove Mozilla", the
second meaning "Let's have the same conversation again in 6 months" and the
first meaning "Nobody working on Mozilla really cares"
20:47:04 <nirik> ok, I guess I will mail people to come next week.
20:47:21 <abadger1999> But when a system admin is deploying things (or we as
packagers are proxying for the system admin) we want to make sure that our workload as a
whole system is as low as possible.
20:47:23 <mjg59> I'm in favour of keeping Mozilla and not having this
conversation every 6 months
20:47:34 * spot is here
20:47:38 <abadger1999> So we want the ability to unbundle those libraries.
20:47:40 <spot> is there a question for me?
20:47:57 <mjg59> abadger1999: Yeah, and we also want bug free software, maintainers
and users
20:48:04 <mjg59> All of these things are tradeoffs
20:48:06 <abadger1999> spot: Talking libvpx (in specific) bundled libraries in
general as it applies to mozilla.
20:48:08 <hicham> well, yes, you are the one who mailed mozilla folks spot
20:48:10 <notting> hicham: re: gecko-maint, caillon had other commitments, most
other members are in wrong timezone
20:48:44 <mjg59> #proposal: Mozilla gets to do whatever it wants with its packaging,
up to (but not including) deleting user data
20:48:50 <spot> fwiw, i don't at all like mozilla's attitude towards
bundling.
20:49:10 <abadger1999> mjg59: We'll never ever have bug-free software though --
so the question is what's most beneficial to our workload and to the workload of the
system admins.
20:49:36 * nirik is uneasy by it, since it seems they aren't trying to hard to work
with us on it.
20:49:40 <mjg59> abadger1999: Well, what's beneficial to *my* workload is having
a working web browser that's maintained by people who have proved they can maintain
it
20:50:03 <pjones> abadger1999: mjg59: can we not try to make this as abstract as
possible? we don't really need a discussion about the nature of software bugs. We
know firefox is a file. ;)
20:50:18 <notting> (note: i have to leave in ~15 mins or so)
20:50:20 <abadger1999> pjones: haha :-)
20:50:27 <mjg59> pjones: I'd prefer to be specific. I think Mozilla is a special
case and I think we should explicitly acknowledge that.
20:50:36 <spot> mjg59: is chromium also a special case?
20:50:42 <mjg59> spot: Right now? No.
20:50:47 <mjg59> In a couple of years? Maybe.
20:50:50 <spot> mjg59: because to be fair, they're doing the same as mozilla on
a much larger scale.
20:51:02 <nirik> notting: we have no other items after this... so just open floor.
20:51:03 <notting> spot: aren't they bundling things we can't ship in any
case?
20:51:12 <mjg59> Firefox has significant brand recognition that we genuinely benefit
from
20:51:12 <ajax> spot: where by "the same" you mean "bundling"
not "being a web browser", i assume
20:51:15 <spot> notting: those items are removable.
20:51:24 <mjg59> I don't think Chromium provides that
20:51:25 <spot> ajax: well, technically both, but yes.
20:51:25 <rdieter> spot: I read somewhere today chome's marketshare went ahead
of firefox today
20:51:37 <hicham> mozilla isn't doing what google is doing
20:52:05 <mjg59> rdieter: Remember that Chrome -> Chromium = Firefox ->
Iceweasel
20:52:07 <pjones> rdieter: so *completely* not relevant.
20:52:25 <mjg59> We can't ship Chrome
20:52:27 <hicham> mjg59: i don't think that this is a fair comparison
20:52:34 <nirik> back to the topic, I'd like to hear more from upstream as to
why they are bundling in this case. The security argument seems poor. I'd also like
that they had a roadmap to unbundle.
20:53:02 <notting> well, in staying close to upstream, you're at the mercy of
upstream. c.f. kde not maintaining security updates for older releases
20:53:13 <spot> nirik: i'd be happy to pass along the contact info, but i would
not expect much more info from them on this.
20:53:28 <hicham> i am just wondering if we can't ask mozilla for an exception
instead of granting them an exception ...
20:53:36 <mjg59> hicham: We did.
20:53:39 <mjg59> They said no.
20:53:44 <nirik> It's hard to get too much from: "It sounds like we're
still finding issues with our fuzzers from time to time and there are still changes coming
to the library. So we're going to keep it close for a while yet."
20:54:18 <mjg59> nirik: I think the assumption that we can change their mind on this
by demonstrating that a specific rational argument doesn't support their position
isn't obviously true
20:54:26 <hicham> mjg59: we asked them to allow building against libvpx, not to
patch xulrunner to use the system vpx
20:54:34 <nirik> I suppose not. ;(
20:54:42 <mjg59> hicham: Why do you believe the answer would be different?
20:55:01 <spot> nirik: i can only assume they feel that the system libvpx will in
some way make firefox work poorly, and they are unwilling to permit anyone to do that and
still call the resultant product "firefox"
20:55:11 <hicham> mjg59: because if our vpx matches their vpx we might have an
agreement
20:55:23 <pjones> nirik: I think it's pretty clear that they choose to bundle
the libraries with higher volatility (in terms of changes), and they think libvpx is under
a lot of flux
20:55:25 <notting> i'm sure someone with sufficient skill could send a patch
that adds --enable-system-vpx
20:55:32 <mjg59> Fundamentally, we are an entirely insignificant part of MoFo's
market share, they've shown little historical interest in adhering to our whims on
this point and we need them more than they need us
20:55:40 <nirik> notting: they did. it was rejected.
20:55:42 <spot> notting: that patch was sent and rejected
20:55:59 <mjg59> So could we please just vote on this?
20:56:02 <pjones> and in order to carry it ourself, we've basically got to
redbaron it.
20:56:06 <pjones> +1 to voting on it.
20:56:12 <pjones> (and I'm still +1 to granting them the exception)
20:56:16 <notting> pjones: i think that lapsed
20:56:23 <pjones> notting: details.
20:56:48 <notting> pjones: just saying, if it hadn't, and we *did* go the
iceweasel route... that would be the obvious way
20:57:25 <notting> i'm for voting on non-comical proposals. does someone have
one?
20:57:26 <nirik> ok, so we are voting then?
20:57:32 <mjg59> And can we be clear what we're voting on?
20:57:40 <nirik> proposal: grant firefox a exception to bundle libvpx
20:57:51 <mcepl> mjg59: I have my doubts about their opinions on Linux share of MoFo
users, but that's besides the point. I would say on MoFo defense (what did you
expect?) that comparing to Google/Chromium they have some history of after some time
pushing patches upstream.
20:57:51 <pjones> +1 to nirik's proposal.
20:57:54 <mjg59> I think we should start with a vote for a generic exception, and
then if that fails do so for a limited one
20:58:15 <nirik> mjg59: ok, you have one?
20:58:34 <mjg59> proposal: Mozilla be exempted from FPC's policy on library
bundling
20:58:40 <gholms> A carte blanche?
20:58:43 <mjg59> Yes
20:58:48 <gholms> Interesting...
20:58:49 <nirik> -1 here
20:59:15 <pjones> there's only 6 of us here, right?
20:59:27 <mjg59> +1
20:59:33 <hicham> that would solve future conflicts, I agree with mjg59
20:59:43 <mjg59> pjones: Yeah, so +5 is still possible
20:59:49 <nirik> pjones: I thought we only had 5 exactly... but I could have
miscounted.
21:00:07 <nirik> SMParrish isn't active, but is in channel. ;)
21:00:12 <pjones> Oh, okay.
21:00:15 <pjones> so this can't pass.
21:00:24 <notting> i'm leery of carte blanche in case they do something really
dumb. but i suppose that could be an exception
21:00:29 <Oxf13> needing unanimity kind of sucks.
21:00:43 <pjones> notting: we can always *revoke* it.
21:00:44 <nirik> well, you could try again next week when more folks were around.
21:00:47 <ajax> who said unanimity.
21:01:18 <gholms> How about bringing up and voting on both proposals both here and
in the ticket? There's no reason you can't vote on both types of exceptions.
21:01:53 <notting> i'm ok with voting in ticket in an attempt to get quorum
21:01:58 <mjg59> Yeah
21:02:04 <ajax> wfm
21:02:11 <nirik> just as a side note, does anyone have problems with an iceweasel
package being in fedora provided it passes review, etc?
21:02:21 <pjones> nirik: yes
21:02:37 <gholms> It would need to update side-by-side with firefox.
21:02:38 <nirik> ok would someone like to update the ticket?
21:02:45 <pjones> Seriously, if we're against having dupicate libraries, how can
we be fore having duplicate application code?
21:02:45 <hicham> i am against such a package
21:02:47 <nirik> pjones: out of curiosity, what?
21:02:53 <pjones> for
21:03:06 <hicham> ice* browsers are useless
21:03:12 <mjg59> I would be in favour of out firefox package being *trivially*
rebrandable
21:03:18 <hicham> just rebranding+destructive patches
21:03:22 <notting> nirik: it strikes me as a petty waste of resources
21:03:28 <mjg59> So that downstreams can handle this more easily
21:03:47 <nirik> if an iceweasel package was in, was well maintained and had an
active community of packagers, I would be much more likely to drop firefox. (ie, find out
if it's viable before we move to it)
21:04:04 <nirik> anyhow, I guess I am going off topic.
21:04:04 <notting> mjg59: can you put your global and local(vpx-only) proposals in
the ticket for voting
21:04:13 <mjg59> notting: Sure
21:04:22 <pjones> nirik: we know it's /viable/, don't we? since debian does
it within reason.
21:04:56 <notting> nirik: imo, it makes sense to have ff or iw. not both
21:04:57 <nirik> I don't know how well it works there...
21:05:07 <ajax> i feel like we've now spent more time talking about this than it
would require to patch both the firefox and system versions of vpx in the event of a
security problem.
21:05:11 <nirik> #agreed will vote on proposals in ticket.
21:05:28 <nirik> shall we move on then?
21:05:32 <ajax> please.
21:05:36 <notting> ajax: i have no doubts about mofoco's ability to push new
security releases at a rapid pace
21:05:39 <pjones> yes.
21:05:41 <pjones> move on.
21:05:43 <nirik> #topic Open Floor
21:05:48 <nirik> anyone have anything for open floor?
21:06:00 * gholms raises hand
21:06:07 <nirik> gholms: go ahead
21:06:48 <gholms> I have a rel-eng ticket that could result in very a minor
distro-wide change. If any of you have any input on it I would appreciate hearing from
you.
21:06:52 <gholms> .releng 4149
21:06:52 <zodbot> gholms: Ticket #4120 (task closed): Override tag request for
rubygem-hoe || Ticket #4156 (task closed): task 2513514 stuck in tests || Ticket #4158
(task created): tag banshee-1.8.0-4.fc14 gio-sharp-0.2-2.fc14 libgpod-sharp-0.7.95-1.fc14
gudev-sharp-0.1-3.fc14 gkeyfile-sharp-0.1-3.fc14 gtk-sharp-beans-2.14.0-2.fc14 || Ticket
#4157 (task created): Please tag nss-softokn-3.12.8-1.fc12 nss-softokn-3.12.8-1.fc13
(12 more messages)
21:07:07 <gholms> Err, that didn't work so well.
21:07:13 <gholms> https://fedorahosted.org/rel-eng/ticket/4149
21:07:35 <Oxf13> .rel 4149
21:07:36 <zodbot> Oxf13: #4149 (Need a way to point EC2 instances to specific
mirrors) - Fedora Release Engineering - Trac -
https://fedorahosted.org/rel-eng/ticket/4149
21:07:45 <gholms> Thanks
21:08:00 * nirik is happy with whatever solution folks interested come up with there. ;)
21:09:25 <notting> yeah, i'm ok with whatever the yum and MM people agree on
21:09:41 <ajax> up, enter
21:10:11 <notting> gholms: have the MM maintainers chimed in yet?
21:10:47 <gholms> mdomsch added the needed MM support already.
21:11:18 <gholms> It isn't released yet, but it's there.
21:11:37 <pjones> totally okay with it then.
21:11:38 <mdomsch> yep
21:11:47 <notting> sweet. if you need the repo def changed, plz file a blocker bug
against fedora-release
21:11:53 <mdomsch> needs some testing, but is pretty straightforward
21:12:04 <mdomsch> notting: with the config plugin, we shouldn't need to
21:12:11 <gholms> How soon should such a bug be filed?
21:12:12 <mdomsch> and I prefer not to
21:12:27 <notting> i thought the yum folks said they'd prefer a non-plugin
solution
21:12:39 <gholms> mdomsch: skvidal and Oxf13 are saying avoiding a plugin would be
better.
21:13:01 <mdomsch> oh? I missed that. I thought skvidal was on board, exactly so
we get
21:13:07 <mdomsch> a) dynamic operation
21:13:13 <mdomsch> b) no munging the config file
21:13:23 <Oxf13> I defer to skvidal on how it should operate
21:13:31 <Oxf13> my only contribution that I like was adding a tag to the MM url
string
21:13:35 <mdomsch> a) being that we can grab the value every time yum runs, rather
than when the AMI is created
21:13:38 <Oxf13> how that tag gets added isn't as much of a concern of mine
21:13:42 <gholms> With the currently-favored solution we change the *stock* repo
configs.
21:13:59 <notting> gholms: right, which is a blocker bug against fedora-release
21:14:00 <nirik> anyhow, sounds like we are fine with whatever you guys come up
with. ;)
21:14:01 <gholms> Those can stay the same, and the value gets filled in a different
file at boot time. Simple!
21:14:08 <gholms> Sounds good.
21:14:08 <notting> gholms: (or, you do it in appliance-tools)
21:14:21 <gholms> notting: Read the wiki page; there are problems with that
approach.
21:15:02 <pjones> mdomsch: okay, so it sounds like you and skvidal need to make sure
you're on the same page - aside from that, I think a lot of us will defer to you two.
21:16:07 <nirik> Any other open floor items?
21:17:34 * nirik will close the meeting in a minute if nothing else comes up.
21:18:39 <nirik> #endmeeting
7:29 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2010-10-05)
On 10/5/10, Kevin Fenzi <kevin(a)scrye.com> wrote:
===================================
#fedora-meeting: FESCO (2010-10-05)
===================================
Meeting started by nirik at 19:30:01 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2010-10-05/fesco.2010-10-...
Meeting summary
---------------
* init process (nirik, 19:30:01)
* mclasen will not be able to attend today due to a backhoe incident.
(nirik, 19:30:48)
* cwicket will also be unable to attend. (nirik, 19:30:59)
* kylem is also unable to attend. (nirik, 19:31:13)
* #473 new meeting time (redux) (nirik, 19:33:54)
* LINK: https://fedorahosted.org/fesco/ticket/473 (nirik, 19:33:54)
* ACTION: make sure cwickert is updated, revisit next week. (nirik,
19:46:09)
* reminder: you can vote in tickets if unable to attend the meeting.
(nirik, 19:46:22)
* Updates policy / Vision implementation status (nirik, 19:46:48)
* ideas wanted to improve stable N-1 wording/distinction. (nirik,
19:57:04)
* LINK: http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs
<-- only shows formatting rules, so some recommendations for their
content might be nice. (gholms, 20:08:46)
* AGREED: will asking testers/qa to be on the lookout for things not
following the update_policy and notify us via a ticket for further
discussion. (nirik, 20:09:54)
* AGREED: will see if FPC is willing/able to expand on the changelog
guidelines. (nirik, 20:12:47)
* #472 About Mozilla's decision to not allow using the system's libvpx
(nirik, 20:14:40)
* LINK: https://fedorahosted.org/fesco/ticket/472 (nirik, 20:14:40)
* LINK: https://fedorahosted.org/fesco/ticket/472 (nirik, 20:30:41)
* AGREED: will vote on proposals in ticket. (nirik, 21:05:11)
* Open Floor (nirik, 21:05:43)
* LINK: https://fedorahosted.org/rel-eng/ticket/4149 (gholms,
21:07:13)
Meeting ended at 21:18:39 UTC.
Action Items
------------
* make sure cwickert is updated, revisit next week.
Action Items, by person
-----------------------
* cwickert
* make sure cwickert is updated, revisit next week.
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* nirik (145)
* pjones (69)
* mjg59 (56)
* notting (39)
* gholms (31)
* ajax (23)
* hicham (22)
* abadger1999 (17)
* spot (10)
* Oxf13 (10)
* zodbot (8)
* mdomsch (8)
* mcepl (1)
* rdieter (1)
* SMParrish (0)
* kylem (0)
* mclasen (0)
* cwickert (0)
--
19:30:01 <nirik> #startmeeting FESCO (2010-10-05)
19:30:01 <zodbot> Meeting started Tue Oct 5 19:30:01 2010 UTC. The chair
is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:30:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link
#topic.
19:30:01 <nirik> #meetingname fesco
19:30:01 <zodbot> The meeting name has been set to 'fesco'
19:30:01 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones
cwickert mjg59
19:30:01 <nirik> #topic init process
19:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen
mjg59 nirik notting pjones
19:30:06 * notting is here
19:30:36 * ajax waves
19:30:48 <nirik> #info mclasen will not be able to attend today due to a
backhoe incident.
19:30:56 * pjones throws a trout at ajax
19:30:59 <nirik> #info cwicket will also be unable to attend.
19:31:12 <gholms> A backhoe incident? Ouch.
19:31:13 <nirik> #info kylem is also unable to attend.
19:31:21 <nirik> gholms: took out his home internet it seems.
19:31:30 <gholms> Ok, that's not *so* bad.
19:31:52 <notting> and kylem will not be here
19:32:19 <nirik> SMParrish: / mjg59: you guys here?
19:33:15 <mjg59> Afternoon
19:33:27 <nirik> Hello. :) Thats 5.
19:33:45 <nirik> Shall we start with meeting time?
19:33:54 <nirik> #topic #473 new meeting time (redux)
19:33:54 <nirik> https://fedorahosted.org/fesco/ticket/473
19:34:09 <nirik> has everyone updated their
http://whenisgood.net/ee8prq/results/z5binx entry?
19:34:15 <ajax> i have
19:34:25 * nirik 's didn't really change any
19:35:04 <nirik> so, currently we have 0 times everyone can attend. ;)
19:35:18 <pjones> yeah :/
19:35:22 <nirik> a few times with 1 person left out, but everyone else...
19:35:31 <pjones> and excluding one person doesn't really help that much
19:36:11 <nirik> I guess we need to confirm that everyone updated before we
do anything else?
19:36:24 <notting> although one of the times where mclasen is the only
holdout his update info says will become available in a couple of weeks
19:37:01 <nirik> oh?
19:37:12 <mjg59> Wait. I'm suddenly worried by the timezones here.
19:37:15 <nirik> wed 1-2?
19:37:17 <pjones> So can we move to that time and then hope that he can make
do responding to trac until then? sounds not that great.
19:37:27 <nirik> mjg59: yeah, the site is confusing.
19:37:28 <pjones> mjg59: yeah, the site's representation of timezones is
weird.
19:37:30 <notting> nirik: 2-3 your time. unless i'm forgetting what your
time is
19:37:31 <nirik> I think it's in my local time.
19:37:39 <pjones> nirik: right.
19:37:41 <pjones> it's in mountain
19:37:49 <nirik> yeah.
19:38:04 <notting> nirik: he says 5-6PM e(d|s)t will become available for
him in mid-ocyt
19:38:06 <pjones> but on the individual pages you can set it to a different
local time.
19:38:10 <gholms> whenisgood allows you to set time zones.
19:38:54 <mjg59> notting: I don't think that actually helps
19:38:55 <nirik> I see 1-2my time on wed being just him unable to attend...
so one hour of that would work. (Althought thats sure late for you guys)
19:38:56 <pjones> notting: uh, pretty sure I didn't have 5-6pm EST5EDT
selected as okay
19:39:16 <pjones> (given that the meeting often takes two hours, I didn't
select anything after 3)
19:39:22 <notting> pjones: i may have been confusing the displayed TZ as PDT
19:40:18 <nirik> so, everyone here has updated? and I am pretty sure mclasen
has and I know kylem has.
19:40:30 <nirik> that leaves cwickert and SMParrish as unknowns?
19:40:49 <notting> SMParrish did
19:40:55 <notting> (mouse over their names)
19:41:09 <nirik> ah yes.
19:42:32 <nirik> so, make sure cwickert updated and then go from there?
and/or ask everyone else to doublecheck that they can't be available more
times?
19:43:04 <mjg59> nirik: I've left the entire working day other than
lunchtime
19:43:23 <mjg59> So I think I'm relatively unable to add more at this point
:)
19:43:38 <nirik> tue 11-12 has either cwickert or kylem unavailable... if we
do that block they could both attend, just not for the entire time. ;)
19:44:27 <nirik> mjg59: yeah, mostly me too.
19:44:42 <notting> and, of course, we'll have elections in about a months
time
19:44:46 <nirik> so, how much time is left in this term.
19:44:47 <nirik> yeah.
19:45:28 <nirik> so, let me make sure cwickert updated, and then see if we
can get any times then? revisit next week?
19:45:42 <mjg59> Ok
19:45:59 <nirik> any objections?
19:46:08 <ajax> nope
19:46:09 <nirik> #action make sure cwickert is updated, revisit next week.
19:46:22 <nirik> #info reminder: you can vote in tickets if unable to attend
the meeting.
19:46:46 <nirik> ok, moving on.
19:46:48 <nirik> #topic Updates policy / Vision implementation status
19:46:48 <nirik> .fesco 351
19:46:48 <nirik> .fesco 382
19:46:49 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac -
https://fedorahosted.org/fesco/ticket/351
19:46:53 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo -
Trac - https://fedorahosted.org/fesco/ticket/382
19:46:59 <nirik> Our fun updates tickets. :)
19:47:09 <nirik> So, I have several things here:
19:48:11 <nirik> There was a suggestion made to add/clarify
https://fedoraproject.org/wiki/Updates_Policy about stable release N and
stable release N+1
19:48:29 <nirik> currently it's just "stable releases"
19:48:46 <nirik> do we want to specifically say N+1 should be treated any
differently than N ?
19:49:22 <nirik> Thoughts?
19:49:28 <ajax> i do, but the impression i got from the list was...
disappointing
19:49:56 <nirik> what would we do differently?
19:50:28 <nirik> The suggestion I got was to say that N+1 should get
'less'
updates... but didn't say how.
19:50:33 <ajax> right.
19:51:04 <ajax> what i was hearing was "that doesn't make any sense",
which
is just bizarre to me
19:51:07 <gholms> Should it?
19:51:23 <ajax> since all my experience says that eventually you stop being
able to fix things in place without massive upheaval
19:51:42 <ajax> so the amount that you _can_ fix in older releases naturally
falls off
19:51:50 * nirik nods.
19:52:09 <ajax> but apparently that's just, like, my opinion, man.
19:52:12 <pjones> yeah, that's pretty much how I see it as well
19:52:16 <nirik> not just yours... ;)
19:52:48 <nirik> so, is there any way to codify this into the policy aside
from the "The update rate for any given release should drop off over time,
approaching zero near release end-of-life." sentence?
19:53:17 <pjones> I hope so; I don't imagine a statement like that will have
any credence.
19:54:03 <ajax> yeah, i just can't think of a better way to word it
19:55:12 <nirik> updates to N+1 releases should only fix serious bugs or
security issues. updates to N releases could additionally fix more minor
bugs if all the other criteria are met?
19:55:20 <notting> ... surely you mean n-1
19:55:27 <nirik> right, sorry.
19:55:30 * nirik fails math
19:55:48 <pjones> notting: somehow I was assuming that the whole time
without saying anything. Yeah, obviously n-1
19:56:12 <nirik> anyhow, not sure we can/will decide this today. I guess I
will ask for more input from the people who asked for this and try and get a
concrete wording.
19:57:04 <nirik> #info ideas wanted to improve stable N-1
wording/distinction.
19:57:31 <nirik> So, the next thing I had: we have an updates policy. Yea!
What do we want to do about enforcing/educating maintainers about it?
19:58:07 <gholms> Another round of package reviews! :P
19:58:12 * gholms runs
19:58:17 <nirik> riiiight.
19:58:46 <nirik> I was thinking a first easy step would be to ask
proventesters to look out for things that don't fit the stable release
policy and bring them to our attention.
19:59:02 <nirik> some things it's hard to tell though.
19:59:38 <nirik> some examples: dracut was updated in f12/13 with a bunch of
patches. Were those all bugfixes?
19:59:59 <pjones> if it's hard to tell, that means either a) we need to
think about how to make a generic exemplar of that case, or b) the packager
needs to be telling us more about the update
20:00:07 <nirik> NetworkManager rebases to a git snapshot in all of
f12/f13/f14/rawhide at the same time.
20:00:19 <pjones> And I think both of those are "b" there.
20:00:59 <nirik> right, so more education...
20:01:12 <mjg59> Ideally we'd have some means of identifying this
20:01:14 <pjones> (obviously, there could be more classes of things; feel
free to bring them up if they're of consequence)
20:01:28 <mjg59> But insisting that all changelog elements be flagged with a
bug just encourages people not to mention things in changelogs
20:01:46 <nirik> yeah.
20:02:05 <pjones> mjg59: If your changelog looks like this, it's "b"
in my
list:
20:02:07 <pjones> * Wed Sep 22 2010 Harald Hoyer <harald(a)redhat.com> 005-4 -
backported a lot of bugfixes from git
20:02:31 <pjones> insisting that there's an actual changelog might be a
start? ;)
20:02:51 <mjg59> pjones: Yeah, but how? Name and shame?
20:03:00 <pjones> this specific case is obviously bad regardless of the
updates policy - how would a user know if they should update it?
20:03:01 <mjg59> It doesn't seem obvious how to do this in an automated way
20:03:10 <nirik> yeah, automating this is doomed.
20:03:10 <pjones> no, it's really not obvious how to automate it.
20:03:14 <hicham> would have been best to list the bugs at least
20:03:38 <mjg59> Well, we can certainly insist that the update request has
something in the update description that isn't just a cut and paste of the
changelog
20:04:20 <pjones> so it looks like we need to focus some on changelog
quality as well as update request text quality
20:04:49 <notting> but for now, just... raise exceptions to fesco?
20:04:59 <mjg59> Guess so
20:05:13 <nirik> of course after something is found, what do we do?
20:05:40 <nirik> unpush it?
20:05:41 <mjg59> Ask people not to do it again?
20:05:57 <mjg59> I don't think there's a hard and fast rule
20:06:00 <pjones> educate them? (a clockwork orange style?)
20:06:02 <mjg59> In some cases unpushing may be worse
20:06:10 <mjg59> It's partially a social expectations change
20:06:26 <mjg59> We need people to be more aware of what they're doing
20:06:43 <nirik> ok, so any objections to me asking testers/qa to be on the
lookout and let us know via a ticket for now?
20:07:03 <pjones> that seems like a good start.
20:07:05 <ajax> sure
20:07:08 <gholms> As a packager I would appreciate some documentation on
*what* should go in changelogs. It varies enough between people that I
don't know what would be best to do.
20:07:30 <nirik> Changelog in the package should be changes to the
packaging.
20:07:35 <pjones> gholms: good point
20:07:41 <nirik> ie, updated to version 10 added patch for foo, etc
20:08:46 <gholms>
http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs <-- only
shows formatting rules, so some recommendations for their content might be
nice.
20:08:53 <nirik> yeah.
20:09:11 <nirik> Note that the update could have more info about the update
rather than just package changes.
20:09:54 <nirik> #agreed will asking testers/qa to be on the lookout for
things not following the update_policy and notify us via a ticket for
further discussion.
20:09:58 <nirik> ok, shall we move on?
20:10:11 <nirik> gholms: perhaps we should ask FPC to clarify contents
there.
20:10:42 <gholms> I would certainly appreciate that. It's up to you folks
what to do.
20:11:05 <pjones> I'm +1 to asking FPC to expand that section to be more
instructive.
20:11:24 * nirik is +1 to them looking into it if they can.
20:12:19 <nirik> any other votes/comments on that?
20:12:24 <ajax> fine with me
20:12:28 <notting> wfm
20:12:47 <nirik> #agreed will see if FPC is willing/able to expand on the
changelog guidelines.
20:13:20 <nirik> ok, on ticket #467 Make Feature Freeze happen sooner, I
don't see any new info... should we skip it this week?
20:14:25 <ajax> sure
20:14:32 <nirik> I can ping on the ticket again.
20:14:40 <nirik> #topic #472 About Mozilla's decision to not allow using the
system's libvpx
20:14:40 <nirik> https://fedorahosted.org/fesco/ticket/472
20:15:03 <ajax> i do love how people can only see code duplication when it's
named /lib.*/
20:15:03 * pjones sighs.
20:15:08 <pjones> ajax: no shit
20:15:34 <pjones> I'm still +1 to letting this skate for now, though with a
bit more nuance than what I said in the ticket.
20:15:53 * nirik is wanting more info I think...
20:15:59 <nirik> do we have any of the firefox maintainers here?
20:17:02 <pjones> I guess the real question is: what's the holdup on the
libvpx side?
20:17:14 <pjones> --- [blizzard] idle 135:15:48, signon: Thu Sep 23 14:03:32
20:17:17 <pjones> well, that won't help.
20:17:45 <nirik> yeah, and can we not use the system version in fedora if
they can temp have their patches against it? what else in the repo uses it?
20:18:01 <hicham> gstreamer
20:18:17 <nirik> and is this going to be fixed by f15? or go longer?
20:18:33 <mjg59> I think approaching this discussion in this manner isn't
really helpful
20:18:46 <mjg59> The real question is "Does Mozilla matter to us more than
the bundling policy"
20:19:08 <hicham> i think it does matter a lot, as stransky said
20:19:21 <mjg59> And that's what we should answer, rather than trying to
argue that Mozilla kind of adheres to the bundling policy in spirit if not
in reality if we take a sufficiently holistic view
20:19:39 <pjones> mjg59: I wasn't arguing that. At all.
20:19:46 <mjg59> I'm going to say that Mozilla matters to us more, and we
should just leave it at that
20:19:52 <gholms> Enough so that your answer would be different if this
happened to a less prominent package?
20:19:59 <hicham> if our libvpx matches mozilla's copy, I don't see where
is
the problem
20:20:15 <mjg59> gholms: Yes. I have no qualms at all about saying that
Mozilla gets to follow different rules, just like the kernel does.
20:20:33 <notting> of note is that (afaik) all the bundled libs in mofoco sw
are *modified* ones
20:20:37 <mjg59> In the same way that finding a licensing problem with glibc
doesn't result in us dropping glibc
20:20:53 <notting> the ones where they aren't modified they have
--enable-system-<foo> and we use that (hey, that's why we keep updating nss)
20:21:14 <Oxf13> also, those modifications might not be suitable for all
other consumers of said bundled libraries
20:21:17 <mjg59> And given that our Mozilla maintainers have indicated that
they have no interest in maintaining a fork, and nobody else has
demonstrated that they'd be able to provide sufficient support for a fork, I
really don't see the point in arguing the case
20:21:27 <Oxf13> so just taking those modifications and throwing at our
system libraries isn't exactly the best course of action.
20:21:29 <mjg59> We ship Mozilla even though it has bundled libraries. End
of story.
20:21:39 <hicham> I don't see another solution than to grant an exception
since mozilla folks refused for now
20:21:40 <mjg59> The alternatives are all dreadful.
20:21:41 <nirik> Oxf13: could be... I don't know what changes they have
made...
20:22:02 <pjones> the real question is if splitting out their library
changes and making them work in the system libraries is more trouble than
it's worth. I think the answer is almost certainly "yes".
20:22:20 <hicham> i am against shipping an unbranded firefox or ice<***> for
this reason
20:22:21 <pjones> since, you know, that's exactly what mozilla upstream is
working on.
20:22:37 <Oxf13> nirik: by and large, I would assume that if the changes
were suitable for all consumers, those changes would be upstream, like
previous cases with mozilla.
20:22:52 <nirik> Oxf13: they specifically mentioned "security fixes"
20:22:58 <nirik> which seems very odd to me.
20:23:19 <hicham> so their patches are not upstreamed yet
20:23:19 <pjones> Oxf13: isn't this the nature of the problem? that seems
to be obviously the case but there are some upstream maintainers dragging
their feet?
20:23:31 <nirik> " We prefer to ship our own copies of the media
20:23:31 <nirik> libraries, as if necessary we can cherry-pick a critical
security fix and push
20:23:31 <nirik> out a release quickly, rather than relying on the distros
to update their
20:23:31 <nirik> libraries. We can guarantee the safety and stability of our
libraries this way."
20:23:41 <Oxf13> nirik: a security fix that works for Mozilla's narrow use
case may not be suitable for other use cases.
20:23:58 <pjones> I think you're in the weeds with that one.
20:24:09 <nirik> who me?
20:24:14 <pjones> no, Oxf13
20:24:25 <notting> nirik: they're doing the right thing as application
developers
20:24:33 <pjones> I mean, there's a remote chance, but.
20:24:40 <nirik> notting: right, but they aren't letting us as distributors
do what we think is right.
20:24:46 <pjones> notting: yeah, that's the conclusion I came to as well -
but it sortof sucks for us.
20:25:06 <Oxf13> pjones: fair enough.
20:25:08 <notting> nirik: is 'use a library version they don't develop,
ship, or test against' right?
20:25:16 <nirik> ie, if this was a normal case, the fedora maintainer would
unbundle and be responsible for getting the unbundled thing in fedora
updated
20:25:57 <pjones> nirik: (with apologies to kde) there's something to be
said for the size of the project here.
20:26:00 <nirik> notting: no. But they are developing it in this case right?
it's their internal fork?
20:26:12 <ajax> normal apps have neither the complexity nor the visibility
of firefox.
20:26:20 <ajax> i don't have any problem saying ff is more equal.
20:26:37 <notting> nirik: i believe it's a vendor branch, in SCM parlance
20:27:45 <nirik> well, on the plus side it sounds like they are heading the
right way.
20:28:35 <nirik> so, what do we want to do here? vote on something? or
gather more info? or ?
20:29:53 <pjones> we could vote on letting them bundle it; I think most of
us are widely in support of it, and we're discussing reasoning more than
anything else here.
20:29:56 <notting> i'm surprised... where are the opposing viewpoints?
20:30:17 <nirik> notting: our FPC folks are against the exception.
20:30:24 <pjones> nirik: oh?
20:30:36 <nirik> see ticket, toshio and spot
20:30:41 <nirik> https://fedorahosted.org/fesco/ticket/472
20:30:42 <pjones> (I mean, yes, I see that in the thread, but... where are
they? ;)
20:30:49 <pjones> it's not like toshio doesn't know where our meetings
are.
20:31:09 <nirik> spot is in channel, not sure if he's around.
20:32:54 <nirik> I kinda wish we had more info... like if there's a timeline
on when they would use system, the security thing seems weak to me.
20:33:04 * nirik summoned abadger1999
20:33:11 * abadger1999 here
20:33:27 * abadger1999 notes that spot is the one that corresponded with
mozilla... and the libvpx package maintainer.
20:33:47 <gholms> Well, look at how long other media libraries have remained
forked.
20:34:11 <nirik> gholms: sure, but note in the ticket that they say they are
close to unbundling those.
20:34:31 <nirik> abadger1999:
http://meetbot.fedoraproject.org/fedora-meeting/2010-10-05/fesco.2010-10-...
has the log/backscroll.
20:34:33 <gholms> If that's the case then you know about how long to expect.
20:34:45 <abadger1999> nirik: not all of them.
20:34:48 <nirik> not really. I don't know if this is the same sort of case.
20:35:26 * nirik notes we are over 15min... votes to continue?
20:35:29 * abadger1999 tries to find tickets with some info
20:35:36 <nirik> +1 from me. I would like to hear from abadger1999.
20:36:38 <abadger1999> Hmm... so should ask spot since blizzard's quoted
reply doesn't say which libraries are close to being unbundled.
20:37:07 <abadger1999> I do know that mozilla has extended libpng in their
copy so that's unlikely to be pushed to the system for a while.
20:37:25 <pjones> maybe we should put this off for a week and invite
blizzard to come here and talk to us directly.
20:37:30 <pjones> since this sounds a lot like playing telephone.
20:37:32 * nirik would like that.
20:38:44 <notting> if we can't get everyone here today... who wants to do
herding for next week?
20:40:42 <pjones> I'm not against putting it to a vote now, but nirik
sounded like he wants more info first.
20:41:04 * abadger1999 finishes reading logs
20:41:13 <abadger1999> pjones: +1 to inviting others.
20:41:24 <nirik> I kinda do, but if no one else wants to, we can vote I
suppose.
20:41:25 <abadger1999> i'd like spot and blizzard if possible.
20:42:02 <ajax> sure, let's have a party.
20:42:30 <hicham> invite kkofler also
20:42:35 <abadger1999> Since they're the two that have been doing the
communication in the background.
20:42:59 <nirik> hicham: I don't think that would be productive.
20:43:08 <gholms> ...
20:43:37 <hicham> so no decision for today ...
20:43:57 <hicham> I thought that gecko-maint would be here
20:44:22 <nirik> I can invite people, but if someone else knows/talks to
those involved, they could do that and I would be happy. ;)
20:44:50 <abadger1999> notting: So I don't 100% agree with your thought that
they're doing what's best for app development. But it's pretty nuanced so
we might just be coming at the same ideas from different angles.
20:45:49 <hicham> nirik : what are the possible solutions for this case ?
20:46:17 <abadger1999> basically, When you as a developer are releasing an
app to a platform, then you do want to have control over what is being used.
20:46:38 <mjg59> Well, options seem to be "Grant Mozilla a broad
exemption",
"Grant Mozilla a limited exemption", "Don't grant Mozilla an
exemption"
20:46:48 <nirik> right.
20:47:01 <pjones> and the latter two make a lot of work for somebody.
20:47:03 <hicham> mjg59: I don't think the third one is possible
20:47:04 <mjg59> With the third of those meaning "Remove Mozilla", the
second meaning "Let's have the same conversation again in 6 months" and
the
first meaning "Nobody working on Mozilla really cares"
20:47:04 <nirik> ok, I guess I will mail people to come next week.
20:47:21 <abadger1999> But when a system admin is deploying things (or we as
packagers are proxying for the system admin) we want to make sure that our
workload as a whole system is as low as possible.
20:47:23 <mjg59> I'm in favour of keeping Mozilla and not having this
conversation every 6 months
20:47:34 * spot is here
20:47:38 <abadger1999> So we want the ability to unbundle those libraries.
20:47:40 <spot> is there a question for me?
20:47:57 <mjg59> abadger1999: Yeah, and we also want bug free software,
maintainers and users
20:48:04 <mjg59> All of these things are tradeoffs
20:48:06 <abadger1999> spot: Talking libvpx (in specific) bundled libraries
in general as it applies to mozilla.
20:48:08 <hicham> well, yes, you are the one who mailed mozilla folks spot
20:48:10 <notting> hicham: re: gecko-maint, caillon had other commitments,
most other members are in wrong timezone
20:48:44 <mjg59> #proposal: Mozilla gets to do whatever it wants with its
packaging, up to (but not including) deleting user data
20:48:50 <spot> fwiw, i don't at all like mozilla's attitude towards
bundling.
20:49:10 <abadger1999> mjg59: We'll never ever have bug-free software though
-- so the question is what's most beneficial to our workload and to the
workload of the system admins.
20:49:36 * nirik is uneasy by it, since it seems they aren't trying to hard
to work with us on it.
20:49:40 <mjg59> abadger1999: Well, what's beneficial to *my* workload is
having a working web browser that's maintained by people who have proved
they can maintain it
20:50:03 <pjones> abadger1999: mjg59: can we not try to make this as
abstract as possible? we don't really need a discussion about the nature of
software bugs. We know firefox is a file. ;)
20:50:18 <notting> (note: i have to leave in ~15 mins or so)
20:50:20 <abadger1999> pjones: haha :-)
20:50:27 <mjg59> pjones: I'd prefer to be specific. I think Mozilla is a
special case and I think we should explicitly acknowledge that.
20:50:36 <spot> mjg59: is chromium also a special case?
20:50:42 <mjg59> spot: Right now? No.
20:50:47 <mjg59> In a couple of years? Maybe.
20:50:50 <spot> mjg59: because to be fair, they're doing the same as mozilla
on a much larger scale.
20:51:02 <nirik> notting: we have no other items after this... so just open
floor.
20:51:03 <notting> spot: aren't they bundling things we can't ship in any
case?
20:51:12 <mjg59> Firefox has significant brand recognition that we genuinely
benefit from
20:51:12 <ajax> spot: where by "the same" you mean "bundling"
not "being a
web browser", i assume
20:51:15 <spot> notting: those items are removable.
20:51:24 <mjg59> I don't think Chromium provides that
20:51:25 <spot> ajax: well, technically both, but yes.
20:51:25 <rdieter> spot: I read somewhere today chome's marketshare went
ahead of firefox today
20:51:37 <hicham> mozilla isn't doing what google is doing
20:52:05 <mjg59> rdieter: Remember that Chrome -> Chromium = Firefox ->
Iceweasel
20:52:07 <pjones> rdieter: so *completely* not relevant.
20:52:25 <mjg59> We can't ship Chrome
20:52:27 <hicham> mjg59: i don't think that this is a fair comparison
20:52:34 <nirik> back to the topic, I'd like to hear more from upstream as
to why they are bundling in this case. The security argument seems poor. I'd
also like that they had a roadmap to unbundle.
20:53:02 <notting> well, in staying close to upstream, you're at the mercy
of upstream. c.f. kde not maintaining security updates for older releases
20:53:13 <spot> nirik: i'd be happy to pass along the contact info, but i
would not expect much more info from them on this.
20:53:28 <hicham> i am just wondering if we can't ask mozilla for an
exception instead of granting them an exception ...
20:53:36 <mjg59> hicham: We did.
20:53:39 <mjg59> They said no.
20:53:44 <nirik> It's hard to get too much from: "It sounds like we're
still
finding issues with our fuzzers from time to time and there are still
changes coming to the library. So we're going to keep it close for a while
yet."
20:54:18 <mjg59> nirik: I think the assumption that we can change their mind
on this by demonstrating that a specific rational argument doesn't support
their position isn't obviously true
20:54:26 <hicham> mjg59: we asked them to allow building against libvpx, not
to patch xulrunner to use the system vpx
20:54:34 <nirik> I suppose not. ;(
20:54:42 <mjg59> hicham: Why do you believe the answer would be different?
20:55:01 <spot> nirik: i can only assume they feel that the system libvpx
will in some way make firefox work poorly, and they are unwilling to permit
anyone to do that and still call the resultant product "firefox"
20:55:11 <hicham> mjg59: because if our vpx matches their vpx we might have
an agreement
20:55:23 <pjones> nirik: I think it's pretty clear that they choose to
bundle the libraries with higher volatility (in terms of changes), and they
think libvpx is under a lot of flux
20:55:25 <notting> i'm sure someone with sufficient skill could send a patch
that adds --enable-system-vpx
20:55:32 <mjg59> Fundamentally, we are an entirely insignificant part of
MoFo's market share, they've shown little historical interest in adhering to
our whims on this point and we need them more than they need us
20:55:40 <nirik> notting: they did. it was rejected.
20:55:42 <spot> notting: that patch was sent and rejected
20:55:59 <mjg59> So could we please just vote on this?
20:56:02 <pjones> and in order to carry it ourself, we've basically got to
redbaron it.
20:56:06 <pjones> +1 to voting on it.
20:56:12 <pjones> (and I'm still +1 to granting them the exception)
20:56:16 <notting> pjones: i think that lapsed
20:56:23 <pjones> notting: details.
20:56:48 <notting> pjones: just saying, if it hadn't, and we *did* go the
iceweasel route... that would be the obvious way
20:57:25 <notting> i'm for voting on non-comical proposals. does someone
have one?
20:57:26 <nirik> ok, so we are voting then?
20:57:32 <mjg59> And can we be clear what we're voting on?
20:57:40 <nirik> proposal: grant firefox a exception to bundle libvpx
20:57:51 <mcepl> mjg59: I have my doubts about their opinions on Linux share
of MoFo users, but that's besides the point. I would say on MoFo defense
(what did you expect?) that comparing to Google/Chromium they have some
history of after some time pushing patches upstream.
20:57:51 <pjones> +1 to nirik's proposal.
20:57:54 <mjg59> I think we should start with a vote for a generic
exception, and then if that fails do so for a limited one
20:58:15 <nirik> mjg59: ok, you have one?
20:58:34 <mjg59> proposal: Mozilla be exempted from FPC's policy on library
bundling
20:58:40 <gholms> A carte blanche?
20:58:43 <mjg59> Yes
20:58:48 <gholms> Interesting...
20:58:49 <nirik> -1 here
20:59:15 <pjones> there's only 6 of us here, right?
20:59:27 <mjg59> +1
20:59:33 <hicham> that would solve future conflicts, I agree with mjg59
20:59:43 <mjg59> pjones: Yeah, so +5 is still possible
20:59:49 <nirik> pjones: I thought we only had 5 exactly... but I could have
miscounted.
21:00:07 <nirik> SMParrish isn't active, but is in channel. ;)
21:00:12 <pjones> Oh, okay.
21:00:15 <pjones> so this can't pass.
21:00:24 <notting> i'm leery of carte blanche in case they do something
really dumb. but i suppose that could be an exception
21:00:29 <Oxf13> needing unanimity kind of sucks.
21:00:43 <pjones> notting: we can always *revoke* it.
21:00:44 <nirik> well, you could try again next week when more folks were
around.
21:00:47 <ajax> who said unanimity.
21:01:18 <gholms> How about bringing up and voting on both proposals both
here and in the ticket? There's no reason you can't vote on both types of
exceptions.
21:01:53 <notting> i'm ok with voting in ticket in an attempt to get quorum
21:01:58 <mjg59> Yeah
21:02:04 <ajax> wfm
21:02:11 <nirik> just as a side note, does anyone have problems with an
iceweasel package being in fedora provided it passes review, etc?
21:02:21 <pjones> nirik: yes
21:02:37 <gholms> It would need to update side-by-side with firefox.
21:02:38 <nirik> ok would someone like to update the ticket?
21:02:45 <pjones> Seriously, if we're against having dupicate libraries, how
can we be fore having duplicate application code?
21:02:45 <hicham> i am against such a package
21:02:47 <nirik> pjones: out of curiosity, what?
21:02:53 <pjones> for
21:03:06 <hicham> ice* browsers are useless
21:03:12 <mjg59> I would be in favour of out firefox package being
*trivially* rebrandable
21:03:18 <hicham> just rebranding+destructive patches
21:03:22 <notting> nirik: it strikes me as a petty waste of resources
21:03:28 <mjg59> So that downstreams can handle this more easily
21:03:47 <nirik> if an iceweasel package was in, was well maintained and had
an active community of packagers, I would be much more likely to drop
firefox. (ie, find out if it's viable before we move to it)
21:04:04 <nirik> anyhow, I guess I am going off topic.
21:04:04 <notting> mjg59: can you put your global and local(vpx-only)
proposals in the ticket for voting
21:04:13 <mjg59> notting: Sure
21:04:22 <pjones> nirik: we know it's /viable/, don't we? since debian
does
it within reason.
21:04:56 <notting> nirik: imo, it makes sense to have ff or iw. not both
21:04:57 <nirik> I don't know how well it works there...
21:05:07 <ajax> i feel like we've now spent more time talking about this
than it would require to patch both the firefox and system versions of vpx
in the event of a security problem.
21:05:11 <nirik> #agreed will vote on proposals in ticket.
21:05:28 <nirik> shall we move on then?
21:05:32 <ajax> please.
21:05:36 <notting> ajax: i have no doubts about mofoco's ability to push new
security releases at a rapid pace
21:05:39 <pjones> yes.
21:05:41 <pjones> move on.
21:05:43 <nirik> #topic Open Floor
21:05:48 <nirik> anyone have anything for open floor?
21:06:00 * gholms raises hand
21:06:07 <nirik> gholms: go ahead
21:06:48 <gholms> I have a rel-eng ticket that could result in very a minor
distro-wide change. If any of you have any input on it I would appreciate
hearing from you.
21:06:52 <gholms> .releng 4149
21:06:52 <zodbot> gholms: Ticket #4120 (task closed): Override tag request
for rubygem-hoe || Ticket #4156 (task closed): task 2513514 stuck in tests
|| Ticket #4158 (task created): tag banshee-1.8.0-4.fc14
gio-sharp-0.2-2.fc14 libgpod-sharp-0.7.95-1.fc14 gudev-sharp-0.1-3.fc14
gkeyfile-sharp-0.1-3.fc14 gtk-sharp-beans-2.14.0-2.fc14 || Ticket #4157
(task created): Please tag nss-softokn-3.12.8-1.fc12
nss-softokn-3.12.8-1.fc13 (12 more messages)
21:07:07 <gholms> Err, that didn't work so well.
21:07:13 <gholms> https://fedorahosted.org/rel-eng/ticket/4149
21:07:35 <Oxf13> .rel 4149
21:07:36 <zodbot> Oxf13: #4149 (Need a way to point EC2 instances to
specific mirrors) - Fedora Release Engineering - Trac -
https://fedorahosted.org/rel-eng/ticket/4149
21:07:45 <gholms> Thanks
21:08:00 * nirik is happy with whatever solution folks interested come up
with there. ;)
21:09:25 <notting> yeah, i'm ok with whatever the yum and MM people agree on
21:09:41 <ajax> up, enter
21:10:11 <notting> gholms: have the MM maintainers chimed in yet?
21:10:47 <gholms> mdomsch added the needed MM support already.
21:11:18 <gholms> It isn't released yet, but it's there.
21:11:37 <pjones> totally okay with it then.
21:11:38 <mdomsch> yep
21:11:47 <notting> sweet. if you need the repo def changed, plz file a
blocker bug against fedora-release
21:11:53 <mdomsch> needs some testing, but is pretty straightforward
21:12:04 <mdomsch> notting: with the config plugin, we shouldn't need to
21:12:11 <gholms> How soon should such a bug be filed?
21:12:12 <mdomsch> and I prefer not to
21:12:27 <notting> i thought the yum folks said they'd prefer a non-plugin
solution
21:12:39 <gholms> mdomsch: skvidal and Oxf13 are saying avoiding a plugin
would be better.
21:13:01 <mdomsch> oh? I missed that. I thought skvidal was on board,
exactly so we get
21:13:07 <mdomsch> a) dynamic operation
21:13:13 <mdomsch> b) no munging the config file
21:13:23 <Oxf13> I defer to skvidal on how it should operate
21:13:31 <Oxf13> my only contribution that I like was adding a tag to the MM
url string
21:13:35 <mdomsch> a) being that we can grab the value every time yum runs,
rather than when the AMI is created
21:13:38 <Oxf13> how that tag gets added isn't as much of a concern of mine
21:13:42 <gholms> With the currently-favored solution we change the *stock*
repo configs.
21:13:59 <notting> gholms: right, which is a blocker bug against
fedora-release
21:14:00 <nirik> anyhow, sounds like we are fine with whatever you guys come
up with. ;)
21:14:01 <gholms> Those can stay the same, and the value gets filled in a
different file at boot time. Simple!
21:14:08 <gholms> Sounds good.
21:14:08 <notting> gholms: (or, you do it in appliance-tools)
21:14:21 <gholms> notting: Read the wiki page; there are problems with that
approach.
21:15:02 <pjones> mdomsch: okay, so it sounds like you and skvidal need to
make sure you're on the same page - aside from that, I think a lot of us
will defer to you two.
21:16:07 <nirik> Any other open floor items?
21:17:34 * nirik will close the meeting in a minute if nothing else comes
up.
21:18:39 <nirik> #endmeeting
Interesting, from the meeting we can tell
1) A number of people want to give Mozilla an exception.
2) BRANDING is an issue, like I said in another thread. Which is why
people are against removing it.
3) Maintainers for Mozilla aren't being expected to follow package
guidelines, citing the use of system libs as a source of extra work.
4) People still seem to think that Iceweasel is somehow inferior to
Firefox. Plus if Fedora removed the branding it wouldn't remove
compatibility, source code, plugin support and wouldn't introduce
so-called "sketchy" patches.
8:27 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2010-10-05)
On Wed, Oct 06, 2010 at 08:29:32 -0400,
Brandon Lozza <brandon(a)pwnage.ca> wrote:
Interesting, from the meeting we can tell
1) A number of people want to give Mozilla an exception.
2) BRANDING is an issue, like I said in another thread. Which is why
people are against removing it.
People have claimed that the Firefox brand helps Fedora. I'd like to see
some measurement of this. Especially in our target audience.
3) Maintainers for Mozilla aren't being expected to follow
package
guidelines, citing the use of system libs as a source of extra work.
Yes and no. There are suggestions that Mozilla does eventually intend
to use the upstream libraries once they are considered good enough
(except for maybe libpng because of the fork) and so the exception is
temporary per library.
4) People still seem to think that Iceweasel is somehow inferior to
Firefox. Plus if Fedora removed the branding it wouldn't remove
compatibility, source code, plugin support and wouldn't introduce
so-called "sketchy" patches.
I don't think that just debranding Firefox would be all that much extra
work. Doing that would leave us positioned to do other changes when we
were ready and to be able to more quickly respond to security issues.
Replacing on of the library dependencies would be work and doing all of
those might not currently be sustainable. Also the maintainers of the
affected libraries in Fedora would need to help as there are patches in
Firefox for some libraries that aren't upstream.
There was also talk about whether or not it would be allowed for there
to be a separate Iceweasel package in Fedora. This might be done to
test the feasibility of maintaining it. There were mixed feelings about
this amoung FESCO.
4:45 p.m.
New subject: Summary/Minutes for today's FESCo meeting (2010-10-05)
Bruno Wolff III wrote:
There was also talk about whether or not it would be allowed for
there
to be a separate Iceweasel package in Fedora. This might be done to
test the feasibility of maintaining it. There were mixed feelings about
this amoung FESCO.
This is essentially not feasible because most of the disputed patches are in
xulrunner, and a hypothetical separate Iceweasel package would share
xulrunner with Firefox, unless we have even more bundled libraries.
I also don't see what we have to gain from shipping both.
So it's really an either-or situation.
IMHO, the version which is not compliant with our guidelines needs to go
away, period. We need to stop treating Mozilla specially, it needs to be
held by the same rules as any other upstream. If they don't cooperate, it's
the maintainer's job to fix things or orphan it. If nobody picks it up when
orphaned, it should be retired like any other package. Firefox is NOT an
essential package, the GNOME spin could just ship Epiphany (GNOME's default
browser) instead, and other desktop spins ALREADY ship the respective
desktop's default instead of Firefox!
Kevin Kofler
9:51 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2010-10-05)
On Wed, Oct 13, 2010 at 5:45 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Bruno Wolff III wrote:
> There was also talk about whether or not it would be allowed for there
> to be a separate Iceweasel package in Fedora. This might be done to
> test the feasibility of maintaining it. There were mixed feelings about
> this amoung FESCO.
This is essentially not feasible because most of the disputed patches are in
xulrunner, and a hypothetical separate Iceweasel package would share
xulrunner with Firefox, unless we have even more bundled libraries.
I also don't see what we have to gain from shipping both.
So it's really an either-or situation.
IMHO, the version which is not compliant with our guidelines needs to go
away, period. We need to stop treating Mozilla specially, it needs to be
held by the same rules as any other upstream. If they don't cooperate, it's
the maintainer's job to fix things or orphan it. If nobody picks it up when
orphaned, it should be retired like any other package. Firefox is NOT an
essential package, the GNOME spin could just ship Epiphany (GNOME's default
browser) instead, and other desktop spins ALREADY ship the respective
desktop's default instead of Firefox!
Kevin Kofler
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
It doesn't help when a majority of voting FESCo members are biased
Firefox users who seem to hate the idea of Iceweasel (based on what I
gather from their meeting notes). There seem to be some preconceptions
about what happens when you remove the branding. No conclusive data
can be provided to indicate how much users Firefox brings the distro.
I also don't appreciate the comment at the meeting about "non
contributing" members on the mailing list complaining about this
issue. It's an argument often used to ignore people with valid
arguments who also don't happen to have a computer science degree.
Some of us advocate Fedora and that in itself is a contribution.
Fedora consists of volunteers in many areas, not all of them make
packages or write code.
9:57 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2010-10-05)
On Thu, Oct 14, 2010 at 10:51:08AM -0400, Brandon Lozza wrote:
It doesn't help when a majority of voting FESCo members are
biased
Firefox users who seem to hate the idea of Iceweasel (based on what I
gather from their meeting notes). There seem to be some preconceptions
about what happens when you remove the branding. No conclusive data
can be provided to indicate how much users Firefox brings the distro.
Actually, I generally use epiphany.
I also don't appreciate the comment at the meeting about
"non
contributing" members on the mailing list complaining about this
issue. It's an argument often used to ignore people with valid
arguments who also don't happen to have a computer science degree.
Some of us advocate Fedora and that in itself is a contribution.
Fedora consists of volunteers in many areas, not all of them make
packages or write code.
I should point out that my degrees are in biology and biology, and the
one that I haven't quite got yet is in biology.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
6:42 p.m.
New subject: Summary/Minutes for today's FESCo meeting (2010-10-05)
On Thu, 14 Oct 2010 10:51:08 -0400
Brandon Lozza <brandon(a)pwnage.ca> wrote:
It doesn't help when a majority of voting FESCo members are
biased
Firefox users who seem to hate the idea of Iceweasel (based on what I
gather from their meeting notes).
I use midori here. Every once in a great while I will run firefox to
look at something or see some behavior, but I almost never have it
running. Please don't speak for others when you don't really know the
answer to the question.
There seem to be some preconceptions
about what happens when you remove the branding. No conclusive data
can be provided to indicate how much users Firefox brings the distro.
Indeed.
I also don't appreciate the comment at the meeting about
"non
contributing" members on the mailing list complaining about this
issue. It's an argument often used to ignore people with valid
arguments who also don't happen to have a computer science degree.
Some of us advocate Fedora and that in itself is a contribution.
Fedora consists of volunteers in many areas, not all of them make
packages or write code.
Sure. I agree, but just discussing something or being vocal about it
means you expect someone else to do the work. In an all volunteer setup
like Fedora, you may have to realize that this means it won't be done
unless someone steps up to do it.
kevin
6:29 p.m.
New subject: Summary/Minutes for today's FESCo meeting (2010-10-05)
On Wed, 2010-10-13 at 23:45 +0200, Kevin Kofler wrote:
Firefox is NOT an
essential package, the GNOME spin could just ship Epiphany (GNOME's default
browser) instead, and other desktop spins ALREADY ship the respective
desktop's default instead of Firefox!
Epiphany is still not serious about security:
https://bugzilla.redhat.com/show_bug.cgi?id=643224
Until this changes, I definitely won't use it.
--
Matt
1:52 p.m.
New subject: Summary/Minutes for today's FESCo meeting (2010-10-05)
On Wed, 6 Oct 2010 08:29:32 -0400
Brandon Lozza <brandon(a)pwnage.ca> wrote:
...snip many tons of lines...
Can you please trim your replies?
Interesting, from the meeting we can tell
1) A number of people want to give Mozilla an exception.
2) BRANDING is an issue, like I said in another thread. Which is why
people are against removing it.
3) Maintainers for Mozilla aren't being expected to follow package
guidelines, citing the use of system libs as a source of extra work.
No, it's that upstream doesn't want them to unbundle those libs right
now, no matter how much work they are willing to do.
4) People still seem to think that Iceweasel is somehow inferior to
Firefox. Plus if Fedora removed the branding it wouldn't remove
compatibility, source code, plugin support and wouldn't introduce
so-called "sketchy" patches.
Do you have a f14 rpm for iceweasel people could try out and examine?
kevin
7:46 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2010-10-05)
On 10/05/2010 11:20 PM, Kevin Fenzi wrote:
===================================
#fedora-meeting: FESCO (2010-10-05)
===================================
...
19:59:38<nirik> some examples: dracut was updated in f12/13
with a bunch of patches. Were those all bugfixes?
19:59:59<pjones> if it's hard to tell, that means either a) we need to think
about how to make a generic exemplar of that case, or b) the packager needs to be telling
us more about the update
20:00:07<nirik> NetworkManager rebases to a git snapshot in all of
f12/f13/f14/rawhide at the same time.
20:00:19<pjones> And I think both of those are "b" there.
20:00:59<nirik> right, so more education...
20:01:12<mjg59> Ideally we'd have some means of identifying this
20:01:14<pjones> (obviously, there could be more classes of things; feel free to
bring them up if they're of consequence)
20:01:28<mjg59> But insisting that all changelog elements be flagged with a bug
just encourages people not to mention things in changelogs
20:01:46<nirik> yeah.
20:02:05<pjones> mjg59: If your changelog looks like this, it's "b"
in my list:
20:02:07<pjones> * Wed Sep 22 2010 Harald Hoyer<harald(a)redhat.com> 005-4 -
backported a lot of bugfixes from git
20:02:31<pjones> insisting that there's an actual changelog might be a start?
;)
Well, I could list all bugs found in F12,F13,F14 in the changelog, which are
also displayed in https://admin.fedoraproject.org/updates/dracut-005-4.fc13
But I cannot list all the RHEL6 bugs.
It's basically a new dracut version, but I tried only to cherry-pick the
relevant patches of dracut upstream for the bugfixes + known bugs without
bugzillas + patches needed for the cherry-picking.
It was a decision of:
- backport only the bugfixes + new code to adapt for the backporting (which
might introduce new bugs)
or
- cherry-picking tested code, which fixes the bugs + tested patches needed for
the cherry-picking
so I chose the latter and cherry-picked.
+Patch42: 0042-kernel-modules-add-more-hardcoded-modules.patch
+Patch43: 0043-dracut-functions-use-udevadm-to-get-ID_FS_.patch
+Patch44: 0044-dracut.conf-use-as-default-for-config-variables.patch
+Patch45: 0045-znet-use-ccw-init-and-ccw-rules-from-s390utils-in-dr.patch
+Patch46: 0046-znet-renamed-rd_CCW-to-rd_ZNET.patch
+Patch47: 0047-fcoe-add-sbin-vconfig-and-the-8021q-kernel-module.patch
+Patch48: 0048-dracut.8-fix-rd_LVM_LV-description.patch
+Patch49: 0049-plymouth-only-display-luksname-and-device-for-multip.patch
+Patch50: 0050-dracut.spec-remove-elfutils-libelf-requirement.patch
+Patch51: 0051-use-grep-directly-without-nm-to-drop-binutils-requir.patch
+Patch52: 0052-plymouth-plymouth-populate-initrd-get-rid-of-awk.patch
+Patch53: 0053-dracut-get-rid-of-the-file-command.patch
+Patch54: 0054-dracut.spec-clean-up-the-requirements.patch
+Patch55: 0055-90mdraid-dracut-functions-fix-md-raid-hostonly-detec.patch
+Patch56: 0056-40network-parse-ip-opts.sh-add-ip-auto6-to-valid-opt.patch
+Patch57: 0057-40network-dhclient-script-be-more-verbose.patch
+Patch58: 0058-40network-ifup-be-more-verbose.patch
+Patch59: 0059-TEST-50-MULTINIC-do-not-provide-a-cdrom-in-the-testc.patch
+Patch60: 0060-95fcoe-fcoe-up-wait_for_if_up.patch
+Patch61: 0061-get-rid-of-rdnetdebug.patch
+Patch62: 0062-95znet-removed-55-ccw.rules-and-ccw_init.patch
+Patch63: 0063-Makefile-make-more-clean.patch
+Patch64: 0064-selinux-loadpolicy.sh-exit-for-selinux-0.patch
+Patch65: 0065-dracut-functions-check-if-specific-dracut-module-is-.patch
+Patch66: 0066-multipath-simplify-and-install-wwids-rhbz-595719.patch
+Patch67: 0067-multipath-remove-multipath-udev-rules-if-no-multipat.patch
+Patch68: 0068-90crypt-crypto_LUKS-identifier-corrected.patch
+Patch69: 0069-selinux-move-selinux-to-a-separate-module.patch
+Patch70: 0070-plymouth-cryptroot-ask.sh-beautify-password-prompt.patch
+Patch71: 0071-network-depend-on-ifcfg-if-etc-sysconfig-network-scr.patch
+Patch72: 0072-network-strip-pxelinux-hardware-type-field-from-BOOT.patch
+Patch73: 0073-dracut.spec-moved-znet-to-dracut-network.patch
+Patch74: 0074-Write-rules-for-symlinks-to-dev-.udev-rules.d-for-la.patch
+Patch75: 0075-dracut-functions-set-LANG-C-for-ldd-output-parsing.patch
+Patch76: 0076-dracut-functions-use-LC_ALL-C-rather-than-LANG-C.patch
+Patch77: 0077-dmsquash-resume-do-not-name-the-dev-.udev-rules-like.patch
+Patch78: 0078-dmsquash-live-mount-live-image-at-dev-.initramfs-liv.patch
+Patch79: 0079-dmsquash-live-depend-on-dm-module.patch
+Patch80: 0080-dmsquash-live-do-not-umount-dev-.initramfs-live-for-.patch
+Patch81: 0081-plymouth-depend-on-crypt-if-cryptsetup-exists.patch
+Patch82: 0082-dracut.spec-removed-duplicate-COPYING.patch
+Patch83: 0083-Just-look-for-cryptroot-instead-of-sbin-cryptroot.patch
+Patch84: 0084-Have-cryptroot-ask-load-dm_crypt-if-needed.patch
+Patch85: 0085-crypt-assemble-70-luks.rules-dynamically.patch
+Patch86: 0086-cryptroot-ask-s-getargs-rd_NO_CRYPTTAB-getarg-rd_NO_.patch
+Patch87: 0087-crypt-parse-crypt.sh-fix-end-label-for-luks-udev-rul.patch
+Patch88: 0088-crypt-wait-for-all-rd_LUKS_UUID-disks-to-appear.patch
+Patch89: 0089-dracut-lib.sh-getarg-returns-the-value-of-the-last-a.patch
+Patch90: 0090-dracut-fixed-stripping-of-kernel-modules.patch
+Patch91: 0091-conffile-before-confdir.patch
+Patch92: 0092-selinux-fixed-error-handling-for-load-policy.patch
+Patch93: 0093-btrfs-add-hostonly-check.patch
+Patch94: 0094-lvm-wait-for-all-rd_LVM_LV-and-rd_LVM_VG-specified-t.patch
+Patch95: 0095-90crypt-keys-on-external-devices-support.patch
+Patch96: 0096-crypt-remove-emergency-source-of-dracut-lib.sh.patch
+Patch97: 0097-dracut-functions-fix-m-a-handling.patch
+Patch98: 0098-removed-redundant-64-lvm.rules-install.patch
+Patch99: 0099-crypt-strip-luks-from-rd_LUKS_UUID.patch
+Patch100: 0100-crypt-loop-until-all-non-busy-crypt-devs-closed.patch
+Patch101: 0101-dracut-functions-fix-check-255-logic-and-dependencie.patch
+Patch102: 0102-crypt-fix-printf.patch
+Patch103: 0103-mdraid-remove-local.patch
+Patch104: 0104-mdraid-remove-mdadm.conf-on-rd_NO_MDADMCONF.patch
+Patch105: 0105-dracut-lib.sh-fixed-getarg-for-nonexistent-parameter.patch
+Patch106: 0106-mkdir-dev-.udev-rules.d-with-mode-0755.patch
+Patch107: 0107-init-create-dev-.udev-rules.d-with-correct-permissio.patch
+Patch108: 0108-dracut-functions-fixed-omit.patch
+Patch109: 0109-Harden-check-for-used-modules-in-hostonly-mode.patch
+Patch110: 0110-fips-udev-trigger-with-action-add.patch
+Patch111: 0111-dracut-let-fwdir-be-specified-multiple-times.patch
+Patch112: 0112-dracut-functions-use-proc-self-mountinfo-instead-of-.patch
+Patch113: 0113-dracut-add-fstab-to-ignore-proc-self-mountinfo.patch
+Patch114: 0114-plymouth-load-dm_crypt-module.patch
+Patch115: 0115-crypt-depend-on-dm.patch
+Patch116: 0116-plymouth-udev-trigger-with-action-add.patch
+Patch117: 0117-dm-install-all-md-dm-kernel-modules.patch
+Patch118: 0118-mkinitrd-do-not-call-dracut-in-host-only-mode.patch
+Patch119: 0119-dmraid-switch-to-rd_NO_MDIMSM-if-no-mdadm-installed.patch
+Patch120: 0120-mknod-with-mode-and-set-umask-for-the-rest.patch
+Patch121: 0121-plymouth-do-not-create-hvc0.patch
+Patch122: 0122-init-set-old-umask-before-switch_root.patch
+Patch123: 0123-init-do-not-set-umask-yet.patch
+Patch124: 0124-lvm-also-handle-LVM1-volumes.patch
+Patch125: 0125-dracut-functions-filter_kernel_modules-search-in-ext.patch
+Patch126: 0126-dracut-lib-and-usr-lib-dirs-detection.patch
+Patch127: 0127-lvm-install-lvm-mirror-and-snaphot-libs.patch
+Patch128: 0128-lvm-support-for-dynamic-LVM-SNAPSHOT-root-volume.patch
+Patch129: 0129-95fstab-sys-mount-all-etc-fstab.sys-volumes-before-s.patch
+Patch130: 0130-TEST-12-RAID-DEG-mark-test-failed-for-multiple-dummy.patch
+Patch131: 0131-test-double-disk-space-for-root-images.patch
+Patch132: 0132-network-kill-9-dhclient-if-normal-kill-does-not-succ.patch
+Patch133: 0133-md-do-not-use-no-degraded-for-incremental-mode.patch
7:53 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2010-10-05)
On Wed, Oct 06, 2010 at 02:46:28PM +0200, Harald Hoyer wrote:
But I cannot list all the RHEL6 bugs.
Why not? Strip partner names if necessary, but please make it possible
for people to decide whether a given update is a benefit to them.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
10:59 a.m.
New subject: Summary/Minutes for today's FESCo meeting (2010-10-05)
Matthew Garrett (mjg59(a)srcf.ucam.org) said:
> But I cannot list all the RHEL6 bugs.
Why not? Strip partner names if necessary, but please make it possible
for people to decide whether a given update is a benefit to them.
Well, he could list them in the bug field, but bodhi would elide
them in the updates advisory. He could do double duty and list
them all in the changelog, but that's getting a bit extreme when
it comes to 100 patches.
Bill
12:20 p.m.
New subject: Summary/Minutes for today's FESCo meeting (2010-10-05)
On 10/06/2010 05:59 PM, Bill Nottingham wrote:
Matthew Garrett (mjg59(a)srcf.ucam.org) said:
>> But I cannot list all the RHEL6 bugs.
>
> Why not? Strip partner names if necessary, but please make it possible
> for people to decide whether a given update is a benefit to them.
Well, he could list them in the bug field, but bodhi would elide
them in the updates advisory. He could do double duty and list
them all in the changelog, but that's getting a bit extreme when
it comes to 100 patches.
Bill
here we go:
https://admin.fedoraproject.org/updates/dracut-005-5.fc13
https://admin.fedoraproject.org/updates/dracut-005-5.fc12
Patches are here:
short URL: http://goo.gl/23Bu
http://pkgs.fedoraproject.org/gitweb/?p=dracut.git;a=tree;h=refs/heads/f1...
1:53 p.m.
New subject: Summary/Minutes for today's FESCo meeting (2010-10-05)
On Wed, 06 Oct 2010 19:20:55 +0200
Harald Hoyer <harald(a)redhat.com> wrote:
Thanks.
This seems like a lot of change for stable releases, but if they are
all bugfixes that might matter to those users I suppose it makes sense.
Thanks for adding more details.
kevin
4942
days inactive
4952
days old
14 comments
8 participants
participants (8)
-
Bill Nottingham -
Brandon Lozza -
Bruno Wolff III -
Harald Hoyer -
Kevin Fenzi -
Kevin Kofler -
Matt McCutchen -
Matthew Garrett