20:00:35 <nirik> #startmeeting FESCO (2010-01-19)
20:00:35 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:35 <nirik> #meetingname fesco
20:00:35 <nirik> #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones cwickert mjg59
20:00:35 <nirik> #topic init process
20:00:35 <zodbot> The meeting name has been set to 'fesco'
20:00:35 <zodbot> Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 nirik notting pjones skvidal
20:00:43 * skvidal is here
20:00:45 <nirik> Who all is around for a fesco meeting?
20:00:48 * cwickert is here
20:01:09 * pjones here
20:02:06 <Kevin_Kofler> 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 <nirik> skvidal: we can try...
20:02:44 <nirik> #topic FOLLOWUP: #298 Revoke Paul Johnsons pacakger access and put him on probation.
20:02:45 <nirik> .fesco 298
20:02:47 <zodbot> nirik: #298 (Revoke Paul Johnsons pacakger access and put him on probation.) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/298
20:03:11 <nirik> any news here? I have not seen any posts from him, nor contact to my last few emails...
20:03:19 <Kevin_Kofler> Why is this still on the agenda? Haven't we already decided there's no reason to act on this?
20:03:24 <dgilmore> nirik: ive seen no feedback from him
20:03:46 <nirik> 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 <cwickert> he hardly cooperates with anybody, IMO we need to do something here
20:04:20 <nirik> 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 <nirik> mchua: ? oops... wasn't on the meeting page...
20:05:04 <pjones> Kevin_Kofler: IIRC we agreed that there should be some movement now that he's aware of the problem
20:05:31 <nirik> 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 <mchua> 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 <cwickert> give him some kind or warning, tell him to respond within a week
20:05:58 <nirik> mchua: sorry, I didn't update fesco yet either. ;(
20:06:07 <pjones> cwickert: so, in effect, same as we said last time?
20:06:26 * dgilmore thinks we should act now
20:06:39 <cwickert> pjones: last time was a friendly reminder, this time we need to be more serious
20:06:40 <dgilmore> but i was also the person who brought the issue up
20:07:09 <nirik> he's not primary for mono...
20:07:27 <cwickert> I think the email problems are a lame excuse. If somobody cannot manager his mail filters, he should not own packages ;)
20:08:00 <Kevin_Kofler> I think technical difficulties can always happen.
20:08:08 <skvidal> 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 <nirik> dgilmore: I haven't seen any commits from him since jan 1st.
20:08:54 <pjones> skvidal: certainly in a long timeframe, yes.
20:09:00 <pjones> (obviously outages happen)
20:09:08 <cwickert> nirik: but hs submitted a few new reviews
20:09:19 <skvidal> pjones: yes, short term shit happens
20:09:21 <cwickert> where he did not respond to my comments ether
20:09:42 <Kevin_Kofler> nirik: That's just 18 days, was there a commit actually needed that he didn't do?
20:09:56 <nirik> not that I know of.
20:10:20 <Kevin_Kofler> So I don't see how the apparent lack of commits is a problem.
20:10:22 <pjones> 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 <nirik> but the primary issue here was that he was commiting things and messing up other maintainers commits.
20:10:50 <Kevin_Kofler> Well, he said that was a broken script and he stopped using that script.
20:10:52 <notting> nirik: so, leave it as handled until he does it again?
20:11:03 <pjones> nirik: I really think the primary issue was the email problem and the broken script, combined
20:11:05 <nirik> Kevin_Kofler: sure, but with no commits, we don't know for sure. ;)
20:11:20 <Kevin_Kofler> No commits means he isn't clobbering anyone's work, at least. ;-)
20:11:26 <pjones> nirik: which (as he tells it) resulted in the clobbering, among other things
20:11:43 <pjones> is there some reason to /doubt/ his claim that he's stopped using the broken script?
20:12:15 <nirik> pjones: only in that people have asked him to not clobber their changes in the past and it kept happening.
20:12:48 <pjones> but it "kept happening" before rather than after he said he knew how that happened and has fixed his workflow, right?
20:13:08 <nirik> 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 <nirik> pjones: yeah, thats my understanding... yes.
20:13:20 <cwickert> 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 <pjones> 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 <nirik> but that was only a few days ago.
20:14:14 <cwickert> this script has no brain - use your own...
20:14:17 <Kevin_Kofler> I think it's a script which works similarly to our cvs-import.sh, it just overwrites everything no matter what.
20:14:23 <pjones> nirik: okay, so it does sound like there are stil some communications problems
20:14:29 <Kevin_Kofler> He says he tried to code it to detect changes in CVS, but that didn't work.
20:14:41 <nirik> pjones: or could be...
20:15:19 <nirik> 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 <cwickert> 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 <nirik> personally, I would be ok with giving him till next week to get his email fixed up...
20:16:06 <nirik> thoughts? votes?
20:16:44 <pjones> 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 <cwickert> one more week, but we should make clear that this is a serious problem and not only some technical issues
20:17:53 <nirik> 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 <nirik> #topic #302 libssh2 - non-responsive maintainer
20:19:30 <nirik> .fesco 302
20:19:31 <zodbot> nirik: #302 (libssh2 - non-responsive maintainer) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/302
20:19:49 <nirik> 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 <nirik> He doesn't wish to work with the ticket reporter as a comaintainer at this time.
20:20:28 <skvidal> that's also fine
20:20:33 <Kevin_Kofler> I think this sucks.
20:20:38 <cwickert> +1
20:20:38 <skvidal> if the current co-maintainer is working on it
20:20:45 <Kevin_Kofler> The ticket reporter has good reasons to request comaintainership.
20:20:46 <skvidal> then that's fine by me
20:20:52 <Kevin_Kofler> (He's the maintainer in RHEL 6+.)
20:21:02 <skvidal> Kevin_Kofler: not a pertinent reason for fedora
20:21:06 <nirik> Kevin_Kofler: should we force a maintainer to work with someone they don't wish to?
20:21:09 <Kevin_Kofler> So I don't see why he shouldn't be allowed to comaintain the package also in Fedora and EPEL 5-.
20:21:33 <Kevin_Kofler> We need to work together to make Fedora good.
20:21:41 <pjones> 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 <Kevin_Kofler> The maintainer brought up no concrete reason against it, just "he rubbed me the wrong way".
20:21:55 <nirik> 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 <skvidal> Kevin_Kofler: there are lots of folks who I would not give comaintainer access to just b/c they annoy me
20:22:25 <skvidal> Kevin_Kofler: I don't see anything wrong with that
20:22:26 <Kevin_Kofler> 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 <pjones> I think asking somebody to be co-maintainer with somebody they find abrasive also has its problems.
20:22:27 <nirik> There are also issues on curl.
20:23:04 <pjones> 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 <nirik> so, shall we close this with: the maintainer is responsive, please try and work with him or the other co-maintainer?
20:23:33 <Kevin_Kofler> I don't see why we need to force Kamil to jump through hoops to get his fixes merged.
20:23:44 <pjones> 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 <skvidal> nirik: +1
20:23:50 <cwickert> nirik: did he give a good reason for refusing this particular comaintainer. I can't find anything in his mail
20:24:01 <Kevin_Kofler> cwickert: He didn't.
20:24:04 <nirik> cwickert: nothing concerete...
20:24:10 <nirik> just "rubbed the wrong way"
20:24:16 <Kevin_Kofler> And IMHO that's not acceptable.
20:24:22 <cwickert> yaeh, whatever this mean...
20:24:34 <cwickert> +1 Kevin_Kofler
20:24:39 <nirik> note on the curl package, cweyl did a commit and kamil partially reverted it with a 'this commit was nonsense'
20:24:55 <notting> *sigh*
20:24:57 <Kevin_Kofler> He has valid reasons to request comaintainership and it's getting rejected on a "I hate this guy" basis.
20:25:04 <nirik> they disagree when/if curl needs rebuilding for libssh2 changes.
20:25:27 <pjones> 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 <cwickert> is there anybody to decide who is actually wrong or right?
20:25:37 <pjones> which is what you're implying, AFAICS, Kevin_Kofler.
20:25:46 <Kevin_Kofler> We thought common sense would be enough.
20:25:50 <Kevin_Kofler> Sadly, it seems not. :-/
20:25:54 <skvidal> Kevin_Kofler: common sense says to me
20:25:57 <dgilmore> nirik: +1
20:25:58 <skvidal> if someone is a pain in the ass
20:26:01 <skvidal> I don't want to work with them
20:26:05 <pjones> I don't think common sense dictates that kamil should be a co-maintainer.
20:26:16 <skvidal> and if I have a choice in the matter
20:26:18 <skvidal> I won't work with them
20:26:25 <skvidal> now - I don't think kamil is a pain in the ass
20:26:33 <skvidal> but maybe the libssh2 maintainer does
20:26:37 <skvidal> and guess what? That's his right
20:26:44 <skvidal> so let's not legislate relationships here
20:26:46 <skvidal> and move along
20:26:49 <Kevin_Kofler> I think cweyl is the one who's behaving like a PITA here.
20:27:34 <Kevin_Kofler> cweyl added a %define _default_patch_fuzz 2 \n\n to curl.
20:27:43 <Kevin_Kofler> That was the "nonsense" Kamil reverted.
20:27:49 <nirik> 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 <Kevin_Kofler> There's no need to set _default_patch_fuzz there.
20:27:57 <pjones> 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 <Kevin_Kofler> And the \n\n makes no sense altogether.
20:28:06 <nirik> I don't think we should force that.
20:28:18 <Kevin_Kofler> So it made sense for Kamil to revert that.
20:28:18 <skvidal> pjones: that's the ballpark
20:28:26 <Kevin_Kofler> The commit really was nonsense.
20:28:33 <nirik> pjones: except this was cweyl. ;)
20:28:39 <pjones> nirik: er, right, sorry.
20:29:09 <nirik> 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 <pjones> 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 <notting> 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 <skvidal> notting: no, I don't think we do
20:29:47 <pjones> notting: no, I don't think so.
20:29:48 <Kevin_Kofler> nirik: cweyl added that nonsense to Kamil's package.
20:29:52 <nirik> agreed.
20:29:55 <Kevin_Kofler> It's normal for a maintainer to fix his own package.
20:29:58 <nirik> Kevin_Kofler: 'kamil's package'
20:29:58 <nirik> ?
20:30:23 <pjones> I think the discussion about curl is... not actually useful.
20:30:31 <pjones> (and wildly confusing)
20:30:39 <nirik> right, lets move on? unless we want to vote on closing the topic ticket?
20:30:50 <Kevin_Kofler> kdudka is the primary and sole maintainer of curl.
20:30:52 <skvidal> nirik: yes - moving on
20:31:03 <Kevin_Kofler> cweyl was only able to commit as provenpackager, he's not even a comaintainer.
20:31:15 <nirik> #topic #308 package-swift
20:31:18 <cwickert> +1 for moving, I cannot decide who is wrong or right here
20:31:19 <notting> nirik: +1 to closing ticket
20:31:20 <nirik> .fesco 308
20:31:22 <zodbot> nirik: #308 (package-swift) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/308
20:31:22 <Kevin_Kofler> So it's normal that if he commits nonsense, the maintainer (kdudka) reverts it.
20:31:49 <nirik> skvidal: you want to talk about this?
20:32:03 <Kevin_Kofler> 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 <skvidal> sure
20:32:23 <skvidal> so short version
20:32:31 <skvidal> it's a package to nuke orphaned/dead pkgs from people's systems
20:32:42 <skvidal> so we don't end up with cruft installed that isn't obsoleted by anything
20:32:51 <skvidal> examples off the top of my head are things like gnome-blog
20:33:23 * dgilmore likes this
20:33:26 <Kevin_Kofler> -1, we already decided in the past we don't need this.
20:33:35 <skvidal> Kevin_Kofler: we did?
20:33:38 <cwickert> Kevin_Kofler: huh?
20:33:46 <nirik> 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 <Kevin_Kofler> There are already ways to deal with this problem (e.g. yum list extras).
20:33:46 <dgilmore> ive had to manually clean up cruft in the past to update boxes
20:33:59 <skvidal> nirik: the pkg would not be required by anything
20:34:01 <cwickert> +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 <Kevin_Kofler> I remember this discussion having come up at multiple times in the past.
20:34:13 <nirik> 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 <skvidal> notting: not sure how to maintain it other than manually
20:34:22 <pjones> 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 <skvidal> nirik: in which case you just remove this pkg or don't install it
20:34:28 <nirik> Kevin_Kofler: it has.
20:34:32 <skvidal> nirik: or exclude it
20:34:38 <nirik> skvidal: would this be installed by default?
20:34:43 <Kevin_Kofler> 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 <skvidal> nirik: it could be in the base group as default but not required at all
20:35:11 <nirik> what does anaconda do here?
20:35:26 <skvidal> doesn't it let you select the items from that group?
20:35:28 <Kevin_Kofler> 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 <pjones> nirik: anaconda pretends there aren't conflicts and you get a broken package.
20:36:06 <nirik> pjones: so, it doesn't remove them? icky
20:36:09 <pjones> which is not as nice of a solution as skvidal's.
20:36:26 <skvidal> notting: can you think of a better way than doing it manually?
20:36:27 <pjones> nirik: we want to avoid removing packages that aren't from fedora
20:36:31 <nirik> no, I meant: what does anaconda do on an upgrade if this package is there?
20:36:46 <skvidal> pjones: we can probably do that with complete nvrs and ranges
20:36:51 <skvidal> rather than just name-based obsoletes
20:36:56 <pjones> in that case, it'll install the package, since it's effectively a new version of the fedora packages in question
20:37:07 <skvidal> nirik: it would install it - which will obsoletes (and therefore remove) the old pkgs
20:37:16 <Kevin_Kofler> I think it doesn't make sense to artificially remove packages at all.
20:37:22 <nirik> so it will remove the obsolete packages ?
20:37:23 <pjones> (and we still avoid mucking with things not from fedora)
20:37:25 <pjones> nirik: right
20:37:26 <skvidal> nirik: yes
20:38:01 <nirik> Kevin_Kofler: the bad case currently is when those packages break upgrades...
20:38:04 <Kevin_Kofler> This thing causes more problems than it solves.
20:38:13 <Kevin_Kofler> Then you remove them and retry the upgrade.
20:38:17 <pjones> 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 <dgilmore> Kevin_Kofler: how?
20:38:28 <notting> skvidal: no, but it will need to be maintained *and updated* if packages ever come back
20:38:37 <skvidal> notting: agreed
20:38:38 <Kevin_Kofler> dgilmore: Fire up your favorite PK frontend and remove them.
20:38:50 <dgilmore> Kevin_Kofler: how does it break things?
20:38:55 <pjones> notting: doesn't have to be updated, necessarily - if we're obsoleting, we can obsolete with a version now IIRC.
20:39:06 <pjones> (and more importantly a <=)
20:39:10 <dgilmore> Kevin_Kofler: well how does it cause more problems?
20:39:56 <Kevin_Kofler> 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 <skvidal> 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 <pjones> 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 <skvidal> nirik: b/c a yum install package-swift would obsolete out the old pkgs just as uch
20:40:16 <pjones> Kevin_Kofler: that's... not a very good user experience, IMHO.
20:40:25 <Kevin_Kofler> They should remove packages if they get errors about them.
20:40:35 <nirik> Kevin_Kofler: thats a bad thing to train users to do.
20:40:41 <Kevin_Kofler> Usually Anaconda will just proceed with the upgrade and leave the packages broken.
20:40:49 <nirik> 'glibc-common is breaking my update, I best yum remove it'
20:40:49 <Kevin_Kofler> Then the user can remove the packages which don't work.
20:41:00 <pjones> 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 <notting> 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 <pjones> 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 <skvidal> notting: yah - we'd need to query more yumdb and yum history info to do that
20:41:41 <pjones> 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 <nirik> 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 <Kevin_Kofler> As long as you don't use the updates repos with DVD updates, you have to keep those packages.
20:42:04 <Kevin_Kofler> Because they might have a fixed one in updates.
20:42:05 <skvidal> nirik: how is that a downside?
20:42:15 <nirik> sure, it's a small one I admit. ;)
20:42:19 <Kevin_Kofler> Anaconda removing everything with broken deps is not a good idea.
20:42:32 <skvidal> it's not removing everytrhing with broken deps
20:42:41 <pjones> we're not talking about removing everything with broken deps. at all.
20:42:44 <skvidal> it is removing only pkgs which were removed from fedora between releases
20:42:48 <pjones> we're talking about removing things that have been /removed from fedora/
20:42:49 <drago01> it should atleast prompt the user ... not silently remove stuff
20:42:51 <skvidal> and were not obsoleted from their system
20:42:56 <skvidal> drago01: <shudder>
20:42:59 <Kevin_Kofler> The package-swift idea can work, but it needs to be manually maintained, which sucks.
20:42:59 <pjones> we're talking about leaving the same broken dep policy in place.
20:43:07 <pjones> drago01: please can we not try to design UI here?
20:43:13 <Kevin_Kofler> And it'll also remove things which don't have broken deps in the first place.
20:43:17 * drago01 leaves
20:43:22 <Kevin_Kofler> And which thus doesn't need to be removed at all.
20:43:26 <nirik> mugshot might be a better example
20:43:57 <wwoods> 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 <skvidal> wwoods: isn't that what I'm suggesting?
20:44:26 <skvidal> wwoods: a mechanism to deal with obsoletes system-wide?
20:44:29 <skvidal> s/syste/distro/
20:44:32 <notting> skvidal: how much overhead would the yum plugin version be?
20:44:42 <wwoods> only obsoletes. it doesn't handle pulling new features.
20:44:46 <notting> (ignoring the part about it not being written yet)
20:44:46 <pjones> 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 <skvidal> notting: I have no idea - not even looked into it
20:44:56 <Kevin_Kofler> 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 <pjones> skvidal: ... so we might need to make yum check for that?  which is a little ugly...
20:45:01 <skvidal> notting: well I did - we'd need add'l metadata for it
20:45:09 <wwoods> they're two halves of the same problem - we ignore comps changes between distro releases
20:45:10 <Kevin_Kofler> If they build, ship them, if they don't, let provenpackagers fix the build and still ship them.
20:45:13 <Kevin_Kofler> Orphaned or not.
20:45:22 <nirik> Kevin_Kofler: what about something like mugshot?
20:45:24 <Kevin_Kofler> Then we wouldn't have this problem in the first place.
20:45:24 <notting> skvidal: additional metadata we're not tracking?
20:45:29 <wwoods> adding a metapackage with a bunch of Obsoletes lines is.. one way to handle half the problem
20:45:31 <pjones> Kevin_Kofler: sometimes packages aren't removed because they're orphaned
20:45:37 <skvidal> notting: we need to have the list of pkgs we're nuking
20:45:41 <skvidal> notting: we don't have that anywhere
20:45:46 <pjones> Kevin_Kofler: one of the cases we were specifically talking about was mkinitrd->dracut and getting rid of nash, for example.
20:45:49 <notting> skvidal: erm, yes.
20:45:49 <wwoods> 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 <Kevin_Kofler> nirik: The server being dead? That's a problem indeed.
20:45:53 <nirik> there is a distinction now between "orphan" and "retired"
20:46:04 <nirik> Kevin_Kofler: nothing replaces it. It's useless.
20:46:05 <skvidal> wwoods: but comps doesn't list even MOST things
20:46:36 <dgilmore> wwoods: thats impossible to do. because of what skvidal said
20:46:44 <pjones> 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 <skvidal> okay
20:47:02 <wwoods> 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 <skvidal> if we want to put this off until more discussion
20:47:07 <skvidal> I'm fine with that
20:47:11 <wwoods> and suggest that the problem should be thought about as a whole
20:47:18 <skvidal> but let me ask this
20:47:20 <skvidal> if I submit this pkg
20:47:25 <skvidal> is there an issue with that?
20:47:26 <skvidal> not for comps
20:47:32 <Kevin_Kofler> pjones: nash should just be obsoleted by dracut, not by a magic metapackage.
20:47:38 <wwoods> 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 <skvidal> okie doke
20:48:25 <skvidal> I'll pitch the package at a reviewer or two
20:48:27 <skvidal> thx
20:48:28 <wwoods> but also: thinking about the larger problem doesn't prevent this modest solution from being useful
20:48:35 <notting> skvidal: assuming that any theoretical submitter is also signing up for the fun of maintaining that spec file, sure
20:48:44 <Kevin_Kofler> nirik: The problem is, if it's implemented as a metapackage with Obsoletes, it's effectively always default.
20:48:49 <pjones> Kevin_Kofler: fair enough in that specific case.
20:48:50 <skvidal> notting: I was going to make sure Oxf13 owns it :)
20:48:54 <nirik> Kevin_Kofler: ?
20:48:57 <wwoods> 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 <pjones> Kevin_Kofler: how do you figure that?
20:49:05 <pjones> if nothing in comps says to install it, it's not default.
20:49:05 <skvidal> yum update will pull it in
20:49:10 <nirik> I would also suggest humbly that it have a number of co-maintainers...
20:49:11 <Kevin_Kofler> The first yum update will pull it in to replace the obsoleted stuff.
20:49:13 <skvidal> b/c it obsoletes the other pkgs
20:49:20 <skvidal> that's true
20:49:22 <nirik> ah, true.
20:49:26 <pjones> it's not being installed unless a) you specify it manually, or b) you're upgrading and it obsoletes something installed
20:49:47 <pjones> you'll get it in the actual upgrade, not the next yum run.
20:50:05 <nirik> right, so we do need to decide if thats ok.
20:50:27 <nirik> what is the policy for adding a obsolete to it?
20:50:45 <skvidal> what's the policy for any pkg to add an obsolete
20:50:48 <skvidal> this works for ANY pkg
20:50:49 <skvidal> of course
20:50:57 <pjones> Well, to start with: if a package is /retired/ and not /replaced/, it should be added.
20:51:06 <pjones> (note that "retired" is not the same as "orphaned")
20:51:22 <nirik> ok, and how long does it keep them? N releases?
20:51:31 <skvidal> and if a pkg is replaced then it won't be needed to be added to this pkg
20:51:39 <skvidal> nirik: <shrug> does it matter?
20:51:45 <skvidal> nirik: their versioned obsoletes...
20:51:50 <skvidal> s/their/they're/
20:51:51 <pjones> 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 <skvidal> one sec
20:52:35 <skvidal> well
20:52:41 <skvidal> the pkg is justan example
20:52:48 <skvidal> the spec file is pretty narrow
20:53:00 <skvidal> it has Obsoletes: stuff
20:53:00 <pjones> 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 <skvidal> pulling updates in if they're NEWER versions of the obsolete??
20:53:31 <pjones> and by "pulling" I mean "selecting for installation"
20:53:36 <Kevin_Kofler> We've done 12 releases without such a metapackage, not counting the RHL releases before, why do we need one now?
20:53:44 <skvidal> Kevin_Kofler: b/c change happens
20:54:00 <Kevin_Kofler> It's not any more needed now than it was before.
20:54:13 <Kevin_Kofler> This very idea was brought up in past discussions. It got rejected.
20:54:14 <nirik> 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 <skvidal> nirik: from the retired pkg list
20:54:29 <pjones> 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 <skvidal> nirik: the orphan clubbing that Oxf13 does
20:54:45 <pjones> (though that's been a long time now)
20:54:55 <nirik> skvidal: orphan != retired.
20:55:16 <skvidal> clubbed orphan == retired
20:55:21 <nirik> 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 <skvidal> do you see the difference
20:55:24 <pjones> no; it is often a step towards retired, which is what skvidal is indicating.
20:55:30 <skvidal> CLUBBED ORPHAN
20:55:32 <skvidal> KILLED
20:55:33 <skvidal> DEAD
20:55:36 <skvidal> BEATEN WITH A STICK
20:55:54 <nirik> yes, but does pkgdb mark it such?
20:56:05 * skvidal doesn't care
20:56:09 <skvidal> we make a list of retired pkgs
20:56:16 <skvidal> it's not very complicated
20:56:23 <skvidal> they get retired for one reason or another
20:56:26 <skvidal> if they are not REPLACED
20:56:35 <skvidal> then we put them in the obsoletes in this pkg
20:56:50 <pjones> 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 <nirik> ok, can we see a list and a method for adding them before we say okey dokey here?
20:57:02 <pjones> 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 <skvidal> notting: I'll work on a plugin
20:57:46 <nirik> more discussion, revisit next week?
20:57:51 <skvidal> and we can take MAGICAL actions based on that
20:57:52 <nirik> or whenever
20:57:53 <cwickert1> 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 <cwickert1> s/more important/better
20:58:20 <skvidal> cwickert1: unfortunately a good number of the pkgs are NOT replaced by something
20:58:42 <cwickert1> 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 <skvidal> cwickert1: what they normally break - is the transaction
20:59:05 <Kevin_Kofler> cwickert1: That's what I'm saying, too.
20:59:09 <skvidal> and then the users files a yum bug
20:59:12 <skvidal> and I have to deal with it
20:59:13 <pjones> I'd rather remove them all than sit around thinking about whether or not they can break anything.
20:59:13 <notting> 'don't break something' is fun to encapsulate in code
20:59:13 <skvidal> and the crazy
20:59:14 <nirik> abadger1999 notes there is no way to get a retired package list currently aside from direct db
20:59:32 <skvidal> nirik: yes, and?
20:59:37 <skvidal> we make the list somehow
20:59:57 <pjones> 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 <skvidal> ooo - I know - how about we make the pkg conflict with them :)
21:00:31 <nirik> so these non versioned?
21:00:32 <skvidal> instead of obsoleting them
21:00:41 * skvidal stops
21:00:42 <pjones> nirik: what?
21:00:44 <skvidal> let's move one
21:00:46 <skvidal> move on
21:00:52 <skvidal> just drop this from the meetin
21:00:57 <nirik> ah, nevermind.
21:01:05 <nirik> ok.
21:01:05 * skvidal doesn't care anymore
21:01:06 <cwickert1> skvidal: I can understand your POV, but I still don't like it
21:01:15 <skvidal> cwickert1: doesn't matter
21:01:16 <skvidal> I'm moving on
21:01:55 <nirik> ok.
21:01:58 <nirik> #topic #309 provenpackager request - tomspur
21:02:02 <nirik> .fesco 309
21:02:03 <zodbot> nirik: #309 (provenpackager request - tomspur) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/309
21:02:08 * tomspur is here :)
21:02:46 <cwickert1> tomspur: you shouldn't, we want to talk bad about you ;)
21:02:54 <Kevin_Kofler> ^^
21:03:00 <cwickert1> just kidding, I strongly support the request
21:03:02 <tomspur> cweyl|work, kick me :P
21:03:20 <tomspur> ahm cwickert1 kick me..
21:03:26 * nirik looks for the sponsor feedback.
21:03:27 <cwickert1> 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 <Kevin_Kofler> nirik: There doesn't seem to be any. :-(
21:03:56 <nirik> I thought cwickert1 mailed sponsors on it.
21:03:56 <Kevin_Kofler> But I'm +1 to the request.
21:04:18 <cwickert1> there is feedback, Kevin_Koflerreplied
21:04:29 <Kevin_Kofler> Helping work on the Python 3 transition is a valid motive.
21:04:33 <nirik> Kevin_Kofler: ha. yeah, you responded to that.
21:04:47 <cwickert1> 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 <Kevin_Kofler> And he has the experience, too.
21:05:13 <nirik> +1 from me as well.
21:05:18 <notting> +1 from me
21:05:29 <cwickert1> nirik: it was sent to the sponsors list
21:05:36 <skvidal> +1
21:05:42 <dgilmore> nirik: they are supposed to be made available to sponosors for comments
21:05:45 <dgilmore> +!
21:05:48 <dgilmore> +1
21:06:02 <nirik> cwickert1: yes. But typically the chair does... I almost send a dup before I saw your post. ;)
21:06:13 <cwickert1> sorry about that nirik
21:06:29 <nirik> #agreed tomspur is approved for provenpackager.
21:06:36 <nirik> cwickert1: no worries.
21:06:50 <nirik> #topic #311 Feature: EasierPythonDebugging ( https://fedoraproject.org/wiki/Features/EasierPythonDebugging )
21:06:53 <nirik> .fesco 311
21:06:54 <zodbot> nirik: #311 (Feature: EasierPythonDebugging ( https://fedoraproject.org/wiki/Features/EasierPythonDebugging )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/311
21:06:58 <nirik> oh, and congrats tomspur.
21:07:10 <tomspur> thanks :)
21:07:28 <nirik> the 0 % and stuck is worrysome here.
21:08:21 <dgilmore> this has to land very soon
21:08:21 <notting> 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 <nirik> back from your mash debugging wars notting ? :)
21:09:01 <Kevin_Kofler> +1, likewise, I guess.
21:09:06 <nirik> yeah, +1 here, I am doubting it will be able to make it, but I think they can try.
21:09:25 <dgilmore> :) +1 im all for letting them try land it
21:09:25 <Kevin_Kofler> Though we do need to remind them that 0% 3 weeks before feature freeze is bad. ;-)
21:09:55 <cwickert1> 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 <tomspur> nope...
21:10:44 <pjones> that's freaking awesome.
21:10:55 <tomspur> he can't answer in -devel anyway...
21:11:03 <tomspur> #fedora-python should be a better place
21:11:31 <nirik> tomspur: ?
21:11:37 <dmalcolm> hiya
21:11:43 <cwickert1> never mind, dmalcolm is here
21:11:51 <nirik> dmalcolm: we are talking about EasierPythonDebugging.
21:12:01 <nirik> chances for it landing in the next 3 weeks?
21:12:19 <dmalcolm> 50/50
21:12:58 <nirik> dmalcolm: ok.
21:13:08 <nirik> 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 <Kevin_Kofler> That's 7 +1 votes already.
21:14:22 <skvidal> great
21:14:24 <skvidal> moving along
21:14:26 <skvidal> NEXT
21:14:44 <nirik> sorry.
21:14:49 <nirik> #agreed Feature is approved.
21:14:59 <nirik> #topic #312 Feature: UdisksImprovements ( https://fedoraproject.org/wiki/Features/UdisksImprovements )
21:15:04 <nirik> .fesco 312
21:15:05 <zodbot> 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 <cwickert> does somebody know if/how this affects other DE than Gnome?
21:16:11 <dgilmore> if its landed why is it not 100%
21:16:15 <dgilmore> otherwise +1
21:16:20 <notting> cwickert: it doesn't?
21:16:25 <cwickert> if it breaks nothing, then +1
21:16:29 <cwickert> notting: ok, thanks
21:16:43 <nirik> yeah, +1 seems fine to me...
21:17:11 <nirik> one more?
21:17:21 <skvidal> +1
21:17:26 <nirik> #agreed This Feature is approved.
21:17:27 <skvidal> NEXT
21:17:29 <Kevin_Kofler> cwickert: As notting already replied, it shouldn't have any effect outside of GNOME.
21:17:30 <nirik> #topic #313 Feature: VirtioSerial ( https://fedoraproject.org/wiki/Features/VirtioSerial )
21:17:32 <notting> if other desktops are doing frontends using udisks/dk-disks, they may want updating to take advantage of the new stuff
21:17:35 <nirik> .fesco 313
21:17:36 <zodbot> nirik: #313 (Feature: VirtioSerial ( https://fedoraproject.org/wiki/Features/VirtioSerial )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/313
21:18:00 <nirik> this looks very nice. +1 here.
21:18:25 <Kevin_Kofler> 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 <pjones> +1
21:18:36 <cwickert> definitely +1
21:18:52 <notting> the lack of user-visible changes makes me wonder. but sure, +1
21:19:07 <Kevin_Kofler> +1 to VirtioSerial.
21:19:09 <nirik> #agreed This Feature is approved.
21:19:14 <jforbes> notting: it will eventually allow copy/paste between guests :)
21:19:23 <nirik> #topic Open Floor
21:19:25 <pjones> jforbes: shiny.
21:19:28 <nirik> Anything for open floor?
21:19:36 <notting> w.r.t. feature not getting done
21:19:42 <notting> do we need to revist xfce4.8?
21:19:47 * notting saw some chatter about that earlier
21:19:54 <nirik> notting: not quite yet. The slip is just proposed.
21:20:01 <nirik> if it slips we will drop it.
21:20:04 <nirik> till next cycle.
21:20:35 <notting> ok
21:20:39 <notting> carry on,then
21:20:46 <cwickert> the Xfce release manager proopsed the slip, so it is likely to happen
21:20:59 <nirik> yeah.. .we will see tho
21:20:59 <cwickert> and Xfce 4.8 is dead for F13 :(
21:21:11 <cwickert> anyway, move on
21:21:43 <nirik> anything else?
21:21:46 <Kevin_Kofler> Can't you just ship a prerelease?
21:21:56 <nirik> Kevin_Kofler: lots of important stuff isn't done yet.
21:22:10 <Kevin_Kofler> 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 <cwickert> we'll see. I dislike what KDE does and I don't want to do the same
21:22:38 <Kevin_Kofler> Sadly, that'd slip through the cracks of the feature process. :-(
21:23:10 <nirik> ok, thanks for coming everyone.
21:23:14 <nirik> #endmeeting