17:01:11 <t8m> #startmeeting FESCO (2011-10-10)
17:01:11 <zodbot> Meeting started Mon Oct 10 17:01:11 2011 UTC.  The chair is t8m. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:13 <dbhole_> Hi all. I won't be able to stay for the whole meeting. It is a holiday up here in Canada -- just came here to provide an update on #663 since I wasn't here last week. Rebuild for 663 are done according to rel-eng ticket 4932. I will be going through the list tomorrow to ensure that everything has indeed been rebuilt correctly.
17:01:27 <t8m> #meetingname fesco
17:01:27 <zodbot> The meeting name has been set to 'fesco'
17:01:34 <t8m> #chair notting nirik ajax cwickert mjg59 mmaslano t8m pjones sgallagh
17:01:34 <zodbot> Current chairs: ajax cwickert mjg59 mmaslano nirik notting pjones sgallagh t8m
17:01:41 <t8m> #topic init process
17:01:43 * nirik is here.
17:01:45 <t8m> Hello all
17:01:47 <mmaslano> hi
17:01:49 * notting is here. although i have to step out just before 2PM
17:01:58 <pjones> hello.
17:02:02 * sgallagh is here but juggling many things at the same time
17:02:21 <t8m> Hopefully we will be quick this time
17:03:03 <t8m> We can start I assume
17:03:08 <t8m> #topic #663 Late F16 Feature Java7
17:04:17 <t8m> According to the dbhole's update above he still needs to check that the rebuild was complete.
17:04:33 <t8m> .fesco 663
17:04:38 <zodbot> t8m: #663 (Late F16 Feature Java7) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/663
17:04:55 <dbhole_> Yes, it should be resolved. I just need to verify before closing the ticket
17:05:18 <nirik> I think it's all done.
17:05:21 <nirik> yeah
17:05:30 <t8m> dbhole_, fine
17:06:36 <t8m> OK, any comments?
17:06:52 * nirik has nothing more on this.
17:07:02 * dbhole_ doesn't either
17:07:04 <t8m> I suppose we can move on.
17:07:20 <t8m> #topic #667 Request to fix CRITPATH update process
17:07:22 <dbhole_> OK. Thanks everyone!
17:07:31 <t8m> .fesco 667
17:07:33 <zodbot> t8m: #667 (Request to fix CRITPATH update process) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/667
17:07:47 <mjg59> I asked Luke about the stats on proventester
17:08:00 <mjg59> He said it should be easy enough to do, but I don't have them yet
17:08:02 <mjg59> I'll follow up
17:08:36 <nirik> I also haven't heard on the ticket to allow the 2 week timeout.
17:08:36 <sgallagh> Didn't we make a decision on this last week?
17:08:40 <nirik> I can ask about that.
17:09:03 <sgallagh> Hmm, no one ever sent out the minutes last week
17:09:05 <nirik> also, we did have another proventester meetup... not sure we got very far, but we had various ideas.
17:09:20 <ajax> sgallagh: uh, yes i did.
17:09:40 <ajax> Message-id: <4E89F4D9.8010404@redhat.com>
17:10:13 <notting> think it was as a new thread start rather than a reply to agenda, but they were sent
17:10:38 <ajax> true enough
17:10:41 <t8m> #info Waiting on stats on proventester karma in Bodhi
17:10:48 <sgallagh> Hmm, I didn't see it
17:11:48 <t8m> nirik, where is the ticket for the bodhi changes to allow the critpath timeout?
17:11:52 <nirik> so, I think we defer this topic again, and try and gather more info.
17:11:58 <nirik> t8m: let me get a link, just a sec.
17:12:17 <t8m> nirik, I agree
17:12:30 <nirik> https://fedorahosted.org/bodhi/ticket/642
17:13:38 <t8m> #info The update timeout for critpath packages still to be implemented in Bodhi - https://fedorahosted.org/bodhi/ticket/642
17:14:11 <t8m> Anybody against deferring the ticket to the next meeting?
17:14:39 * nirik isn't
17:14:43 <sgallagh> no
17:14:55 <ajax> nope
17:15:10 <t8m> sgallagh, the decision was only for the partial workaround anyway (the timeout) but there should be more changes if we want to fix the problem (if possible)
17:15:40 <t8m> #info Deferred to next week meeting
17:16:05 <t8m> #topic Fedora Engineering Services tickets
17:16:19 <t8m> https://fedorahosted.org/fedora-engineering-services/report/6
17:16:34 <nirik> currently still stalled mostly. (Although there was some progress on a bundled packages issues recently)
17:16:55 <nirik> If anyone has the time to start trying to push stuff there, please let me know.
17:18:40 <t8m> #topic Next week chair
17:18:50 <t8m> Anybody wants it?
17:19:14 <nirik> I've not in a while, so I can if no one else wants to
17:19:20 <notting> i can do it
17:19:45 <t8m> So, nirik was first?
17:19:47 * nirik is happy to let notting do it. ;)
17:19:55 <t8m> fine
17:20:15 <t8m> #info The next week meeting chair is notting.
17:20:32 <t8m> #topic Open floor
17:20:40 <mjg59> I'll probably be absent next week
17:20:47 <mjg59> But I'll report on what I hear back
17:20:52 <nirik> I wanted to mention/bring up 2 threads from the mailing list... just to see if we wanted to do anything or had any ideas:
17:21:20 <nirik> - pulseaudio 1.0 in f16. The maintainer doesn't think it's a good idea... and I don't think we want to try and tell them otherwise...
17:21:42 <pjones> I think deferring to the maintainer when he says something isn't ready is perfectly reasonable.
17:21:57 <nirik> - firefox updates improvements. Perhaps we could do something to help this process...
17:22:11 <t8m> nirik, of course the maintainer should have the final word although I'd like to hear more detailed info why PA 1.0 in F16 is too risky
17:22:15 <sgallagh> Yeah, hold PA until 17
17:22:18 <notting> agree on PA. haven't had a chance to read through the entire FF thread
17:23:03 <mjg59> The firefox issue appears to be mostly related to extension management
17:23:09 <nirik> ok, just thought I would bring those up in case folks had strong opinions on them.
17:23:19 <ajax> see, this is why you shouldn't give software version numbers
17:23:24 <ajax> people start to think they mean something
17:23:27 <mjg59> There are typically new releases of extensions upstream, but they're not packaged
17:23:28 <t8m> nirik, for FF - I read the thread and the only improvement I can see to be achievable is to somehow bundle or link the update of the main package with the update of the extensions
17:23:53 <nirik> t8m: yeah, perhaps we could get ff maintainers to build those when they build ff?
17:24:02 <mjg59> So the options are either to (a) make sure we have a better update strategy for extensions, or (b) follow upstream's distribution model and don't ship extensions ourselves
17:24:26 <t8m> nirik, yeah, that would be nice - if they got a simple list and if just a simple release bump + rebuild is sufficient
17:24:30 <pjones> ajax: having people code acceptable version numbers into the extensions didn't help anything
17:24:31 <mjg59> The problem with (b) is that there's no good upstream mechanism for managing extensions system-wide
17:24:42 <ajax> pjones: i was referring to PA, but yes.
17:24:59 <nirik> also, something I noticed: our firefox package is owned by gecko-maint, which goes to /dev/null in bugzilla, and none of the commiters have watchbugzilla. So, only bug reports that someone specifically goes to are looked at. No emails are sent to anyone who can do anything.
17:25:08 <sgallagh> mjg59: There's an argument to be made against *allowing* them to be systemwide as well
17:25:27 <t8m> mjg59, and also why the extensions should be something special? we can say then that any sw can be distributed by other means except for base distro
17:25:32 <mjg59> sgallagh: I think that's pretty obviously problematic
17:25:38 <t8m> mjg59, so I'd prefer to not take this path
17:25:58 <mjg59> t8m: I'd prefer us not to have to push ABI-unstable firefox updates on a regular basis, yes
17:26:05 <sgallagh> mjg59: What I mean is that there's a valid argument for requiring individual users to install their own extensions
17:26:08 <mjg59> But that doesn't seem to be an option, and so we are put in a different situation to normal
17:26:10 <sgallagh> Rather than installing them for all users
17:26:33 <mjg59> sgallagh: No, I think it's perfectly reasonable for system-wide deployment in a variety of circumstances
17:27:24 <nirik> so, I don't know that there's any solution off hand, but hopefully we can do something to improve the status quo
17:27:24 <t8m> nirik, I think there is a triager who should regularly go through the FF/gecko bugs but I am not sure how thoroughly and how often he does
17:27:28 <sgallagh> mjg59: Ok, but maybe the answer isn't RPM for this, but instead it's a tool to install extensions globally.
17:27:33 <mjg59> sgallagh: Right
17:27:41 <notting> mjg59: i.e., locked down you get extensions XYZ, and you can't change them?
17:27:51 <mjg59> notting: Sure, some deployments may want that
17:28:03 <mjg59> Or some deployments may just want them installed by default, even if users can disable them
17:28:20 <sgallagh> mjg59: I think my point is that because of the ABI instability of Firefox, it's not sane to try to force that stress on extension packagers, especially when Firefox has an easy built-in way for users to add the extensions they want
17:28:24 <mjg59> It's possible to do this with the upstream packaging, but it's a pain with lots of manual steps
17:28:24 * nirik personally suspects many people enjoy the advatages of having them packaged.
17:28:27 <t8m> well if there should be a way to install FF extensions systemwide, they should be installed by the systemwide packaging tool
17:28:35 <notting> so, if we had a FF extension extension to RPM, that automatically added reqiures/conflicts based on the version checking in the extension code, that would at least avoid silent breakage?
17:28:36 <t8m> and that is rpm
17:28:41 <mjg59> notting: Yes
17:28:57 <mjg59> notting: And we could have autoqa scream more obviously
17:29:07 <mjg59> Whether that would result in anything being done, I have no idea
17:29:25 <nirik> we could also ask testers to install those plugins on test machines, so they get more coverage.
17:30:07 <t8m> #info PA update to 1.0 postponed to F17 - as per maintainer's decision
17:30:25 <mjg59> From the extensions point of view - it's also worth noting that my understanding is gnome upstream don't want us to package shell extensions
17:30:48 <t8m> #info Discussion of Firefox extension updates after Firefox version update
17:30:54 * nirik thinks thats a bad idea off hand, but could be convinced I suppose.
17:31:31 <mjg59> nirik: Extensions are intended to give you a lower expectation of functionality than the stock experience. That's diminished if you get them from the same place as the desktop itself.
17:31:55 <t8m> I suppose that many packages upstreams with own distribution system wants us to not package the plugins/extensions/components/whatever
17:33:00 * nirik isn't sure why that is. They are optional. No one is saying they have to be installed by default.
17:33:02 <mjg59> So it's something that we are going to have to have a wider discussion about at some point
17:33:06 <nirik> sure.
17:33:54 <mjg59> nirik: If you distribute extensions through some external site then you have a mechanism to explain the compromises to the user. If you distribute them alongside the rest of the OS then you don't.
17:34:37 <t8m> Except there can be notably good and well maintained extensions that Fedora may well want to have in the distribution.
17:34:43 <nirik> Couldn't you add that info to the package summary or in packagekit? "this non standard extension may give you reduced functionality..."
17:34:56 <nirik> anyhow, I think we are drifting off here...
17:35:01 <pjones> nirik: that's pretty bad press if you're trying to encourage extensions
17:35:40 <t8m> pjones, I don't think we want to encourage them but OTOH we don't want to discourage them either.
17:35:53 <sgallagh> I need to leave. Sorry.
17:35:54 <pjones> t8m: no, but I assume mozilla is trying to encourage them
17:35:57 * nirik is confused. You are trying to encourage them? but find they diminish the experence and don't want them to be in the same place because people might think better of them?
17:36:27 <nirik> anyhow, I just wanted to bring up this issue... ;) Please do add to the mailing list thread...
17:36:37 <mjg59> nirik: You have a certain expectation of software that we ship. That's not true of software that comes from some third party site.
17:37:03 <mjg59> If users install an extension from our repository and then complain that shell doesn't work properly any more, that's a problem
17:37:04 <pjones> nirik: no, just saying I don't think the firefox people would like to say (or like us to say) "hey, by the way, extensions you get from mozilla are pretty bad"
17:38:05 <nirik> sure
17:38:34 <mmaslano> sorry, but that's up to firefox maintainers. Shouldn't they say something about it?
17:39:11 <t8m> mmaslano, they do not look like to be particularly active in that discussion on the mailing list
17:39:54 <pjones> for fairly obvious reasons
17:39:58 <pjones> at least I assume.
17:41:07 <t8m> Anything else for Open floor?
17:41:34 * nirik has nothing
17:42:16 <ajax> not i
17:42:24 * t8m will close the meeting in 1 minute if nobody objects.
17:43:35 <t8m> #endmeeting