#fedora-meeting: FESCO (2010-04-27)
Meeting started by nirik at 19:00:01 UTC. The full logs are available at
* init process (nirik, 19:00:01)
* #351 Create a policy for updates - status report on implementation
* #340 Determine and approve F11 end of life date (nirik, 19:08:35)
* LINK: http://fedoraproject.org/wiki/LifeCycle says both "13 months"
and N+1 (mjg59, 19:10:48)
* AGREED: move f11 eol date to 2010-06-18 to match the change in F13
release. (nirik, 19:16:31)
* #364 New Sponsor Request: Alex Kurtakov (nirik, 19:24:18)
* AGREED: Alex Kurtakov approved for Sponsor. (nirik, 19:26:52)
* #366 Sponsor self-nomination: oget (nirik, 19:27:28)
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=483301#c7
* AGREED: oget approved as sponsor (nirik, 19:33:29)
* #369 Mozilla trademark guidelines (nirik, 19:33:59)
* AGREED: continue with current procedures. fesco encourages that a
t-bird package with the IMAP patch get in testing ASAP. given the
communication issues aroudn the priority/severity of the bug, we
strongly encourage more people to become involved in triage and
co-maintainership. (nirik, 19:53:23)
* FES tickets / status updates (nirik, 19:54:33)
* LINK: https://fedorahosted.org/fedora-engineering-services/report/6
* Open Floor (nirik, 19:59:43)
* LINK: https://fedoraproject.org/wiki/Elections (nirik, 20:00:22)
Meeting ended at 20:03:39 UTC.
19:00:01 <nirik> #startmeeting FESCO (2010-04-27)
19:00:01 <nirik> #meetingname fesco
19:00:01 <nirik> #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones cwickert mjg59
19:00:01 <nirik> #topic init process
19:00:02 <zodbot> Meeting started Tue Apr 27 19:00:01 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:07 <mjg59> Afternoon
19:00:07 <zodbot> The meeting name has been set to 'fesco'
19:00:08 <zodbot> Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 nirik notting pjones skvidal
19:00:11 * skvidal is here
19:00:52 <Kevin_Kofler> Present.
19:01:11 <mjg59> Like I mentioned on-list, I may not be responsive for half an hour
19:01:17 * notting is here
19:01:26 * cwickert is here too
19:01:37 <mjg59> I'll try to stay online, though
19:01:42 <nirik> mjg59: no worries.
19:02:24 <ajax> i think so, brain, but if we didn't have ears, we'd look like weasels.
19:02:44 <nirik> pjones / dgilmore : around?
19:03:19 <nirik> I guess we can go ahead and get started...
19:03:33 <nirik> #topic #351 Create a policy for updates - status report on implementation
19:03:44 <nirik> I suck and have been busy this last week, so I haven't done much here.
19:03:53 <nirik> we need to work on populating the new groups and such.
19:04:04 <nirik> I will try and work on it this week, but any help very welcome.
19:04:12 * cwickert wonders what is still unclear... the critical path groups?
19:04:19 <Kevin_Kofler> We just need to give up, this policy is just not implementable.
19:04:21 <nirik> cwickert: yes. We need to make them.
19:04:35 <cwickert> nirik: ok, I can work on Xfce and LXDE then
19:04:41 <nirik> that would be great.
19:04:50 <cwickert> where is the right place for suggestions?
19:04:53 <gholms> Anyone happen to have a link to the current policy?
19:05:06 <nirik> Kevin_Kofler: can you bring up the issue at the next KDE sig meeting and see if you can come up with a group that everyone likes?
19:05:15 <nirik> .fesco 351
19:05:18 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351
19:05:23 <gholms> Thanks
19:05:36 <cwickert> https://fedoraproject.org/wiki/Package_update_acceptance_criteria
19:05:51 <nirik> any further constructive thoughts on this? or shall we move along?
19:06:10 <mjg59> I guess we can move along
19:06:11 <Kevin_Kofler> nirik: So what do you want? A list of packages KDE SIG considers critical?
19:06:14 <cwickert> nirik: should I just write this down in the wiki?
19:06:25 <nirik> Kevin_Kofler: yes
19:06:42 <nirik> cwickert: how about a git patch/diff for comps?
19:06:47 <notting> cwickert: or send a patch for comps
19:06:52 <cwickert> notting: ok
19:07:01 <Kevin_Kofler> What if we come up with the empty set?
19:07:18 <ajax> then you're admitting you don't value stability
19:07:24 <ajax> that's a thing you can do, i suppose.
19:07:36 <notting> if you think none of your packages are critical... sure?
19:07:42 <cwickert> Kevin_Kofler: then you obviously haven't learned anything
19:07:51 <nirik> that makes me wonder if we should be shipping a kde desktop then to our users.
19:07:58 <Kevin_Kofler> But I'll bring this up at the next KDE SIG meeting.
19:08:10 <Kevin_Kofler> In fact I can add it to the agenda in the wiki right now.
19:08:16 <nirik> Kevin_Kofler: thanks.
19:08:18 <mjg59> Kevin_Kofler: That's great, thanks
19:08:23 <nirik> ok, moving along.
19:08:25 <cwickert> nirik: please don't punish the KDE users for a single dogmatic maintainer
19:08:35 <nirik> #topic #340 Determine and approve F11 end of life date
19:08:41 <nirik> cwickert: yeah, sorry...
19:08:45 <nirik> .fesco 340
19:08:45 <skvidal> nirik: how's tomorrow?
19:08:45 <zodbot> nirik: #340 (Determine and approve F11 end of life date) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/340
19:08:48 <skvidal> tomorrow seems good
19:08:52 <Oxf13> worksforme
19:08:54 <cwickert> skvidal: +1
19:08:59 <nirik> So, we decided a date... but then we had a slip of a week.
19:09:06 <nirik> do we push out a week? or just leave it the same?
19:09:06 <Kevin_Kofler> -1 to tomorrow. :-)
19:09:09 <skvidal> nirik: a week from tomorrow?
19:09:26 <notting> might as well reflect the schedule slip
19:09:26 * dgilmore is here
19:09:37 * nirik thinks we should just leave it as is.
19:09:44 <dgilmore> nirik: i say we leave the date as is
19:09:50 <dgilmore> i think its still fine
19:10:02 <nirik> do we promise N+1month anywhere?
19:10:24 <cwickert> I think we do
19:10:35 <dgilmore> we are 3 or 4 days off a month
19:10:38 <Oxf13> although I think it says "roughly"
19:10:48 <mjg59> http://fedoraproject.org/wiki/LifeCycle says both "13 months" and N+1
19:10:49 * gholms sees "about 13 months" on http://fedoraproject.org/wiki/LifeCycle
19:10:50 <dgilmore> we were just over a month
19:10:56 <dgilmore> now we are just under it
19:11:01 <Kevin_Kofler> Whatever date we set, we need to guarantee that the last push happens no earlier than the announced EOL date.
19:11:09 <cwickert> http://fedoraproject.org/wiki/LifeCycle#Maintenance_Schedule_Methodology
19:11:20 <gholms> " One month after GA of current release + 2 releases "
19:11:21 <nirik> yeah.
19:11:22 <Kevin_Kofler> It really makes no sense to announce an EOL date and to have the distro essentially unsupported for several days before that.
19:11:37 * jwb yawns
19:12:11 <nirik> Kevin_Kofler: sure it does. updates are not our only form of "support" for a distro.
19:12:47 <nirik> anyhow, votes on the topic?
19:12:55 <nirik> proposal: keep date the same.
19:13:00 <dgilmore> +1
19:13:10 <mjg59> If we keep the date the same, we should update http://fedoraproject.org/wiki/LifeCycle to be clear on that
19:13:31 <mjg59> Since it does have the "One month after GA of current release + 2 releases" text right now
19:13:34 <Kevin_Kofler> I'm for pushing it back at least a week.
19:13:45 * notting is -1. if we've got the policy, might as well follow it
19:13:47 <gholms> It also explicitly says, "Fedora 11 will be maintained until 1 month after the release of Fedora 13. "
19:13:53 <Kevin_Kofler> Plus clarifying that the definition of EOL is that the last update push happens on or after that announced date.
19:14:40 <cwickert> how about announcing the "last orders" two weeks before EOL and push then a week later?
19:14:42 * nirik doesn't care too much. I guess pushing it a week is ok too...
19:14:43 <Kevin_Kofler> In the past we have always worked that way and it's logical. Only recently jwb started this "we do the last push several days before EOL" nonsense.
19:14:54 <ajax> -1, follow the slip.
19:15:05 <cwickert> yeah, follow the slip
19:15:19 <Kevin_Kofler> -1 to keeping the date unchanged, follow the slip
19:15:39 <notting> Kevin_Kofler: huh? if we follow the slip, we move the date a week
19:15:59 <Kevin_Kofler> notting: I mean: -1 to keeping the date unchanged, +1 to following the slip
19:16:05 <nirik> ok, sounds like we push a week out... 2010-06-18
19:16:25 <mjg59> +1 to pushing out a week to match the 13 release
19:16:31 <nirik> #agreed move f11 eol date to 2010-06-18 to match the change in F13 release.
19:17:00 <Kevin_Kofler> Proposal: The last update push must happen on or after the announced EOL date, in order to match user expectations.
19:17:10 <Kevin_Kofler> +1 to my own proposal, obviously.
19:17:28 <nirik> after? why would we push an update to a release we no longer support?
19:17:41 <Kevin_Kofler> Because we missed the day of the EOL with our push?
19:17:54 <Oxf13> plan better
19:17:55 <Kevin_Kofler> And thus do one last late push?
19:18:04 <Kevin_Kofler> Oxf13: Tell that to jwb.
19:18:04 <mjg59> It's not clear to me that a push to -updates is an expected part of support
19:18:15 <Oxf13> EOL doesn't mean EOL, but we might do another push again, so just wait...
19:18:26 <Kevin_Kofler> He brought up that argument last time I suggested such a proposal.
19:18:45 <nirik> I would expect last push to be the day before eol, to allow for mirroring, etc.
19:18:45 <Kevin_Kofler> (He said "what if I just don't do the push?" My answer to that is: then it'll stay on your todo list until you do it.)
19:19:03 <Kevin_Kofler> Mirroring can happen after EOL just fine.
19:19:22 <cwickert> so are we arguing about a single day?
19:19:23 <mjg59> I think the proposal is based on an unsupported premise
19:19:24 <Kevin_Kofler> I remember very much FC6 getting a KDE update pushed on EOL day.
19:19:27 <cwickert> I cannot believe it
19:19:35 <Kevin_Kofler> It didn't cause issues for anybody.
19:19:53 <Kevin_Kofler> (FE6 got the matching updates rushed out at the very last moment, too.)
19:20:03 <Oxf13> I think the point is to do the "final push" a couple days before, in case said final push causes problems, so that we have time to do a quick fix of the problem
19:20:06 <nirik> how about we allow rel-eng to schedule/push updates as needed to match our EOL date.
19:20:09 <Oxf13> so that we don't leave the release in a broken state
19:20:12 <Oxf13> or go beyond the EOL date.
19:20:22 <Kevin_Kofler> Oxf13: That's another reason for my "on or after".
19:20:27 <drago01> does it matter? when it is EOL we expect people to move to a newer release ... a final push won't change anything
19:20:36 <Kevin_Kofler> We could do one last push after the official EOL date if things are broken.
19:20:38 <cwickert> Kevin_Kofler: I suggest you push out KDE 4.4.3 on the day when F11 goes EOL. then you have the great chance to break a lot of systems without needing to fix them
19:20:41 <Oxf13> Kevin_Kofler: then we just disagree on what the EOL date means.
19:20:42 <Kevin_Kofler> RHL 9 did get a post-EOL push.
19:20:50 <Kevin_Kofler> It's not unheard of at all.
19:20:57 <Kevin_Kofler> EOL doesn't mean "we delete everything now".
19:20:58 <Oxf13> the post-eol pushes are what we'd like to /avoid/
19:21:01 <Oxf13> not perpetuate
19:21:10 <dgilmore> Oxf13: right
19:21:30 <Oxf13> so we'll do a "final push" a few days before EOL. If nothing is broken great, it's done.
19:21:30 <Kevin_Kofler> For me, and I believe for most users, "EOL" means "the release is fully supported until that day, what happens after it is undefined".
19:21:34 <dgilmore> I think that releng can do its last push as suits
19:21:38 <Oxf13> if something is broken, we have time to fix it before EOL
19:21:42 <mjg59> I'm happy leaving this up to releng
19:21:49 <dgilmore> if there is something broken that really needs an additional push it will happen
19:22:16 <Oxf13> releng will be sure to announce loudly when we plan to do the final push.
19:22:23 <Kevin_Kofler> Your definition of "EOL" as "we won't do anything after that date no matter what, but the release may effectively already be dead a week or two before" is one you'll have a hard time to communicate to users.
19:22:31 <Kevin_Kofler> They'll think they still get security updates when in fact they don't!
19:22:41 <jwb> hey, shut up
19:22:48 <jwb> i push security updates until the EOL date
19:22:50 <mjg59> I don't see why releng would ever decide to knowingly skip a security update
19:22:52 <Oxf13> Kevin_Kofler: if somebody finds a critical security flaw in the 2 days before the final push and the EOL date, we can visit it then.
19:22:57 <jwb> i have the past 3 releases
19:23:14 * skvidal cannot figure out why we're bickering over this, STILL
19:23:24 <Oxf13> skvidal: KK.
19:23:27 <nirik> and hey, we are at 15min on this topic.
19:23:28 <mjg59> And I think actually trusting people to do their jobs when they have a good track record of doing so is better than us arguing over the precise timing of a hypothetical event
19:23:31 <nirik> votes to continue?
19:23:34 <mjg59> -1
19:23:37 <nirik> -1 here
19:23:40 <skvidal> -1
19:23:56 <dgilmore> skvidal: because Kevin_Kofler has to beat everyone up
19:23:58 <ajax> let's not continue please.
19:24:03 <dgilmore> -1 for the proposal
19:24:04 <Kevin_Kofler> OK, let's let this be a rel-eng matter, decentralization FTW. Not that I agree with rel-eng's position on this, but whatever.
19:24:06 <nirik> ok, moving on.
19:24:06 <skvidal> dgilmore: I'm glad I added him to /ignore long ago
19:24:10 <nirik> #364 New Sponsor Request: Alex Kurtakov
19:24:18 <nirik> #topic #364 New Sponsor Request: Alex Kurtakov
19:24:19 <dgilmore> skvidal: I put him on and off it
19:24:23 <nirik> .fesco 364
19:24:24 <zodbot> nirik: #364 (New Sponsor Request: Alex Kurtakov) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/364
19:24:56 <Kevin_Kofler> +1, all feedback was positive.
19:25:10 <nirik> there were 2 positive feedback replies from sponsors.
19:25:12 <notting> feedback was minimal, but positive. +1
19:25:38 <nirik> I'm +1 here as well... reviews I have seen have been good, and we can use java sponsors.
19:25:51 <cwickert> +1
19:26:12 * cwickert hates java so he is glad if someone else does it
19:26:23 <Kevin_Kofler> :-)
19:26:39 <ajax> +1 on overholt's recommendation
19:26:52 <nirik> #agreed Alex Kurtakov approved for Sponsor.
19:26:58 <mjg59> +1
19:27:07 <skvidal> +1
19:27:28 <nirik> #topic #366 Sponsor self-nomination: oget
19:27:32 <nirik> .fesco 366
19:27:34 <zodbot> nirik: #366 (Sponsor self-nomination: oget) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/366
19:28:11 <nirik> all posistive feedback here as well...
19:28:13 <dgilmore> +1 for oget
19:28:16 <nirik> positive rather.
19:28:17 <Kevin_Kofler> +1, all feedback positive, and lots of it.
19:28:25 <mjg59> +1 again
19:28:27 <skvidal> +0
19:28:30 <ajax> yay, more audio love. +1.
19:28:39 <notting> my only concern is his occasional "will not stop until pulseaudio is removed" diatribes
19:28:46 <cwickert> -+0 for oget
19:28:47 <Kevin_Kofler> notting: Same here.
19:28:49 * nirik had the same concern.
19:28:54 <cwickert> he is a little controversial
19:29:11 <Kevin_Kofler> But he's already a provenpackager, I don't think making him a sponsor gives him any more power to be dangerous.
19:29:14 <mjg59> If we removed everybody with wrong opinions from the project, we'd have far fewer developers
19:29:23 <skvidal> mjg59: and a far more peaceful day
19:29:25 <drago01> like 0 ?
19:29:38 <Kevin_Kofler> Hopefully he'll sponsor some audio and/or KDE contributors (and not only those who hate PulseAudio). ;-)
19:29:40 <mjg59> drago01: I was thinking 1, since I'm pretty sure I'm always right
19:29:58 <drago01> mjg59: hah!
19:30:06 <cwickert> things like https://bugzilla.redhat.com/show_bug.cgi?id=483301 make me doubt he is ready to be a sponsor
19:30:15 <cwickert> https://bugzilla.redhat.com/show_bug.cgi?id=483301#c7
19:31:20 <ajax> well, not wanting to talk to ralf isn't that surprising.
19:31:24 <Kevin_Kofler> ;-)
19:31:25 <skvidal> cwickert: it's ralf
19:31:25 <cwickert> and his "Fedora studio" feature was a mess IMHO, because it doesn't follow the FDO specs
19:31:39 <cwickert> skvidal, ajax: well ok
19:31:47 <nirik> I don't mind differing opinions. I think thats fine.
19:31:51 <Kevin_Kofler> In this case, Ralf was trying to enforce a nonexistent guideline, and in fact our guidelines were clarified to show that Orcan's position is correct in this case.
19:32:10 <Kevin_Kofler> (Epoch: 1 for upgrade path from a third-party repo is allowed. Ralf was trying to ban it.)
19:32:26 <cwickert> I still don't feel comfortable, but I don't agree if there is enough trust in Orcan
19:32:32 <notting> but given that we have assorted cantankerous people already as sponsors (including ralf!) , i'm ok with it. +1
19:32:41 <ajax> we can always take it back if it's enough of a problem.
19:32:43 <nirik> I do not like when you cause users to suffer by forcing your opinions into your packages. (ie, feel free to object to pulse, but it's distro default, so you should support it until it's not).
19:33:02 <cwickert> s/don't agree/don't mind
19:33:07 <nirik> I am a weak +1 as well...
19:33:19 <mjg59> Yeah, if there are problems then this can be revisited
19:33:29 <nirik> #agreed oget approved as sponsor
19:33:35 <Kevin_Kofler> nirik: Agreed with that part, but we already enforced PulseAudio support where it was needed (fluidsynth).
19:33:39 <mjg59> But we have no real reason to believe that these opinions will result in damage to the distribution as a whole at present, so...
19:33:46 <nirik> Kevin_Kofler: yeah, just history at this point.
19:33:50 * nirik nods.
19:33:54 <nirik> ok, moving on...
19:33:59 <nirik> #topic #369 Mozilla trademark guidelines
19:34:03 <nirik> .fesco 369
19:34:05 <zodbot> nirik: #369 (Mozilla trademark guidelines) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/369
19:34:27 <skvidal> how about we put this off until after I'm off of fesco?
19:34:28 <mjg59> So, my opinion is this:
19:34:35 <dgilmore> im all for dropping mozillas trademarks
19:34:41 <mjg59> 1) We do not require that packages be open for provenpackagers
19:34:49 <dgilmore> i think they hinder us too much and gain us little
19:34:53 <mjg59> 2) We generally do not force packagers to do things that they don't want to do
19:34:55 <nirik> My opinion on this one: Revisit if it's a cronic issue. I think this one was a problem with communication and people not realizing the severity of a bug upstream.
19:35:03 <Kevin_Kofler> mjg59: We do require it, except for exceptions we explicitly approved.
19:35:07 <mjg59> 3) The packagers have, in this case, said that the trademark issues are not the primary reason that this patch was missing
19:35:26 <Kevin_Kofler> Part of the proposal here is to overturn the approval of this exception.
19:35:49 <Kevin_Kofler> dgilmore: Agreed.
19:35:50 <mjg59> So my viewpoint is that while the trademark issues may cause problems, this is not a case where they did
19:36:22 <mjg59> And if the maintainers of the package do not feel that they cause them significant problems, there's no point in us trying to change things given that nobody's going to benefit as a result
19:37:11 <drago01> (and they won't change the way they maintain it even after removing the trademarks ... atleast that what I got from caillion's mail)
19:37:24 <mjg59> Right
19:37:30 <Kevin_Kofler> That's part of the issue.
19:37:37 <mjg59> So, given the current maintainers, there's no benefit in removing the trademarks
19:37:46 <mjg59> And I'm not going to vote to replace the maintainers
19:37:55 <Kevin_Kofler> I'm writing up a proposal, give me a few secs.
19:38:02 * skvidal thinks we'd have a hardtime replacing the maintainers anyway
19:38:04 * nirik notes there is still no patch for this issue landed.
19:38:36 * nirik waits eagerly for Kevin_Kofler's proposal.
19:39:13 <Kevin_Kofler> Proposal: The Firefox/Thunderbird/xulrunner stack must be opened to provenpackagers, the restrictive branding which blocks this must be removed. The Debian patch to use the system libffi must be applied per our "no bundled libs" policy. The system libpng must be used, be it by getting APNG support into it or by using Debian's patch to build xulrunner without APNG support. System integration patches such as openSUSE'
19:39:13 <Kevin_Kofler> s KDE integration patch must be considered on the merits of the value to our distro (including spins), not to upstream.
19:39:19 <rsc> nirik: there is a patch according to the ticket - but not accepted?
19:39:36 <nirik> rsc: it's accepted for the next release, but that release has not been made yet.
19:39:50 <rsc> nirik: bah. Then kill the trademark to get the fix now
19:40:09 <drago01> Kevin_Kofler: summary "fork firefox/thunderbird" ?
19:40:12 <mjg59> rsc: Please read caillon's mail on this
19:40:21 <notting> i thought, according to caillon's mail, the patch was being built for updates-testing today-ish
19:40:24 <nirik> and replace maintainers I guess.
19:40:32 <Kevin_Kofler> We wouldn't "fork" it any more than Debian does.
19:40:35 <nirik> notting: I haven't seen a commit yet, but it could be soon, yes.
19:40:54 <nirik> Is there a history of this happening? I can't recall one.
19:40:54 <Kevin_Kofler> We'd just be applying distro integration patches, and rebranding as upstream themselves suggest.
19:41:44 <rsc> mjg59: I less care about that. If we're not allowed to fix the bugs in software we ship, that's broken.
19:42:10 <Oxf13> rsc: it's not that we aren't allowed.
19:42:23 <Oxf13> the maintainer still wouldn't have put that patch in, as it hasn't been tested with the current release
19:42:35 <Kevin_Kofler> Then that's the maintainer's failure.
19:42:48 <rsc> Oxf13: I thought the trademark brand forbids modifications?
19:42:53 <Kevin_Kofler> OK, add to my proposal: The Thunderbird crash bug which triggered this discussion must be fixed ASAP.
19:43:02 <Oxf13> rsc: to some extent, but that wasn't the blocking item in this case.
19:43:04 <drago01> rsc: no it just requires upstream review
19:43:43 <nirik> I'd agree with Kevin_Kofler's proposal probibly if there was a history of problems with our current setup. This does not seem to be the case currently, so I am -1 to it at this time.
19:43:47 <Kevin_Kofler> So any thoughts about that proposal? Vote on it as is? Vote on each separate sentence?
19:44:15 <Kevin_Kofler> nirik: One problem is that Firefox looks and feels like crap in KDE, there's a patch out there to fix that and we aren't using it.
19:44:29 <nirik> Kevin_Kofler: get it upstreamed?
19:44:33 <Kevin_Kofler> Now maybe upstream would approve it, after all openSUSE is shipping it in a branded package.
19:44:43 <Kevin_Kofler> But it's just another silly roadblock.
19:44:56 <cwickert> I don't necessarily think that we need to go the Debian way at this point, but what about the libffi thing? it is a clear violation of our guidelines?
19:45:01 * nirik tries to resist saying "Like testing".
19:45:04 <Kevin_Kofler> Other concrete issues are that there are at least 2 bundled libs in xulrunner (and those are only the ones Debian fixed, there may be more).
19:45:13 <drago01> can we get $kernelmodule into the kernel even if it is not upstream and the mainatiners don't want to add it?
19:45:14 <Kevin_Kofler> Both libffi and libpng are bundled.
19:45:18 <drago01> sounds like the same to me
19:45:24 <drago01> and is wrong either way
19:45:25 <Kevin_Kofler> libpng is patched to support APNG, it won't build with the system copy because of that.
19:45:26 <nirik> My understanding is that the bundled libs have bugs filed and they are working on fixing them.
19:45:27 <dgilmore> firefox/xulrunner/ and freinds ship lots of bundled libraries
19:45:34 <Kevin_Kofler> (unless we patch the system libpng to support APNG)
19:46:40 <Kevin_Kofler> Debian has a patch to allow building xulrunner without APNG support.
19:46:49 <Oxf13> just because there is a patch doesn't make it right
19:46:51 <rsc> I don't see a good reason why Mozilla is allowed to bundle libraries (or even forks of libraries) while other software isn't allowed to do that.
19:46:52 <nirik> bundled libs should be fixed. sounds like they are working on it?
19:46:59 <Kevin_Kofler> Then get APNG support into the system libpng.
19:47:03 <Oxf13> that patch may change how the software works, in ways that upstream is not willing to accept.
19:47:03 <nirik> rsc: they aren't. They are bugs.
19:47:06 <Kevin_Kofler> (to Oxf13)
19:47:17 * notting is -1 to all of Kevin_Kofler's proposal, as a dictate
19:47:19 <nirik> should we remove firefox and rsync until they can do this?
19:47:20 <rsc> nirik: yes, but we don't fix them because of the trademark? Or because of the maintainer?
19:47:27 <rsc> nirik: yes, please
19:47:35 <nirik> rsc: because we don't have a upstreamable patch that does so.
19:47:36 <Kevin_Kofler> The problem is: upstream libpng refuses to ship APNG support, Mozilla refuses to build with a libpng without it.
19:47:45 <Kevin_Kofler> We have a policy not to bundle libraries.
19:47:47 <ajax> i'm not comfortable taking a stand against trademark guidelines that are more permissive than our own.
19:47:49 <Kevin_Kofler> So we HAVE to patch one or the other.
19:47:56 <Kevin_Kofler> Right now we're violating our policy on bundled libs.
19:48:08 <Oxf13> yep. Software integration is hard
19:48:14 <Oxf13> and you have to make choices.
19:48:26 <notting> it's not as if xulrunner/ff is the only app in the distro currently in violation
19:48:30 <Kevin_Kofler> IMHO in this case we should just patch libpng.
19:48:35 <Kevin_Kofler> That way Konqueror could support APNG too.
19:48:48 <Kevin_Kofler> (though that code is not written yet)
19:48:53 * nirik doesn't see firefox currently building a bundled libpng. I guess my grep could be in error.
19:48:58 <drago01> who uses apng anyway?
19:49:04 <Oxf13> nirik: could be xulrunner instead of ff?
19:49:05 <Kevin_Kofler> nirik: It's built statically.
19:49:11 <Kevin_Kofler> And linked into xulrunner.
19:49:12 <drago01> everything is either gif or flash
19:49:18 <drago01> but whatever
19:49:51 <nirik> ah, could well be.
19:50:04 <nirik> ok, we are at 15min now.
19:50:08 <nirik> votes to continue
19:50:17 <ajax> no, thank you.
19:50:30 <Kevin_Kofler> +1 to continuing
19:50:35 <nirik> +1 from me because we haven't decided anything. We should at least vote down the current proposal in the ticket.
19:51:20 <Kevin_Kofler> Let me check what the proposal in the ticket actually was.
19:51:28 <ajax> there isn't one?
19:51:42 <cwickert> +1 to continue
19:51:43 <notting> alternate proposal: continue with current procedures. fesco encourages that a t-bird package with the IMAP patch get in testing ASAP. given the communication issues aroudn the priority/severity of the bug, we strongly encourage more people to become involved in triage and co-maintainership.
19:51:58 <ajax> the ticket says "I am proposing that FESCo discuss and decide on the right solution to the current problem and the policy about such matters in general."
19:52:01 <skvidal> notting: +1
19:52:08 <Kevin_Kofler> -1 to notting.
19:52:11 <Kevin_Kofler> +1 to my own proposal.
19:52:12 <cwickert> notting: sounds reasonable, +1
19:52:22 <nirik> +1 to nottings proposal... revisit if this sort of problem becomes more common.
19:52:29 <ajax> +1 to notting
19:52:36 <Kevin_Kofler> notting's proposal doesn't solve the underlying problem at all.
19:52:44 <Kevin_Kofler> It'll just come back in a worse way sooner or later.
19:53:12 <skvidal> we have 5 for notting
19:53:13 <nirik> the underlying problem? yes, I agree we need better communication between fedora users/bugs and upstream to note severity of issues...
19:53:15 <Kevin_Kofler> And it doesn't solve any of the other blatant policy violations: bundled libs, being the only packages with an exemption from provenpackager commits etc.
19:53:15 <skvidal> counting himself
19:53:19 <skvidal> so it's passed, right?
19:53:23 <nirik> #agreed continue with current procedures. fesco encourages that a t-bird package with the IMAP patch get in testing ASAP. given the communication issues aroudn the priority/severity of the bug, we strongly encourage more people to become involved in triage and co-maintainership.
19:53:25 <nirik> yep.
19:53:29 <notting> i think we gain more from working closely with upstream than we'd gain with running willy-nilly with a patch gun.
19:53:46 <Kevin_Kofler> The underlying problem is that Mozilla's trademark diktats are given preference over our own policies and values (freedom).
19:54:08 <nirik> the trademark has nothing to do with the current issue.
19:54:13 <mjg59> Right
19:54:17 * nirik gives up and moves on.
19:54:19 <Kevin_Kofler> Plus, the fact that the primary maintainer has a conflict of interest.
19:54:33 <nirik> #topic FES tickets / status updates
19:54:33 <Kevin_Kofler> (caillon is also affiliated with upstream Mozilla.)
19:54:33 * notting suspects the current issue is being used as a prop.
19:54:36 <Oxf13> yes, he's interested in making sure changes are well tested
19:54:38 <nirik> https://fedorahosted.org/fedora-engineering-services/report/6
19:54:42 <Oxf13> boy that certainly conflicts with Fedora.
19:54:53 <nirik> mmcgrath: anything to note in FES this week?
19:54:53 <ajax> Kevin_Kofler: if you feel that these issues are worth discussing in more detail, please file them as fesco tickets.
19:55:00 <Kevin_Kofler> It does when the matter is Mozilla's policies being given preference over our own.
19:55:05 <mmcgrath> nirik: Just a couple of things
19:55:16 <Oxf13> Kevin_Kofler: [ citation needed ]
19:55:16 <mmcgrath> one sec
19:55:26 <nirik> I'd like to note to folks: http://lists.fedoraproject.org/pipermail/users/2010-April/371558.html if you have friday free and want to play some bzflag.
19:55:31 <Kevin_Kofler> Oxf13: Bundled libs, see the evidence I provided.
19:55:36 <Kevin_Kofler> And it's just one of the issues.
19:55:40 <mmcgrath> ajax: did you have a chance to look at https://fedorahosted.org/fedora-engineering-services/ticket/7
19:55:51 <ajax> mmcgrath: i did, it looks good, which i should note on the ticket.
19:55:55 <mmcgrath> <nod> excellent.
19:56:01 <Kevin_Kofler> Oxf13: I gave more in the ML thread.
19:56:07 <mmcgrath> other thent hat bruno broke out ftbfs into several groups, I've been getting those handed out.
19:56:14 <ajax> just need to get to testing and packaging it, but i've been away fighting intel gfx fires.
19:56:18 <nirik> also https://fedorahosted.org/fedora-engineering-services/ticket/19 could have someone work on xulrunner or other bundled libs packages. Sign right up.
19:56:18 <Oxf13> Kevin_Kofler: meeting moved on. Good luck on your crusade.
19:56:22 <mmcgrath> nirik: wrt the SIG ticket - https://fedorahosted.org/fedora-engineering-services/ticket/2
19:56:48 <mmcgrath> I chatted a bit with Jon on it, I guess everyone that didn't respond doesn't exist.... What's next?
19:57:40 <nirik> ok.
19:57:54 <nirik> well, we need to update the SIGs page... note inactive ones...
19:58:13 <nirik> and I would like to get a contact list of folks who said they can provide updates on their sig.
19:58:18 <nirik> I will update the ticket later today.
19:58:50 * mmcgrath doesn't have a list yet either
19:58:53 <mmcgrath> nirik: thanks, that's it.
19:59:22 <nirik> cool. As always feel free to comment/sign up for tickets if you think of good things that need doing.
19:59:43 <nirik> #topic Open Floor
19:59:52 <skvidal> nirik: the election stuff
19:59:54 <nirik> Anyone have anything for open floor?
19:59:56 <nirik> oh, right.
19:59:58 <skvidal> anyone been nominated yet?
20:00:16 <Kevin_Kofler> Is any additional info needed from KDE SIG for that SIG ticket?
20:00:22 <nirik> https://fedoraproject.org/wiki/Elections
20:00:41 <Kevin_Kofler> I don't remember having been contacted and I don't know whether anybody else from KDE SIG was.
20:01:11 <nirik> Kevin_Kofler: I was going to ask about it last week, but forgot, then I wasn't on line in time for the meeting this morning.
20:01:12 <nirik> sorry.
20:01:24 <nirik> skvidal: 2 for each of the board and fesco
20:01:26 <nirik> so far
20:01:53 <nirik> https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations and https://fedoraproject.org/wiki/Board/Elections/Nominations
20:02:03 <nirik> They all sound like shady characters so far.
20:02:43 <nirik> anyone have anything else? or shall we close out?
20:03:08 <ajax> nothing from me.
20:03:27 <nirik> ok, thanks for coming everyone!
20:03:39 <nirik> #endmeeting
devel mailing list