17:01:07 <mmaslano> #startmeeting FESCO (2011-09-19)
17:01:07 <zodbot> Meeting started Mon Sep 19 17:01:07 2011 UTC.  The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:13 <mmaslano> #meetingname fesco
17:01:13 <zodbot> The meeting name has been set to 'fesco'
17:01:20 <mmaslano> #chair notting nirik ajax cwickert mjg59 mmaslano t8m pjones sgallagh
17:01:20 <zodbot> Current chairs: ajax cwickert mjg59 mmaslano nirik notting pjones sgallagh t8m
17:01:36 * notting is here
17:01:37 <pjones> HELLO PARTY PEOPLE
17:01:43 <notting> although not very caught up on tickets
17:01:49 <adamw> party? who? whuh? /me leaves in a hurry
17:01:58 <nb> lol
17:02:00 <pjones> adamw: not you
17:02:13 <t8m> hi all
17:02:20 * nirik is here.
17:02:30 <ajax> i guess i'm here too
17:02:44 <mmaslano> okay, let's start
17:02:50 <mmaslano> #topic init process
17:03:06 <mmaslano> #topic #663 Late F16 Feature Java7
17:03:26 <nirik> so, not sure there's been any news here...
17:03:54 <nirik> we need to get dbhole to do those last things... I can mail on it.
17:04:06 <mmaslano> thanks
17:04:31 <mmaslano> #action nirik will write to dbhole about Java7 feature page
17:04:51 <mmaslano> #topic #664 Older releases need a different approach for updates / karma
17:05:30 <mjg59> nirik: How did the discussion about the proventester meetings go?
17:05:43 <nirik> not much feedback I fear.
17:05:51 <mmaslano> nirik: did you have a meeting?
17:05:55 <nirik> I have decided to try and do a meeting 2011-09-21 (wed) at noon MST (18:00UTC) in #fedora-meeting
17:06:07 <mmaslano> https://fedorahosted.org/fesco/ticket/664
17:06:12 <nirik> so, please do come if you are a proventester and we can at least get some testing done. ;)
17:06:13 <t8m> .fesco 664
17:06:15 <zodbot> t8m: #664 (Older releases need a different approach for updates / karma) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/664
17:06:17 * sgallagh is here (late and under the weather)
17:06:21 * dbhole will wait till the end to get back to 663
17:07:23 <t8m> adamw, around? any ideas coming from QA to get more testers?
17:07:28 <mmaslano> adamw: what about your drumming? ;-)
17:08:53 <nirik> so we want to talk about any other changes on this now? or see if we can get more proventesters/
17:09:16 <mmaslano> dledford: did you have time to look at split of critpath?
17:09:40 <t8m> Well I still think that implementing the timeout for critpath should be done.
17:09:42 <mjg59> Really I ought to follow ajax's lead and sign up for this
17:09:47 <dledford> mmaslano: Not enough to write something down yet.  I have an idea of what to propose and could give a limited bit of that here if you like.
17:10:13 <mmaslano> dledford: that would be great
17:10:15 * nirik notes fedora-easy-karma makes quick work of things if you run with updates-testing enabled.
17:10:42 <mmaslano> nirik: who long have we this tool? did it help number of testers?
17:10:47 <adamw> yo
17:10:57 <adamw> uh, we really haven't done very much, f16 beta is way more important
17:11:04 <nirik> mmaslano: it's been around a while, but could probibly get more press for sure...
17:11:09 <adamw> i was working 16 hour days on the beta all last week, so...yeah.
17:11:25 <mmaslano> adamw: I understand..
17:11:46 <mmaslano> nirik: my point is that we have these update policy for a year and we are still missing testers
17:11:54 <notting> f-easy-karma had initial packaging in march of last year. so, since F-13
17:11:54 <mmaslano> I don't believe that's change overnight
17:12:21 <nirik> mmaslano: yeah, it will not be easy I agree.
17:12:38 <t8m> adamw, can you estimate when you will have time to discuss that?
17:12:58 <dledford> mmaslano: The idea is not really to split up critpath, but to add to it.  Packages can be pulled into critpath as they are, but then they would be identified as to why they are critpath in terms of usage/testing.  So, you would have things like critpath-hardware compatibility, critpath-early boot (prior to switch to real root), critpath-late boot, critpath-networking, etc.  A package can belong to more than one critpath testing group,
17:12:58 <dledford> and the testing group it belongs to determines what sort of testing it needs to be approved.
17:13:10 <ajax> i admit i've mostly been using my proventester bit for f16 though.  i'm not in the habit of keeping VMs for old releases yet.
17:13:20 <notting> ajax: that's the other ticket
17:13:41 <dledford> mmaslano: if a package is only in critpath-hardware compatibility, then obviously it's more important that someone with the right hardware test it that a listed proventester.  So, tailor the critpath approval requirements to the testing requirements.
17:13:53 <nirik> dledford: interesting. You might also ping lmacken and talk about bodhi 2.0 plans... see how that ties in with the karma revamp there.
17:13:59 <t8m> dledford, heh it seems you are working on a way to make even less packages to final :D
17:14:18 <ajax> notting: well, if as a proventester i was testing older releases more, we'd have less kvetching about not being able to get karma
17:14:30 <adamw> t8m: post-beta, besides what nirik is doing.
17:14:33 <mmaslano> dledford: I hope number of packages in critpath will be lower, so testers could work on smaller set of important updates
17:14:37 <adamw> t8m: when that is...is an open question. =)
17:14:47 <t8m> dledford, although I can see that some easy-to-follow testplans can probably attract a few more testers
17:15:35 <dledford> mmaslano: that's in there too, for instance dependencies get pulled in regardless right now, but if a dependency isn't really needed for update (say network-manager pulls in all sorts of stuff related to vpns, but you don't need a vpn to get to the fedora repo, then you drop the vpn parts other than dependency checking)
17:15:39 <t8m> dledford, but on its own I don't think it will improve things as far as critpath updates stuck in testing
17:15:45 <pjones> I think in general the problem really is that nobody gets excited about working on old releases.
17:16:14 <nirik> pjones: yeah, and the people who are using it are less likely to run testing updates and less likely to be involved.
17:16:18 <mmaslano> dledford: I suppose you will have problem find tester for mdadm ;-)
17:16:31 <pjones> nirik: right
17:16:46 <t8m> pjones, well for example I do not really bother except for critical problems and security due to the update policy - I have other ways how to waste time than on packages sitting idle in testing
17:16:48 <adamw> mmaslano: yes, that's one we often run into
17:17:00 <mmaslano> nirik: they can stuck with older releases for various reason. Many people update only every second release
17:17:07 <adamw> mmaslano: a) finding people running f14 with mdraid arrays who are willing to test updates and b) making sure they know they can +1 updates if their array keeps working
17:17:10 <pjones> nirik: it's unclear to me how these process changes can effect that in a meaningful way.
17:17:13 <dledford> mmaslano: mdadm is a hardware enablement thing, part of this is that if we can automate certain tasks with autoqa, then do so.  Some well crafted vm images and a set of predefined update runs in those vms might satisfy some of those requirements.
17:17:31 <t8m> pjones, that's from my pov as package maintainer
17:17:37 <pjones> adamw: whereas the very idea of having done a raid install implies that you might not want to risk testing ;)
17:17:44 <mjg59> dledford: Yes ideally hwenablement like that would be entirely autoqa
17:18:36 <nirik> I fear short term the best solution is 'try and find more testers' and/or add a timeout for corner cases...
17:18:51 <t8m> nirik, I think both would be ideal
17:19:21 <nirik> t8m: arguments for a timeout seemed insufficently compelling to get enough votes last week.
17:20:30 * mmaslano thougth that we are trying found more testers for years...
17:20:45 <t8m> Well I understood that we will be looking for some creative ideas how to solve the problem. I do not really see any that would substantially improve things so perhaps we should at least partially workaround the problem for now with the timeout
17:21:29 <notting> what was the exact proposal again? we could always re-vote
17:22:12 <nirik> proposal: any update with no -karma can be pushed to stable after 2 weeks by the maintainer/submitter.
17:22:14 <t8m> Allow push to stable without meeting the minimum karma requirement if the update is in testing for two weeks and there are no -1 karma points
17:22:45 <t8m> (for critpath)
17:22:52 <t8m> I'd leave non-critpath as is
17:23:07 <notting> well, non-critpath can already do so
17:23:12 <t8m> yes
17:23:15 <pjones> I still think that obviates the point of critpath
17:23:36 <mjg59> And does nothing to help security updates get through faster
17:23:50 <sgallagh> Perhaps we should change things only for the oldest stable branch? I mean, the current stable and current Branched versions *tend* to get more testing.
17:23:55 <mjg59> And means that the problem becomes an irritation rather than a showstopper so we stop caring about trying to fix it.
17:23:57 <t8m> well 2 weeks is faster than 3 months
17:24:06 <mjg59> t8m: Two weeks is still unacceptable
17:24:30 <mmaslano> mjg59: it's better than month
17:24:33 <t8m> mjg59, and the problem is not just security updates but regular bug fixes as well
17:24:46 <nirik> it's sometimes a lot longer. ;)
17:24:48 <mjg59> t8m: Fixing it for security updates fixes it for everyone
17:24:56 <t8m> mjg59, not at all
17:24:57 <mjg59> And we need to fix it for security updates
17:24:59 <pjones> sgallagh: but if you're saying that, the question remains: why are people doing updates for the oldest stable branch?
17:25:06 <mmaslano> mjg59: that's different topic
17:25:14 <pjones> if it's just security updates, that's one thing.  but as t8m notes, it isn't.
17:25:15 <mjg59> mmaslano: No, it's really not
17:25:18 <mjg59> They're equivalent
17:25:20 <nirik> xorg-x11-drv-nouveau-0.0.16-14.20101010git8c8f15c.fc14 -> Submitted: 2011-04-10 23:39:47
17:25:31 <mjg59> We fail to get updates tested fast enough. That includes security updates.
17:25:54 <mjg59> Two weeks is an unacceptable period of time for a security update to wait
17:26:05 <t8m> mjg59, for example if we make it so the security updates are worked on the proventesters meetings - maybe that could work, however if you include regular bugfix updates the meetings will be overwhelmed and they will not be able to test everything
17:26:08 <dledford> The problem isn't the updates, it's the process.  You want to require testing, but there is no provision for providing testing.  You can't make a hard requirement on something that doesn't have a hard source of supply.
17:26:39 <t8m> dledford, +infinity
17:26:40 <mmaslano> dledford: +1
17:26:50 <mjg59> dledford: It is unacceptable for untested packages to go to stable
17:27:08 <dledford> mjg59: then make a hard source of supply for testing
17:27:27 <t8m> mjg59, it's just your idea that packages without karma are completely untested
17:27:30 <mjg59> dledford: That's a difficult thing to do in a volunteer-led distribution
17:27:30 <dledford> mjg59: the argument in this case all boils down to an impossible set of requirements to meet
17:27:33 <t8m> mjg59, it's surely untrue
17:27:33 <pjones> dledford: I don't agree - the problem isn't exclusively supply.  the reason there's no supply of testers is that demand for actually *receiving* updates is low.
17:27:35 <sgallagh> mjg59: Then we need a budget for a formal QA department that's answerable for delays.
17:27:48 <pjones> if people were interested in f13, there would be f13 testers.
17:28:02 * mmaslano says 15 minutes out. Continue?
17:28:14 <notting> yes, continue
17:28:18 <mmaslano> pjones: we are speaking about f14
17:28:18 <t8m> pjones, fine, let's give up on updates completely apart from critical severity security bugfixes
17:28:27 <nirik> mjg59: no karma doesn't mean no testing.
17:28:28 <notting> pjones: well, that implies that those that want updates know what they're missing
17:28:35 <mjg59> nirik: No, but it also doesn't mean testing
17:28:36 <nirik> mmaslano: sure, continue a bit.
17:28:43 <nirik> right, it's unknown.
17:28:44 <drago01> t8m: why if enough people care about the update people would test
17:28:47 <pjones> mmaslano: kindof missed the point there
17:28:49 <sgallagh> mmaslano: +1 to continue
17:28:58 <pjones> t8m: please?
17:29:12 <t8m> drago01, the people who are not using testing updates, do not know about the updates in testing
17:29:17 <mjg59> t8m: It's a policy that works for pretty much every other distribution
17:29:40 <mjg59> While I'm not arguing in favour of it, I would say that it wouldn't be awful if that's where we ended up
17:29:45 <pjones> I'm +1 to t8m's proposal of not doing non-security updates for f14.
17:30:46 <jwb> should that be rephrased to "not doing non-security updates for the oldest stable release"?
17:31:01 <pjones> yes
17:31:05 <sgallagh> pjones, t8m: So if I'm understanding this correctly, we'd have six months of security+bugfixes and then six months of security-only? (Glossing over "enhancements")
17:31:07 <drago01> that does not make sense
17:31:14 <mmaslano> pjones: what will gain on that?
17:31:15 <drago01> if there is an update that fixes bugs
17:31:19 <drago01> and people do test it
17:31:20 * nirik doesn't think that makes much sense.
17:31:22 <drago01> why block it?
17:31:42 <t8m> this is de-facto situation
17:31:59 <ajax> drago01: your predicates seem to be failing though
17:32:00 <mmaslano> that doesn't make sense. People asked me for more freedom in updates policy and we'll do it even stricter?
17:32:12 <sgallagh> Speaking frankly, people who want a guaranteed-stable system tend not to run Fedora. They run RHEL/CentOS.
17:32:22 <nirik> I think there's two things here: 1)what can we do short term to fix up our existing process and 2) what can we do long term... and I think there are a number of things here... new bodhi, splitting critpath, integration with pk, etc... but they will all take time and people driving them.
17:32:25 <drago01> t8m: which is fine
17:32:27 <sgallagh> People running Fedora usually want the latest-and-greatest, and damn the consequences
17:32:28 <drago01> ajax: meh
17:32:36 <pjones> mmaslano: 10 yards delay of game.  people didn't ask for "more freedom", they asked for the ability to not have things tested.
17:32:46 <drago01> sgallagh: citation needed
17:32:52 <pjones> sgallagh: people running the oldest stable release clearly don't want that.
17:33:25 <t8m> drago01, which isn't because there are still some maintainers that think that making an update will eventually get it into stable, but their work is wasted by letting it stay idle in testing for months
17:33:43 <notting> pjones: they either want their packages to become tested, or the ability to push without testing
17:33:51 <notting> and the argument is which of those to implement
17:33:58 <pjones> notting: right, but the first of those isn't happening and the second isn't acceptable.
17:34:18 <pjones> notting: so the question is: wouldn't we be better off not doing the update at all, and working on something current instead?
17:34:18 <sgallagh> pjones: While I'll admit this is my own interpretation, I think F14 is a bit of an unusual case. Perceived issues with systemd and Gnome 3 have caused a disproportionate number of people to stick to the older F14, expecting the bugs to be worked out in F16.
17:34:20 <dledford> pjones: 20 yards intentional foul, I asked for a process that didn't place a requirement on the developer with no accountability for that process being met (or not met as the case often is)
17:34:37 <t8m> it is still very false predication that the packages that are staying in testing are not tested
17:34:38 <mmaslano> sgallagh: my words
17:34:39 <sgallagh> I don't think we usually see so many people hanging on to the oldest stable release for so long.
17:34:48 <t8m> they just don't get the karma needed for push
17:34:48 <pjones> dledford: I admit I was generalizing, rather than specifically speaking of your proposal.
17:35:01 <sgallagh> mmaslano: ?
17:35:27 <mmaslano> sgallagh: that people tend to use older release because of current "unstable" state
17:35:32 <pjones> sgallagh: you keep making claims like those without producing numbers.
17:35:36 <mmaslano> anyway, we don't have any numbers about our users
17:35:36 <mjg59> We can't guarantee testing. We're also unwilling to vote in favour of allowing packages to be pushed unless there is evidence of testing.
17:35:42 * nirik fears we aren't going to come up with a solution here to the short term problem. It's either get more testers, or allow less testing.
17:35:46 <mjg59> So:
17:35:54 <mjg59> #proposal move onto the next topic because we're not doing anything useful here
17:36:00 <notting> are the whys of why we have f14 users really relevant, though? the current update policy was decided on the basis of not regressing user's systems and functionality. i.e., not "i updated and now i can't do anything". do we really feel that those conditions have changed?
17:36:01 <sgallagh> pjones: I don't have numbers to give. I'm only working from broad generalities based on reading the fedora-devel and fedora mailing lists.
17:36:11 <Southern_Gentlem> pjones,  logs from the #fedora channel the first 2 months that f15 was released
17:36:16 <pjones> sgallagh: right.  I don't think that's data of any kind.
17:36:20 <pjones> Southern_Gentlem: and I don't think that is, either.
17:36:21 <drago01> sgallagh: if that where the case there wouldn't be a shortage of testers
17:36:21 <nirik> mjg59: +1 sadly.
17:36:26 <pjones> mjg59: +1 to that
17:36:57 <notting> -1 to moving on w/o some sort of next steps to work on offline to get out of this morass
17:37:09 <pjones> notting: nirik does have his meeting scheduled for wednesday
17:37:11 <sgallagh> drago01: I think you're making an assumption that users==testers there
17:37:14 <t8m> -1 same as notting
17:37:27 <sgallagh> As we already discussed, most users are unaware of updates-testing unless they've submitted a BZ
17:37:45 <mjg59> We can probably improve the amount of testing
17:37:50 <mjg59> But we can't guarantee that testing will occur
17:37:58 <sgallagh> The only people who are aware of updates-testing in the general case are developers, who tend to be using either the latest stable or the current Branched
17:38:05 <pjones> sgallagh: that's the same (bad) assumption you were making when you spoke of generalities from reading mailing lists and Southern_Gentlem was making when citing #fedora.
17:38:05 <mjg59> That doesn't appear to entirely address dledford's concerns
17:38:25 <dledford> mjg59: nor can we guarantee that the testing will improve in relation to any given update that's stalled...
17:38:38 <notting> pjones: given that updates-testing isn't enabled by default, i suspect that has more resemblance to the truth than its converse
17:38:38 <sgallagh> pjones: No, I'm asserting that developers are closer to testers than users are.
17:38:39 <nirik> I think the things to target are the critpath and security updates, starting with oldest release... I don't know if we can, but ideally I'd like to get enough testers to where we can get all those tested... but then the issue becomes: will people stick with it...
17:39:11 <dledford> nirik: there is no guarantee that they will
17:39:14 <mjg59> dledford: Indeed. If you want guarantees, then without paying people for it we're not going to get it
17:39:37 <mjg59> dledford: Improving AutoQA does give us the ability to effectively guarantee that for some subset of configurations
17:39:51 <drago01> what about this: EOL old releases earlier
17:40:11 <drago01> if we don't have the resources to support them
17:40:16 <drago01> so don't pretend we have
17:40:23 <dledford> mjg59: which has been my point all along, we have a volunteer project, we have volunteer resources, and a process that puts hard roadblocks in the way of progress, and where the only resolution to those roadblocks is volunteer effort, is a doomed process.
17:40:26 <nirik> well, it's not like they aren't supported.
17:40:27 <mjg59> If we believe that there's going to be a glorious autoqa future that makes the problem tractable then the question is whether it's better to (a) allow pushing without testing or (b) prevent updates from going out until we get there
17:40:34 <pjones> drago01: I'd also get behind that, though I was taking a slightly less aggressive stance with suggesting maybe we should attempt security fixes for longer.
17:40:40 <mmaslano> drago01: in that case we can also speak about longer cycle of release ;-)
17:40:44 <sgallagh> For what it's worth, I proposed last week that our long-term approach to this should be extending PackageKit/F-easy-karma so that it alerts users to testing updates (with the OPTION to install them) and then nags for karma.
17:40:46 <t8m> drago01, I think the security only proposal is better in that case
17:41:03 <mjg59> dledford: A volunteer project with no users will die. If users have the expectation that updates will break things, they'll either stop using updates or go elsewhere.
17:41:09 <nirik> sgallagh: thats been suggested many times, but I fear will not happen unless people specifically step up to implement it.
17:41:27 <sgallagh> nirik: Has anyone tried taking it to the PackageKit community?
17:41:42 <nirik> I think they have and the answer was: great, patches welcome...
17:42:03 <dledford> mjg59: and a volunteer project that can't get anything done for fear of upsetting someone will likewise die when legitimate issues go unsolved
17:42:31 <mjg59> dledford: Nobody is denying this is a legitimate issue. But the trivial solution for it breaks other things.
17:42:31 <Southern_Gentlem> ?
17:42:44 <t8m> mjg59, if users have the expectation to not get their bugs fixed in older releases they will either use the current one and if it is too unstable then use different distro anyway
17:43:07 * nirik is only seeing: see what happens with a proventesters meetup this week and revisit next week. I don't see any other steps we can agree on that are short term.
17:43:20 <mjg59> Fundamentally we need more testers and better autoqa
17:43:45 <pjones> nirik: +1
17:43:46 <notting> i'll see if i can shake out some more testers as well
17:44:04 <drago01> pjones: yeah but in that case I see no reason to block tested non security updates
17:44:05 <dledford> I agree with the better autoqa, and I'm perfectly fine gating packages on passing autoqa as it is developed.  More testers is nice to have, but can't be relied upon.
17:44:07 <t8m> nirik, ok +1
17:44:25 <nirik> another idea from long ago:
17:44:27 <pjones> drago01: the reason to block them is to discourage them.
17:44:40 <mmaslano> so, more testers, change critpath, autoqa and file RFE for PackageKit?
17:44:45 <nirik> karma swaps by maintainers: hey, you test my critpath package, I'll test yours.
17:44:57 <mjg59> nirik: Works for some cases, less well for others
17:45:09 <nirik> sure, just an option that some maintainers may not think of.
17:45:12 <mjg59> If you still need an estoric hardware setup then you still need testers for that
17:45:25 <t8m> most maintainers are not proventesters
17:45:32 <mmaslano> nirik: that works when you have small number of packages
17:45:34 <Southern_Gentlem> testers mailing list feed from bodhi stateing critpath or not on packages to be tested
17:45:57 <nirik> t8m: they could easily become so.
17:46:07 <nirik> Southern_Gentlem: it's in every updates-testing report
17:46:34 <nirik> The following Fedora 14 Security updates need testing: / The following Fedora 14 Critical Path updates have yet to be approved:
17:46:57 <Southern_Gentlem> nirik, is there some sort of notification for us proven testers other than going to look
17:47:10 <nirik> not sure.
17:47:39 <nirik> it used to spam proventesters I think, but then people complained.
17:47:59 <Southern_Gentlem> at this point yet another mailing list with that report might help
17:48:14 <jwb> why can't it go to the test list?
17:48:32 <nirik> we can perhaps discuss that at the proventesters meetup?
17:48:38 <Southern_Gentlem> +1
17:48:38 <t8m> nirik, +1
17:49:09 <mmaslano> #action nirik will bring up question about list of untested updates on proventester meeting
17:49:38 <mmaslano> so, could we move on and wait more testers, change critpath, autoqa and file RFE for PackageKit?
17:49:52 <mmaslano> we have other tickets to solve
17:50:03 <t8m> mmaslano, +1 for moving on
17:50:07 <notting> yeah, like that upcoming ticket is solvable today. ahem.
17:50:17 <mjg59> notting: Oh I think there's an easy solution
17:50:19 <nirik> I think we need more data to decide anything about changing critpath, and I think RFE on packagekit is not likely to go anywhere, but sure. ;)
17:50:24 <sgallagh> +1 for moving on
17:50:28 <mjg59> +1 for moving on
17:50:44 <dledford> +1 for moving on
17:51:10 <mmaslano> dbhole: are you still here? could we finish your ticket?
17:51:12 <mjg59> dledford: I don't think you get to vote :p
17:51:18 <dbhole> mmaslano: Yes, I am  :)
17:51:25 <dbhole> and yes, sure
17:51:33 <dledford> mjg59: I didn't think so either, but I was gonna put my $.02 in dammit :-)
17:51:37 <mmaslano> so, back to Java
17:51:39 <mmaslano> #topic #663 Late F16 Feature Java7
17:51:40 <pjones> +1 for moving on
17:51:42 <dbhole> Sorry for not being here earlier.. I had it marked in my calendar too.. alarm didn't go off :/
17:51:45 <mmaslano> .fesco 663
17:51:46 <zodbot> mmaslano: #663 (Late F16 Feature Java7) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/663
17:52:01 <mmaslano> dbhole: what's the state of your feature page?
17:52:22 <dbhole> Okay, so w.r.t to that, java-1.6.0-openjdk is built, I am not sure how to easily ensure that everything is built with 6 in F16, but I will look into it
17:52:43 <dbhole> mmaslano: As for feature page, is there some page someone could please point me too? I could find no instructions on how to set up tech preview feature pages
17:52:48 <nirik> should be able to do it with some repoquery?
17:52:51 <dbhole> or previous examples to use as template
17:53:25 <mmaslano> dbhole: http://fedoraproject.org/wiki/Features/Java7 looks ok to me
17:53:49 <t8m> maybe some release note
17:53:51 <mmaslano> dbhole: I suppose you have to use date of build
17:54:04 <mmaslano> dbhole: to find out which java was used for build
17:54:08 <dbhole> nirik: Yeah, I will write a script to list everything built while 1.7 was default.. the problem is that it is about 20 days and there is no way to isolate java packages.. I am sure I can come up with some incantation that searched only those that BR java or something
17:54:36 <dbhole> s/searched/searches
17:54:47 <nirik> ok. Yeah, update the feature page to reflect that it's a stand alone tech preview and not used to build anything...
17:54:49 <dbhole> mmaslano: How can I propose that for inclusion as techpreview though?
17:55:05 <dbhole> nirik: Sure, I'll do that as soon as the meeting is done
17:55:08 <mmaslano> dbhole: not sure, rbergeron?
17:55:10 <nirik> dbhole: I'd ask the marketing list, and add a release note about it...
17:55:31 <mmaslano> dbhole: nirik is probably right, it's only release note
17:55:51 <dbhole> nirik, mmaslano: Would it not be possible to add it here too? http://fedoraproject.org/wiki/Releases/16/FeatureList ?
17:56:05 <dbhole> As a tech preview only of course.. I will change the summary accordingly
17:56:12 <nirik> I don't recall if we did in the past when we had techpreview...
17:56:40 <mmaslano> dbhole: I guess it's on rbergeron to move finished features into this list
17:56:44 <nirik> dbhole: I can look back in history after the meeting...
17:56:48 <t8m> dbhole, when you update the feature page we can vote on it again
17:57:17 <dbhole> t8m: Ah okay. Sure.. I will update it and add a note to #663 and be here next week, would that be okay?
17:57:44 <mmaslano> #action dbhole update feature page of Java7
17:57:59 <nirik> I don't know that we need to vote again, but following up next week sounds good.
17:58:10 <dbhole> great, thanks everyone!
17:58:22 * dbhole will update it right now
17:58:57 <mmaslano> nirik: we have to vote if criteria of update are met
17:59:45 <mmaslano> #action dbhole will write a script for packages built with Java7
18:00:02 <mmaslano> next ticket..
18:00:05 <mmaslano> #topic #667 Request to fix CRITPATH update process
18:00:13 <mmaslano> .fesco 667
18:00:16 <zodbot> mmaslano: #667 (Request to fix CRITPATH update process) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/667
18:00:34 <nirik> this is the other side of the coin of the eariler one.
18:00:37 <t8m> mmaslano, I think we discussed that already, the tickets should be merged
18:00:49 <mmaslano> great!
18:00:49 <t8m> 667 and 664
18:00:59 <mmaslano> new business
18:01:01 <mmaslano> #topic #669 remove non-yum depsolvers from fedora defaults
18:01:07 <mjg59> -1
18:01:07 <mmaslano> .fesco 669
18:01:09 <zodbot> mmaslano: #669 (remove non-yum depsolvers from fedora defaults) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/669
18:01:12 <t8m> +1
18:01:44 <mmaslano> I have different proposal
18:01:55 <pjones> does it involve us doing less babysitting?
18:02:10 <mmaslano> all dep solvers should be using rpm library
18:02:14 <nirik> so, my thoughts on this: There's two levels of things here... a) if something is allowed in the collection at all, b) if something is made default for a majority of our users. Also, there's a level of base OS stack that should make scrutiny more and more as you go down.
18:02:17 <mmaslano> rpm guys are working on it
18:02:35 <pjones> mmaslano: I think the objection to that is that it's slow.
18:02:46 <mmaslano> pjones: I didn't see any number
18:02:52 <notting> ? zif and yum both use librpm
18:03:06 <pjones> notting: I was rather thinking of a more historical perspective
18:03:18 <mmaslano> notting: at least yum is using their own dep-solver
18:03:23 <nirik> in this case, I think we should request pk not use zif by default, and urge those involved to work on longer term solutions like packaging/yum people maintaining the pk yum backend, rpm growing depsolver, etc.
18:03:29 <ajax> sigh.  every interaction with yum feels like breaking up a playground fight.
18:03:44 <dledford> ajax: +1
18:03:53 <t8m> nirik, +1
18:04:07 <notting> mmaslano: rpm depsolver involves handing it a transaction and having it sort out whether it works. you still need some mechanism to decide what transaction to hand it, ergo, a depsolver
18:04:19 <notting> mmaslano: (see also, header requirements, file conflicts, other fun)
18:04:23 <mjg59> Ok.
18:04:33 <mjg59> The default for PK is default_backend=yum,zif
18:04:37 <mjg59> What does that actually mean?
18:04:37 <dledford> nirik: your idea does not address the reasons that pk split from using a yum backend (threading issues, etc.) and only addresses maintenance.
18:04:52 <drago01> I asked on the list so here again ... whats the point here as long as both resolvers end up with a valid transaction?
18:04:55 <mjg59> Is it "Use yum unless it's unavailable, and if so use zif"?
18:05:00 <nirik> dledford: I would hope those could be addressed longer term.
18:05:06 <drago01> mjg59: yeah
18:05:11 <mjg59> So...
18:05:18 <mjg59> The current situation is that everything is using yum by default?
18:05:25 <pjones> mjg59: makes you wonder what the problem is, eh?
18:05:26 <nirik> drago01: confusion for support and users that the two provide different answers. Confusion for maintainers.
18:05:49 <notting> nirik: that's 'if' they provide different answers?
18:06:00 <nirik> sure, but I thought that was a given...
18:06:13 <t8m> notting, but they do - the algorithm in yum and zif is completely different
18:06:17 <drago01> nirik: how so?  if this causes problem the deps in one or more packages are just wrong
18:06:20 <mjg59> I don't think it would be excessively controversial to say that we should never have a situation where the default configuration is to provide two levels of user facing tools that do the same thing but have different behaviour
18:06:25 <drago01> *problems
18:06:29 <mjg59> But we don't have that situation
18:06:51 <notting> drago01: packaging is done in some cases to ensure that yum's depsolver does the right thing. (multi-arch obsoletes, and comparisons of multiple providers being the main cases)
18:06:53 <nirik> drago01: what if you can't solve it for both dep solvers?
18:07:07 <mjg59> And threatening to remove stuff because of a hypothetical seems entirely unreasonable
18:07:11 <mjg59> So:
18:07:17 * nirik is -1 for removing anything
18:07:24 <mjg59> #proposal: Defer issue until the situation actually arises
18:07:31 <pjones> drago01: then one of them is broken
18:07:31 <sgallagh> mjg59: +1
18:07:37 <mmaslano> notting: well, multi-arch doesn't work well
18:07:40 <t8m> alternative proposal
18:07:42 <pjones> er,
18:07:45 <pjones> nirik: then one of them is broken
18:08:08 <pjones> mjg59: +1 to that
18:08:09 <t8m> #proposal: Explicitly state that non-yum depsolvers are not allowed for default installs
18:08:23 <pjones> t8m: why?  there's no compelling reason to do so
18:08:35 <mjg59> t8m: I don't see the benefit of that. We might want to end up defaulting to zif and not have yum in the default install.
18:08:36 <dledford> pjones: not necessarily, I have some packages with convoluted obsoletes that are tuned to yum specific behavior...if zif didn't exhibit the same behavior the result could be wrong without zif being at fault really
18:08:43 <sgallagh> t8m: -1
18:08:43 <mjg59> I mean, I don't think it's *likely* that we'd want that, but it'd be possible.
18:08:54 <nirik> so, this would next arise if we addressed the feature, or if pk changed default backend?
18:09:04 <mjg59> nirik: Yes, to both
18:09:08 <notting> nirik: correct
18:09:14 <pjones> dledford: I think if zif (or yum, for that matter) failed to implement that same behavior, I'm comfortable defining that as wrong.
18:09:43 <nirik> I'm +0 to that, I fear the backend might get changed without any kind of notification to us, so we miss it.
18:09:52 <t8m> nirik, exactly
18:10:05 <t8m> and I am -1 to that
18:10:23 <pjones> nirik: if that happens and we miss it, that's a surprisingly good outcome.  by which I mean I expect if that changes, we'll notice things breaking.
18:10:24 <mjg59> Ok.
18:10:41 <mmaslano> #proposal do nothing until errors will be found
18:10:42 <nirik> pjones: true, but it seems pretty reactive instead of proactive. ;(
18:10:44 <mjg59> #proposal: No Fedora release should ship with two different depsolvers enabled by default
18:10:58 <t8m> mmaslano, that seems to be the default mode of operation here
18:11:04 <t8m> mjg59, +1
18:11:12 <t8m> mjg59, that one I accept
18:11:25 <sgallagh> mjg59: +1
18:11:30 <notting> mjg59: what does that even mean? you mean, the fallback line as presented above?
18:11:45 <mjg59> notting: Yeah that could be differently worded
18:12:02 * spot points out that would proposal mean that zif could not be the default pk depsolver.
18:12:07 <pjones> notting: presumably either zif gets removed from that or zif doesn't get installed by default so that line doesn't matter much?
18:12:09 <sgallagh> I interpreted that to mean: we ship with yum enabled. Anyone wanting to use Zif should have to enable it manually (and assume the risks that entails)
18:12:10 <spot> ugh. me talk good.
18:12:22 <mjg59> spot: Yes, I think that's deliberate
18:12:29 <drago01> mjg59: not really ... different use cases means different tools (each one handles the other one better)
18:12:32 <mjg59> spot: Anaconda's depsolver should match the desktop UI
18:12:34 <spot> mjg59: okay, just to make it clear.
18:12:52 <ajax> spot: well.  rfc 2119 says "should" statements are merely strong recommendations.  i don't know if that's the language we're using here.
18:12:54 <mjg59> If nothing in the default install uses yum then I have no problem with everything using zif
18:12:57 * nirik is +1 to mjg59's proposal with clarification.
18:13:30 <mmaslano> -1 I don't want force yum depsolver to pk
18:13:31 <t8m> mjg59, including anaconda of course :)
18:13:40 <mjg59> t8m: Yeah.
18:13:53 <pjones> mmaslano: well, anaconda is using yum and isn't likely to change since that's a major release worth of work
18:13:56 <mjg59> But if there's no strong agreemtn on that then let's just defer.
18:14:08 <mjg59> I'm not going to lose sleep over this
18:14:38 * nirik would like to avoid PK switching to zif at this time, otherwise yeah...
18:14:49 <mmaslano> it's +2 and -1
18:14:58 <dledford> mjg59: why should anaconda's depsolver have to match the installed one?  Anaconda will create a valid transaction, and all deps will be solved, then when you boot into the system and run the other depsolver, all deps are still solved so it shouldn't make any difference.  It's not like zif would say "Oh, anaconda screwed up and didn't install these 10 packages, let me grab them for you now" would it?
18:14:59 <t8m> mmaslano, +3
18:15:05 <sgallagh> I propose leaving yum as the exclusive depsolver at this time, pending a Feature in a future release to switch to Zif.
18:15:32 <t8m> sgallagh, or some else depsolver
18:15:34 <notting> dledford: well, it *COULD*. not saying it would, though.
18:15:36 <mjg59> dledford: Having a valid transaction isn't ideal. You really do want repeatable transactions.
18:15:39 <pjones> dledford: because (and we're way out here in the realm of theory here) it's possible for one depsolver to leave the package set in such a state that the other can never complete any transaction.
18:16:06 <mjg59> dledford: Otherwise you end up with situations where doing a package install in the installed system works fine, but you end up with unexpected solutions in Anaconda, which hasn't been as well tested
18:16:41 <dledford> pjones: but it's an rpm verified transaction, so if a depsolver can do it and be a valid final state, so can a user at the command line (without using --force or --no-deps), so I think that scenario is *WAY* out there.
18:16:44 <t8m> noone else would vote for the last mjg's proposal?
18:17:05 <nirik> dledford: is it? does zif do a rpm transaction test? dunno, I haven't looked.
18:17:14 <notting> don't like the wording, really. various projects with extensions have their own depsolver. and heck, ld.so is one too
18:17:24 <nirik> so, can we reword?
18:17:25 <mjg59> Yeah ok
18:17:29 <sgallagh> t8m: +1
18:17:43 <mmaslano> #proposal: No Fedora release should ship with two different depsolvers enabled by default
18:17:45 <pjones> dledford: but it "rpm verified" only means it's internally consistent; it doesn't mean e.g. obsoletes got processed right to choose what should go in to the transaction.
18:17:48 <mmaslano> +4 -1
18:18:19 * ajax waiting for mjg's reword
18:18:24 * pjones too
18:18:25 <dledford> pjones: does rpm not track obsoletes or conflicts then?  I was under the impression it did...
18:18:41 <mjg59> #proposal: By default, all RPM-based package managers in a Fedora release must use the same dependency solver
18:18:41 <notting> #proposal The RPM package installation GUI that is installed by default should use the same dependency solver/backend as the non-GUI default. <- is that what you meant?
18:18:47 <pjones> dledford: yum does that part typically in order to determine what goes in to the transaction set.
18:19:13 <sgallagh> dledford: If a package can be Obsoleted by two different packages, then two different depsolvers might make different choices.
18:19:17 <sgallagh> One could be a dead-end.
18:19:46 <t8m> I like the nottings proposal
18:19:54 <pjones> dledford: so it'll use e.g. conflicts to say that the ts is *bad*, but it never pulls in new packages from anything at all, so it's not making choices about obsoletes; only verifying that they're valid.
18:19:56 <ajax> notting: mjg's wording sounds even stronger.  +1 either way though.
18:20:09 <t8m> yeah +1 either way
18:20:14 * pjones is for it
18:20:20 <sgallagh> +1 either way for me as well
18:20:25 <notting> sure, +1 to either
18:20:30 <mjg59> +1 to either
18:20:31 * notting defers to mjg59 as initial proposer
18:20:39 <nirik> +1
18:20:48 <mmaslano> it's +5
18:21:03 * sgallagh counts +7
18:21:08 <mmaslano> oh, sorry
18:21:15 <sgallagh> +8 if notting is assumed to also be +1
18:21:23 <nirik> hum.
18:21:30 <nirik> so, this means we need to nuke synaptic?
18:21:41 <spot> nirik: if it is installed "by default"
18:21:43 <kalev> could it be reworded so that it would only address depsolvers in default-installed RPM package managers?
18:21:51 <nirik> I sure hope not. ;)
18:22:16 <mmaslano> #action The RPM package installation GUI that is installed by default should use the same dependency solver/backend as the non-GUI default.
18:22:23 <nirik> nottings would take care of it. so, move on. ;)
18:22:34 <mmaslano> #topic #670 Problems with device-mapper-multipath on sysv to systemd upgrade
18:22:40 <mmaslano> .fesco 670
18:22:41 <zodbot> mmaslano: #670 (Problems with device-mapper-multipath on sysv to systemd upgrade) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/670
18:22:51 <notting> so, my answer to this is to just make a trigger to preserve state on upgrade, and be done with it
18:23:23 <nirik> if that works, sure.
18:23:23 <t8m> as this is not a network facing daemon, can it not be just enabled by default?
18:24:02 <nirik> we could do that yeah... but then it's useless on 99% of installs.
18:24:18 <t8m> look at this comment https://bugzilla.redhat.com/show_bug.cgi?id=739279#c6
18:24:36 <t8m> this will make it no-op for 99% of installs
18:24:38 <mjg59> If it's not dangerous then I'd say leave it up to the maintainer
18:24:46 <t8m> yeah
18:24:58 <sgallagh> I want to know why it isn't part of our standard packaging guidelines to simply ALWAYS require an upgrade trigger to determine whether the user had manually selected it to be enabled at boot.
18:25:05 <sgallagh> Asking chkconfig is pretty easy.
18:25:09 <nirik> mjg59: well, they need our permission to add it to the 'enabled to start on boot'
18:25:31 <notting> sgallagh: would be overriding FPC, but we could do so
18:25:38 <t8m> sgallagh, there are some nasty problems with the scripts I think
18:25:40 <mjg59> nirik: Right, and if they want to do that then I'm fine with it
18:25:47 <sgallagh> t8m: Citation needed
18:26:00 <t8m> sgallagh, unfortunately I do not know where I read that
18:26:15 <notting> sgallagh: impedence mismatch between runlevels and systemd targets led to the perfect being the enemy of the good
18:26:16 <sgallagh> FWIW, I have a package that is doing this (since it was converted before the finalized guidelines were put into place)
18:26:26 <nirik> FPC didn't want to go that route... I don't know the details, but I'd want to check with them on them before deciding that.
18:26:35 <t8m> nirik, +1
18:27:02 <notting> proposal: as in the bug, just enable it by default, conditional on the presence of a configuration file
18:27:20 <mmaslano> +1
18:27:21 <sgallagh> notting: +1 (since it's not network-facing)
18:27:21 <notting> (it does not ship a configuration by default)
18:27:26 <mjg59> notting: +1
18:27:27 <t8m> notting, +1
18:27:35 <nirik> +1
18:27:41 <nirik> does it need to be default in comps still?
18:27:49 * notting is +1 to that
18:28:21 <notting> nirik: ... probably not? but that's not really a fesco issue.
18:28:23 <mmaslano> #action enable device-mapper-multipath if configuration script exist
18:28:37 <nirik> sure, just tossing it out there.
18:28:39 <sgallagh> notting: I think I want to talk to FPC about the upgrade case a bit more, though. I think at least that services enabled at runlevel 3, 4 AND 5 should be eligible for upgrade protection
18:28:44 <t8m> mmaslano, that's not correct
18:28:54 <sgallagh> I can see where graphical targets might be trickier.
18:29:52 <mmaslano> #undo
18:29:52 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x136d1fac>
18:30:08 <mmaslano> #action enable it by default, conditional on the presence of a configuration file
18:30:12 * gholms recommends #agreed for things that are not action items
18:30:34 <mmaslano> #agreed enable it by default, conditional on the presence of a configuration file
18:31:13 <mmaslano> #topic chairman for next week
18:31:20 <mjg59> I can do it
18:31:30 <mjg59> Unless anyone else wants to take that bullet
18:31:34 <nirik> thanks mjg59. :)
18:31:44 <mmaslano> #action mjg59 will be chairman for the next week
18:31:55 <mmaslano> #topic open floor
18:32:12 <sgallagh> I've been asked to raise a question about systemd conversions post-beta
18:32:19 <t8m> I'll probably won't be able to make ti next week.
18:32:28 <sgallagh> Are we allowing conversions still (and if not, what's our answer when asked?)
18:33:12 <nirik> I'm ok with non critpath conversions still...
18:33:20 <nirik> would be happy to get them over and done with. ;)
18:33:29 <t8m> nirik, +1
18:33:48 <sgallagh> nirik: But not for critpath?
18:34:07 <nirik> I'd be afraid those would interfere with testing...
18:34:11 <nirik> but i think they are all done anyhow.
18:34:32 <notting> should have a deadline before final change deadline, though
18:34:46 <spot> nirik: krb5 and samba are not done, i think they both end up being critpath
18:34:52 <mmaslano> sgallagh: hard to say. What if sysvinit script doesn't work well with systemd?
18:34:58 <nirik> ah, hum.
18:35:00 <notting> mmaslano: ask for exception?
18:35:02 <spot> (although krb5 is only affected because of krb5-server)
18:35:15 * notting arbitrarily says... 2011-10-01?
18:35:20 <mmaslano> notting: do we want control their scripts?
18:35:21 <nirik> spot: how many are left?
18:35:40 <spot> nirik: there are 6 on my todo list, but apparently, there are quite a few that I am unaware of.
18:36:10 <notting> mmaslano: not sure what you mean
18:36:29 * nirik +1's notting's 2011-10-01... gives a few weeks before final freeze, but a bit more time now.
18:36:50 <t8m> yeah, the notting's deadline is fine
18:36:52 <nirik> I guess I'd be ok with krb5 and samba as well...
18:36:57 <notting> admittedly, that date was pulled out of a hat
18:37:40 <t8m> and as krb5 and samba are critpath due to client libraries and not the daemons, they should be fine to convert before that deadline too
18:38:01 <nirik> more votes ?
18:38:03 <sgallagh> Ok, and what happens to those packages not converted after 2011-10-01?
18:38:13 <nirik> sgallagh: convert in f17
18:38:30 <sgallagh> nirik: Do we still allow them to ship with init scripts in F16?
18:38:41 <t8m> sgallagh, sure
18:39:03 <sgallagh> (I tend to agree, but it does mean we've failed at our full conversion goal)
18:39:07 <nirik> sure, I would think so...
18:39:15 <nirik> sure, but it's not over yet. ;)
18:39:19 <Viking-Ice> that goal was way out of reach
18:39:19 <ajax> all exercise is about failure.
18:40:03 <Viking-Ice> we are at most shipping 1/3 now
18:40:07 <nirik> Viking-Ice: BTW, thanks for pushing this and working so hard on it. spot too. ;) It's appreciated.
18:40:08 * spot notes that his "6" is not the number left to total conversion, just the number i am committing to doing before f16. :)
18:40:28 <sgallagh> Ok, so +1 to notting's proposal
18:41:47 <t8m> If I count that it's +4 (notting, nirik, sgallagh, me) anybody else?
18:42:29 <pjones> yeah, I can be +1 on this.
18:42:31 <ajax> for oct 1?  sure, +1
18:43:37 <spot> also, just to be clear, that includes critpath items samba and krb5?
18:43:43 <nirik> we should possibly mail that to devel-announce to communicate it to maintainers.
18:44:13 <mmaslano> #agreed 2011-10-01 is deadline for conversion of critpath init scripts. Critpath will need exception from FESCo after this date.
18:44:19 * nirik is +1 for those.
18:44:30 <notting> wait, the 2011-10-01 i proposed was for *all*
18:44:40 <notting> if we want critpath to be different, we can
18:44:49 <notting> but i would propose none after that date
18:45:05 * spot is fine with that
18:45:14 <nirik> yeah.
18:45:17 <mmaslano> ok, I hope undo works
18:45:20 <mmaslano> #undo
18:45:20 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x193f876c>
18:45:42 <ajax> i'm still +1
18:45:55 <mmaslano> #agreed 2011-10-01 is deadline for conversion of init scripts. Exception from FESCo will be needed after this date.
18:46:20 <t8m> fine
18:47:11 <nirik> fine with me. nothing else here...
18:47:17 <mmaslano> who will send an email to announce?
18:48:03 <mmaslano> ok, I'll do it
18:48:14 <mmaslano> anything else for open floor?
18:48:25 <nirik> thanks mmaslano
18:48:28 * nirik has nothing
18:48:31 <kalev> sgallagh, notting: you were toying with the idea to change the systemd triggers to also keep the previous init script state as reported by chkconfig
18:48:33 <ajax> nothing from me
18:48:39 <kalev> is there enough time for the FPC to discuss that and to get all packages changed before F16 final freeze? Changing the triggers in F17 doesn't make much sense any more, because the triggers will have already run for updaters in F16.
18:49:39 <sgallagh> kalev: Realistically? Probably not. It would require a lot of post-beta changes, unfortunately.
18:51:21 <t8m> it's too late for that
18:52:27 <sgallagh> kalev: I'd like to discuss it for allowing those who are interested to do it, but making a large change of that nature is out of scope at this time.
18:52:49 * nirik would suggest bringing it up to FPC?
18:52:53 <sgallagh> I have to leave now.
18:52:55 <mmaslano> sgallagh: kalev: I suppose this is good question for FPC or our next meeting
18:53:15 <mmaslano> kalev: feel free to create ticket for next week if you want to
18:53:18 <sgallagh> mmaslano: Assign me an action item to raise it on the packaging list (I'll do so tomorrow)
18:53:22 <kalev> Yeah, I just wanted to point out that if you want to bring it to FPC, it should get discussed this week or there's really no time at all left
18:53:44 <sgallagh> kalev: I think if FPC approves it, it falls under the same 2011-10-01 deadline
18:54:21 <mmaslano> #action sgallagh will raise question about changing systemd triggers on the packaging list
18:54:45 <mmaslano> thank you all
18:54:54 <mmaslano> #endmeeting