=================================== #fedora-meeting: FESCO (2011-10-10) ===================================
Meeting started by t8m at 17:01:11 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-10-10/fesco.2011-10-10-17.01.log.html Meeting summary --------------- * init process (t8m, 17:01:41) * #663 Late F16 Feature Java7 (t8m, 17:03:08) * #667 Request to fix CRITPATH update process (t8m, 17:07:20) * Waiting on stats on proventester karma in Bodhi (t8m, 17:10:41) * LINK: https://fedorahosted.org/bodhi/ticket/642 (nirik, 17:12:30) * The update timeout for critpath packages still to be implemented in Bodhi - https://fedorahosted.org/bodhi/ticket/642 (t8m, 17:13:38) * Deferred to next week meeting (t8m, 17:15:40) * Fedora Engineering Services tickets (t8m, 17:16:05) * LINK: https://fedorahosted.org/fedora-engineering-services/report/6 (t8m, 17:16:19) * Next week chair (t8m, 17:18:40) * The next week meeting chair is notting. (t8m, 17:20:15) * Open floor (t8m, 17:20:32) * PA update to 1.0 postponed to F17 - as per maintainer's decision (t8m, 17:30:07) * Discussion of Firefox extension updates after Firefox version update (t8m, 17:30:48) Meeting ended at 17:43:35 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * t8m (47) * nirik (33) * mjg59 (26) * sgallagh (12) * ajax (8) * pjones (8) * zodbot (6) * notting (6) * dbhole_ (4) * mmaslano (2) * cwickert (0) -- 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: <[email protected]> 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 -- devel mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/devel
