Summary/Minutes for today's FESCo meeting (2010-10-05)

[Brandon Lozza]

On 10/5/10, Kevin Fenzi <kevin at 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-05-19.30.log.html
>
> 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 at 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-05-19.30.log.txt
> 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.