=================================== #fedora-meeting: FESCO (2010-12-08) =================================== Meeting started by nirik at 17:30:03 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-12-08/fesco.2010-12-08-17.30.log.html Meeting summary --------------- * init process (nirik, 17:30:03) * kylem unable to attend. (nirik, 17:30:34) * Updates policy / Vision implementation status (nirik, 17:33:14) * LINK: https://fedoraproject.org/wiki/Updates_Policy (nirik, 17:35:33) * LINK: http://www.mail-archive.com/epel-devel-list@xxxxxxxxxx/msg03432.html (nirik, 17:42:42) * Meeting time (nirik, 17:54:28) * LINK: http://whenisgood.net/99a9zq/results/p585aa (mjg59, 17:55:16) * AGREED: will stick with this time at least for now. (nirik, 18:00:21) * #505 FPC guidelines for review (nirik, 18:00:33) * LINK: https://fedorahosted.org/fesco/ticket/505 (nirik, 18:00:34) * AGREED: FESCo has no problem with these two FPC guidelines. (nirik, 18:08:56) * #508 improve the general standard of packagers/maintainers in the distribution. (nirik, 18:09:13) * LINK: https://fedorahosted.org/fesco/ticket/508 (nirik, 18:09:13) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=450013 (nirik, 18:18:22) * LINK: https://fedoraproject.org/wiki/How_to_debug_Dracut_problems (Viking-Ice, 18:29:25) * ACTION: notting will look at folding these into the maintainers best practices. (nirik, 18:39:51) * AGREED: nirik will ping FPC about a) a review template and b) adding SHOULD/best practices to guidelines? (nirik, 18:42:11) * #509 F15Feature: F15Boost146 - http://fedoraproject.org/wiki/Features/F15Boost146 (nirik, 18:42:48) * LINK: https://fedorahosted.org/fesco/ticket/509 (nirik, 18:42:48) * AGREED: Feature is approved. (nirik, 18:44:38) * #510 F15Feature: FourkBSectorBooting - http://fedoraproject.org/wiki/Features/FourkBSectorBooting (nirik, 18:44:44) * LINK: https://fedorahosted.org/fesco/ticket/510 (nirik, 18:44:44) * AGREED: Feature is approved. (nirik, 18:45:50) * #511 F15Feature: Gnome3 - http://fedoraproject.org/wiki/Features/Gnome3 (nirik, 18:45:55) * LINK: https://fedorahosted.org/fesco/ticket/511 (nirik, 18:45:55) * AGREED: feature was already approved. ;) (nirik, 18:47:21) * #512 F15Feature: LibreOffice - http://fedoraproject.org/wiki/Features/LibreOffice (nirik, 18:47:27) * LINK: https://fedorahosted.org/fesco/ticket/512 (nirik, 18:47:27) * AGREED: Feature is approved. (nirik, 18:49:05) * #513 F15Feature: Maven3 - http://fedoraproject.org/wiki/Features/Maven3 (nirik, 18:49:11) * LINK: https://fedorahosted.org/fesco/ticket/513 (nirik, 18:49:12) * AGREED: Feature is approved. (nirik, 18:50:12) * #514 F15Feature: Sugar 0.92 - http://fedoraproject.org/wiki/Features/Sugar_0.92 (nirik, 18:50:18) * LINK: https://fedorahosted.org/fesco/ticket/514 (nirik, 18:50:18) * AGREED: Feature is approved. (nirik, 18:51:20) * Open Floor (nirik, 18:51:25) Meeting ended at 19:01:40 UTC. Action Items ------------ * notting will look at folding these into the maintainers best practices. Action Items, by person ----------------------- * notting * notting will look at folding these into the maintainers best practices. * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * nirik (159) * cwickert (66) * mjg59 (36) * notting (31) * mmaslano (19) * ajax (17) * Viking-Ice (16) * SMParrish (12) * mclasen (12) * zodbot (7) * mclasen_ (1) * fenrus02 (1) * rbergeron (1) * vinzv (1) * Southern_Gentlem (1) * dtardon (1) * kylem (0) -- 17:30:03 <nirik> #startmeeting FESCO (2010-12-08) 17:30:03 <zodbot> Meeting started Wed Dec 8 17:30:03 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:30:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:30:03 <nirik> #meetingname fesco 17:30:03 <nirik> #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano 17:30:03 <nirik> #topic init process 17:30:03 <zodbot> The meeting name has been set to 'fesco' 17:30:03 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 mmaslano nirik notting 17:30:28 <nirik> who all is here for fesco meeting? 17:30:32 * cwickert is here 17:30:33 <mjg59> ! 17:30:34 <nirik> #info kylem unable to attend. 17:30:41 * mmaslano here 17:30:41 * SMParrish here 17:30:56 * notting is here 17:33:00 <nirik> ok, lets go ahead and dive in. 17:33:14 <nirik> #topic Updates policy / Vision implementation status 17:33:14 <nirik> .fesco 351 17:33:14 <nirik> .fesco 382 17:33:15 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351 17:33:18 <nirik> * Adjustments to updates policy: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Changes_Ideas_Container 17:33:19 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382 17:33:27 <nirik> here's our weekly updates topic. ;) 17:33:39 <nirik> I've added more ideas from the test list. 17:33:59 <cwickert> blame me for not working on it, I'm just too busy 17:34:11 <SMParrish> same here 17:34:42 <nirik> So, what remains on the 2 tickets above? could we close those and open a new one for improving the process? 17:35:06 <cwickert> where is the *current* status? 17:35:27 <cwickert> I have lost the overview because we just have too many tickets and wiki pages 17:35:33 <nirik> https://fedoraproject.org/wiki/Updates_Policy 17:35:55 <cwickert> yh, you mean the policy itself, not the implematation? 17:35:58 <nirik> yeah. I am suggesting we close the 2 above... and open a new one for adjusting the existing updates policy. 17:36:20 <mjg59> Sounds good 17:36:39 * SMParrish agrees 17:36:44 <nirik> well, https://fedoraproject.org/wiki/Updates_Policy should have the current policy and what is implemented, right? 17:36:51 <nirik> if not, we should adjust it. 17:37:04 <cwickert> right 17:37:31 * mclasen things smaller, focused tickets would be good, seeing the 'updates policy' standing topic every week is becoming a bit of a drag... 17:38:09 <nirik> yeah, thats why I tried to collect all ideas from the thread in https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Changes_Ideas_Container 17:38:12 * cwickert tends to agree but is afraid we loose the bug picture then 17:38:41 * nirik notes there's lots of ideas there I don't like, but I wanted to collect them all so we could see them outside the gigantic threads. ;) 17:39:24 <nirik> we don't have some things from the stable release vision still however... 17:39:28 <nirik> metrics 17:39:59 <cwickert> back to the board then? 17:40:01 <nirik> "Project members should be able to transparently measure or monitor a new updates process to objectively measure its effectiveness, and determine whether the updates process is achieving the aforementioned vision statements." 17:40:24 <nirik> well, how about I propose in the ticket we close it and the board can tell us if they see more than must be done. 17:40:34 <mjg59> nirik: Sure 17:41:03 <notting> the other one that wasn't done was updates-features (or whatever it was called) 17:41:04 <nirik> any objections? 17:41:09 <cwickert> but what to do about the metrics. this really is an interesting topic 17:41:33 <nirik> yeah, we have some from bodhi, I think we were hoping to improve on those. 17:41:46 <nirik> perhaps I could invite lmacken next week to show us what it has currently? 17:41:51 <mmaslano> are they displayed somewhere? 17:42:04 <mmaslano> or it's only number of updates now? 17:42:05 <nirik> they run currently when he runs them I think. 17:42:13 <nirik> he's posted them in the past. 17:42:42 <nirik> http://www.mail-archive.com/epel-devel-list@xxxxxxxxxx/msg03432.html 17:42:46 <nirik> was one from a while back 17:43:02 * mclasen is +1 on closing the big ticket 17:43:28 <cwickert> just a moment... it was the board that demanded metrics, right? I think we should give them a list of metrics we like to see and then tell then they need to nag the people to provide us these numbers 17:44:05 <mmaslano> not sure how these metrics say whether updates or better or not ;-) 17:44:45 <nirik> well, they wanted measurements as part of their vision statement. I can ask them to clarify/see if the bodhi stats are what they wanted. 17:44:50 <cwickert> mmaslano, that's why we would need numbers from before and after the policy change 17:45:05 <mmaslano> cwickert: sure 17:45:39 <cwickert> nirik, it is not what the board wants but what "project members" want I think 17:46:03 <nirik> well, the board vision was asking for project members to be able to see, yes... 17:46:05 <cwickert> I think the numbers are nice but not enough to tell is the policy was actually successfull 17:46:21 <nirik> yeah, so we would need to figure out what numbers would be. 17:46:26 <nirik> (if any) 17:46:32 <cwickert> I'd like to see the average days in testing or the number of stuck security updates 17:47:25 <nirik> proposal: close 351, close 382 and ask the board to re-open if they need further items for it to be considered done, open new ticket for stats/metrics and new ticket for improving/changing updates process? 17:47:46 <notting> and maybe one rfe for updates-features 17:47:47 <mjg59> +1 17:48:07 <mmaslano> +1 17:48:08 <cwickert> +1 17:48:16 <SMParrish> +1 17:48:20 <nirik> ok. Would any folks like to own any of the 2/3 new tickets? ;) 17:48:33 <mclasen> +1 17:48:44 <cwickert> I'd like to take the updates-features ticket 17:48:51 <nirik> cwickert: ok, cool. 17:49:00 <cwickert> although I'm not even sure we need to address this with a repo 17:49:21 <nirik> I can take the improving/changing updates process... I can try and cull some out of the ideas container each week to discuss? 17:49:32 <notting> cwickert: what would be the other way to do it? 17:49:40 <nirik> anyone want to take the lead on stats/metrics? 17:50:10 <cwickert> notting, for example on a yum level with an improved version of yum-plugins-security? 17:50:50 <nirik> well, I will do the above after the meeting and we can go from there... 17:51:02 <notting> given the interdependencies, and the question of then packaging multiple versions of security updates in the same repo, i don't think just categorization is practial 17:51:07 <notting> or practical, even 17:51:40 <cwickert> notting, multiple versions of security updates? 17:51:53 <nirik> something between repos.fedoraproject.org and a full updates repo might work... but hard to say... 17:52:38 <notting> you have version 2.5 in base. you release 3.4 as enhancement. and then there's a security fix that needs addressed in 3.5. what do you do? 17:53:33 <nirik> yeah, it gets complex fast. 17:53:36 <cwickert> notting, publish both in the same repo, the plugin should be ablt to do the right thing 17:53:48 <cwickert> but I agree it is a valid concern 17:54:11 <nirik> ok, shall we move on? 17:54:21 <cwickert> +1 17:54:28 <nirik> #topic Meeting time 17:54:29 <nirik> * Will 17:30UTC work moving forward? 17:54:38 <nirik> is this time going to work for folks? 17:54:51 * mmaslano is content with this time 17:55:00 <SMParrish> works for me 17:55:01 <cwickert> mjg59, can you share the results link? 17:55:02 <mjg59> Works for me 17:55:06 <mjg59> cwickert: Oh, sure 17:55:16 <mjg59> http://whenisgood.net/99a9zq/results/p585aa 17:55:21 <notting> nirik: good enough 17:55:28 <cwickert> works for me, but if I were to work in the office, I would be on the train now 17:55:44 <cwickert> hope I never have to go to the office on wednesdays 17:55:49 <nirik> :) 17:55:52 <nirik> mclasen: ? 17:55:56 <mclasen> I only have 30-45 minutes in this slot 17:56:13 <mclasen> but if it works for everybody else, it is probably best to stay with this time 17:56:26 <mclasen> and I'll timeslice with my other meeting as best as I can 17:56:28 <mjg59> I think this is about the latest in the day we can do, since otherwise we pretty much exclude mmaslano 17:56:55 <nirik> ok. 17:57:04 <nirik> #agreed will stick with this time at least for now. 17:57:05 <mjg59> And other days look worse than Wednesday in thatrespect 17:57:20 <cwickert> mmaslano, you are in my timezone, right? you have no time in the afternoon in general? 17:57:41 <mmaslano> cwickert: UTC+1 17:57:51 <cwickert> same here :) 17:58:01 <notting> i could potentially move an hour earlier if need be. but no earlier than 11:30 17:58:24 <cwickert> how about 30 minutes earlier? 17:58:34 * nirik could move earlier if everyone else wanted... but I'm often busy with dayjob first thing in the morning. 17:58:52 <nirik> #undo 17:58:52 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0xe822d10> 17:59:00 <mjg59> cwickert: lunch at RH is 12-1:30, so starting at 12 isa problem 17:59:15 <mjg59> There's something wrong with my space bar 17:59:16 <cwickert> i see 17:59:43 <mjg59> cwickert: And there's not really any alternative food source in easy walking distance due to the westford office being in the middle of nowhere 18:00:03 <cwickert> ok, then lets stick with the current slot 18:00:14 <nirik> ok. 18:00:15 <mclasen> mjg59: free banana in the kitchen ? 18:00:21 <nirik> #agreed will stick with this time at least for now. 18:00:27 <nirik> moving on then... 18:00:33 <nirik> #topic #505 FPC guidelines for review 18:00:34 <nirik> https://fedorahosted.org/fesco/ticket/505 18:00:42 <nirik> 2 FPC guidelines for us to review. 18:00:50 <nirik> first: https://fedorahosted.org/fpc/ticket/38 18:01:56 <mjg59> I've no objections 18:02:02 <nirik> The dessenting vote seems to be due to kernel changelogs not having versions. 18:02:24 <nirik> but they do get populated when someone does a real build I think. 18:02:38 <nirik> I guess not always. 18:02:44 * mclasen has no opinion in this, it seems hardly worth legislating 18:02:54 * notting agrees with mclasen 18:02:57 <mjg59> Well, it's not too much of a problem to get the kernel to conform 18:03:55 <nirik> so, sure +1, revisit if it causes too much kernel maintainer pain. 18:04:12 <cwickert> sorry, but I don't understand the original FPC: "If E-V-R is left unchanged..." - how that? 18:04:26 <mclasen> if you commit a fix without building, I guess 18:04:37 * mclasen does that sometimes 18:04:44 * cwickert too 18:04:44 <mmaslano> it's common, when you have more maintainers of one package... 18:04:53 <nirik> yeah, but changelogs are per build... 18:05:03 <nirik> so build them up and have one for that build with all the changes. 18:05:14 <cwickert> right 18:05:37 <nirik> so, any objections to this? votes? 18:05:40 <mclasen> there's some tension there between changelog-per-commit and changelog-per-build, I guess 18:05:50 <SMParrish> no objections here 18:05:52 <mclasen> no objections 18:05:53 <cwickert> mmaslano, how could you have the same E-V-R? doesnt the buildsys refuse to build this? 18:06:31 <mmaslano> cwickert: in this case you don't build, just commit and leave it unbuild for new patches from others 18:07:06 <nirik> anyhow, next? 18:07:18 <nirik> Explain why rpmlint warns about executable files in %doc - https://fedorahosted.org/fpc/ticket/36 18:07:32 <cwickert> +1 18:07:52 <nirik> +1 here. no executable docs seems reasonable to me. 18:08:13 <SMParrish> +1 18:08:19 <notting> +1 18:08:19 <mjg59> +1 18:08:31 <ajax> sorry i'm late 18:08:42 <nirik> no worries. 18:08:56 <mmaslano> +1 18:08:56 <nirik> #agreed FESCo has no problem with these two FPC guidelines. 18:09:13 <nirik> #topic #508 improve the general standard of packagers/maintainers in the distribution. 18:09:13 <nirik> https://fedorahosted.org/fesco/ticket/508 18:09:18 <notting> hoo boy. 18:09:20 <cwickert> ok, now that I understood the changelog thing I'm also +1 to it 18:09:26 <nirik> notting: yeah. ;) 18:09:49 <cwickert> closed worksforme? 18:09:50 <mjg59> I don't understand the rationale behind this proposal 18:09:50 <nirik> So, there are some ideas here I think we could improve our maintainers responsibilitys page with. 18:10:02 * cwickert nether 18:10:07 <nirik> but some of the requirements are impossible or don't make sense. 18:10:22 <nirik> well, the ticket submitter is active in QA. 18:10:26 <mjg59> Is the concern that having too many packages diverts attention from important ones, or that having low quality packages is worse than having no packages? 18:10:40 <nirik> They would like maintainers to do better so the overall quality was better... 18:10:51 <nirik> mjg59: I think the latter. 18:11:03 <mjg59> nirik: Yeah, I don't think that obviously follows 18:11:25 <mjg59> So I disagree with the proposal as-is on that basis 18:11:44 <mjg59> Which isn't to say that there aren't aspects that wouldbebeneficial 18:12:32 <nirik> yeah, mandating seems a fail to me... there's no way we can require proof of upstream communication. 18:12:40 <cwickert> should we vote on the individual suggestions? 18:12:41 * mclasen_ is in another meeting now, sorry if I'm unresponsive... 18:12:44 <notting> the proposal appears to be a reaction to perceived bureacracy by ... adding more? 18:12:49 <mjg59> I think the best we can do is ensure that some of this ends up in a best practices document 18:13:02 <cwickert> notting, *good* question 18:13:17 <cwickert> +1 mjg59 18:13:37 <mjg59> And encourage people to read that as part of the packaging process 18:14:00 <nirik> yeah, I think as 'suggested' / 'best practice' the suggestions make sense. 18:14:06 <cwickert> some things could go into the package mainteiner responsibilities, but more as a SHOULD then a MUST 18:14:12 <mjg59> I'd love to see all our maintainers be capable of handling all bugs themselves (and then getting those upstream), but I think that's an unrealistic expectation 18:14:43 <notting> mjg59: to play devil's advocate, then... if it's just a 'should', what are the chances that it will actually help? 18:14:46 <mjg59> And mandating this as part of the package submission process would pretty much disqualify most of our maintainers 18:15:10 <mjg59> notting: Little. I think we need to accept that our maintainers are mostly packagers rather than developers. 18:15:20 <mjg59> Changing that sounds entirely outside fesco's remit. 18:16:06 <nirik> also, the suggestion of looking at red hat qa processes may be worth persuing, but I think a lot of the process is just going to not apply with us. 18:16:20 * Viking-Ice points out atleast try to get them to provides us with debug info on their components. 18:16:30 <nirik> hey Viking-Ice. :) 18:16:54 <notting> re: test cases, obvs we're gated on QA having a place to place them. but that's in progress. 18:16:56 <nirik> Viking-Ice: I think asking for testing info is a great idea... 18:17:33 <cwickert> notting, has QA considered testopia? 18:17:42 <nirik> cwickert: I thought it wasn't free? 18:17:45 <Viking-Ice> if they cant provide us with the information on how to debug their own package we surely wont get any testing idea from them 18:17:54 <Southern_Gentlem> cwickert, they did then found out it wasnt free 18:18:14 <notting> cwickert: they have looked into many TCMSes, but i don't recall which ones 18:18:19 <Viking-Ice> s/idea/info/ 18:18:22 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=450013 18:18:33 <cwickert> Southern_Gentlem, I thought it was MPL like bugzilla 18:19:00 <nirik> Viking-Ice: sure, and we can work to improve over time. Forcing them to provide info or you will remove their package seems like way way too much bark and not enough wag. 18:20:02 <Viking-Ice> ok so how about this requiring this for any new package introduced to the release from F15 and onwards and we try to gather this information for existing packagings? 18:20:18 <nirik> as a suggestion/note, I think it's a great idea. 18:20:28 <Viking-Ice> part of the review process 18:20:38 <cwickert> Viking-Ice, only test cases or all suggestions? 18:21:12 <Viking-Ice> those I mentioned as required 18:21:25 <nirik> well, it's not something that directly has anything to do with the package, but perhaps FPC would consider adding Should: entries for it? or Suggests: ? 18:21:49 <Viking-Ice> I would think the best way to collect this is when package gets added to the distro 18:21:50 <nirik> Or we could note it on the join page/new package process/SCM requests. 18:22:11 <cwickert> Viking-Ice, I'd say no because I connot fulfill them all. e.g. I cannot have a bugzilla account for a package that does not have any bug tracker :) 18:22:30 <Viking-Ice> than you would just point that out in the review request 18:22:33 <nirik> Viking-Ice: or perhaps qa could flag new packages as they are added, and approach maintainers then with a suggestion list? 18:22:48 <cwickert> there are packages that don't have a tracker and I have no idea how to contact upstream, but they just work 18:23:16 <notting> i think having some sort of 'how to test' as part of new package submission would be useful to collect 18:23:18 <nirik> there are also packages where upstream doesn't care/is hostile, so being in contact with them doesn't matter. 18:23:57 <Viking-Ice> ok so what about them provide how to debug and minimal information a report and test cases before package gets accepted? 18:24:06 <cwickert> sure test cases would be nice if there are people to actually run them. 18:24:46 <notting> cwickert: ? even if there aren't people now, it's much easier to have them for people to show up and pick off, rather than have people show up and not have anything to work from 18:24:48 <nirik> Viking-Ice: as a "Please help us, read $foo and provide us test cases at $bar with process $baz" I think it's great. 18:24:50 <mmaslano> the process of review is long anyway 18:25:15 <nirik> Viking-Ice: as a "you MUST do these things before your package is allowed in" I think it's not. 18:25:43 <Viking-Ice> why not if I may ask 18:26:07 <cwickert> Viking-Ice, what kind of debugging would you expect? 18:26:18 <mjg59> Because most of our maintainers would have no idea how to write such a list? 18:26:24 <nirik> well, for example, recently libreoffice was added to rawhide. If we required a comphrehensive test plan in place before it could be added, it would be F29 before we saw it. 18:26:35 <Viking-Ice> it's like stealing a candy from a baby trying to get how to debug info out the maintainers 18:26:51 <dtardon> Viking-Ice, rtfm? 18:27:03 <mjg59> We've had 15 minutes of this 18:27:09 <mjg59> Do we want to continue? 18:27:18 <cwickert> +1 to continue 18:27:20 * nirik is ok to go a bit more. 18:27:24 <mjg59> Ok 18:27:28 <nirik> I'd like to propose something tho: 18:28:03 <Viking-Ice> nirik: we need the information from that they would otherwise request reporters to provide them with these are what we usually call how to debug component 18:28:09 <nirik> proposal: ping FPC about adding should/suggestions for these in review, suggest changes to the join wiki page noting them and revisit next week. 18:28:54 <nirik> Viking-Ice: do you have an example? 18:29:24 <cwickert> Viking-Ice, I think most QA people have more test cases in mind than package owners, e.g. for a standard desktop app I never would test if "Help -> About" works 18:29:25 <Viking-Ice> https://fedoraproject.org/wiki/How_to_debug_Dracut_problems 18:29:35 <notting> proposal #2: ping FPC about making an official review template 18:30:00 <Viking-Ice> nirik: this is what I wrote when dracut was being introduced 18:31:28 <nirik> Viking-Ice: how do you do that for a library? 18:31:54 <nirik> notting: it's been suggested a bunch. 18:32:27 <mmaslano> Viking-Ice: sorry but that can't be done for all packages. It should be voluntary 18:32:35 <nirik> any other proposals? votes on the existing ones? 18:33:11 <cwickert> lets make all points suggestions rather than preconditions and then vote on them individually 18:33:48 <nirik> cwickert: suggestions for what? 18:34:13 <cwickert> SHOULD items in a review rather than MUST 18:34:14 * nirik suspects FPC would reject adding them anywhere to guidelines. 18:35:12 <notting> well 18:35:15 <notting> stepping back 18:35:21 <notting> if none of them are must 18:35:37 <notting> does anyone object to them going on the package maintainer responsibilities as best practices? 18:35:47 <cwickert> +1 18:35:52 <mjg59> Sounds good to me 18:36:17 <nirik> I'm fine with all of them except the 'familiar with the programming lang' one. 18:36:54 <cwickert> so am I, I cannot learn vala because I own a single vala package that is a dep of others 18:37:11 <Viking-Ice> by all mean scrap it it was stretching it a bit to far.. 18:37:11 <SMParrish> that one needs to go 18:37:20 <notting> nirik: i think it's fine as a best practice to be familiar with what you're packaging 18:37:52 <cwickert> as a recommendation it is ok 18:38:02 <nirik> well, to the point of getting it packaged and working, but should I have to go take a R class to package an R package? 18:38:20 <notting> cwickert: that's the point of best practices 18:38:21 <nirik> I suppose as a suggestion it might be ok if phrased right. 18:38:46 <cwickert> nirik, in a perfect wotld (tm) you should know R already ;) 18:38:52 <nirik> :) 18:39:18 <fenrus02> R is just like S ... but slightly newer. 18:39:18 <nirik> ok, so, would someone care to look at diff to the package maintainer responsibilities wiki page with these changes? 18:39:28 <notting> i'll look at it 18:39:51 <nirik> #action notting will look at folding these into the maintainers best practices. 18:40:03 <nirik> ok, do we wish to ask FPC on the other items? 18:40:27 <nirik> I guess I can ping them... 18:41:09 <nirik> sound ok => nirik will ping FPC about a) a review template and b) adding SHOULD/best practices to guidelines? 18:41:54 <nirik> any objections? if not I will move on... 18:41:57 <cwickert> please do nirik 18:42:00 <nirik> thanks for the ticket and discussion Viking-Ice 18:42:07 <cwickert> ping FPC I mean 18:42:11 <nirik> #agreed nirik will ping FPC about a) a review template and b) adding SHOULD/best practices to guidelines? 18:42:22 <Viking-Ice> nirik: thanks for considering this 18:42:40 <nirik> ok, we have a pile of features now. 18:42:48 <nirik> #topic #509 F15Feature: F15Boost146 - http://fedoraproject.org/wiki/Features/F15Boost146 18:42:48 <nirik> https://fedorahosted.org/fesco/ticket/509 18:42:54 <cwickert> +1 18:43:15 <nirik> +1 from me. I do think we should look at some kind of 'featurelet' or something for newer versions... but until we revamp the feature process this is fine. 18:44:00 <nirik> other votes? 18:44:02 <mjg59> +1 18:44:11 <SMParrish> +1 18:44:15 <mmaslano> +1 18:44:30 <notting> sure, +1. would be nice to not have a 'we're breaking this ABI' feature every release, but... meh. 18:44:34 <ajax> +1 18:44:38 <nirik> #agreed Feature is approved. 18:44:40 <ajax> notting: boost tbh 18:44:44 <nirik> #topic #510 F15Feature: FourkBSectorBooting - http://fedoraproject.org/wiki/Features/FourkBSectorBooting 18:44:44 <nirik> https://fedorahosted.org/fesco/ticket/510 18:44:56 <nirik> +1 here. I almost bought one of these drives the other day. ;) 18:45:02 <ajax> +1 shiny 18:45:04 <mmaslano> +1 18:45:15 <SMParrish> +1 18:45:25 <notting> +1. booting is good. 18:45:27 <cwickert> +1 18:45:47 <mjg59> +1 18:45:50 <nirik> #agreed Feature is approved. 18:45:55 <nirik> #topic #511 F15Feature: Gnome3 - http://fedoraproject.org/wiki/Features/Gnome3 18:45:55 <nirik> https://fedorahosted.org/fesco/ticket/511 18:45:59 <mjg59> +1 18:46:04 <nirik> oh wait... didn't we already do this one? 18:46:09 <ajax> pretty sure we did 18:46:14 <nirik> or perhaps last cycle? 18:46:26 <cwickert> I think we did it 2 weeks ago 18:46:55 <cwickert> or was it 3? I'm sure it was not last cycle 18:47:11 <nirik> yeah. Sorry. 18:47:21 <nirik> #agreed feature was already approved. ;) 18:47:27 <nirik> #topic #512 F15Feature: LibreOffice - http://fedoraproject.org/wiki/Features/LibreOffice 18:47:27 <nirik> https://fedorahosted.org/fesco/ticket/512 18:47:38 <nirik> +1 here. Folks are already asking about it in #fedora. 18:47:52 <ajax> and on devel@ 18:47:56 <cwickert> +1 18:48:04 * rbergeron gives a big d'oh to the gnome feature. Sorry guys :) 18:48:08 <SMParrish> +1 18:48:10 <notting> +1. although this appears pretty much already done 18:48:11 <ajax> you would think people would know to check 'koji latest-pkg dist-f15 libreoffice' 18:48:15 <ajax> +1 18:48:19 <mmaslano> +1 18:48:47 <mjg59> +1 18:48:55 * cwickert needs to leave now, please count me as +1 to maven3 and sugar 0.92 18:49:00 <nirik> ok. 18:49:05 <nirik> #agreed Feature is approved. 18:49:11 <nirik> #topic #513 F15Feature: Maven3 - http://fedoraproject.org/wiki/Features/Maven3 18:49:12 <nirik> https://fedorahosted.org/fesco/ticket/513 18:49:15 <nirik> +1 here as well 18:49:18 <cwickert> +1 18:49:20 <notting> i have to leave now too... i have votes in the tickets. 18:49:22 <notting> sorry. 18:49:29 <mmaslano> +1 18:49:37 <ajax> +1 18:50:12 <nirik> #agreed Feature is approved. 18:50:18 <nirik> #topic #514 F15Feature: Sugar 0.92 - http://fedoraproject.org/wiki/Features/Sugar_0.92 18:50:18 <nirik> https://fedorahosted.org/fesco/ticket/514 18:50:29 <nirik> +1 here too, notting and cwickert are also +1 18:50:35 <SMParrish> +1 18:50:40 <mmaslano> +1 18:50:49 <mjg59> +1 18:51:15 <ajax> +1 18:51:20 <nirik> #agreed Feature is approved. 18:51:25 <nirik> #topic Open Floor 18:51:35 <nirik> ok, anyone have anything at all for open floor? 18:52:59 * nirik will close out in a minute or two if nothing comes up. 18:53:17 <ajax> i've heard a modest amount of complaints that abrt is doing more harm than good 18:53:53 <ajax> along multiple axes, but in particular it's simply too much data for apps like firefox and evo for maintainers to respond to 18:54:22 <ajax> i don't have any particular suggestions for this (well, i do, but i'll be politic), but it's something i'd like to see discussed from the distro planning POV 18:54:44 <nirik> yeah, came up on the list recently again as well. 18:55:11 <vinzv> hi 18:56:15 <ajax> is this something people want to talk about here next week, or should it be more of a fedora-devel issue 18:56:38 <nirik> I did note that totem and rhythumbox (I can't spell that to save my life) have the vast majority of bastens bugs. 18:57:23 <nirik> I wonder if we could get abrt to have a maintainer opt out thing that would be easy to change by maintainers? 18:57:35 <nirik> right now it's blacklist is in the package itself. 18:58:18 <nirik> or if we could have them file in another place. ;( 18:59:18 <nirik> ajax: I think we should try and come up with some possible actions and discuss next week? 18:59:46 <ajax> yeah. i'll look over the list and see if i can extract some RFE kind of material. 19:00:32 <nirik> ok, thanks. You want me to file a ticket and assign to you so we don't forget it next week? 19:00:37 <ajax> please 19:00:38 * mmaslano must leave now. 19:00:53 <ajax> there was something else that was bothering me that i wanted to bring up, but it must not have been important enough, else i'd remember. 19:01:28 <nirik> ok. 19:01:36 <nirik> Thanks for coming everyone! 19:01:40 <nirik> #endmeeting
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
