20:00:35 #startmeeting FESCO (2010-01-19) 20:00:35 Meeting started Tue Jan 19 20:00:35 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:35 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:35 #meetingname fesco 20:00:35 #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones cwickert mjg59 20:00:35 #topic init process 20:00:35 The meeting name has been set to 'fesco' 20:00:35 Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 nirik notting pjones skvidal 20:00:43 * skvidal is here 20:00:45 Who all is around for a fesco meeting? 20:00:48 * cwickert is here 20:01:09 * pjones here 20:02:06 Present. 20:02:09 * notting is here 20:02:11 * skvidal would like this meeting to be 1 hour long, if possible 20:02:15 * dgilmore is here 20:02:43 skvidal: we can try... 20:02:44 #topic FOLLOWUP: #298 Revoke Paul Johnsons pacakger access and put him on probation. 20:02:45 .fesco 298 20:02:47 nirik: #298 (Revoke Paul Johnsons pacakger access and put him on probation.) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/298 20:03:11 any news here? I have not seen any posts from him, nor contact to my last few emails... 20:03:19 Why is this still on the agenda? Haven't we already decided there's no reason to act on this? 20:03:24 nirik: ive seen no feedback from him 20:03:46 Kevin_Kofler: because he's failed to fix his email or respond of late? I guess we could go to the unresponsive maintainer procedure? 20:04:04 he hardly cooperates with anybody, IMO we need to do something here 20:04:20 give him another week to fix/respond and then act? or do something now? 20:04:41 * mchua notes that Marketing folks might show up here (this is our usual meeting time/place) but we'll gather in #fedora-mktg instead, so send people that way if needed. (sorry for the interruption.) 20:04:58 mchua: ? oops... wasn't on the meeting page... 20:05:04 Kevin_Kofler: IIRC we agreed that there should be some movement now that he's aware of the problem 20:05:31 so, we could reassign his packages until he gets stuff fixed... are there comaintainers or people who would like to become primary on them? 20:05:38 nirik: Yeah, that was my bad - when we changed it some months back I didn't update the page. We'll figure it out afterwards. 20:05:43 give him some kind or warning, tell him to respond within a week 20:05:58 mchua: sorry, I didn't update fesco yet either. ;( 20:06:07 cwickert: so, in effect, same as we said last time? 20:06:26 * dgilmore thinks we should act now 20:06:39 pjones: last time was a friendly reminder, this time we need to be more serious 20:06:40 but i was also the person who brought the issue up 20:07:09 he's not primary for mono... 20:07:27 I think the email problems are a lame excuse. If somobody cannot manager his mail filters, he should not own packages ;) 20:08:00 I think technical difficulties can always happen. 20:08:08 cwickert: maybe it's not QUITE that bad - but I agree that communication about your packages should be possible and not technically constrained 20:08:16 dgilmore: I haven't seen any commits from him since jan 1st. 20:08:54 skvidal: certainly in a long timeframe, yes. 20:09:00 (obviously outages happen) 20:09:08 nirik: but hs submitted a few new reviews 20:09:19 pjones: yes, short term shit happens 20:09:21 where he did not respond to my comments ether 20:09:42 nirik: That's just 18 days, was there a commit actually needed that he didn't do? 20:09:56 not that I know of. 20:10:20 So I don't see how the apparent lack of commits is a problem. 20:10:22 so maybe the thing we should do is find somebody (not already involved in the whole fiasco) to act as co-maintainer in sort of a UN-observer role. 20:10:25 but the primary issue here was that he was commiting things and messing up other maintainers commits. 20:10:50 Well, he said that was a broken script and he stopped using that script. 20:10:52 nirik: so, leave it as handled until he does it again? 20:11:03 nirik: I really think the primary issue was the email problem and the broken script, combined 20:11:05 Kevin_Kofler: sure, but with no commits, we don't know for sure. ;) 20:11:20 No commits means he isn't clobbering anyone's work, at least. ;-) 20:11:26 nirik: which (as he tells it) resulted in the clobbering, among other things 20:11:43 is there some reason to /doubt/ his claim that he's stopped using the broken script? 20:12:15 pjones: only in that people have asked him to not clobber their changes in the past and it kept happening. 20:12:48 but it "kept happening" before rather than after he said he knew how that happened and has fixed his workflow, right? 20:13:08 How about we tell him: fix your email please before commiting/etc. If we see further issues down the road, we will revoke packager? 20:13:16 pjones: yeah, thats my understanding... yes. 20:13:20 pjones: of course we should trust him, but he even overwrote his own stuff, so this shouldn't happen even with a broken script 20:13:46 cwickert: I am not really ready to concede that you can't do all kinds of stupid things with a broken shell script. 20:14:01 * nirik offered in email to work with him on irc and/or look at any bounce emails he got against the logs. No answer. 20:14:10 but that was only a few days ago. 20:14:14 this script has no brain - use your own... 20:14:17 I think it's a script which works similarly to our cvs-import.sh, it just overwrites everything no matter what. 20:14:23 nirik: okay, so it does sound like there are stil some communications problems 20:14:29 He says he tried to code it to detect changes in CVS, but that didn't work. 20:14:41 pjones: or could be... 20:15:19 so, the two things we could do are: give him more time to fix stuff and see if he breaks anything, or revoke his status. 20:15:46 there definitely are still communication probems as well as "attitude problems", e.g. only posting a srpm in a review but not the spec because people interested should get the spec fron the srpm 20:15:47 personally, I would be ok with giving him till next week to get his email fixed up... 20:16:06 thoughts? votes? 20:16:44 I think telling him we're going to revoke his packager status might be extreme, but we probably should let him know that we need some assurances that a) the communication problems are resolved or at least better (or at least acute) 20:16:54 * skvidal is fine with delaying this another week 20:17:23 one more week, but we should make clear that this is a serious problem and not only some technical issues 20:17:53 ok, any opposed to that? 20:18:07 * nirik can update the ticket/mail him again. 20:18:39 * nirik will move on to the next topic unless someone objects soon. 20:18:55 #topic #302 libssh2 - non-responsive maintainer 20:19:30 .fesco 302 20:19:31 nirik: #302 (libssh2 - non-responsive maintainer) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/302 20:19:49 So, the maintainer isn't nonresponsive, just somewhat busy. He's added a co-mainainter for libssh2. 20:19:59 * dgilmore is ok with that 20:20:07 * skvidal is fine w/that too 20:20:15 He doesn't wish to work with the ticket reporter as a comaintainer at this time. 20:20:28 that's also fine 20:20:33 I think this sucks. 20:20:38 +1 20:20:38 if the current co-maintainer is working on it 20:20:45 The ticket reporter has good reasons to request comaintainership. 20:20:46 then that's fine by me 20:20:52 (He's the maintainer in RHEL 6+.) 20:21:02 Kevin_Kofler: not a pertinent reason for fedora 20:21:06 Kevin_Kofler: should we force a maintainer to work with someone they don't wish to? 20:21:09 So I don't see why he shouldn't be allowed to comaintain the package also in Fedora and EPEL 5-. 20:21:33 We need to work together to make Fedora good. 20:21:41 Kevin_Kofler: which means he's working on the software. That's fine and all, but it's not really how we've structured the reasoning for who's maintainer. 20:21:49 The maintainer brought up no concrete reason against it, just "he rubbed me the wrong way". 20:21:55 I would suggest he take a less confrontational approach, and submit bug reports with patches and/or gate his changes via the other comaintainer until the maintainer is willing/able to add him. 20:22:19 Kevin_Kofler: there are lots of folks who I would not give comaintainer access to just b/c they annoy me 20:22:25 Kevin_Kofler: I don't see anything wrong with that 20:22:26 It sucks if fixes get only into RHEL and not Fedora because we don't allow the RHEL maintainer to just commit them. 20:22:26 I think asking somebody to be co-maintainer with somebody they find abrasive also has its problems. 20:22:27 There are also issues on curl. 20:23:04 Kevin_Kofler: if the requester decides that if he can't maintain it, he won't even submit patches, that sounds like a problem as well. 20:23:33 so, shall we close this with: the maintainer is responsive, please try and work with him or the other co-maintainer? 20:23:33 I don't see why we need to force Kamil to jump through hoops to get his fixes merged. 20:23:44 he's got some opportunity to earn the maintainer's trust here, and he's sortof avoided doing so, instead declaring that he should be added because he's got a related job. 20:23:48 nirik: +1 20:23:50 nirik: did he give a good reason for refusing this particular comaintainer. I can't find anything in his mail 20:24:01 cwickert: He didn't. 20:24:04 cwickert: nothing concerete... 20:24:10 just "rubbed the wrong way" 20:24:16 And IMHO that's not acceptable. 20:24:22 yaeh, whatever this mean... 20:24:34 +1 Kevin_Kofler 20:24:39 note on the curl package, cweyl did a commit and kamil partially reverted it with a 'this commit was nonsense' 20:24:55 *sigh* 20:24:57 He has valid reasons to request comaintainership and it's getting rejected on a "I hate this guy" basis. 20:25:04 they disagree when/if curl needs rebuilding for libssh2 changes. 20:25:27 I don't think we've ever put in any policy anywhere that there's some /requirement/ to add people as co-maintainers without substantial (positive) previous interaction. 20:25:36 is there anybody to decide who is actually wrong or right? 20:25:37 which is what you're implying, AFAICS, Kevin_Kofler. 20:25:46 We thought common sense would be enough. 20:25:50 Sadly, it seems not. :-/ 20:25:54 Kevin_Kofler: common sense says to me 20:25:57 nirik: +1 20:25:58 if someone is a pain in the ass 20:26:01 I don't want to work with them 20:26:05 I don't think common sense dictates that kamil should be a co-maintainer. 20:26:16 and if I have a choice in the matter 20:26:18 I won't work with them 20:26:25 now - I don't think kamil is a pain in the ass 20:26:33 but maybe the libssh2 maintainer does 20:26:37 and guess what? That's his right 20:26:44 so let's not legislate relationships here 20:26:46 and move along 20:26:49 I think cweyl is the one who's behaving like a PITA here. 20:27:34 cweyl added a %define _default_patch_fuzz 2 \n\n to curl. 20:27:43 That was the "nonsense" Kamil reverted. 20:27:49 I hope for fedora that Kamil takes a less confrontational path and earns cweyls trust so he can be added... I think it would be great for him to be able to work on the package in fedora. 20:27:54 There's no need to set _default_patch_fuzz there. 20:27:57 skvidal: AFAICT, kamil said "hey, I can help out here" but phrased it very poorly, in effect demanding co-maintainer status, and pj took that offensively, and refused the request, having had little experience with kamil. Does that sound about right? 20:28:01 And the \n\n makes no sense altogether. 20:28:06 I don't think we should force that. 20:28:18 So it made sense for Kamil to revert that. 20:28:18 pjones: that's the ballpark 20:28:26 The commit really was nonsense. 20:28:33 pjones: except this was cweyl. ;) 20:28:39 nirik: er, right, sorry. 20:29:09 Kevin_Kofler: sure. But wouldn't it be better to ask him? hey, this was not needed, could you fix or or if you like I will do so? 20:29:15 anyway, that's /not/ entirely unreasonable. he needs to do the work to demonstrate that he's reasonable as a co-maintainer. 20:29:37 the main issue that brought this up was the prospective of non-responsive maintainership. that's not the case now, and the package has a co-maintainer. do we really need to step in more than this? 20:29:46 notting: no, I don't think we do 20:29:47 notting: no, I don't think so. 20:29:48 nirik: cweyl added that nonsense to Kamil's package. 20:29:52 agreed. 20:29:55 It's normal for a maintainer to fix his own package. 20:29:58 Kevin_Kofler: 'kamil's package' 20:29:58 ? 20:30:23 I think the discussion about curl is... not actually useful. 20:30:31 (and wildly confusing) 20:30:39 right, lets move on? unless we want to vote on closing the topic ticket? 20:30:50 kdudka is the primary and sole maintainer of curl. 20:30:52 nirik: yes - moving on 20:31:03 cweyl was only able to commit as provenpackager, he's not even a comaintainer. 20:31:15 #topic #308 package-swift 20:31:18 +1 for moving, I cannot decide who is wrong or right here 20:31:19 nirik: +1 to closing ticket 20:31:20 .fesco 308 20:31:22 nirik: #308 (package-swift) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/308 20:31:22 So it's normal that if he commits nonsense, the maintainer (kdudka) reverts it. 20:31:49 skvidal: you want to talk about this? 20:32:03 I don't see how kdudka behaved badly there, and if cweyl hates him because of that, this is not a valid reason to reject his comaintainership request for libssh2. 20:32:04 sure 20:32:23 so short version 20:32:31 it's a package to nuke orphaned/dead pkgs from people's systems 20:32:42 so we don't end up with cruft installed that isn't obsoleted by anything 20:32:51 examples off the top of my head are things like gnome-blog 20:33:23 * dgilmore likes this 20:33:26 -1, we already decided in the past we don't need this. 20:33:35 Kevin_Kofler: we did? 20:33:38 Kevin_Kofler: huh? 20:33:46 should this go through the feature process? some people will be surprised by it if we don't announce it a lot 20:33:46 There are already ways to deal with this problem (e.g. yum list extras). 20:33:46 ive had to manually clean up cruft in the past to update boxes 20:33:59 nirik: the pkg would not be required by anything 20:34:01 +1 for the package, good idea, I had something similar in mind. Debian does the same 20:34:04 * notting doesn't like the manual process of maintaining this, and the potential issues for when packages come back 20:34:05 I remember this discussion having come up at multiple times in the past. 20:34:13 The big downside in the past has been: you have a package thats not maintained, but works fine for you and you don't want it removed. 20:34:15 notting: not sure how to maintain it other than manually 20:34:22 Kevin_Kofler: they don't work very well; users have to know a lot about packaging to do certain things, and this makes those things happen automatically. 20:34:27 nirik: in which case you just remove this pkg or don't install it 20:34:28 Kevin_Kofler: it has. 20:34:32 nirik: or exclude it 20:34:38 skvidal: would this be installed by default? 20:34:43 But of course I don't have URLs ready, months or years have passed since, my memory can only store so many URLs. ;-) 20:34:49 nirik: it could be in the base group as default but not required at all 20:35:11 what does anaconda do here? 20:35:26 doesn't it let you select the items from that group? 20:35:28 I think it's unhelpful to remove working packages from users' systems, and if the packages don't work, the users will notice and remove them anyway. 20:35:46 nirik: anaconda pretends there aren't conflicts and you get a broken package. 20:36:06 pjones: so, it doesn't remove them? icky 20:36:09 which is not as nice of a solution as skvidal's. 20:36:26 notting: can you think of a better way than doing it manually? 20:36:27 nirik: we want to avoid removing packages that aren't from fedora 20:36:31 no, I meant: what does anaconda do on an upgrade if this package is there? 20:36:46 pjones: we can probably do that with complete nvrs and ranges 20:36:51 rather than just name-based obsoletes 20:36:56 in that case, it'll install the package, since it's effectively a new version of the fedora packages in question 20:37:07 nirik: it would install it - which will obsoletes (and therefore remove) the old pkgs 20:37:16 I think it doesn't make sense to artificially remove packages at all. 20:37:22 so it will remove the obsolete packages ? 20:37:23 (and we still avoid mucking with things not from fedora) 20:37:25 nirik: right 20:37:26 nirik: yes 20:38:01 Kevin_Kofler: the bad case currently is when those packages break upgrades... 20:38:04 This thing causes more problems than it solves. 20:38:13 Then you remove them and retry the upgrade. 20:38:17 Kevin_Kofler: artificially? they're packages which a) will be broken by the TS being run, and b) have effectively been removed from the repo(or its progeny) you got them from 20:38:20 Kevin_Kofler: how? 20:38:28 skvidal: no, but it will need to be maintained *and updated* if packages ever come back 20:38:37 notting: agreed 20:38:38 dgilmore: Fire up your favorite PK frontend and remove them. 20:38:50 Kevin_Kofler: how does it break things? 20:38:55 notting: doesn't have to be updated, necessarily - if we're obsoleting, we can obsolete with a version now IIRC. 20:39:06 (and more importantly a <=) 20:39:10 Kevin_Kofler: well how does it cause more problems? 20:39:56 It removes packages users might not want removed, it might also catch rebuilt versions from third-party repos depending on how the Obsoletes is versioned exactly etc. 20:40:01 nirik: if we don't want this in anaconda, for example. I'm fine with it just being a pkg in the distro 20:40:05 Kevin_Kofler: so what you're saying is that to do an upgrade, we should be instructing users to fire up PK and manually remove any packages that aren't in the new repo (and aren't obsoleted by anything in the new repo), and then continue? 20:40:15 nirik: b/c a yum install package-swift would obsolete out the old pkgs just as uch 20:40:16 Kevin_Kofler: that's... not a very good user experience, IMHO. 20:40:25 They should remove packages if they get errors about them. 20:40:35 Kevin_Kofler: thats a bad thing to train users to do. 20:40:41 Usually Anaconda will just proceed with the upgrade and leave the packages broken. 20:40:49 'glibc-common is breaking my update, I best yum remove it' 20:40:49 Then the user can remove the packages which don't work. 20:41:00 Kevin_Kofler: in the current anaconda upgrade path, we leave them broken. I'd rather remove them, and I suspect the rest of the anaconda team would agree. 20:41:21 skvidal: i'd love for it to be able to only act on packages from fedora itself. but that approach implies yum plugin, not package 20:41:24 so you're saying we should leave packages we /know ahead of time will break/ on the system and let the user remove them when they notice? 20:41:40 notting: yah - we'd need to query more yumdb and yum history info to do that 20:41:41 and you really think the user is going to figure out that it's because they were removed from fedora and not updated during the upgrade? 20:41:50 skvidal: another possible downside: if you get your gnome-blog removed, and decide to rpm -e package-swift and re-install it, you can't because you don't have the rpm around anymore... 20:41:53 As long as you don't use the updates repos with DVD updates, you have to keep those packages. 20:42:04 Because they might have a fixed one in updates. 20:42:05 nirik: how is that a downside? 20:42:15 sure, it's a small one I admit. ;) 20:42:19 Anaconda removing everything with broken deps is not a good idea. 20:42:32 it's not removing everytrhing with broken deps 20:42:41 we're not talking about removing everything with broken deps. at all. 20:42:44 it is removing only pkgs which were removed from fedora between releases 20:42:48 we're talking about removing things that have been /removed from fedora/ 20:42:49 it should atleast prompt the user ... not silently remove stuff 20:42:51 and were not obsoleted from their system 20:42:56 drago01: 20:42:59 The package-swift idea can work, but it needs to be manually maintained, which sucks. 20:42:59 we're talking about leaving the same broken dep policy in place. 20:43:07 drago01: please can we not try to design UI here? 20:43:13 And it'll also remove things which don't have broken deps in the first place. 20:43:17 * drago01 leaves 20:43:22 And which thus doesn't need to be removed at all. 20:43:26 mugshot might be a better example 20:43:57 I think there needs to be a smarter, distro-wide policy/implementation for handling obsoleted (and newly-added) parts of the system through upgrades 20:44:18 wwoods: isn't that what I'm suggesting? 20:44:26 wwoods: a mechanism to deal with obsoletes system-wide? 20:44:29 s/syste/distro/ 20:44:32 skvidal: how much overhead would the yum plugin version be? 20:44:42 only obsoletes. it doesn't handle pulling new features. 20:44:46 (ignoring the part about it not being written yet) 20:44:46 also the "re-added in an update" problem isn't really that bad - though we may need to add some logic to yum for it. If we do versioned obsoletes there, then re-adding it *won't* be covered by the obsolete. 20:44:51 notting: I have no idea - not even looked into it 20:44:56 The smarter distro-wide policy would be to just not remove packages which aren't replaced and Obsoleted by another package in the first place. 20:45:01 skvidal: ... so we might need to make yum check for that? which is a little ugly... 20:45:01 notting: well I did - we'd need add'l metadata for it 20:45:09 they're two halves of the same problem - we ignore comps changes between distro releases 20:45:10 If they build, ship them, if they don't, let provenpackagers fix the build and still ship them. 20:45:13 Orphaned or not. 20:45:22 Kevin_Kofler: what about something like mugshot? 20:45:24 Then we wouldn't have this problem in the first place. 20:45:24 skvidal: additional metadata we're not tracking? 20:45:29 adding a metapackage with a bunch of Obsoletes lines is.. one way to handle half the problem 20:45:31 Kevin_Kofler: sometimes packages aren't removed because they're orphaned 20:45:37 notting: we need to have the list of pkgs we're nuking 20:45:41 notting: we don't have that anywhere 20:45:46 Kevin_Kofler: one of the cases we were specifically talking about was mkinitrd->dracut and getting rid of nash, for example. 20:45:49 skvidal: erm, yes. 20:45:49 it would seem like a much smarter way would involve actually parsing the differences between the comps files between the two, and acting on that 20:45:52 nirik: The server being dead? That's a problem indeed. 20:45:53 there is a distinction now between "orphan" and "retired" 20:46:04 Kevin_Kofler: nothing replaces it. It's useless. 20:46:05 wwoods: but comps doesn't list even MOST things 20:46:36 wwoods: thats impossible to do. because of what skvidal said 20:46:44 wwoods: comps is sortof a weird approach, because it's design is more around a profile of what should get installed than a list of all packages and when to install them. 20:46:56 okay 20:47:02 I'm not a huge fan of comps either - I just wanted to make the point that this is one aspect of a larger problem 20:47:04 if we want to put this off until more discussion 20:47:07 I'm fine with that 20:47:11 and suggest that the problem should be thought about as a whole 20:47:18 but let me ask this 20:47:20 if I submit this pkg 20:47:25 is there an issue with that? 20:47:26 not for comps 20:47:32 pjones: nash should just be obsoleted by dracut, not by a magic metapackage. 20:47:38 without getting too bogged down in implementation details (i.e. nobody's married to comps or magic metapackages) 20:47:51 * nirik doesn't have a issue with it off hand as long as it's not default. If it is default I think it needs a feature page and/or more discussion. 20:48:15 okie doke 20:48:25 I'll pitch the package at a reviewer or two 20:48:27 thx 20:48:28 but also: thinking about the larger problem doesn't prevent this modest solution from being useful 20:48:35 skvidal: assuming that any theoretical submitter is also signing up for the fun of maintaining that spec file, sure 20:48:44 nirik: The problem is, if it's implemented as a metapackage with Obsoletes, it's effectively always default. 20:48:49 Kevin_Kofler: fair enough in that specific case. 20:48:50 notting: I was going to make sure Oxf13 owns it :) 20:48:54 Kevin_Kofler: ? 20:48:57 so please don't think I'm trying to stop this from going forward. would just like to see the Big Picture discussed. 20:48:59 Kevin_Kofler: how do you figure that? 20:49:05 if nothing in comps says to install it, it's not default. 20:49:05 yum update will pull it in 20:49:10 I would also suggest humbly that it have a number of co-maintainers... 20:49:11 The first yum update will pull it in to replace the obsoleted stuff. 20:49:13 b/c it obsoletes the other pkgs 20:49:20 that's true 20:49:22 ah, true. 20:49:26 it's not being installed unless a) you specify it manually, or b) you're upgrading and it obsoletes something installed 20:49:47 you'll get it in the actual upgrade, not the next yum run. 20:50:05 right, so we do need to decide if thats ok. 20:50:27 what is the policy for adding a obsolete to it? 20:50:45 what's the policy for any pkg to add an obsolete 20:50:48 this works for ANY pkg 20:50:49 of course 20:50:57 Well, to start with: if a package is /retired/ and not /replaced/, it should be added. 20:51:06 (note that "retired" is not the same as "orphaned") 20:51:22 ok, and how long does it keep them? N releases? 20:51:31 and if a pkg is replaced then it won't be needed to be added to this pkg 20:51:39 nirik: does it matter? 20:51:45 nirik: their versioned obsoletes... 20:51:50 s/their/they're/ 20:51:51 at least until the N+1 release, though there's no specific need to remove anything., 20:52:26 * nirik grumbles at no spec link in the ticket. 20:52:32 one sec 20:52:35 well 20:52:41 the pkg is justan example 20:52:48 the spec file is pretty narrow 20:53:00 it has Obsoletes: stuff 20:53:00 skvidal: so, there is one issue there. which is that a better usage model would include pulling updates in if they're /newer/ versions of the obsolete - but we definitely don't want to extend that to all obsoletes. 20:53:30 pulling updates in if they're NEWER versions of the obsolete?? 20:53:31 and by "pulling" I mean "selecting for installation" 20:53:36 We've done 12 releases without such a metapackage, not counting the RHL releases before, why do we need one now? 20:53:44 Kevin_Kofler: b/c change happens 20:54:00 It's not any more needed now than it was before. 20:54:13 This very idea was brought up in past discussions. It got rejected. 20:54:14 skvidal: how do you gather a list of what should be in there? 20:54:16 * rdieter thinks it's been needed, for a long time. 20:54:23 nirik: from the retired pkg list 20:54:29 Kevin_Kofler: we've done 12 releases (plus some RHL releases before that) where we thought we needed something to solve this and didn't have a solution, several of which were before versioned obsoletes worked right, so this solution would not have worked. 20:54:38 nirik: the orphan clubbing that Oxf13 does 20:54:45 (though that's been a long time now) 20:54:55 skvidal: orphan != retired. 20:55:16 clubbed orphan == retired 20:55:21 orphan means not maintained, or maintainer gave up. Someone else could bring it back. Retired means it was put down for a reason. 20:55:23 do you see the difference 20:55:24 no; it is often a step towards retired, which is what skvidal is indicating. 20:55:30 CLUBBED ORPHAN 20:55:32 KILLED 20:55:33 DEAD 20:55:36 BEATEN WITH A STICK 20:55:54 yes, but does pkgdb mark it such? 20:56:05 * skvidal doesn't care 20:56:09 we make a list of retired pkgs 20:56:16 it's not very complicated 20:56:23 they get retired for one reason or another 20:56:26 if they are not REPLACED 20:56:35 then we put them in the obsoletes in this pkg 20:56:50 right; it's not the same as the orphan list. the part of the orphan list which /is/ to be retired becomes /part/ of the retired pkgs list. 20:57:01 ok, can we see a list and a method for adding them before we say okey dokey here? 20:57:02 effectively, we already do this, we're just not publishing it in a way that our tools can use. 20:57:17 * notting would still prefer a plugin-based approach. but maybe he's alone in that 20:57:32 * skvidal decides this is WAY more effort than it is worth 20:57:43 notting: I'll work on a plugin 20:57:46 more discussion, revisit next week? 20:57:51 and we can take MAGICAL actions based on that 20:57:52 or whenever 20:57:53 the more I think about it the less I like the package. most of the retired packages are obsoleted by something else. having a proper list of obsoletes is more important than a package 20:58:10 s/more important/better 20:58:20 cwickert1: unfortunately a good number of the pkgs are NOT replaced by something 20:58:42 IMO they can remain on the system, as long as they don't break something 20:59:00 * nirik doesn't dislike the idea, just wants to see more info... but could be just me. 20:59:05 cwickert1: what they normally break - is the transaction 20:59:05 cwickert1: That's what I'm saying, too. 20:59:09 and then the users files a yum bug 20:59:12 and I have to deal with it 20:59:13 I'd rather remove them all than sit around thinking about whether or not they can break anything. 20:59:13 'don't break something' is fun to encapsulate in code 20:59:13 and the crazy 20:59:14 abadger1999 notes there is no way to get a retired package list currently aside from direct db 20:59:32 nirik: yes, and? 20:59:37 we make the list somehow 20:59:57 notting: right - the easiest option is to implement the same solution, but change the criteria to "only add the things where leaving them around breaks something". 21:00:28 ooo - I know - how about we make the pkg conflict with them :) 21:00:31 so these non versioned? 21:00:32 instead of obsoleting them 21:00:41 * skvidal stops 21:00:42 nirik: what? 21:00:44 let's move one 21:00:46 move on 21:00:52 just drop this from the meetin 21:00:57 ah, nevermind. 21:01:05 ok. 21:01:05 * skvidal doesn't care anymore 21:01:06 skvidal: I can understand your POV, but I still don't like it 21:01:15 cwickert1: doesn't matter 21:01:16 I'm moving on 21:01:55 ok. 21:01:58 #topic #309 provenpackager request - tomspur 21:02:02 .fesco 309 21:02:03 nirik: #309 (provenpackager request - tomspur) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/309 21:02:08 * tomspur is here :) 21:02:46 tomspur: you shouldn't, we want to talk bad about you ;) 21:02:54 ^^ 21:03:00 just kidding, I strongly support the request 21:03:02 cweyl|work, kick me :P 21:03:20 ahm cwickert1 kick me.. 21:03:26 * nirik looks for the sponsor feedback. 21:03:27 tomspur is one of the most active reviewers since he joined Fedora 21:03:43 * notting doesn't see anything in the ticket/feedback that makes it seem like a bad idea 21:03:45 nirik: There doesn't seem to be any. :-( 21:03:56 I thought cwickert1 mailed sponsors on it. 21:03:56 But I'm +1 to the request. 21:04:18 there is feedback, Kevin_Koflerreplied 21:04:29 Helping work on the Python 3 transition is a valid motive. 21:04:33 Kevin_Kofler: ha. yeah, you responded to that. 21:04:47 Kevin_Kofler and me were +1, here and on the sponsors list. more feedback? 21:05:06 * nirik was confused on this because I thought I was supposed to send those requests to the sponsors list. Oh well, no biggie. 21:05:08 And he has the experience, too. 21:05:13 +1 from me as well. 21:05:18 +1 from me 21:05:29 nirik: it was sent to the sponsors list 21:05:36 +1 21:05:42 nirik: they are supposed to be made available to sponosors for comments 21:05:45 +! 21:05:48 +1 21:06:02 cwickert1: yes. But typically the chair does... I almost send a dup before I saw your post. ;) 21:06:13 sorry about that nirik 21:06:29 #agreed tomspur is approved for provenpackager. 21:06:36 cwickert1: no worries. 21:06:50 #topic #311 Feature: EasierPythonDebugging ( https://fedoraproject.org/wiki/Features/EasierPythonDebugging ) 21:06:53 .fesco 311 21:06:54 nirik: #311 (Feature: EasierPythonDebugging ( https://fedoraproject.org/wiki/Features/EasierPythonDebugging )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/311 21:06:58 oh, and congrats tomspur. 21:07:10 thanks :) 21:07:28 the 0 % and stuck is worrysome here. 21:08:21 this has to land very soon 21:08:21 nah, we need to make python debugging harder. 21:08:38 * notting is +1 to this. if it doesn't land, we drop it. 21:08:51 back from your mash debugging wars notting ? :) 21:09:01 +1, likewise, I guess. 21:09:06 yeah, +1 here, I am doubting it will be able to make it, but I think they can try. 21:09:25 :) +1 im all for letting them try land it 21:09:25 Though we do need to remind them that 0% 3 weeks before feature freeze is bad. ;-) 21:09:55 can someone ping dmalcom in #fedora-devel and tell him to come over? 21:10:10 * cwickert1 can't with his current nickname... 21:10:43 nope... 21:10:44 that's freaking awesome. 21:10:55 he can't answer in -devel anyway... 21:11:03 #fedora-python should be a better place 21:11:31 tomspur: ? 21:11:37 hiya 21:11:43 never mind, dmalcolm is here 21:11:51 dmalcolm: we are talking about EasierPythonDebugging. 21:12:01 chances for it landing in the next 3 weeks? 21:12:19 50/50 21:12:58 dmalcolm: ok. 21:13:08 any other questions? votes? 21:13:19 * cwickert thinks, we should at least give him a try, so +1 21:13:46 * pjones agrees 21:13:59 * skvidal is +1 21:14:18 That's 7 +1 votes already. 21:14:22 great 21:14:24 moving along 21:14:26 NEXT 21:14:44 sorry. 21:14:49 #agreed Feature is approved. 21:14:59 #topic #312 Feature: UdisksImprovements ( https://fedoraproject.org/wiki/Features/UdisksImprovements ) 21:15:04 .fesco 312 21:15:05 nirik: #312 (Feature: UdisksImprovements ( https://fedoraproject.org/wiki/Features/UdisksImprovements )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/312 21:15:45 * notting is +1 to this 21:16:05 does somebody know if/how this affects other DE than Gnome? 21:16:11 if its landed why is it not 100% 21:16:15 otherwise +1 21:16:20 cwickert: it doesn't? 21:16:25 if it breaks nothing, then +1 21:16:29 notting: ok, thanks 21:16:43 yeah, +1 seems fine to me... 21:17:11 one more? 21:17:21 +1 21:17:26 #agreed This Feature is approved. 21:17:27 NEXT 21:17:29 cwickert: As notting already replied, it shouldn't have any effect outside of GNOME. 21:17:30 #topic #313 Feature: VirtioSerial ( https://fedoraproject.org/wiki/Features/VirtioSerial ) 21:17:32 if other desktops are doing frontends using udisks/dk-disks, they may want updating to take advantage of the new stuff 21:17:35 .fesco 313 21:17:36 nirik: #313 (Feature: VirtioSerial ( https://fedoraproject.org/wiki/Features/VirtioSerial )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/313 21:18:00 this looks very nice. +1 here. 21:18:25 notting: I guess the new Solid backend in KDE branches/work may want to support this, indeed. But current KDE still uses HAL. 21:18:31 +1 21:18:36 definitely +1 21:18:52 the lack of user-visible changes makes me wonder. but sure, +1 21:19:07 +1 to VirtioSerial. 21:19:09 #agreed This Feature is approved. 21:19:14 notting: it will eventually allow copy/paste between guests :) 21:19:23 #topic Open Floor 21:19:25 jforbes: shiny. 21:19:28 Anything for open floor? 21:19:36 w.r.t. feature not getting done 21:19:42 do we need to revist xfce4.8? 21:19:47 * notting saw some chatter about that earlier 21:19:54 notting: not quite yet. The slip is just proposed. 21:20:01 if it slips we will drop it. 21:20:04 till next cycle. 21:20:35 ok 21:20:39 carry on,then 21:20:46 the Xfce release manager proopsed the slip, so it is likely to happen 21:20:59 yeah.. .we will see tho 21:20:59 and Xfce 4.8 is dead for F13 :( 21:21:11 anyway, move on 21:21:43 anything else? 21:21:46 Can't you just ship a prerelease? 21:21:56 Kevin_Kofler: lots of important stuff isn't done yet. 21:22:10 You could also ship F13 with 4.7 and queue 4.8 as an update like we're routinely doing with KDE. 21:22:37 we'll see. I dislike what KDE does and I don't want to do the same 21:22:38 Sadly, that'd slip through the cracks of the feature process. :-( 21:23:10 ok, thanks for coming everyone. 21:23:14 #endmeeting