=================================== #fedora-meeting: FESCO (2010-04-13) =================================== Meeting started by nirik at 19:00:09 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-04-13/fesco.2010-04-13-19.00.log.html Meeting summary --------------- * init process (nirik, 19:00:09) * #351 Create a policy for updates (nirik, 19:02:54) * LINK: https://fedoraproject.org/wiki/Critical_Path_Packages_Proposal defines the set of things that should be considered critical path. (nirik, 19:10:56) * LINK: https://fedoraproject.org/wiki/Package_update_acceptance_criteria (nirik, 19:19:41) * AGREED: add critical-path-group-<desktop> groups to comps, SIGs/releng can populate as needed in regards to the criteria already laid down. (nirik, 19:28:34) * AGREED: submitter's vote does not count (nirik, 19:43:23) * AGREED: updates can set the karma level to +1 (nirik, 19:50:14) * #363 Proposal: auto sign pkgs in koji (nirik, 19:55:27) * AGREED: the proposal is approved. (nirik, 20:14:14) * FES tickets update (nirik, 20:14:35) * LINK: https://fedorahosted.org/fedora-engineering-services/ticket/17 (nirik, 20:15:26) * F13 Beta (nirik, 20:21:01) * Open Floor (nirik, 20:22:38) * AGREED: Discussion on devel list to try and solve metacity deps in anaconda and firstboot (nirik, 20:32:15) * LINK: http://fpaste.org/mMfn/ (skvidal, 20:35:09) * skvidal re-ran the potentially unmaintained script again, results at http://fpaste.org/mMfn/ (nirik, 20:35:21) * LINK: http://skvidal.fedorapeople.org/misc/potentially-unmaintained/koji-old-pkg-query.py (skvidal, 20:38:00) * LINK: http://koji.fedoraproject.org/koji/packageinfo?packageID=8216 (cwickert, 20:39:12) * LINK: http://koji.fedoraproject.org/koji/packageinfo?packageID=8203 (cwickert, 20:39:22) Meeting ended at 20:44:38 UTC -- 19:00:09 <nirik> #startmeeting FESCO (2010-04-13) 19:00:09 <nirik> #meetingname fesco 19:00:09 <zodbot> Meeting started Tue Apr 13 19:00:09 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:09 <nirik> #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones cwickert mjg59 19:00:09 <nirik> #topic init process 19:00:10 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:00:13 <zodbot> The meeting name has been set to 'fesco' 19:00:14 <zodbot> Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 nirik notting pjones skvidal 19:00:18 * skvidal is here 19:00:20 * cwickert is here 19:00:50 <Kevin_Kofler> Present. 19:00:57 <pjones> oh crap it is that time again. 19:01:05 * notting is here 19:02:23 <nirik> I guess we have 6 folks, so can go ahead and start in. 19:02:54 <nirik> #topic #351 Create a policy for updates 19:03:07 <nirik> I added some outstanding questions from implementation to the ticket. 19:03:11 <mjg59> Here 19:03:27 <nirik> Kevin_Kofler: you noted that @kde-desktop is big... is there a subset of that that would be good to consider instead? 19:04:15 <ajax> i think so, brain, but if we didn't have ears we'd look like weasels. 19:04:27 <Kevin_Kofler> Well, kdebase-workspace, kdm and their deps might be a starting point. 19:04:44 <Kevin_Kofler> (That'll also include kdelibs and kdebase-runtime.) 19:04:51 <Kevin_Kofler> I'll also note that even that set includes many, many libs. 19:04:51 <cwickert> also kicker? 19:04:59 <Kevin_Kofler> There's no more kicker. 19:05:03 <cwickert> erm, sry 19:05:04 <Kevin_Kofler> It's Plasma and it's part of kdebase-workspace. 19:05:07 <cwickert> ok 19:05:14 <nirik> notting: have you had a chance to look anymore about how we populate critpath? or were you still looking at that? 19:05:25 <Kevin_Kofler> For example, deps of kdebase-workspace include even eet. 19:05:43 <Kevin_Kofler> kdebase-workspace requires qedje (optional dep, but compile-time optional) and qedje requires eet. 19:05:53 <nirik> .fesco 351 19:05:55 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351 19:06:02 <cwickert> Kevin_Kofler, I think that kdeplasma-addons is also necessary, without you have no desktop 19:06:15 <notting> nirik: i know how we populate it. we can set a group for kde like we have for gnome now. 19:06:21 <Kevin_Kofler> Uh, plasma-desktop works fine without kdeplasma-addons. 19:06:29 <Kevin_Kofler> Only plasma-netbook requires (parts of) it. 19:06:36 <cwickert> Kevin_Kofler, it didn't start for me 19:06:39 <nirik> notting: and for xfce/lxde as well? 19:06:49 <Kevin_Kofler> We usually don't ship kdeplasma-addons on live images for space reasons. 19:06:54 <nirik> so, they could be seperate? or would be part of crit-path? 19:06:54 <Kevin_Kofler> They still work fine. 19:07:33 <notting> nirik: either or. we can calculate new crit-path to include those functionalities for lxde/xfce. it's just a comps tweak. 19:07:52 <Kevin_Kofler> That said, a bug in kdeplasma-addons, or any other plasmoid for that matter, CAN crash the entire plasma-desktop. 19:08:14 <Kevin_Kofler> Plasmoids run in process. 19:08:20 <Kevin_Kofler> (at least C++ plasmoids) 19:08:21 <nirik> if we just put all these in critpath, it's easier to implement. If we want them to be a seperate "important packages" set, it will require some changes in bodhi/pkgdb 19:08:34 <skvidal> sorry my network just fell over 19:08:38 <skvidal> did anyone ping at me? 19:08:42 <pjones> okay, so why's there not a comps group for this? 19:08:59 <nirik> pjones: for which? 19:09:04 <notting> pjones: there is, for the older definition of critical-path 19:09:07 <nirik> skvidal: just to join the meeting. ;) 19:09:12 <skvidal> nirik: okay - good 19:09:35 <pjones> nirik: "the things we want from kde in this set", I guess? 19:10:28 <nirik> well, first question: Should we just add everything we want in 'Important packages' to critical path? Or should we have another group seperate of critical path for this? 19:10:42 <skvidal> well per-spin critpaths? 19:10:56 <nirik> https://fedoraproject.org/wiki/Critical_Path_Packages_Proposal defines the set of things that should be considered critical path. 19:11:07 <nirik> adding "important packages" to it, expands it's scope. 19:11:12 <Kevin_Kofler> And shouldn't it be up to the SIG owning the spin to define its critical path? 19:11:50 <nirik> we do have a @critical-path-gnome now I guess. 19:11:56 <skvidal> nirik: right 19:12:12 <nirik> Kevin_Kofler: I would hope/think so. 19:12:15 * cwickert likes to point out that http://kojipkgs.fedoraproject.org/mash/branched-20100412/logs/critpath.log is still incorrectly considering xfce4-notifyd and it's deps as crit path 19:12:20 <mjg59> Kevin_Kofler: No, not if the SIG ends up with definitions of critpath that don't match everyone elses 19:12:36 <pjones> mjg59: if they do that, they get a useless spin... what's the problem? 19:12:38 <mjg59> Ideally that won't be an issue 19:12:48 <mjg59> pjones: Reflects badly on the rest of the distribution regardless, sadly 19:12:50 <notting> cwickert: would have the check the script - it's perhaps pulling all providers 19:12:54 <skvidal> mjg59: I think the general criteria of critpath should be the same, yes 19:12:55 <pjones> mjg59: true, but... 19:13:04 <Kevin_Kofler> mjg59: It's still the spin owners' business. 19:13:25 <Kevin_Kofler> I don't see why all the decisions in Fedora need to go through the central bureaucracy. 19:13:28 <nirik> ok, so sounds like people would prefer we add @critical-path-$otherdesktop groups? 19:13:34 <skvidal> mjg59: for the spins my general opinion is critpath == fedora critpath + whatever makes the spin work 19:13:41 <pjones> nirik: that'd be my first choice, yeah 19:14:10 <ajax> nirik: aye 19:14:27 <mjg59> nirik: I think that would be fine, but with the proviso that releng can add whatever they feel appropriate to individual critpath groups 19:14:30 <nirik> also, our proposal adds "Major desktop productivity apps" where do they fit in? another group? 19:15:30 <nirik> notting: does it pull from the groups currently? I thought it was using a hard coded list currently? 19:16:06 <notting> not sure what you mean. it pulls from the critical-path groups in comps... do you consider that a hard-coded list? 19:16:06 <abadger1999> nirik: It pulls from the groups but the generated list is hardcoded into bodhi at irregular intervals. 19:16:11 <Kevin_Kofler> I think the proposal considers way too much stuff to be critical. 19:16:45 <nirik> abadger1999: yeah. Thats what I meant... bodhi doesn't pull the changes from comps automagically... 19:16:49 <Kevin_Kofler> In fact, I don't see the extra bureaucracy added by the critical spin process as having had any practical benefits. 19:17:02 <abadger1999> nirik: nottings update will push that data into pkgdb so that the list stays in sync better. 19:17:04 <Kevin_Kofler> I sure haven't missed it for the KDE stuff which hasn't been in critpath so far. 19:17:28 <notting> abadger1999: basically, need to determine a good place to insert the process for auto-updates 19:17:32 <Kevin_Kofler> Even apps as critical, why? 19:17:35 <abadger1999> <nod> 19:17:38 <Kevin_Kofler> Apps are trivial to revert if they don't work. 19:17:45 <nirik> Kevin_Kofler: your views are well known. 19:19:13 <ajax> nirik: i'm not sure "productivity apps" is a good idea for critpath 19:19:14 <Kevin_Kofler> (Of course I meant the critical path process, there's no such thing as a "critical spin process". :-) ) 19:19:31 <nirik> ajax: it's in our approved process. ;) We can of course amend it. 19:19:33 <Kevin_Kofler> ajax: Me neither. 19:19:41 <nirik> https://fedoraproject.org/wiki/Package_update_acceptance_criteria 19:19:41 <cwickert> Kevin_Kofler, it's not about reverting but about not pushing it in first place. when you have to revert something, it's already too late 19:19:54 <Kevin_Kofler> Soon we're going to declare the whole distro as "critical". 19:20:03 <Kevin_Kofler> cwickert: I mean apps are trivial for the USER to revert if they don't work for him. 19:20:19 <Kevin_Kofler> They won't make his system stop booting. 19:20:25 <cwickert> the user should not get any apps that don't work! 19:20:30 <nirik> ajax: would you like to see us remove apps there? 19:20:45 <ajax> nirik: i would. _possible_ exception for firefox. 19:20:46 <Kevin_Kofler> Of course, our tools are less than helpful there: yum should be set up to keepcache by default and PackageKit should support downgrades! 19:20:57 <notting> ajax: the idea is that things like firefox, mail readers, etc. that greatly disrupt a users's productivity if they break should get testing 19:21:26 <ajax> notting: yeah, i just don't know how to draw a line between that, and abiword, and geda. 19:21:31 <nirik> I would expect many people would use those apps, so getting testing shouldn't be that hard... 19:21:33 <Kevin_Kofler> For KDE, the browser and the mail reader would already mean kdebase and kdepim. 19:22:03 <mcepl> notting: well, the originally was idea of critpath "whatever gives you barebone desktop", wasn't it? 19:22:20 <ajax> i'm willing to grant that firefox is exceptional, because, well, duh. 19:22:24 <nirik> mcepl: yes. 19:22:24 <skvidal> mcepl: it was actually originally - whatever makes it so you can get bits on disk 19:22:42 <skvidal> mcepl: and then we said 'oh, livecd' so the desktop bits got added to that 19:22:56 <notting> mcepl: and then regressions in firefox, thunderbird, X, etc. got enough publicity that the scope gets expanded... 19:23:05 <skvidal> nod 19:23:11 * mcepl isn't FESCO so just mumbles somethng about creeping featureritis 19:23:12 <cwickert> Kevin_Kofler, one more reason to make smaller packages ;) 19:23:35 <skvidal> mcepl: vs what? being happy with unusable releases/updates? 19:23:45 <Kevin_Kofler> cwickert: Well, for it to be helpful, we'd have to outright make separate SRPMs, from the same upstream tarballs, ugh! 19:23:46 <mcepl> notting: no, critpath shouldn't be IMHO, "whatever makes Fedora look bad" ... 19:24:17 <Kevin_Kofler> IMHO critpath should be the empty set. :-) 19:24:19 <mcepl> skvidal: please, keep the discussion about critpath from updates; what is actually "critical"? 19:24:34 <skvidal> mcepl: it has to do with updates, too 19:24:41 <nirik> so, currently we have 'firefox, thunderbird and evolution'... the kde parts are part of kde crit path already. 19:25:00 <Kevin_Kofler> Are they? 19:25:02 <cwickert> except kedpim 19:25:10 <cwickert> and kdebase is not critpath ether 19:25:17 <cwickert> kdebase-workspace is 19:25:26 <nirik> cwickert: it would be part of the kde-desktop critpath no? 19:25:37 <cwickert> not according to Kevin_Kofler 19:25:50 <pjones> kde-omgcallitsomethingdifferent-critpath, n'est pas? 19:25:51 <nirik> ok. 19:25:53 <Kevin_Kofler> I'll note that we haven't actually discussed this recently. 19:26:08 <mcepl> skvidal: yes, but when talking about "critical" we have at least some hope to discuss rationally some compromise ... if we talk about updates then "Fedora should be like RHEL" and "Fedora should be like Rawhide" groups will never agree. 19:26:09 <cwickert> Kevin_Kofler, I think kdebase really should be critpath. I consider a file manager cruciual for a desktop 19:26:27 <Kevin_Kofler> So I'm just communicating my own feelings, there hasn't been any recent KDE SIG discussion on this. 19:26:31 <skvidal> mcepl: and that's what fesco is for - to decide that argument 19:26:43 <notting> nirik: kde has no crit path at the moment. anyway.... 19:26:51 <Kevin_Kofler> Last we did discuss it, we found that we don't see a need to be included in critpath at all. But that was quite some time ago. 19:26:55 <mcepl> OK, whatever, as you wish ... going to do something useful 19:27:00 * nirik sighs. Yes, thats what we are talking about creating here. ;( 19:27:21 <skvidal> mcepl: you're welcome to run for fesco 19:27:27 <notting> Proposal: add critical-path-group-<desktop> groups to comps, SIGs/releng can populate as needed in regards to the criteria already laid down. 19:27:38 <skvidal> notting: +1 19:27:43 <nirik> +1 to that. 19:27:43 <ajax> notting: ack 19:28:16 <skvidal> just need one more :) 19:28:25 <pjones> +1 19:28:27 <mjg59> +1 19:28:29 * notting acks himself 19:28:34 <nirik> #agreed add critical-path-group-<desktop> groups to comps, SIGs/releng can populate as needed in regards to the criteria already laid down. 19:29:07 <nirik> ok, I have a few more minor questions at: https://fedorahosted.org/fesco/ticket/351#comment:24 19:29:19 <nirik> 3/4/5 there. 19:29:42 <cwickert> +1 just for the record 19:29:57 <ajax> nirik: 3 seems straightforward; mock install the critpath list, then rpm -qa in the chroot. 19:30:28 <mjg59> ajax: That's 2 19:30:35 <ajax> oh hey it is. 19:30:37 <mjg59> nirik: I'd go with "No", "No", "No", personally 19:30:56 <ajax> 4 and 5 are certainly mutually exclusive. 19:31:05 <nirik> true. 19:31:15 <Kevin_Kofler> I don't see 4 and 5 as mutually exclusive. 19:31:33 <Kevin_Kofler> If the submitter tested the update, why should that not be reflected in karma and thus be sufficient for a stable push? 19:31:49 <mjg59> Because we don't trust the submitter to have adequately tested 19:31:57 <nirik> for 3, I was thinking it might be nice if people could submit for stable, but it automatically pushes in a week or karma... since that would save maintainer effort of tweaking it again after a week... but that might be hard to do. 19:32:14 <Kevin_Kofler> I'd say no to 3 (autopushing always sucks, it should be the maintainer's decision), but yes to 4 and 5. 19:32:29 <pjones> I'd say "correct, it only gives them the choice", "no", and "no". 19:32:49 <pjones> I wouldn't say "yes" or "no" for 3 because there's too much ambiguity in the question for that to be a meaningful answer. 19:33:08 <Kevin_Kofler> mjg59: But why? 19:33:11 <ajax> i don't intrinsically have a problem with 3, but i think it's outside the current scope. 19:33:16 <Kevin_Kofler> The maintainer should ALWAYS be trusted! 19:33:24 <Kevin_Kofler> It should be the #1 principle we're working on. 19:33:39 <mjg59> The maintainer has demonstrated that the maintainer cannot be trusted 19:33:42 <pjones> Kevin_Kofler: that's insane 19:33:42 <Kevin_Kofler> Adding bureaucratic red tape which stops the maintainer from doing his job is counterproductive. 19:33:55 <pjones> nobody pushes something they think is broken. 19:34:06 <cwickert> Kevin_Kofler, testing is a maintainer's job 19:34:14 <pjones> by definition the submitter believes it works. 19:34:41 <cwickert> and giving people sufficient time is necessary for testing. if the maintainer is the only one to test, the testing is more or less useless 19:34:45 <nirik> there is an implied +1 from the maintainer. 19:34:49 <ajax> and i think i'm against 4, on the grounds that the maintainer wouldn't have submitted it if they thought it didn't work. 19:34:55 <ajax> ie, what nirik just said. 19:35:03 <nirik> counting it in "someone has independently verified the update" seems a bad idea to me... 19:35:07 <Kevin_Kofler> Not really. I normally didn't do ANY testing, only where I +1ed my own update I actually tested it. :-) 19:35:25 <nirik> Kevin_Kofler: ? wow. 19:35:28 <pjones> Kevin_Kofler: I'm pretty sure you're effectively unique in this regard. 19:35:41 <notting> 3. "does not autopush". no on 4. *assuming* no on #4, i could see a maybe on #5 for non-critical-path items 19:35:46 <Kevin_Kofler> Yes, I've done direct stable pushes without more testing than "it builds". Guess what: they worked, and fixed some critical issues for some people! 19:36:23 <ajax> notting: that sounds right to me. 19:36:24 <cwickert> Kevin_Kofler, they worked because you are closing all the bugs "ustream" ;) 19:36:37 <nirik> ok, so 3 seems pretty agreed. 19:37:04 <cwickert> +1 for #3 19:37:06 <Kevin_Kofler> cwickert: The bugs which we close upstream come from upstream, not from any quick fix we directly pushed to stable. :-) 19:37:56 <ajax> let's make this clearer 19:37:57 <nirik> on, 4 I am a no. 19:38:10 <nirik> so that seems like 5 for no and 1 yes on question 4. 19:38:23 <cwickert> Kevin_Kofler, I am not convinced because I have seen bigs in our KDE that are not in Debian for example. nevertheless all of my reports are closed 19:38:26 <ajax> proposal re 3: minimum time spent in updates-testing does not imply automatic push to stable 19:38:28 <Kevin_Kofler> And usually, I do wait for at least one person to have tested an update before queueing it for stable. That may or may not be me. 19:39:07 <nirik> ajax: +1 I guess. 19:39:15 <pjones> ajax: +1 to that 19:39:16 <Kevin_Kofler> Of course if it's some package like kmid2 which has hardly any user, and definitely nobody ever doing any testing, what can I do other than just pushing stuff? 19:39:30 <Kevin_Kofler> I do try to test those updates myself before pushing them, but that's all I can do. 19:39:36 <mjg59> Kevin_Kofler: And since that's the kind of behaviour we're trying to stop, it sounds like the submitter should not be able to provide enough karma to push to stable 19:39:40 <ajax> Kevin_Kofler: if it has hardly any users, then it's not critpath, is it. 19:39:50 <ajax> Kevin_Kofler: try to stick to one argument at a time. 19:40:17 <Kevin_Kofler> But you also voted to have the karma requirements apply to non-critical packages as well! 19:40:27 <cwickert> on the one hand I agree to #4, on the other it's hard for the small desktops because they only have a few users/testers 19:40:28 <nirik> ok, any other votes on 3? I don't see any desenting ones, so I think thats done with. 19:40:35 <Kevin_Kofler> I was the only one who voted for striking that section! 19:40:45 <pjones> but right now we're discussing rules for critpath stuff! 19:40:49 <cwickert> +1 for #3 (but I already said that) 19:41:15 <nirik> lets move on to question 4... votes please? 19:41:20 <cwickert> can we just vote on the numbers? 19:41:41 <pjones> for number for, I propose that the submitter's vote does not count. 19:41:46 <pjones> number four even 19:41:52 * notting agrees with pjones 19:41:53 <nirik> pjones: I agree 19:41:54 <ajax> pjones: +1 19:41:58 <skvidal> #4 -1 19:42:05 <skvidal> so I agree with pjones 19:42:07 <Kevin_Kofler> I propose that the submitter should be able to set threshold at +1 and give his own vote for that. 19:42:12 * nirik notes that it should be easy to implement this in bodhi if we like from what I understand. 19:42:14 <cwickert> +-0, because I maintain packages that hardly have any testers 19:42:28 <nirik> cwickert: can't those packages wait a week? 19:42:43 <ajax> for 4, pjones notting nirik ajax skvidal -> +5 agreed 19:42:47 <cwickert> nirik, usually they can, so count me in, +1 then 19:43:08 <mjg59> Yeah, I'm +1 to submitter not being allowed to add karma 19:43:21 <cwickert> +1 to that 19:43:23 <nirik> #agreed submitter's vote does not count 19:43:27 <Kevin_Kofler> -1 to that 19:43:31 <pjones> for #5, I propose that the submitter should not be allowed to set the threshold at +1 19:43:42 <nirik> pjones: so, that means it must be +2 or more? 19:43:50 <ajax> pjones: agreed, with the understanding that this is a critpath policy, not a general policy. 19:44:03 <Kevin_Kofler> I propose that they should be allowed to set it at +1. 19:44:14 <pjones> for #5, I propose that for critpath packages, the threshold must be +2 or higher. 19:44:16 <cwickert> i think if the maintainer is not conted, +1 means that at least one other person has tested it 19:44:19 <Kevin_Kofler> Especially if their own vote doesn't count anyway. 19:44:25 <notting> ajax: the section nirik is referring to in questions #4 and #5 is *not* the critpath section 19:44:27 <nirik> for critpath the threshold doesn't matter... it will always require a +1 from tester/rel-eng and +1 from sometone else. 19:44:35 <nirik> (at leasat thats what I understand) 19:44:44 <pjones> Oh, hrm. 19:44:51 <pjones> well, now I've got to rethink this. 19:44:53 <ajax> hurr then. 19:45:04 <pjones> okay: ready, set, discuss some more. 19:45:05 * nirik is sorry if his questions were unclear. 19:45:09 <Kevin_Kofler> So there seems to have been a misunderstanding, we must redo the vote for #4. 19:45:21 <nirik> do we? 19:45:24 * notting reiterates his prior vote on #4 19:45:26 <ajax> doesn't change my vote for #4 at all. 19:45:29 <pjones> mine either. 19:45:34 * nirik 's vote is the same for 4 19:45:40 <mjg59> Also 19:45:45 <ajax> so that's five, so no we don't. 19:45:46 <skvidal> #4 == submitter vote doesn't count 19:45:50 * cwickert still doesn't change his mind about #34 19:45:52 <skvidal> my vote is unchanged 19:45:53 <cwickert> #4 19:45:59 <pjones> okay, so we all stay the same on 4. 19:46:06 <ajax> so! number 5. this is "important", which is "critpath for a spin" more or less? 19:46:07 <cwickert> right, on to 5 then... 19:46:09 <ajax> is that accurate? 19:46:27 <nirik> no. This is "any update" 19:46:57 <nirik> important/crit-path packages already need at least +2... +1 from proventester +1 from other person. 19:46:58 <notting> ajax: no, he's asking for clarification on "all updates can ... reach the positive bodhi karma threshold specified by the updates submitter" 19:47:03 <cwickert> sorry, but what have spins to do with it? have i missed something? where is critpath for spins defined? 19:47:09 <mjg59> For non-critpath/important, I guess I'm ok with a +1 requirement 19:47:24 <ajax> cwickert: i was inferring it from point 1 in his 5 questions. my bad,. 19:47:38 <Kevin_Kofler> Karma +1 is already one more than should be required. 19:47:40 <nirik> so, this is just any update. Can they set it to +1? 19:47:43 <pjones> yeah, for normal packages, I think +1 is fine 19:47:50 <pjones> as long as it isn't the maintainer. 19:47:51 <Kevin_Kofler> So I vote for yes, +1 should be enough! 19:47:59 <nirik> I am fine with them doing that since we decided #4 the way we did. 19:48:14 <ajax> +1 is fine for non-special updates, yes. 19:48:24 * notting is ok with +1 for non-critpath updates 19:48:25 <cwickert> ajax, I still don't get it, sorry. the word 'spin' is not even in the ticket... 19:48:28 <skvidal> one sec 19:48:47 <skvidal> is #5 contigent on the submitter's vote not being counted? 19:48:58 <pjones> cwickert: but it's implied with the @groups in #1 19:49:10 <ajax> cwickert: what is critpath+@lxde-desktop if not "things that are important to the lxde spin being consumable" 19:49:13 <Kevin_Kofler> skvidal: It was just decided that the submitter's vote won't be counted. 19:49:16 <skvidal> so essentially we're saying every update needs atleast one other tester, and critpath needs more than one 19:49:20 <cwickert> pjones, so it covers the desktop groups but not the actual spin? 19:49:36 <ajax> skvidal: or, standard 1 week timeout, yes. 19:49:42 <skvidal> ajax: okay 19:49:45 <skvidal> then fine +1 19:49:49 <skvidal> to #5 19:49:55 <Kevin_Kofler> But re #4, I still don't see what difference it makes whether I tested my update or somebody else did. 19:49:59 <nirik> ok, I don't see any objections. 19:50:06 <Kevin_Kofler> In the end effect it will have been tested by 1 person. 19:50:12 <cwickert> ajax, well, many things are important for the LXDE spin, but many of them have nothing to do with the LXDE desktop 19:50:14 <nirik> #agreed updates can set the karma level to +1 19:50:26 <Kevin_Kofler> Nowhere is there any verification that I actually did test any update I queued (and I'll happily admit I often didn't). 19:50:57 <ajax> cwickert: if i was reading the questions as being about "important" updates, then my opinion on #5 is different than if it's about arbitrary updates. 19:51:12 <nirik> ok, thats my questions. Do we wish to talk any more about this topic? or do we know what we need to do now? 19:51:20 <Kevin_Kofler> Another big issue is that we'll now need one person on EACH distro to #1 the update. 19:51:31 <abadger1999> I have one clarification question 19:51:36 <Kevin_Kofler> *to +1 the update 19:51:48 <cwickert> ajax, you mean sylpheed is critical because it is the default mail client in the LXDE while it normally wouldn't considered critpach? 19:51:53 <Kevin_Kofler> I think this is very much unworkable without a way to have the +1 counted for ALL affected distros. 19:51:56 <ajax> Kevin_Kofler: oh no, you'll have to click three buttons instead of one. 19:52:03 <abadger1999> For #1: we're having different comps groups go into the process of making the critical path list. But we're fine with a single critical path list coming out of that, correct? 19:52:16 <notting> abadger1999: i am, at least. 19:52:17 <Kevin_Kofler> ajax: That's not the point at all! 19:52:21 * abadger1999 making sure there's no bodhi/pkgdb work resulting from that. 19:52:23 <nirik> abadger1999: thats what I was gathering, yes. 19:52:27 <abadger1999> Excellent. 19:52:29 <Kevin_Kofler> Testers will probably only +1 the update for the distro they tested it on. 19:52:35 <skvidal> abadger1999: I'm cool w/that 19:54:07 <nirik> Kevin_Kofler: as they should, since thats what they tested? 19:54:08 <Kevin_Kofler> So we'll end up with many broken upgrade paths due to stuff having been tested on the older distro first, many packages not getting pushed to the previous stable release etc. 19:54:08 <ajax> Kevin_Kofler: aah, i see you're finally beginning to understand quality testing. 19:54:08 <Kevin_Kofler> nirik: No. 19:54:08 <Kevin_Kofler> A +1 for one distro should be sufficient to push the update to all. 19:54:08 <Kevin_Kofler> Otherwise we end up with broken upgrade paths. 19:54:08 <Kevin_Kofler> That's one of the biggest issues with this new policy. 19:54:08 <ajax> or, you could deploy updates sensibly. 19:54:08 <ajax> that's another option. 19:54:08 <Kevin_Kofler> Updates to distros should be kept in sync. 19:54:08 <Kevin_Kofler> The same bugfix updates should go out to all supported releases at the same time. 19:54:08 <mjg59> It's almost like we'd had this conversation before 19:54:08 <cwickert> if something works on F11 it can still crash horribly on F13 19:54:14 <drago01> or we could start using distro epoch ... 19:54:15 <Kevin_Kofler> cwickert: Theoretically yes. 19:54:20 <cwickert> paractically too 19:54:24 <nirik> yes, anything further (thats new) on this topic? or shall we move on? 19:54:27 <Kevin_Kofler> In practice it's so extremely unlikely that it's just not worth worrying about. 19:54:40 <Kevin_Kofler> drago01: That'll just replace upgrade path breakage with regressions. 19:54:43 <Kevin_Kofler> Not that great a plan. 19:55:21 <nirik> ok, moving on then? 19:55:25 <cwickert> nirik, lets move please. i don't want to argue about testing with people who say they actually don't test anything 19:55:27 <nirik> #topic #363 Proposal: auto sign pkgs in koji 19:55:34 <nirik> .fesco 363 19:55:35 <zodbot> nirik: #363 (Proposal: auto sign pkgs in koji) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/363 19:55:50 <drago01> that might happen if you have foo-1.0 in F-N and foo-2.0 in F-N-1 with different config file formats ... which shouldn't happen anyway 19:55:52 <drago01> Kevin_Kofler: ^^ 19:56:00 <drago01> anyway offtopic here 19:56:19 <nirik> I'm fine with this proposal. I think it's a great idea. 19:56:20 <Kevin_Kofler> drago01: A bug getting fixed only in Fn-1 means that if you upgrade to Fn, you have a regression. 19:56:48 <skvidal> nirik: are you comfortable with my addendum? 19:56:53 <nirik> This is just one single 'koji' key for all non scratch builds right? not per release or anything? 19:57:01 <ajax> skvidal: "our" key. which? 19:57:08 <notting> i don't see how the addendum necessarily follows as required. i'm ok with the original proposal 19:57:13 <skvidal> ajax: a fedora-release-specific key 19:57:21 <nirik> skvidal: sure, I think thats a good idea too... but does it need to be done before this? 19:57:40 <Kevin_Kofler> I don't understand skvidal's addendum. 19:57:48 <skvidal> it feels like it should be done - but maybe it is not required 19:57:59 <skvidal> it is just way of saying 'yes someone in fedora signed off on this as a repo' 19:58:11 <Kevin_Kofler> "repositories must be signed by our key" – which repositories? 19:58:14 <ajax> by repository, you mean repodata as well as the package, i guess? 19:58:19 <skvidal> no 19:58:29 <skvidal> so a repo has a dir repodata 19:58:32 <skvidal> which as a file repomd.xml 19:58:44 <skvidal> yum supports checking a detached signature on repomd.xml 19:58:55 <skvidal> since repomd.xml has sh256 checksums of all the metadata 19:58:59 <Kevin_Kofler> Oh, so you want the official Fedora repositories to have signed metadata? 19:59:02 <skvidal> and the metadata has sha256checksums of all the pkgs 19:59:12 <Kevin_Kofler> That's definitely a good idea! 19:59:13 <skvidal> then the trust comes down from the signed repomd.xml 19:59:36 <ajax> i'm... slightly cautious about that. 19:59:41 <skvidal> now - I see the point that maybe this is not required to implement auto-signed pkgs about keys 19:59:43 <skvidal> ajax: okay, why? 20:00:27 <Kevin_Kofler> I'm +1 to autosigning packages and +1 to signing the metadata in official Fedora repositories. 20:00:30 <skvidal> ajax: if it helps, this mechanism has been vetted by mark cox 20:00:30 <ajax> well, maybe not. one second. 20:00:52 <Kevin_Kofler> (Third-party repositories obviously need to make their own decisions on how to handle signing.) 20:01:06 <ajax> skvidal: just trying to make sure i have the details straight. this detached signature would be from the same key that signs the koji packages? 20:01:11 <dgilmore> skvidal: all packages for all releases will be signed via one key 20:01:11 <nirik> yeah, both sound great, but whenever either can land is fine with me. I don't think there needs to be a requirement on one for the other. 20:01:28 <notting> skvidal: i'm concerned about repomd.xml signing merely because i understand how we build repositories now and am having trouble wrapping my head around how we sanely integrate it into current processes. i'm fine with the idea. :) 20:01:28 <skvidal> ajax: no - it [wc]ould be a different signature 20:01:30 <dgilmore> skvidal: the key says this was built in fedora's koji, nothing more nothing less 20:01:37 <nirik> dgilmore: right. 20:01:54 <skvidal> dgilmore: that key is the one signing the pkgs 20:01:58 <dgilmore> skvidal: then we would sign the repodata we push out to users and they would verify that and the koji key 20:02:22 <ajax> skvidal: then i guess i don't see what it adds. i can pretty easily make a key that claims to be the F13 release key, and sign my repodata with that. 20:02:30 <ajax> it won't be the same key, of course. 20:02:40 <skvidal> ajax: and then you'll get that key onto the user's systems, how? 20:03:00 <skvidal> ajax: if you're proposing a MITM attack, then you'd need to get the users to trust your key. 20:03:42 <ajax> skvidal: okay, so, in your model, how do you get the user to trust the key that signs repomd.xml? 20:04:04 <skvidal> ajax: that's the key we blow on the system at install in the fedora-release pkg 20:04:46 <notting> skvidal: technically, we put both (koji and release) keys on the system @ install? 20:05:00 <skvidal> notting: that would be what we're going for here, yes. 20:05:07 <skvidal> in an IDEAL world 20:05:20 <skvidal> we would actually put a trust key on the systems 20:05:23 <notting> and we're not concerning ourselves with bug 998 yet 20:05:26 <skvidal> and yum would download the other keys 20:05:30 <skvidal> notting: no one cares about 998 20:05:38 <skvidal> verify that the other keys were signed by our trust keys 20:05:45 <Kevin_Kofler> What's bug 998? 20:05:46 <skvidal> and then agree to them 20:06:03 <nirik> Kevin_Kofler: one of the oldest still open bugs... 20:06:06 <skvidal> s/to them/to trust them/ 20:06:09 <nirik> .bug 998 20:06:11 <zodbot> nirik: Bug 998 Network install/upgrade is unsafe, should check GPG signatures. - https://bugzilla.redhat.com/show_bug.cgi?id=998 20:06:31 <ajax> skvidal: well, okay then, that's no worse than what we've got, and doesn't imply getting the user to reflexively say yes to any more "do you trust this key" prompts 20:06:50 <Kevin_Kofler> Oh, that one. Fun… 20:07:08 <mbonnet> skvidal: would yum allow packages signed by the "Koji" key to be installed? Do we want it to without explicit authorization? 20:07:08 <ajax> it doesn't solve my pet irritation that there's no trust cascade from Fn to Fn+1, but that's out of scope. 20:07:27 <skvidal> mbonnet: when the CA code is implemented that, in fact, would be the point 20:07:48 <skvidal> ajax: if we have a CA key then it would 20:08:04 <mbonnet> skvidal: I see a distinction between "I trust repodata signed with this key" and "I trust packages signed with this key", but maybe that's not an important distinction. 20:09:14 <nirik> ok, so where are we here? 20:09:27 <nirik> aside from at 15minutes. ;) 20:09:28 <ajax> i'm in favor of jesse's proposal. 20:09:43 * nirik didn't see any objections... 20:09:50 <ajax> i'm slightly in favor of doing skvidal's amendment at the same time, but i'm not going to insist on it either way 20:09:55 <pjones> I still think this completely erodes all actual trust, but meh. 20:10:08 * notting is in favor of both proposals, but sees no reason to tie them 20:10:21 <skvidal> I'm fine with not requiring the latter for the former 20:10:26 <Kevin_Kofler> I've been in favor of autosigning all this time, I'm +1 to it. 20:10:42 <Kevin_Kofler> And like notting, I'm also +1 to skvidal's comment, but don't see the need to do both at the same time. 20:11:08 <nirik> pjones: you have objections? 20:11:19 <nirik> oh, I suppose we need to vote to continue discussion... 20:11:26 <pjones> nirik: I think auto-signing without certs that explain what the signature means aren't terribly meaningful. 20:11:40 <pjones> isn't, rather. 20:11:57 <ajax> pjones: i think the idea is it's the same cert as we would otherwise use for the final release. 20:12:03 <nirik> pjones: it means "This was built by koji.fedoraproject.org and is not a scratch build" 20:12:06 <ajax> which is, admittedly, theatre. 20:12:23 <skvidal> pjones: no one knows what the certs mean now - they are fundamentally a 'look my bits didn't work' functionality 20:12:38 <pjones> skvidal: fair enough. 20:12:55 <skvidal> the only benefit we get out of yum complaining about them 20:13:05 <skvidal> is we find out when something slipped out of bodhi/mash w/o being signed 20:13:07 <pjones> nevertheless, this seems to be a fine proposal, I just don't see it actually accomplishing anything. 20:13:19 <skvidal> pjones: if we allow auto-signed pkgs 20:13:25 <skvidal> then releng doesn't have to sign as a separate step 20:13:29 <ajax> pjones: if nothing else, it makes release compose a hell of a lot faster 20:13:33 <pjones> that's true. 20:13:53 <skvidal> pjones: and I like Oxf13 and jwb and I sorta like notting and I think we should be nicer to them :) 20:14:03 * skvidal grins in notting's general direction 20:14:14 <nirik> #agreed the proposal is approved. 20:14:17 <ajax> (well, amortizes release compose time over the preceeding six months. whatever.) 20:14:35 <nirik> #topic FES tickets update 20:14:42 <nirik> mmcgrath: you have anything in general to note? 20:15:01 <mmcgrath> nirik: hey, no major work since last week, little fixes, new lists generated. 20:15:20 <nirik> I added 2 new tickets that I'd like to note here for input or scorn: 20:15:26 <nirik> https://fedorahosted.org/fedora-engineering-services/ticket/17 20:15:39 <nirik> Investigate implementing cross desktop support shortcuts 20:15:56 <nirik> Have some way to more easily get our end users to our support forums. 20:16:21 <mmcgrath> I saw that, I think jose took one already 20:16:25 <mmcgrath> well I assigned it :) 20:16:38 <nirik> yeah... hopefully some good will come of it. Any input welcome in the ticket. 20:17:13 <nirik> and also I filed: https://fedorahosted.org/fedora-engineering-services/ticket/18 which is "investigate weekly Fedora gaming sessions". :) 20:17:18 <Kevin_Kofler> Putting the shortcuts into the xdg-user-dir for Desktop should be sufficient. 20:17:37 <nirik> Kevin_Kofler: oh, thats a good idea... 20:17:38 <Kevin_Kofler> KDE will show them in its default folder view applet, most other environments directly on the desktop. 20:18:02 <nirik> although they will need to figure out what DE they are running under for the right apps. 20:18:32 <nirik> I'll also note that "port syslinux isohybrid perl script to C" had a patch submitted upstream. 20:18:58 <nirik> and "Document Fedora as android devel platform" worked fine here this weekend and looks good. 20:18:59 <pjones> did somebody actually talk to hpa about that first? 20:19:04 <pjones> he tends to actually be a fan of perl. 20:19:10 <ajax> ... the nutter 20:19:12 <Kevin_Kofler> Well, .desktop files directly take at least HTTP URLs. 20:19:20 <Kevin_Kofler> Not sure about mailto or irc URLs. 20:19:39 <nirik> pjones: not sure, I think mdomsch did... ticket is at https://fedorahosted.org/fedora-engineering-services/ticket/15 20:19:47 <pjones> okay 20:20:50 <nirik> ok, thats all I had on that. Update/file new tickets... keep the work going. ;) 20:21:01 <nirik> #topic F13 Beta 20:21:07 <nirik> Beta went out today... 20:21:18 * skvidal 's update just finished 20:21:18 <ajax> \o/ 20:21:26 <nirik> I'd like to give kudos to all who worked on it. ;) 20:21:51 <skvidal> ajax: is that a symbol for devil worship? :) 20:22:05 <Oxf13> put your hands in the air 20:22:13 <pjones> skvidal: no, that's \m/ 20:22:27 <skvidal> :) 20:22:32 <nirik> Thats the surfer sign right? :) 20:22:38 <nirik> #topic Open Floor 20:22:42 <nirik> Anything for open floor? 20:22:47 <pjones> nirik: I thought the surfer sign had the thumb extended? 20:23:01 <nirik> \o( 20:23:07 <Kevin_Kofler> nirik: The surfer sign would be _rm/ :-) 20:23:08 <pjones> so it's more like >n/ 20:23:11 <nirik> or )o/ 20:23:14 <skvidal> pjones: did you not read the bruhaha on the ambassadors or whatever for it? 20:23:20 <cwickert> i have something on my mind 20:23:25 <pjones> skvidal: what? 20:23:26 <nirik> cwickert: go ahead. 20:23:35 <cwickert> about cleaning up the deps... 20:23:42 <pjones> skvidal: about the horns? 20:23:44 <Oxf13> that'd be the "hang loose" sign 20:23:45 <skvidal> pjones: yes 20:23:49 <cwickert> I still haven't come up with a proposal 20:23:54 <skvidal> cwickert: to clean up which deps? 20:23:56 <cwickert> but i have filed several bugs 20:23:59 <Oxf13> or "shakka" 20:24:14 <cwickert> .fesco 345 20:24:15 <zodbot> cwickert: #345 (Dependency chain painpoints) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/345 20:24:16 <nirik> cwickert: the evince thing was fixed. 20:24:17 <skvidal> ah 20:24:33 <cwickert> nirik, there are even more on nautilus 20:24:35 <cwickert> and others 20:24:56 <cwickert> but I have no idea how we could make a *propsal* or a plan out of this 20:24:59 <nirik> yeah, the pidgin/evolution one is the next big one I want to see done. 20:25:17 <cwickert> I think we must file bugs and decide on a per-bugs-base 20:25:33 <nirik> yeah, I don't know what we want there. Really it should be: If you notice a bad dep, file a bug and try and get it fixed. If you run into problems escalate it? 20:25:42 <cwickert> is there a general rule of thumb that everybody agrees to? 20:25:52 <Kevin_Kofler> I think the "firstboot Requires metacity" issue is the worst. 20:26:00 <cwickert> or something we as FESCO could do to make it happen? 20:26:03 <Kevin_Kofler> It's dragging quite some unwanted GNOME stuff onto the KDE spin. 20:26:22 <cwickert> Kevin_Kofler, actually it's system-config-kexboard depending on metacity 20:26:28 <nirik> cwickert: I think it's hard to have a general rule... each case could be quite different. 20:26:43 <Kevin_Kofler> It is? Last I checked it was firstboot… 20:26:55 <cwickert> firstboot requires s-c-k 20:27:04 <nirik> firstboot does require metacity 20:27:07 <Kevin_Kofler> firstboot also uses metacity directly. 20:27:07 <ajax> need a window manager somehow. 20:27:21 <cwickert> foh, indeed 20:27:24 <nirik> s-c-k requires firstboot 20:27:24 <Kevin_Kofler> Yeah, but it could be made to use kwin on the KDE spin. 20:27:31 <ajax> it could! PGA i'm sure. 20:27:39 <Kevin_Kofler> kwin can be run standalone as well. 20:27:40 <nirik> in the past deps like that have been solved by a virtual provide. 20:27:43 <cwickert> ajax, this is something we could do with a proposal, i will come up with one by next week 20:27:57 <nirik> Requires: somewindomanagerofsomekind 20:28:06 <Kevin_Kofler> But in Rawhide even Anaconda itself wants Metacity. :-( 20:28:28 <cwickert> is there any reason not to use a virtual provides for netwm compatible WMs? 20:28:40 <Oxf13> that's because anaconda no longer uses it's own wm 20:28:43 <Kevin_Kofler> With Metacity being deprecated even in GNOME, with gnome-shell integrating the WM, I think we really shouldn't use metacity for this purpose. 20:28:44 <Oxf13> it uses metacity 20:28:48 <ajax> cwickert: only in the sense that you don't know how to invoke them. 20:29:07 <Kevin_Kofler> I could hardcode a solution for kwin, but that won't help the other spins. 20:29:14 <cwickert> ajax, this is left up to the spins, we are already doing this for a couple of releases now 20:29:21 <ajax> Kevin_Kofler: that's a little stronger of a position than gnome is actually taking. 20:30:05 <Kevin_Kofler> cwickert: The problem is that Anaconda and Firstboot need to invoke the WM outside of the usual context. 20:30:06 <nirik> How about we try and use our devel list for a discussion of this issue and see if we can reach a solution there? (I know... trying to make the devel list used for devel topics, what am I thinking!) 20:30:15 <ajax> nirik: capital idea. 20:30:18 <Kevin_Kofler> They need a WM in their own, sorta-embedded environment. 20:30:24 <pjones> nirik: sure. 20:30:40 <cwickert> I think the wm issue is really something for a proposal. the rest needs to be decided individually 20:30:46 <cwickert> eof for now 20:30:49 <Oxf13> Kevin_Kofler: actually we need less stuff like that duplicating functionality 20:31:01 <nirik> cwickert: would you be willing to drop a post to the devel list explaining the issue in detail and possible solutions? 20:31:07 <Oxf13> there is no good reason for Anaconda to continue maintaining it's own WM duplicating features of other WMs as it needs them. 20:31:18 <notting> Oxf13: ... which is why it isn't any more 20:31:20 <cwickert> nirik, sure, if i find the time to test it 20:31:28 <Kevin_Kofler> Sure, but always dragging in the GNOME WM isn't a good solution either! 20:31:30 <nirik> anaconda should just use ratpoison. :) 20:31:32 <Oxf13> notting: right, we don't want to go back to it. 20:31:43 <cwickert> nirik, twm ftw ;) 20:31:48 <Oxf13> Kevin_Kofler: you object because it's the "gnome" wm? 20:31:51 <Oxf13> really? 20:32:00 <Kevin_Kofler> I object because it has MANY GNOME deps. 20:32:07 <Kevin_Kofler> Even stuff like libcanberra. 20:32:15 <nirik> #agreed Discussion on devel list to try and solve metacity deps in anaconda and firstboot 20:32:18 <pjones> I wouldn't mind having fewer deps. 20:32:18 <cwickert> Oxf13, no because it pulls in things like gconf etc 20:32:24 <Kevin_Kofler> This is all stuff the KDE spin ONLY ships because metacity requires it. 20:32:26 <Oxf13> now that's a different argument. 20:32:39 <Oxf13> one that's worth having, if there are ways to lessen the dep list on metacity 20:32:45 <Kevin_Kofler> We need a lighterweight WM for Anaconda and Firstboot to use. 20:32:48 <Oxf13> far better discussion than "go write your own" 20:32:52 <pjones> that being said, you're going to have some of that anyway, because we use gtk widgets. 20:32:58 <notting> nirik: .. is that the end of the agenda? 20:33:03 <nirik> notting: yes. 20:33:07 <nirik> Anything else for open floor? 20:33:11 <Kevin_Kofler> GTK+ is one thing, libcanberra, GConf etc. is another. 20:33:15 <cwickert> not from me... 20:33:18 <pjones> yeah, I said "some" for a reason. 20:33:20 * nirik will close out the meeting in a minute if nothing else comes up. 20:33:28 <cwickert> openbox ftw! ;) 20:33:35 <skvidal> one more thing 20:33:37 <skvidal> sorry 20:33:40 <nirik> skvidal: ok. 20:33:50 <skvidal> I just finished running the 'potentially unmaintained' script again 20:33:55 <skvidal> just for the fun of it 20:34:00 <cwickert> results? 20:34:06 <skvidal> it seems like we're getting an increasing number of pkgs which don't look healthy 20:34:08 <Oxf13> skvidal: I bet it got bigger. 20:34:11 <skvidal> Oxf13: :) 20:34:19 <Oxf13> we had a couple people orphan up a lot of packages recently 20:34:25 <skvidal> yah 20:34:35 <skvidal> lemme upload the by-user output 20:34:49 <nirik> oh yeah, I was wondering what happened with that. 20:35:09 <skvidal> http://fpaste.org/mMfn/ 20:35:21 <nirik> #info skvidal re-ran the potentially unmaintained script again, results at http://fpaste.org/mMfn/ 20:35:46 <cwickert> awjb has 61 packages, wow! 20:35:52 <skvidal> I've got 4 pkgs in there which need some love, too 20:35:56 <nirik> this is against 13? 20:36:11 <skvidal> rawhide 20:36:13 <cwickert> wft? I have 44? 20:36:33 <skvidal> any pkg that has not been rebuilt by a user since the last autorebuild 20:36:41 <skvidal> I'll have to recheck the dates - but I think I'm current on that 20:36:42 <pjones> skvidal: python-goopy probably ought to just be pkgwacked 20:36:46 <cwickert> skvidal, i had like 15 or 20 and updated some of them, but the list got even bigger for me? 20:36:49 <nirik> that time is growing since we didn't have one this cycle. 20:36:53 <drago01> there might be valid reasons for that 20:36:55 <skvidal> pjones: you'd be the guy to do that :) 20:36:59 <ajax> wooo, i'm popular. 20:37:00 <pjones> skvidal: since there's never been a single upstream update since the first release and that was several years ago and all. 20:37:22 <skvidal> pjones: I can give you the bullets, but you're going to have to pull the trigger. :) 20:37:26 <cwickert> skvidal, I thought it was "within the last year", right? 20:37:29 <pjones> skvidal: yeah 20:37:42 <skvidal> cwickert: 6months, iirc 20:37:57 <cwickert> skvidal, this is not enough IMO 20:38:00 <skvidal> http://skvidal.fedorapeople.org/misc/potentially-unmaintained/koji-old-pkg-query.py 20:38:03 * Kevin_Kofler has 3 packages on the list as well. 20:38:04 <skvidal> that's the script 20:38:09 <skvidal> I'll rerun it with whatever number 20:38:11 <cwickert> when was the script run? 20:38:18 <skvidal> like 10minutes ago 20:38:23 <skvidal> so - something to keep in mind 20:38:27 <Kevin_Kofler> ksensors: dead upstream, z88dk: no upstream release in the last few months 20:38:28 <cwickert> skvidal, then it must be wring 20:38:29 <skvidal> this list is not meant to abuse anymore 20:38:30 <cwickert> wrong 20:38:36 <pjones> skvidal: a'ight, done. 20:38:46 <skvidal> as before - it's just to point out things someone might have forgotten about 20:38:55 <skvidal> or not been able to maintain for whatever reason 20:39:01 <skvidal> and sometimes the script just points out bugs :) 20:39:02 <Kevin_Kofler> flasm: not actually sure, I picked that up because pertusus said it can be useful for debugging Gnash, I don't really have a use for it myself, I have to check its upstream status. 20:39:09 <cwickert> skvidal, the list shows sakura and lilyterm, both were updated 4 days ago 20:39:12 <cwickert> http://koji.fedoraproject.org/koji/packageinfo?packageID=8216 20:39:14 <nirik> sure... some of might are legit dead... some of them are just very slow to update. 20:39:19 <skvidal> cwickert: a rawhide build? 20:39:22 <cwickert> http://koji.fedoraproject.org/koji/packageinfo?packageID=8203 20:39:27 <cwickert> F13 as well 20:39:40 <skvidal> cwickert: I don't see rawhide there 20:39:49 <Oxf13> neither do I 20:39:58 <cwickert> skvidal, i think it's inherited? 20:40:00 <skvidal> this is checking dist-rawhide in koji 20:40:02 <Oxf13> and the F13 one won't show up in rawhide until/unless it goes into dist-f13 stable 20:40:10 <cwickert> ah 20:40:14 <Kevin_Kofler> flasm is also up to date. 20:40:22 <Kevin_Kofler> (1.62, there's no newer upstream release.) 20:40:34 <Kevin_Kofler> So all these are false positives, they haven't been touched because upstream hasn't released anything newer. 20:40:43 <Kevin_Kofler> I'm sure many of those packages are like that. 20:40:47 <Kevin_Kofler> Not just mine. 20:40:54 <nirik> sure. 20:41:09 <Oxf13> it's a list of things to check into 20:41:09 <skvidal> anyway - I was just thinking about this - so I ran it again - some useful info to know, etc 20:41:09 <cwickert> are builds for F13 no longer inherited into rawhide automatically? 20:41:14 <Oxf13> not a definitive list of "These all have problems!" 20:41:20 <Oxf13> cwickert: only when they go stable. 20:41:26 <cwickert> i see 20:41:35 <nirik> skvidal: perhaps worth posting on devel? might get some folks thinking about things they should drop... 20:41:38 <skvidal> Oxf13: right - this is not a list of YOU ARE BAD AND DOOM - it's just a list of 'hmm, maybe go look at this' 20:41:49 <Oxf13> skvidal: sometimes it's hard to get people to realize that 20:41:50 <skvidal> nirik: fine by me - I just wanted to run this by y'all see if anything leapt out 20:42:20 <nirik> yeah, I see some of mine I keep meaning to drop... should do so. 20:42:23 <skvidal> Oxf13: I don't disagree... 20:42:34 <skvidal> pjones: thanks for killing a pkg 20:42:40 <nirik> when do we do the orphan purge this cycle? or it's already done for f13? 20:42:41 <skvidal> pjones: the repodata load thanks you 20:43:08 <Oxf13> nirik: we did it around branch time 20:43:09 <pjones> skvidal: jebus and I love you, seth. 20:43:19 <nirik> ok. 20:43:20 <skvidal> pjones: fsm, too? 20:43:25 <Kevin_Kofler> :'-( one less package… 20:43:29 <pjones> his noodly appendage too. 20:43:33 * nirik thinks he should kill gdk-pixbuf and tpb with fire. 20:43:37 * Kevin_Kofler would like to see Fedora ship everything possible and imaginable. 20:43:53 <pjones> Kevin_Kofler: and again, we're talking about a package with no upstream and no users. 20:43:54 <Kevin_Kofler> Total world domination. :-) 20:44:00 <skvidal> that's all I have 20:44:01 <nirik> ok, anything else? or shall we close the meeting now? 20:44:26 <Oxf13> I'd rather not see Fedora collapse under it's own weight of unmaintainable crap. Leave that to Debian 20:44:34 <nirik> Thanks for coming everyone. 20:44:38 <nirik> #endmeeting
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
