17:00:23 <jds2001> #startmeeting FESCo meeting 20091120
17:00:23 <zodbot> Meeting started Fri Nov 20 17:00:23 2009 UTC.  The chair is jds2001. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:26 <jds2001> #chair dgilmore dwmw2 notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler
17:00:26 <zodbot> Current chairs: Kevin_Kofler dgilmore dwmw2 j-rod jds2001 nirik notting sharkcz skvidal
17:00:39 <jds2001> nirik: gimme 2 seconds past 17:00 :D
17:00:40 * nirik is here.
17:00:40 <Kevin_Kofler> #meetingname fesco
17:00:40 <zodbot> The meeting name has been set to 'fesco'
17:00:41 * skvidal is here
17:00:47 <Kevin_Kofler> Present.
17:00:50 <nirik> jds2001: sorry. ;)
17:00:57 <jds2001> np
17:01:21 * notting is here
17:02:03 <jds2001> i think we can get started....
17:02:15 <jds2001> #topic linville provenpackager membership
17:02:19 <jds2001> .fesco 274
17:02:20 <zodbot> jds2001: #274 (Linville requests "provenpackager" membership) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/274
17:02:22 <jds2001> +1
17:02:24 <skvidal> +1
17:02:29 <Kevin_Kofler> +1
17:02:36 <nirik> +1 from me. He does good work and has a good rationale.
17:02:37 * sharkcz is here
17:02:37 <notting> feedback was positive on the list - +1
17:02:40 <sharkcz> +1
17:02:41 <Kevin_Kofler> He clearly knows what he's doing. :-)
17:02:41 <j-rod> +1
17:02:43 * j-rod here now
17:03:12 <jds2001> #agreed Linville provenpackager membership is approved
17:03:23 <jds2001> #topic packagekit fiasco
17:03:26 <jds2001> .fesco 277
17:03:27 <zodbot> jds2001: #277 (what to do about the default user-can-install-pkgs policy kit setting for package kit) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/277
17:03:37 <jds2001> this has been pretty much decideded
17:03:41 <nirik> do we need to do anything here?
17:03:43 <jds2001> anything else on this topic?
17:03:47 <jds2001> dont think so.
17:03:47 <skvidal> yes
17:03:50 <skvidal> I think a lot more
17:03:57 <skvidal> it impacts critpath pkgs and changes
17:04:08 <nirik> right. I would say we should try and get a secuity policy in place that would have things like this reviewed
17:04:44 <skvidal> we need to determine what happens when a package makes a significant change to its behavior and we  are uninformed about it - when the pkg is critpath or default-install critpath
17:04:48 <jds2001> if you look at my blog post, from a security pov i dont see an issue. maybe im being too literal.
17:05:11 <notting> well, i think the ticket itself can be closed. or the subject changed.
17:05:11 <skvidal> jds2001: if you really want to be debate the security impacts of this - we can - but I think I can suffice to say I disagree with you
17:05:20 <Kevin_Kofler> If your argument is that local users can just boot into single user mode anyway, then let's do away with all the password prompts and just run everything as root.
17:05:29 <Kevin_Kofler> There's a reason we don't do that.
17:05:42 <skvidal> let's not debate security impact
17:05:43 <jds2001> Kevin_Kofler: that of course is absurd :D
17:05:51 <nirik> I think there are risks, all be them small.
17:05:57 <skvidal> let's only discuss significant behavior change
17:06:03 <jds2001> sounds good.
17:06:07 <Kevin_Kofler> jds2001: But it follows from your argument, ergo your argument is wrong. :-)
17:06:07 <skvidal> does anyone disagree that this is a significant behavior change?
17:06:08 <nirik> skvidal: so, what can we do?
17:06:26 * nirik does not. It clearly is.
17:06:45 <skvidal> nirik: I think we may need to talk about eval'ing changes to critpath pkgs independent of their association with a feature
17:06:57 <jds2001> skvidal: nope, no disagreement here
17:07:05 <Kevin_Kofler> I think the decision which they made is the right one (though what about updates? Are those still allowed without password prompts? Is that a good or a bad thing?)
17:07:08 <skvidal> and - to be clear -  I think we may want to consider making it law that owners of critpath pkgs have to hold themselves to a much different standard
17:07:11 <nirik> skvidal: ok, how can we do that though? there are lots of them.
17:07:21 <jds2001> Kevin_Kofler: updates never have been.
17:07:30 <nirik> Kevin_Kofler: they are allowed.
17:07:37 <nirik> jds2001: ?
17:07:40 <jds2001> nirik: they are?
17:07:42 <skvidal> nirik: the only way we can do anything. Hold them back until we get a sign off by the maintainer
17:07:54 <jds2001> i was under the impression they werent. my bad.
17:08:00 <skvidal> nirik: the biggest problem we ran into here was insufficient documentation and communication
17:08:02 <notting> sorry, be back in ~2 minutes
17:08:16 <jds2001> skvidal: 1000% agreed.
17:08:20 <skvidal> and after that
17:08:22 <Kevin_Kofler> That said, I really don't see why the PolicyKit and PackageKit folks don't want to support "remember authorization" anymore, IMHO that was the best solution.
17:08:22 * nirik is pretty sure they are. But I think they were in f11 as well, so thats not really a behavior change.
17:08:24 <skvidal> too little responsibility taken
17:08:29 <Kevin_Kofler> Now we're at the other extreme, where people have to enter the password all the time.
17:08:48 <nirik> skvidal: agreed on that.
17:08:51 <Kevin_Kofler> It's definitely better than "blanket allow", but I don't think it's the best ultimate goal.
17:09:05 <skvidal> the purpose of having the maintainer signoff that there are no significant behavior changes - is so we have a paper trail and, ultimately, an incident path
17:09:06 <basr> The flag that was allowing that has been removed from policykit
17:09:11 <nirik> how can we get maintainers to note these things, without massive slowdown to the entire distribution?
17:09:24 <skvidal> okay - let's stop discussing the technical specifics of the pk
17:09:26 <Kevin_Kofler> basr: Right, that's what I'm complaining about.
17:09:37 <Kevin_Kofler> That said, PackageKit could support this without PolicyKit support if it really wanted to.
17:09:43 <Kevin_Kofler> (I outlined a way to do this.)
17:09:46 * nirik nods. We should look at this in general. Nothing specific can help right now.
17:09:46 <jds2001> Kevin_Kofler: i think we're done talking about this specific thing, and have moved on to more general "large behavioral changes in critpath packages by surprise"
17:10:09 <skvidal> nirik: I don't want them to talk deeply - I just want them to submit a notice of behavior changes
17:10:13 <Kevin_Kofler> Another problem I've seen is the maintainer's initial attitude.
17:10:28 <Kevin_Kofler> Well, "the maintainers'" attitude, really.
17:10:29 <skvidal> nirik: if they've kept to the api and not broken things - then it is easy - they submit 'no changes' and sign off
17:10:51 <nirik> skvidal: ok, so in stable releases we could add a checkbox to bodhi. However, what happens for rawhide?
17:10:56 <skvidal> nirik: until they've signed off - we don't go anywhere
17:10:58 <jds2001> skvidal: submit to where? do we have infrastructure for this?
17:10:58 <Kevin_Kofler> davidz's "it's not my fault, leave me alone" reaction (when he was the one who removed the option from PolicyKit 1) was no good either.
17:11:04 <nirik> (which is the only place really that it should be breaking abi/behavior)
17:11:12 <dgilmore> skvidal: significant behavioural changes in any package should be well documented
17:11:21 <skvidal> jds2001: it's the same thing we're talking about for keeping rawhide  and the distro unbroken
17:11:23 <dgilmore> crit-path more so than the rest
17:11:36 <skvidal> jds2001: critpath pkgs require extra dilligence
17:12:02 <skvidal> if the maintainers don't want to do that work, then they need to find other pkgs to maintain
17:12:15 <skvidal> and if no one wants to do that work for that pkg then I think fedora is better off w/o that pkg
17:12:18 <jds2001> sure, of course they do - I'm just wondering how to enforce the signoff of "the behavior didnt change"
17:12:24 <nirik> perhaps we could have maintainers note in changelog: "- ABI or Significant behavior change in this version"
17:12:26 <jds2001> is that part of rel-eng or QA?
17:12:41 <Kevin_Kofler> skvidal: What if nobody wants to do that work for the kernel? ;-)
17:12:42 <skvidal> jds2001: it's a little of both - but, ultimately, it is probably part of  autoqa
17:12:43 <Kevin_Kofler> Or glibc?
17:12:46 <notting> the way you do this is with autoqa
17:12:55 <skvidal> Kevin_Kofler: we'll cross that bridge if/when we come to it
17:12:57 <skvidal> notting: right
17:13:01 <notting> which can tell you if new suid binaries are added, the policy for polkit changes, or similar things
17:13:04 <abadger1999> Kevin_Kofler: Can I sum up that concern as -- we have a paper trail but, how do we use that to change the behaviour of the person who is accountable in the end?
17:13:04 <nirik> would autoqa have caught the specific thing in this case?
17:13:13 <skvidal> nirik: no.
17:13:22 <jds2001> how can autoqa catch a behavior change?
17:13:22 <notting> well, it didn't exist at the time :)
17:13:30 <jds2001> it catches config file changes i guess.
17:13:45 <skvidal> jds2001: it can't - but it can say 'pkg X changes, are these changes stated to be non-behavioral'
17:13:46 <jds2001> but that's useless if you change the behavior of the code
17:13:46 <nirik> config files change all the time...
17:13:57 <notting> jds2001: there was no code change here
17:14:01 <skvidal> jds2001: what we're looking for is the maintainer saying "No, this is not going to break your stuff"
17:14:19 <dgilmore> autoqa could trigger a extra check if we tracked file changes and the file layout changed greatly
17:14:21 <skvidal> jds2001: or "yes, this could be a big deal"
17:14:28 <dgilmore> or even if files were added and removed
17:14:30 <skvidal> let's not worry about automating the checks.
17:14:33 <notting> but i'm still not sure how this helps if there aren't some sort of guidelines as to how to organize things by default
17:14:55 <Kevin_Kofler> Changing a PolicyKit default policy doesn't require adding or removing any file.
17:15:00 <Kevin_Kofler> Your check won't catch this.
17:15:12 <dgilmore> skvidal: :) the maintainers need to speak up when behaviour changes greatly
17:15:19 <nirik> wouldn't it be easier to make it a negative default?
17:15:29 <skvidal> nirik: it would be.
17:15:29 <Kevin_Kofler> Moreover, in this case, it'd just have caught that things got ported to PolicyKit 1, the related behavior changes would have went unnoticed.
17:15:31 <notting> given the check hasn't been written yet, i don't think you can conclusively state what it won't do
17:15:32 <jds2001> Kevin_Kofler: it catches md5 changes in the config files :)
17:15:32 <nirik> ie, anytime behavior _does_ change, note it.
17:15:35 <jds2001> go look at the code :)
17:15:54 <skvidal> nirik: anytime the pkg is updated. yes
17:15:55 <Kevin_Kofler> People already knew that things were being ported.
17:16:03 <notting> jds2001: <bikeshed> wrong hash! </bikeshed>
17:16:03 <Kevin_Kofler> But nobody expected such a big change in the default policy.
17:16:06 <skvidal> hell, we could do it in cvs if we desperately needed to
17:16:08 <basr> I think part of the problem is that this developer /did/ know this would change behavior and didn't care
17:16:09 <drago01> can someone define "significant behavior changes" ?
17:16:18 <nirik> the questions I have are: how do they note this? who do they note it to? We should make it easy so as not to slow down things with red tape.
17:16:20 <skvidal> drago01: doesn't matter
17:16:22 <jds2001> notting: :)
17:16:31 <skvidal> nirik: I WANT to slow things down
17:16:39 <skvidal> nirik: this problem is due to lack of communication and haste
17:16:51 <drago01> skvidal: sure it does ... if you need this process for almost every change it does not scale
17:16:56 <jds2001> for critpath i agree with skvidal
17:16:57 <nirik> skvidal: no. this change was made long ago... not really last minute and hasty
17:17:03 <skvidal> drago01: for critpath changes
17:17:06 <Kevin_Kofler> basr: That, and almost nobody else knew about it.
17:17:18 <skvidal> nirik: haste is what caused no one to mention it or bring it up
17:17:18 <EvilBob> basr: one could say they did know, knew what the response would be so they kept quiet about it?
17:17:26 <notting> the maintainer is already giving his implicit seal of approval by building the package. i'm not sure an additional 'are you sure' is help
17:17:33 <Kevin_Kofler> Maybe some of the GNOME people from the RH Desktop Team knew, but they didn't tell anybody.
17:17:37 <notting> EvilBob: well, if you want to match your nickname, sure
17:17:41 <skvidal> notting: the additional 'are you sure' is not about will it build
17:17:56 <nirik> skvidal: it was not very apparently until after release. I don't think it was haste. ;)
17:17:59 <skvidal> notting: the 'are you sure' is about is this going to surprise people
17:18:04 <jds2001> EvilBob: i dont attribute this at all to malice.
17:18:36 <Kevin_Kofler> skvidal: But it won't help.
17:18:42 <nirik> anyhow, I think it's a good idea to get maintainers of critpath packages to note when exactly they make significant behavior changes in their packages.
17:18:44 <Kevin_Kofler> Because the maintainer WAS sure about what he was doing.
17:18:44 <skvidal> won't help WHAT? the point is notification
17:19:01 <skvidal> it's not about them being SURE
17:19:05 <skvidal> it's about behavior changes
17:19:09 <nirik> skvidal: would you be willing to write up a proposal for us? I don't think there is anything we can agree on right now without details?
17:19:09 <jds2001> Kevin_Kofler: notification to ppl other than the maintainer, to be clear.
17:19:17 <skvidal> even the maintainer acknowldges that this is a significant change
17:19:17 <notting> skvidal: no frozen rawhide intends to work via bodhi. so, we already have a mechanism for this, more or less
17:19:27 <skvidal> notting: indeed
17:19:36 <dgilmore> I think that they looked at one target thought it would be o for that and did not consider any target market outside if that.  but i dont think it was malicious in intent
17:19:37 <nirik> notting: thats only later in the cycle tho isn't it? or is that always?
17:19:56 <notting> nirik: it's after the feature freeze, as it's currently written
17:20:10 <nirik> notting: right, so it could change a bunch before that and not use that method.
17:20:13 <Kevin_Kofler> dgilmore: Of course not, rhughes is not out to backdoor our machines! ;-)
17:20:54 <Kevin_Kofler> The intent isn't the problem, the result and the initial reactions to the complaints are.
17:20:59 <skvidal> nirik: I can write up something, yes.
17:21:01 <notting> nirik: that's why i'd like an autoqa mechanism better. note the changes, log them, publish them
17:21:13 <jds2001> skvidal: cool
17:21:20 <nirik> notting: yeah, we shouldn't have a window where it's not noted.
17:21:22 <skvidal> all I really want to bring up here
17:21:48 <skvidal> is that fesco is comfortable that critpath and desktop-critpath pkg maintainers  will require more work
17:22:02 <dgilmore> skvidal: im fully ok with that
17:22:09 <jds2001> #action skvidal will write up a proposal for notification of major behaviroal changes in critical path packages
17:22:12 <jds2001> skvidal: i am too
17:22:14 <nirik> skvidal: I think thats reasonable. We might also ask them to sign up more co-maintainers if they feel the work is more.
17:22:22 <notting> well, obviously depends on what that 'more work' is, but sure
17:22:45 <notting> jds2001: should we close the original ticket?
17:22:51 <jds2001> anyhow, anything more here or shall we move on? I think we've exhausted this topic for now.
17:22:54 * nirik thinks so.
17:23:04 <dgilmore> jds2001: i think its exhausted
17:23:05 <jds2001> notting: yeah
17:23:08 <skvidal> one more thing
17:23:14 <skvidal> I'd like to take a straw poll on something
17:23:25 <jds2001> go for it
17:23:33 <Kevin_Kofler> jds2001: I think we really need to discuss the attitude issue.
17:23:48 <skvidal> if the pkg had not been patched today. Who here would have been in favor of patching to require root auth to install signed pkgs?
17:23:51 <Kevin_Kofler> The initial reactions to the complaints were outright arrogant.
17:23:52 <skvidal> +1
17:24:05 <dgilmore> skvidal: +1
17:24:06 <EvilBob> +1
17:24:08 <jds2001> 0
17:24:08 <sharkcz> +1
17:24:11 <nirik> skvidal: I would have voted to revert the behavior.
17:24:24 <basr> +1
17:24:33 <skvidal> EvilBob, basr: you're not on fesco, please don't do that
17:24:40 <basr> Sorry
17:24:43 <jds2001> Kevin_Kofler: not much we can change about that.
17:24:53 <Kevin_Kofler> skvidal: +1, I'd have voted for that too.
17:25:02 <skvidal> notting:?
17:25:14 <nirik> Kevin_Kofler: yeah, what would you expect to be done there?
17:25:18 <skvidal> j-rod:? dwmw2?
17:25:19 <abadger1999> jds2001: really, there is... but fesco would have to be willing to do it.
17:25:19 <notting> skvidal: i don't think it's necessarily appropriate behavior for the package collection as a whole. i'm fine with it as a spin-specific configuration
17:25:31 * dwmw2 here
17:25:39 <skvidal> notting: would you have voted to change the behavior?
17:25:48 <skvidal> dwmw2: ?
17:25:55 <skvidal> would you have voted to change the behavior?
17:25:58 <dwmw2> I'd have voted to change the behaviour
17:26:01 <dwmw2> sorry I'm late
17:26:07 <skvidal> dwmw2: it's okay
17:26:10 <notting> skvidal: did i not just say so?
17:26:11 <Kevin_Kofler> That said, IMHO there needs to be a way to remember authorizations, I don't care if it's done in PolicyKit, in the auth agent or in PackageKit. I think that feature addressed the "single user desktop" usecase (which this ill-fated policy tried to address) perfectly.
17:26:17 * nirik thinks that they were bad attitude on many folks part here.
17:26:21 <jds2001> abadger1999: fesco can change personalities?
17:26:24 <dwmw2> anyway, it's done now
17:26:32 <skvidal> okay. we have a quorum - that's what I wanted to check on
17:26:33 <jwb> well, it's getting done
17:26:33 <skvidal> thanks
17:26:37 <jwb> it's not available yet
17:26:37 <notting> Kevin_Kofler: that's an issue for policykit upstream, and i think *very* irrelevant for fesco
17:26:41 <abadger1999> jds2001: reprimands, forced takeover of package, stripping of package maintainer rights... the problem is that fesco doesn't have a lot of middle ground options, only big gun options.
17:26:53 <jds2001> yeah :(
17:27:00 <Kevin_Kofler> notting: PackageKit can remember policies on its own.
17:27:07 <notting> and, well, if we did that every time someone showed bad attitude, we'd have a lot of FESCo members missing packages
17:27:12 <dwmw2> we _do_ have middle ground options. We can express a sternly worded opinion. But people will just ignore it :)
17:27:14 <jwb> i think you guys are focusing a bit too much on the specifics
17:27:20 <notting> Kevin_Kofler: again, an upstream discussion, IMO.
17:27:21 <Kevin_Kofler> It can be done at application level, in the privileged helper.
17:27:25 <jds2001> anyhow, let's move on
17:27:32 <adamw> +1 for jwb - i think what needs to be discussed here is an appropriate process/policy level response
17:27:33 <nirik> abadger1999: right.
17:27:41 <adamw> what needs to be changed in fedora policies + processes so this doesn't happen again
17:27:50 <jwb> right
17:27:51 <nirik> abadger1999: basically nothing (yelling at them) and then removing privs... nothing in the middle
17:28:06 <nirik> adamw: we just discussed that... ;)
17:28:08 <jds2001> adamw: and skvidal is going to be drafting something to that effect.
17:28:09 <dwmw2> adamw: I don't think it's something that can be "fixed" in that way.
17:28:13 <adamw> nirik: well i read it, but it seems to have petered out
17:28:24 <adamw> i can wait for skvidal to draft something though. :)
17:28:34 <jds2001> #topic intellij IDEA
17:28:39 <jds2001> .fesco 272
17:28:40 <zodbot> jds2001: #272 (Intellij IDEA - https://fedoraproject.org/wiki/Features/IntelliJ_IDEA) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/272
17:28:42 <abadger1999> dwmw2: I was thinking more like: mandatory "getting along with customers" training sessions, etc.
17:28:42 * lkundrak here
17:28:50 <Kevin_Kofler> Maybe at least the "yelling at them" part should be tried? ;-)
17:28:56 <dwmw2> abadger1999: "How to avoid promoting an attitude of violence" ?
17:29:08 <j-rod> sorry, got distracted...
17:29:15 <abadger1999> (When thinking of thingswe don't have the ability to do) -- yep.  as a training session :-)
17:29:19 <notting> dwmw2: i think you'd have to write that
17:29:35 <abadger1999> Would attend the dwmw2 class for sure :-)
17:29:36 <notting> *anyway*, IDEA.
17:29:38 <jds2001> anyhow....
17:29:39 * lkundrak has a cheatsheet, sort of https://fedoraproject.org/wiki/Talk:Features/IntelliJ_IDEA
17:30:17 <jds2001> cool :)
17:30:23 <jds2001> open sourcing closed stuff is good
17:30:42 <jds2001> but I searched for IDEA and found that I could pay $600 or so for it.
17:31:03 <lkundrak> the community edition is licensed under ASL 2.0 license
17:31:07 <jds2001> is this more like a "core/enterprise" type business model.
17:31:08 <jds2001> ?
17:31:13 <Kevin_Kofler> Looking at the polls, it appears to be the third most popular Java IDE despite having been proprietary and expensive so far.
17:31:21 <Kevin_Kofler> So it does have potential.
17:32:40 <Kevin_Kofler> I think promoting this as a feature, emphasizing the fact that it's newly Free Software ("Freedom") and that we're right there to ship it ("First"), is a good idea.
17:32:56 <jds2001> if we're the first major distro to ship IDEA, it's a good feature
17:33:02 <dgilmore> i think im +1 for this,  in part to maybe attract new users and in part to say look its great when you open source your code base
17:33:03 <Kevin_Kofler> On the other hand, is the Community Edition fully featured or is it some sort of crippleware?
17:33:20 <notting> so, essentially, this is like the old mysql?
17:33:34 <Kevin_Kofler> (I hate those "open source releases" which are basically demo versions for the proprietary "enterprise" version.)
17:33:49 <jds2001> old? I thought mysql still had that business model.
17:34:10 <dwmw2> demo for oracle? :)
17:34:13 <nirik> I think I am +1 as well... first and helping distribute newly freed stuff is part of our mission. I think advertising it as a feature is good as it will get notice that it's out there and that Fedora is bringing it along first.
17:34:14 <notting> oracle has many business models :)
17:34:38 <nirik> lkundrak: adding a Whiteboard "Featurereview" or something (coordinate with tibbs ?) might be good. That can make sure they all get reviewed in time.
17:34:56 <Kevin_Kofler> lkundrak: How fully featured is the Community Edition?
17:34:59 <dgilmore> Kevin_Kofler: http://www.jetbrains.com/idea/nextversion/editions_comparison_matrix.html
17:34:59 <notting> "Briefly, in the free Community Edition you’ll get all the Java code support — various refactorings and code inspections, coding assistance; debugging, TestNG and JUnit testing; CVS, Subversion and Git support; Ant and Maven build integration; and Groovy and Scala support (through a separate plugin)."
17:34:59 <lkundrak> nirik: you mean in bugzilla?
17:35:02 <jds2001> or have a master bug for the feature
17:35:15 <nirik> lkundrak: yes
17:35:32 <notting> that sounds reasonable enough to me. +1
17:35:40 <jds2001> +1
17:35:42 <sharkcz> +1
17:35:54 <nirik> a common term for whiteboard that marks any reviews needed for features would be better than a blocker, IMHO
17:35:55 <dwmw2> +1
17:35:56 <Kevin_Kofler> dgilmore: Hmmm, that looks a lot like crippleware. :-(
17:35:58 <tibbs> Some observations from a package review guy:
17:36:04 <Kevin_Kofler> Do we really want to promote this business model?
17:36:07 <skvidal> +1, provided the feature set doesn't diminish after it gets in
17:36:16 <tibbs> Blocker bug is good; I can generate a separate report from it.  Whiteboard is OK as well.
17:36:33 <notting> hm
17:36:33 <tibbs> I don't know how many packages there are, but it's in java and that means two things:
17:36:40 <lkundrak> Kevin_Kofler: it's obviously targetted at JVM developers, mostly the "poor open source developer" ones I'd guess. fully featured are scala/groovy/java support. what's missing is support for rails and other frameworks, which is rather popular, to admit
17:36:46 <dwmw2> the community edition is better than the "ultimate" one. It doesn't work with VSS
17:36:47 <tibbs> The review pool for java is much smaller.
17:36:48 <dwmw2> or Perforce
17:36:53 <dgilmore> +1 from me. but we should keep tabs that it doesnt lose features
17:37:02 <lkundrak> Kevin_Kofler: lots of useful open source plugins available though
17:37:02 <notting> however, whatever we ship shouldn't have things like "go here to upgrade now"
17:37:04 <notting> etc.
17:37:05 <tibbs> Java packages tend to be difficult to review because of all the embedding of other code that goes on.
17:37:25 <lkundrak> Kevin_Kofler: it might be that jetbrains open source some more, or community adds ones, but I'd rather not rely on it
17:37:30 <tibbs> So please give us as much time as possible, and if you want to cram 40 packages through the review process you almost certainly won't make it before F13.
17:37:41 <Kevin_Kofler> -1, the community edition appears to be intentionally crippled, IMHO we shouldn't advertise that stuff.
17:37:50 <jds2001> #agreed IntelliJ IDEA feature is accepted for F13
17:38:31 <jds2001> #topic better hostname
17:38:32 <nirik> lkundrak: there isn't any nagware junk in it is there?
17:38:41 <jds2001> .fesco 278
17:38:41 <lkundrak> tibbs: we the core is mostly packaged, and feature team of more than one person guarrantees that there's someone to review. moreover the java packages seem to be pretty demanded, so people grab those reviews quickly
17:38:44 <zodbot> jds2001: #278 (Better Hostname - https://fedoraproject.org/wiki/Features/BetterHostname) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/278
17:38:48 <lkundrak> nirik: what's nagware?
17:38:59 <skvidal> lkundrak: "you should upgrade"
17:39:01 <notting> lkundrak: "please buy the Enterprise Edition!"
17:39:02 <Kevin_Kofler> The big problem with that sort of crippleware is that if the community wants to implement those features, they'll get rejected because they're intentionally not supported. :-/
17:39:02 <skvidal> every 10 minutes
17:39:05 <nirik> lkundrak: it doesn't pop up or say "please download the pay version"
17:39:11 <notting> although i think there's already a guideline for that
17:39:20 <tibbs> lkundrak: Your definition of "quickly" must differ from mine, given the java packages that sit around for months with no reviewer.
17:39:23 <lkundrak> there's none, I'm quite sure, I've run that thing for some time.
17:39:45 <nirik> lkundrak: great.
17:39:59 <dwmw2> BetterHostName seems like a good idea, but can we please make sure that we don't lose the ability to look at the login screen and know the machine's IP address?
17:40:00 <jds2001> cool
17:40:13 <Kevin_Kofler> And people are also not motivated to write code which exists and is just being withheld for political/business reasons.
17:40:17 <dwmw2> I often look at the login prompt and then ssh in.
17:40:23 <Kevin_Kofler> So those features are likely to never come.
17:40:30 <tibbs> I'll go ahead and add a separate report for packages marked with FeatureReview in the whiteboard.
17:40:33 <dwmw2> jds2001: is the cacert thing on the agenda, btw?
17:40:45 <jds2001> dwmw2: i thought so
17:40:52 <jds2001> maybe i forgot
17:40:59 <Kevin_Kofler> Re BetterHostname, this thing calls itself "xdg", but is very much GNOME-specific.
17:41:08 <Kevin_Kofler> I see no effort to integrate it with KDE whatsoever in the feature plan.
17:41:11 <jds2001> i guess not :(
17:41:16 * dgilmore doesnt understand this feature at all
17:41:24 <nirik> yeah, it's very gnome specific it seems.
17:41:25 <dgilmore> maybe because i use KDE and not gnome
17:41:36 <dgilmore> but i dont get what it is trying to achieve
17:41:42 <notting> dgilmore: 'being able to present a hostname to the user that's not dhcp241124.az.rr.com, without breaking thigns'
17:41:46 <nirik> it's a way to display a nice "My computer named Bob" in your file manager, etc it seems
17:42:15 <wwoods> AFAICT none of it is actually GNOME-specific. The KDE implementation/changes are left out, for the KDE SIG/devs to fill in.
17:42:22 * nirik notes Thunar (Xfce file manager) should be going to GIO, so in theory it could use this, but that will be in 4.8
17:42:40 <dgilmore> notting: like a secondary name for a computer?
17:43:01 <jds2001> something of the sort, yeah
17:43:01 <Southern_Gentlem> sorry one word for this is bloat
17:43:07 <dgilmore> "Dennis's Desktop"
17:43:12 <notting> dgilmore: a persistent name, if you will
17:43:12 <dgilmore> or something like that?
17:43:15 <wwoods> there's a *plan* to support the (DE-neutral) service in GNOME. Nothing about that excludes there being a KDE implementation.
17:43:38 <nirik> it also seems to plan to write to /etc/hostname, etc... so you could use it for other things command line, etc.
17:43:42 <dgilmore> notting: we have that now.  its stored in /etc/sysconfig/network
17:43:46 <wwoods> so the plan as listed is "GNOME-specific", yes, but the service/feature is desktop-neutral
17:43:46 <Kevin_Kofler> I see this as a pretty much pointless gimmick.
17:44:11 <skvidal> notting: help me understand something
17:44:24 <skvidal> when I set my hostname in anaconda to 'mylaptop'
17:44:34 <skvidal> it says that when I login and at the prompt
17:44:44 <skvidal> independent of what my ip address/hostname  is
17:44:51 <skvidal> where is this otherwise?
17:45:02 <dgilmore> grep HOST /etc/sysconfig/network
17:45:02 <dgilmore> HOSTNAME=pegasus.ausil.us
17:45:28 <jds2001> yeah im not sure what this is.
17:45:30 <Kevin_Kofler> KDE doesn't really display a hostname outside of KDM at all.
17:45:40 <jds2001> does it somehow expose this other hostname outside the local machine?
17:45:48 <nirik> so this replaces the network / hosts version?
17:45:58 <wwoods> it would probably help if you bothered to actually read the documentation.
17:45:59 <nirik> or its alongside it?
17:46:08 <skvidal> wwoods: can the attitude. thanks.
17:46:11 <dgilmore> right now im -1 on this feature.  we can revisit if they have some tangiable useful extra information to provide
17:46:12 <wwoods> "It is important to understand that the display hostname and hostname are different on a conceptual level; many of the the observations in section 4.4 of the DNS-SD Draft applies here."
17:46:18 <Kevin_Kofler> I don't quite see the point of saying "Tony's Computer" instead of "My Computer" or "This Computer" on the machine itself.
17:46:34 <notting> "Compared to the traditional hostname (which normally conforms to section 3.5 of RFC 1034  with the hostname being a label: 7 bit ASCII without special characters, whitespace or dots) the display hostname is UTF-8. "
17:46:53 <dwmw2> can't the traditional hostname be IDN now?
17:47:01 <dwmw2> we should make sure we get _that_ right
17:47:20 <Kevin_Kofler> dwmw2: Right.
17:47:31 <Kevin_Kofler> I'm pretty sure there are many issues lurking with that.
17:47:33 <dwmw2> that would seem to be sufficient to render this feature unnecessary, right?
17:47:37 <Kevin_Kofler> And they should be fixed.
17:47:45 <wwoods> okay but now you're drafting an *alternate* specification to implement this feature
17:47:46 <dwmw2> IDN is a bit of a clusterfuck all round really.
17:48:00 <dwmw2> wwoods: nah, we're just saying "no" :)
17:48:01 <abadger1999> wwoods: Where does the mapping get done?  Locally or is it advertised by the remote computer?
17:48:01 <dwmw2> -1
17:48:10 <dgilmore> -1
17:48:34 <notting> +1
17:48:36 <wwoods> abadger1999: both.
17:48:43 * nirik is not against the idea, but is still trying to see the impacts.
17:48:44 <jds2001> so i guess we need to clarify what '-1' means in this context.
17:49:07 <jds2001> generally, it means that we dont advertise it as a feature
17:49:09 <dwmw2> jds2001: I mean it as "I don't see the point. If we fix stuff so that IDN works, now tell me what the point is"
17:49:23 <skvidal> abadger1999: In the hostname editing dialog, change the display hostname and icon. Verify that this change is reflected in services that advertised via DNS-SD such as file sharing, remote desktop sharing and DAAP music sharin
17:49:24 <wwoods> dwmw2: I don't think you actually understand the point of the feature.
17:49:40 <dwmw2> wwoods: you're right.
17:49:44 <wwoods> "Hostname data is defined to include more than just the regular hostname, it also includes a display hostname, an icon and possibly more items in the future. Hostname data is usually a user preference and is stored in a persistent local database."
17:50:05 <wwoods> the hostname of my system can stay whatever the DHCP admin wants it to be - dhcp-xxx-yyy
17:50:25 <dwmw2> so it's a pretty UTF-8 "Computer Name", not hostname
17:50:26 <wwoods> but this service allows me to change e.g. the machine name used in DNS-SD queries
17:50:35 <jds2001> +1
17:50:47 <jds2001> and you also get an icon and things like that :)
17:51:07 <dwmw2> doesn't sound entirely insane, when you explain it like that. Is it really a _feature_
17:51:10 <dgilmore> wwoods: i find that to be in bad taste. what if 10 janes on a corporate network set there machine to be "Jane's Computer"
17:51:11 <skvidal> so this is appletalk name broadcast
17:51:24 <dgilmore> skvidal: seems so
17:51:27 <Kevin_Kofler> I'm unhappy with the way the "xdg" namespace is being abused here, but I guess that's an issue for upstream fd.o, not for us.
17:51:33 <wwoods> skvidal: similar, but it's the DNS-SD specification
17:51:59 <wwoods> see e.g. http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt
17:52:02 <skvidal> nod
17:52:06 <notting> skvidal: you know, i've tried to bury what knowledge i have of zones
17:52:18 <skvidal> if we reject this feature
17:52:23 <wwoods> so this is an IETF-targeted standardized form of that sort of nicety
17:52:23 <skvidal> are we just going to get it stuck in anyway
17:52:24 <Kevin_Kofler> dgilmore: You have a good point there.
17:52:27 <skvidal> without any approval?
17:52:40 <Kevin_Kofler> There's a reason DCHP hostnames are autogenerated to be unique.
17:52:42 <skvidal> wwoods: "nicety" is hardly the word I used for appletalk broadcasts
17:52:43 <jds2001> skvidal: that's why i said we need to define what '-1' means
17:52:44 <abadger1999> wwoods: How does the service keep a mapping consistent?  For instance if two remote locations decide to advertise as "Secure Network Storage"  Is there conflict resolution or what?
17:52:47 <rdieter> Kevin_Kofler: +1 the xdg thing, but it does reflect poorly on fedora by promoting it
17:52:55 <wwoods> they aren't hostnames, is the point
17:52:57 <dwmw2> skvidal: probably. The feature process has always been a bit odd like that; we're deciding whether it's something to shout about in the release notes, not whether we should _do_ it or not
17:53:02 <notting> skvidal: is there really strong objection on the grounds of 'you should not do this'?
17:53:05 <sharkcz> using hostname in this context is confusing, "Computer Name" would be IMHO better, but +1 to the feature
17:53:07 <wwoods> they act more like TXT records
17:53:10 <skvidal> notting: I have a couple, yes.
17:53:21 <nirik> abadger1999: good point.
17:53:30 <skvidal> wwoods: and for purposes of 'browsing' cause the ambiguity
17:53:31 <wwoods> there's a further mapping for doing service-hostname to .local namespace hostname
17:53:44 <wwoods> which IIRC does its own magic to avoid duplicate hostnames
17:53:48 <wwoods> but again this is all in the docs
17:53:49 <Kevin_Kofler> wwoods: They'll be shown to users instead of hostnames.
17:53:49 <dgilmore> notting: i think we should not do this period
17:54:21 <wwoods> it's all well-documented IETF-tracked standards with long-discussed implementations by people much smarter and beardier than me
17:54:31 <dgilmore> wwoods: doesnt mean its good
17:54:35 <nirik> wwoods: can you point to the conflict resolution methods in this? I can't see it off hand...
17:54:36 <Kevin_Kofler> So if there's a shared file server called "Shared File Server" and I call my machine "Shared File Server" too, people are going to accidentally trust their files to me.
17:54:38 <wwoods> so probably you should trust the docs for implementation details
17:54:44 <skvidal> wwoods: to be clear the IETF has ratified all sorts of crazy
17:54:51 <wwoods> rather than trying to pick apart the feature based on my quick reading thereof
17:55:11 <skvidal> wwoods: and "trust what this other group has done" gets us in a lot of trouble, typically.
17:55:14 <skvidal> okay
17:55:15 <skvidal> so
17:55:18 * nirik would like to defer, and ask about conflict resolution and ability for other desktops to use this.
17:55:27 <notting> nirik: it's a d-bus service
17:55:38 <notting> nirik: that's fairly desktop-neutral
17:55:43 <wwoods> the display hostname is AFAIK only used for service browsing
17:55:56 <jds2001> just because there's no frontend for KDE doesn't mean there *can't* be.
17:56:11 <wwoods> and there's no requirement for unique names there
17:56:11 <notting> jds2001: what's the current tally?
17:56:15 <nirik> yeah, but I thought it used GIO ?
17:56:30 <abadger1999> I'm just worried about security in this setup.
17:56:32 <jds2001> notting: id have to go through scrollback, gimme a sec
17:56:35 <Kevin_Kofler> wwoods: There is if you want your users to know what machine they're trusting their data to.
17:56:43 <notting> nirik: they are adding a gio interface to the dbus service
17:56:52 * dgilmore proposes that until this is fully evaluated we ban it from fedora. it seems to be a road to insanity
17:57:00 <jds2001> 2 +1, 2 -1
17:57:01 <dgilmore> until we can be sure its not we should play it safe
17:57:05 <abadger1999> We talk about DNS poisoning at times... this seems like it would be subject to the same issue.
17:57:08 <nirik> notting: ok.
17:57:16 <wwoods> ...
17:57:21 <jds2001> yeah
17:57:26 <Kevin_Kofler> +1 to dgilmore
17:57:40 <jds2001> let's defer this until we can read it more thouroughly, and figure out about conflicts.
17:57:49 <wwoods> perhaps I wasn't clear. the feature specifies that the "display hostname" is not. used. as. a. hostname.
17:57:55 * nirik is -1 then i guess without more info.
17:57:55 <jds2001> any objections to that?
17:58:02 <wwoods> so any mention of DNS problems here is completely my mistake
17:58:11 <wwoods> this feature has no impact on actual network hostnames.
17:58:16 <Kevin_Kofler> wwoods: But users still get confused.
17:58:18 <nirik> wwoods: correct.
17:58:21 <jds2001> right
17:58:27 <Kevin_Kofler> Because the UI is showing them the display hostname instead of the real one.
17:58:28 <nirik> but it does change advertised services.
17:58:34 <notting> Kevin_Kofler: no.
17:58:35 <jds2001> but what if there are to "Jane's Computer"
17:58:35 <skvidal> wwoods: umm in the testing
17:58:40 <Kevin_Kofler> So social engineering is trivial.
17:58:42 <notting> it shows them the hostname *the other machine advertises*
17:58:49 <skvidal> it says it checks to make sure it is consistent in the DNS-SD advertised information
17:58:55 <notting> that social engineering attack exists today whether or not we do this
17:58:59 <notting> this changes that *not one bit*
17:59:21 <jds2001> anyhow
17:59:32 <jds2001> can we just defer this and move on?
17:59:35 <nirik> notting: what does it do when 2 people advertise the same name?
17:59:45 <dwmw2> jds2001: +1
17:59:49 <sharkcz> jds2001: +1
17:59:51 <wwoods> then you see two things that say "zebes music share"
17:59:59 <notting> nirik: this feature doesn't do anything. i'm fairly sure it's "whatever dns-sd has always done, regardless of this"
18:00:10 <notting> similar to if two netbios servers advertise the same name, etc.
18:00:15 <Kevin_Kofler> wwoods: And then you get confused about which is which.
18:00:25 <dwmw2> jds2001: what's next?
18:00:40 <jds2001> #agreed this feature is deferred until next week, when a more thourough reading of the spec can be accomplished.
18:00:48 <wwoods> Kevin_Kofler: this is already the case, because everyone's systems all say "localhost music share"
18:00:51 <jds2001> dwmw2: i'd like to get to cacert
18:01:00 <dwmw2> jds2001: ok
18:01:01 * nirik nods. ok. Not sure how they can deal with that... but looking and saying 'this is already available, choose another name' might be good.
18:01:09 <jds2001> even though i made a mistake and didnt throw it on the agenda.
18:01:12 <dwmw2> :)
18:01:17 <dwmw2> the cacert thing is relatively simple
18:01:23 <Kevin_Kofler> wwoods: Looks like we need to force getting the hostname from DHCP then.
18:01:24 <jds2001> #topic cacert inclusion in ca-bundle.crt
18:01:24 <dwmw2> we can't ship it enabled by default. not sensibly
18:01:32 <dwmw2> not while cacert themselves are saying "don't"
18:01:33 <Kevin_Kofler> And if they don't assign one, generate one based on the IP.
18:01:35 <jds2001> dwmw2: +1
18:01:40 <dwmw2> but we _should_ be able to do what ubuntu users can
18:01:44 <dwmw2> with update-ca-certificates
18:01:52 <dwmw2> except that ours should actually work
18:01:55 <notting> Kevin_Kofler: you're lolz. anyway, moving on.
18:02:22 <dwmw2> and then we can have a cacert-ca package which is _optionally_ installed and would dtrt.
18:02:25 <dwmw2> job done.
18:02:25 <Kevin_Kofler> notting: Defaulting to "localhost" is just dumb. ;-)
18:02:35 <jds2001> Kevin_Kofler: we've moved on
18:02:42 <nirik> ok, so what action can we take here then?
18:02:45 <nirik> dwmw2: make it so! :)
18:02:46 <tibbs> If only we could actually redistribute the cacert certificates...
18:02:54 <dwmw2> what needs doing?
18:02:59 <Kevin_Kofler> Well, I think we should really ship the CAcert certs, but licensing makes it moot anyway.
18:03:06 <dwmw2> https://bugzilla.redhat.com/show_bug.cgi?id=466626
18:03:07 <buggbot> Bug 466626: medium, medium, ---, jorton, ASSIGNED, Need a simple tool to configure CA certs
18:03:09 * dgilmore thinks having an easy way to add cacerts root cert is good and should be done. we should not include it ourselves
18:03:09 <skvidal> nirik, notting, wwoods: section 3.7 is about name conflict resolution: http://files.dns-sd.org/draft-cheshire-dnsext-nbp.txt
18:03:11 <Kevin_Kofler> So why are we discussing this in the first place?
18:03:13 <jds2001> well, we cant do it as default.
18:03:22 <jds2001> it makes ssl utterly useless if we do.
18:03:36 <jds2001> as joe made very clear.
18:03:38 <Kevin_Kofler> Because you don't have to pay $$$ for your certs? Come on...
18:03:46 <Kevin_Kofler> That SSL cert cartel is a real problem.
18:03:54 <notting> what's the ticket number here?
18:03:57 <jds2001> Kevin_Kofler: would you trust me to say that you are who you say you are?
18:04:00 <dwmw2> Kevin_Kofler: what's the licensing problem
18:04:01 <Kevin_Kofler> But unfortunately, CAcert don't make it easy to provide an alternative with their strange licensing.
18:04:04 <dwmw2> notting: 276 iirc?
18:04:12 <jds2001> .fesco 276
18:04:13 <zodbot> jds2001: #276 (Missing inclusion of CAcert CA certificates into Fedora's ca-bundle.crt) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/276
18:04:13 <jds2001> sorry
18:04:33 <nirik> ok, so -1 to including it from me.
18:04:38 <nirik> (thats what we are voting on, right)
18:04:40 <dwmw2> definitely -1 to including it
18:04:42 <jds2001> -1 here
18:04:43 <sharkcz> -1
18:04:55 <dgilmore> -1 to including cacert
18:05:19 <Kevin_Kofler> Licensing was discussed in https://bugzilla.redhat.com/show_bug.cgi?id=474549
18:05:20 * dgilmore adds he is a cacert assurer and user
18:05:20 <buggbot> Bug 474549: medium, medium, ---, nobody, NEW, Review Request: ca-cacert.org - CAcert.org CA root certificates
18:05:27 <notting> yeah, -1 to including cacert
18:05:31 <skvidal> -1
18:05:32 <dwmw2> proposal: FESCo would like to see bug #466626 fixed, and the new facility proposed as a feature for F13
18:05:32 <jds2001> #agreed CACert root cert will not be included in fedora
18:05:33 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=466626 medium, medium, ---, jorton, ASSIGNED, Need a simple tool to configure CA certs
18:05:43 <jds2001> dwmw2: +1
18:05:49 <dwmw2> +1, obviously
18:05:54 <Kevin_Kofler> https://bugzilla.redhat.com/show_bug.cgi?id=474549#c4
18:05:55 <buggbot> Bug 474549: medium, medium, ---, nobody, NEW, Review Request: ca-cacert.org - CAcert.org CA root certificates
18:06:02 <nirik> dwmw2: sure, but that has no enforcement, unless we assign one of us to do the work, right?
18:06:04 <Kevin_Kofler> We aren't allowed to redistribute CAcert.
18:06:24 <Kevin_Kofler> For the record, I'm -1 to redistributing CAcert now, but would be +1 if they fix their license!
18:06:35 <Kevin_Kofler> I think it's a big mistake to lock users into the commercial SSL cartels.
18:06:44 <nirik> +1 to someone working on 466626. I hope it's a nice f13 feature!
18:06:44 <jds2001> i would be -1 in any event. they say they're not ready.
18:06:46 <dgilmore> +1
18:07:00 <jds2001> the user needs to make a choice here.
18:07:15 <dgilmore> to having a tool to configure ca certs
18:07:19 <dwmw2> CAcert say we aren't allowed to distribute it because they aren't ready :)
18:07:24 <Kevin_Kofler> And +1 to dwmw2, we need an easy way to configure those certs.
18:07:30 <dwmw2> I can make it work for openssl.
18:07:31 <notting> i am... trying to figure what saying +1 to bug 466626 means if no one is *actually* working on it.
18:07:36 <dwmw2> would end up asking for some help on the nss side
18:07:43 <dgilmore> dwmw2: nss is clunky
18:07:49 <dwmw2> dgilmore: very :)
18:07:57 <dwmw2> notting: it's an encouragement :)
18:08:06 <jds2001> notting: i think it's the whole maintainer attitude thing from earlier
18:08:11 <dwmw2> we can go put it on F13tracker :)
18:08:15 <jds2001> :)
18:08:31 <nirik> notting: nothing at all really.
18:08:50 <jds2001> notting: we dont have any guns, but we can ask nice :D
18:08:58 * notting is -1 to the proposal, then. i don't see this as something of enough importance to override the maintainers
18:09:07 <nirik> aren't we using a standard /etc/pki/ area now for all of openssl/gnutls/nss?
18:09:17 <dwmw2> nirik: I don't think nss copes with that
18:09:24 <nirik> sad
18:09:33 <tibbs> Even if it did, there's still a monolithic bundle of certs in thhere.
18:10:00 <dwmw2> notting: override?
18:10:16 <notting> dwmw2: as in stating 'you should go do this'
18:10:33 <jds2001> it's more of a polite request than a requirement :D
18:10:33 <dwmw2> it's not as if the maintainers have said we _shouldn't_ do it.
18:10:46 <dwmw2> and it's more a constructive response to the 'include cacert' request.
18:10:57 <dwmw2> "No, but how about you help do this, and then it'll work out for you"
18:12:10 <jds2001> #agreed it would be nice for someone to work on bug 466626
18:12:11 * nirik doesn't think it matters... the thing we were voting on what including cacert.
18:12:11 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=466626 medium, medium, ---, jorton, ASSIGNED, Need a simple tool to configure CA certs
18:12:16 <dwmw2> and isn't FESCo _supposed_ to give guidance to maintainers?
18:12:37 <jds2001> alrighty
18:12:50 <nirik> dwmw2: sure, feel free to tell them 'we think it would be nice if we had this'
18:12:54 <jds2001> #topic User account dialog
18:12:58 <jds2001> .fesco 279
18:12:59 <zodbot> jds2001: #279 (User Account Dialog - https://fedoraproject.org/wiki/Features/UserAccountDialog) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/279
18:13:08 <dwmw2> I'll put it on F13tracker :)
18:13:17 <dwmw2> not tracker, what's it called?
18:13:25 <jds2001> target
18:13:29 <dwmw2> thank you
18:13:42 <jds2001> this seems to be the natural conclusion of having different types of user accounts.
18:14:00 <jds2001> oops
18:14:08 <jds2001> wrong thing :)
18:14:36 <jds2001> or maybe not
18:14:38 <nirik> ok, several things on this one: lack of gdmsetup is a big issue to a lot of our users. They would welcome something with that functionality back.
18:14:56 <jds2001> PolicyKit: We want the dialog to be able to assign privileges/roles to users, for which we will rely on PolicyKit. PolicyKit 1.0 in F12 already provides the necessary framework for group-based policies (see the polkit-desktop-policy package), but minor adjustments might be necessary.
18:15:17 <nirik> does this remove system-config-users? it seems not, just replaces some of it's functionality
18:15:49 <notting> i would suspect it would replace s-c-users on the desktop spin. whether s-c-users goes away entirely is probably up to its maintainer
18:15:53 <nirik> which is fine, as other DE's/etc might still wish to use system-config-users.
18:15:56 <nirik> right.
18:16:24 <dgilmore> this must have a plan for XFCE, KDE, as well.  even if that plan is just making sure that there are .desktop files to launch things.  sinces its looking to replace core parts
18:16:29 * nirik isn't sure how much gdmsetup functionality it will have... better than the none now tho.
18:16:32 <Kevin_Kofler> IMHO they need to decide whether this ought to be a Fedora GNOME feature or a general Fedora feature.
18:16:39 <dgilmore> system-config-users was teh tool for creating users for all DE's
18:16:40 <notting> dgilmore: the hell?
18:16:45 <Kevin_Kofler> If it's the latter, integrating GDM support unconditionally is a mess.
18:16:51 <notting> dgilmore: see above
18:17:10 <Kevin_Kofler> If it's the former, replacing generic system-config tools with it is not a good idea.
18:17:21 <dgilmore> notting: fair enough.
18:17:32 <dgilmore> the feature reads as replacing and making it go away
18:17:49 <Kevin_Kofler> dgilmore: We have kuser in kdeadmin.
18:18:03 <nirik> Kevin_Kofler: doesn't the kde spin use kdm?
18:18:09 <nirik> or does it use gdm still?
18:18:15 <Kevin_Kofler> It uses KDM, that's the point.
18:18:25 <Kevin_Kofler> So having the same tool configure GDM and tons of other things is a bad idea.
18:18:35 <jds2001> halfline: you around?
18:19:04 <nirik> Kevin_Kofler: but you wouldn't ship this thing would you?
18:19:12 <notting> given the mockups, i suspect the gdm bits can just not do anything if there's no gdm
18:19:20 <Kevin_Kofler> nirik: I guess not...
18:19:32 <Kevin_Kofler> Which means it should be clearly advertised as a GNOME-specific feature.
18:19:34 * notting is +1. i'm concerned about the amount of dependencies and the schedule
18:19:36 <dgilmore> Kevin_Kofler: having it support plugins for kdm/gdm etx is a good thing though
18:19:45 <halfline> jds2001: i'm here
18:19:50 <nirik> Kevin_Kofler: yeah.
18:19:57 <jds2001> halfline: does this replace s-c-users?
18:19:59 * nirik is also +1.
18:20:02 <jds2001> or just supplement it?
18:20:12 <Kevin_Kofler> And which also means we can't blindly just throw out generic system-config tools for it (but we do have a KDE solution for user setup, it's called kuser and it's in kdeadmin).
18:20:41 <halfline> jds2001: would replace s-c-users in the desktop spin
18:20:48 <Kevin_Kofler> For PolicyKit, we'll probably get something in PolicyKit-KDE too, though it's not started so far.
18:21:12 <nirik> halfline: right, but s-c-users would still be there if someone wanted it?
18:21:22 <halfline> actually, not even sure we have s-c-users in the desktop spin right now...
18:21:24 <nirik> s/there/in the repos to install/
18:22:02 <notting> halfline: i think we kept -users, dropped -rootpassword (because, well, you have -users)
18:22:13 <halfline> nirik: right
18:22:25 <halfline> different people involved in each app
18:22:51 <nirik> halfline: just as a datapoint, I think we get about 1 user every day or two in #fedora that wants gdmsetup... it's pretty in demand...
18:23:04 <halfline> yea we get a lot of stirr upstream too
18:23:11 <Kevin_Kofler> I'm OK with this feature in principle, but I think it should be advertised as a GNOME feature as that's what it is.
18:23:14 <notting> nirik: but the old gdmsetup was... gah.
18:23:24 <halfline> gnome bug 587750
18:23:24 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=587750 was not found.
18:23:27 <halfline> was updated today in fact
18:23:40 <Kevin_Kofler> It's likely not to get installed on the KDE spin.
18:23:49 <jds2001> +1
18:23:52 <nirik> Kevin_Kofler: so, just change it to "User Account Dialog for Gnome" or "User Account Dialog for Desktop" would make you happy?
18:24:12 <otaylor> of course, this dialog would apply to a lot of spins other than the Desktop spin
18:24:12 <abadger1999> Kevin_Kofler: Does the firstboot-user replacement part affect KDE?  Or is that a firstboot plugin?
18:24:15 <Kevin_Kofler> The first one yes, the second one doesn't make the description any less generic.
18:24:22 <Kevin_Kofler> (replying to nirik)
18:24:25 <dgilmore> "Gnome User Account Dialog"
18:24:37 <nirik> otaylor: yeah, it could.
18:24:38 <Kevin_Kofler> abadger1999: I don't know.
18:24:43 <Kevin_Kofler> That's also an important part.
18:24:50 <Kevin_Kofler> If firstboot is going to require this, it's going to be a problem.
18:24:53 <nirik> otaylor: might make sense for Xfce for example... if we are still using gdm
18:24:53 <dgilmore> abadger1999: we likely need to see it
18:25:04 <abadger1999> halfline: Do you know? (firstboot portion... plugin replacing a different plugin?)
18:25:14 * notting thinks that part is not written yet
18:25:49 * dgilmore thinks this could be very cool if it was done so that there can be multiple backends/frontends
18:25:56 <dgilmore> so if could do gdm and kdm
18:26:07 <halfline> abadger1999: i don't know. my guess is we wouldn't ship the part of firstboot that asks for a username, and then we'd run this early in gdm
18:26:21 <halfline> or maybe we'd do it as a different firstboot module. not sure yet
18:26:28 <Kevin_Kofler> What I'd like to avoid is firstboot (which is required by anaconda which is required by liveinst, thus can't be removed) dragging in this tool through dependencies and so we being forced to ship this on the KDE spin despite it trying to configure GDM when we're shipping KDM.
18:26:50 <Kevin_Kofler> It might even end up dragging in GDM too, through dependencies, and the new GDM drags in a lot of GNOME stuff.
18:26:52 <dgilmore> Kevin_Kofler: but if it could do KDM also
18:26:57 <Kevin_Kofler> Dependency bloat is a major concern there.
18:27:12 <halfline> Kevin_Kofler: i wouldn't worry about that. i'm sure that can be avoided
18:27:24 <dgilmore> have it require login-manager and have gdma nd kdm provide login-manager
18:27:28 <nirik> dgilmore: how about slim and lxdm? there are more. ;)
18:27:32 <notting> reading it, it's a gtk app talking to a dbus backend. given that gdm's configured in flat files, not sure why it would require a login manager at all
18:27:35 <dgilmore> have kdm provide a plugin that allows it to be configured
18:27:52 <dgilmore> nirik: right it should be able to work for them all
18:28:04 <Kevin_Kofler> Well, KDM can already be configured, that's what the System Settings Module is for.
18:28:09 <notting> but sure, bonus points if it's routed through  ccsm or something :)
18:28:17 <Kevin_Kofler> It's GDM which is missing a config tool entirely.
18:28:21 <nirik> dgilmore: if the maintainers on those packages are willing to add plugins or whatever, sure.
18:28:38 * nirik notes he already voted. Goes to get more coffee.
18:28:57 <dgilmore> nirik: right.  but if its designed to be that flexiable  the implementation can follow or not
18:28:58 <jds2001> tally is 3 +1 at this point
18:29:07 <sharkcz> +1 also from me
18:29:22 <jds2001> me, nirik, and notting
18:29:31 <jds2001> alright - one more... :)
18:30:06 <jds2001> dgilmore, Kevin_Kofler, j-rod?
18:30:11 * skvidal 0's
18:30:33 <skvidal> mainly b/c of all the questions about it - but <shrug>
18:30:45 <dgilmore> jds2001: id like to know that its going to be designed in a flexible manner.  the general idea im ok with.
18:31:10 <dgilmore> but i want to make sure others can build on it. or provide different frontends etc
18:31:18 <dgilmore> im 0 for now
18:31:30 <jds2001> i think we're at a deadlock here then.
18:31:45 <skvidal> where did dwmw2 go?
18:32:32 <jds2001> let's defer until halfline can provide more info about the extensibiltiy of it.
18:32:35 <Kevin_Kofler> I'm -1 for now, I think they clearly need to decide whether to target GNOME only or Fedora in general.
18:32:46 <Kevin_Kofler> Design decisions appear to be inconsistent there.
18:32:56 <jds2001> alright, we're deferring this :)
18:33:19 <Kevin_Kofler> On one hand, trying to replace parts of firstboot and system-config tools, on the other hand, integrating with things like GDM.
18:33:34 <jds2001> #agreed User account dialog is deferred for further information as to the flexibility and extensibility to other DE's
18:33:34 * dwmw2 lost
18:33:49 * notting pokes j-rod
18:34:24 <jds2001> #topic sponsorship via co-maintainership
18:34:29 <jds2001> .fesco 275
18:34:31 * j-rod wakes up, apologies profusely
18:34:31 <zodbot> jds2001: #275 (Propose a soft-path via co-maintainer status to becoming sponsored) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/275
18:34:40 <jds2001> j-rod: heh
18:35:07 <jds2001> im not sure that we need to codify anything here
18:35:20 <halfline> i don't think there is going to be any interest in making the user account dialog be pluggable
18:35:20 <nirik> abadger1999: how feasable is this?
18:35:21 <jds2001> it's up to the sponsor whether or not to sponsor someone
18:35:26 <nirik> it would require pkgdb changes.
18:35:41 <nirik> and fas.
18:35:45 <jds2001> nirik: the proposal as written, yeah
18:36:10 <Kevin_Kofler> The current situation is pretty bad though.
18:36:14 <jds2001> wll the fas change would be to create a new group
18:36:16 * nirik notes we have always had a path to sponsor people on other than new package submissions.
18:36:39 <jds2001> and a config change to give that group fedorabugs as well.
18:36:41 <Kevin_Kofler> People either have to submit a dummy package to get sponsored, or convince a sponsor to just sponsor them without following any codified policy.
18:36:53 <notting> nirik: is that *documented*?
18:37:09 * abadger1999 notes he's been somewhat acting on this already.
18:37:32 <abadger1999> Since we split provenpackagers and packagers with packagers only being able to touch the packages they own.
18:37:59 <jds2001> yeah, that was a big step forward in this.
18:38:11 <Kevin_Kofler> The big issue here is that how this should be handled is not documented.
18:38:14 <nirik> notting: https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
18:38:19 <Kevin_Kofler> Sponsors have been handling these as exceptional cases.
18:38:25 <nirik> notting: but not very explicit
18:39:05 <Kevin_Kofler> This clearly tells you to submit packages.
18:39:13 <nirik> another option here is that we could just explictly add 'sponsors are allowed to sponsor people when they feel they understand the guidelines and will do good work'
18:39:23 <abadger1999> So.. as just a policy statement and no code changes this seems feasible to me right now.
18:39:34 <nirik> Kevin_Kofler: it says "The best ways for you..." not "The only way..."
18:39:55 <Kevin_Kofler> nirik: Well, that sentence also needs something like "Independently of this usual process, sponsors are allowed to ...".
18:40:03 <nirik> abadger1999: but we need code changes to implement it, right?
18:40:25 <jds2001> no, we just click the sponsor button like today
18:40:41 <jds2001> all they can touch is what they have acl's to anyhow
18:41:01 <abadger1999> nirik: Maybe.... Thinking about how this would work.
18:41:15 <abadger1999> So right now sponsors an act on the proposed policy fine.
18:41:18 <dgilmore> I know of cases where people have been sponsored by co-workers without having gone though the new review process
18:41:19 <nirik> jds2001: well, there is no indication to another maintainer that they were sponsored for just one package.
18:41:22 <abadger1999> mere package owners can't.
18:41:51 <abadger1999> Adding mere package owners means making them sponsors of some group that can commit to packages.
18:41:55 <nirik> right, a package maintainer that wanted to add a new non sponsored person would need to get a sponsor to sign off on it.
18:42:39 <nirik> so we can't just implement this as written now, it needs code.
18:42:44 <abadger1999> So we'd need three groups in fas instead of two (four, and three if you count cvsadmin).
18:42:53 <abadger1999> That's just another group though.
18:43:30 <abadger1999> We need the acls to allow the new group at the fs level and also in the cvs acl file.
18:43:32 * dwmw2 has to disappear
18:43:43 * jds2001 has to soon too
18:43:48 <jds2001> $DAYJOB calls.
18:43:54 <nirik> is adding another group and making code changes worthwhile here?
18:44:03 <abadger1999> The cvs acl file should be a config change in pkgdb but these things aren't changed often so assumptions can creep in.
18:44:08 * skvidal just wants to get lunch :(
18:44:10 <nirik> or should we just codify that we allow sponsors to sponsor based on other than package reviews?
18:44:15 <notting> wait. i thought this 'worked', (documentation aside), as long as you had a sponsor do it?
18:44:19 <abadger1999> I'm going to guess minimal code changes.
18:44:31 <abadger1999> but lots of testing :-)
18:44:44 <nirik> notting: no.
18:44:58 <nirik> "Also means that when a person of this type asks for access to a package then the package owner should clearly see that the person is not yet fully sponsored and only registered as co-maintainer of packages X."
18:45:22 <jds2001> notting: you can submit new packages without review of a sponsor if you get in via comaintainership right now for instance.
18:46:07 <jds2001> which is why the best way remains to submit a pakcage and show understanding of the guidelines.
18:46:11 <nirik> so there are parts of this as written that require changes.
18:46:44 <nirik> if we are running out of time we could defer? we might want to note this on devel list for maintainer imput too...
18:46:50 <abadger1999> I think this is worthwhile but would like to have the design laid out more before we implement it.
18:47:16 <abadger1999> I think this is pretty doable but I'm not 100% sure.
18:47:35 <abadger1999> Also, jds2001 is going to help me with this since he's not going to be on fesco next term.  Right?
18:47:38 <abadger1999> :-)
18:47:40 * nirik isnt sure the overhead is worth it, might be better to just codify that sponsors can just sponsor people who they feel understand the guidelines in other ways than package submission.
18:47:53 <jds2001> abadger1999: of course :D
18:48:03 <jds2001> abadger1999: we can work on it on FUDBus even :)
18:48:12 <abadger1999> jds2001: Sounds like a plan.
18:49:07 <jds2001> well how's this, let's defer til after fudcon and we can see what effort is required in pkgdb
18:49:11 <jds2001> it sounds pretty easy.
18:49:20 <abadger1999> jds2001: +1
18:50:07 * nirik nods. Sure, if we want to implement this... might be best to get a for sure vote yes before you start coding tho.
18:50:08 <dgilmore> jds2001: sounds good
18:50:27 <jds2001> nirik: true
18:50:32 <jds2001> in that case, +1 :)
18:50:34 <Kevin_Kofler> jds2001: +1
18:50:57 <Kevin_Kofler> (to deferring)
18:50:59 <jds2001> but if it winds up being not feasiable for some reason......
18:51:26 <jds2001> Kevin_Kofler: im gonna start coding pretty quick here, within the next 2 weeks
18:51:57 <jds2001> is it worthwhile is teh quesiton
18:52:03 <jds2001> or a waste of effort?
18:52:40 * nirik is 0 right now, not sure how many people are left around to vote
18:52:47 <jds2001> hello? bueller?
18:52:50 <jds2001> :)
18:52:59 * sharkcz is still here
18:53:03 <jds2001> well, we'll figure out how much effort at any rate
18:53:03 <skvidal> +1
18:53:08 * notting scrolls back to find the specific proposal
18:53:25 <Kevin_Kofler> https://fedorahosted.org/fesco/ticket/275
18:53:30 <jds2001> notting: to code pkgdb to teach it about the new group to implement the proposal as written.
18:53:43 <sharkcz> +1
18:54:18 <Kevin_Kofler> In short, the proposal is to allow any package owner to add unsponsored people as comaintainers, but those people couldn't get new packages in without getting through the regular sponsorship process.
18:54:39 <notting> +1
18:54:43 <jds2001> #agreed the propsoal in ticket 275 is accepted as written, however, it requires pkgdb code changes which will be accomplished at fudcon.
18:54:59 <tibbs> For what it's worth, I'm not sure that's a terribly good idea but I suspect it's better than the status quo.
18:55:00 <Kevin_Kofler> +1 to the proposal as well, for the record.
18:55:07 <jds2001> #topic upcoming meetings
18:55:10 <nirik> this will be nice for upstreams where they are interested in helping maintain their package in fedora.
18:55:21 <jds2001> so next friday is the day after thankgiving
18:55:26 <jds2001> and the next one is fudcon
18:55:49 * nirik should be around both of the next fridays... but I know many of the rest of you may not.
18:56:00 <Kevin_Kofler> I should be around on both too.
18:56:01 <jds2001> so do we hold our fudcon meeting for whatever's on the docket (not sure we'll be quorate there now)
18:56:10 <Kevin_Kofler> Thanksgiving is not a special day here and I won't be at FUDCon.
18:56:48 <jds2001> well i'm not going anywhere for thanksgiving, so i'll be around
18:57:22 <jds2001> but i suspect that nirik, Kevin_Kofler, dwmw2_gone and I may be the only attendees :D
18:57:32 <skvidal> I will not be online on the day after thanksgiving
18:57:37 <skvidal> or if I am - something better be on fire
18:57:42 <sharkcz> I will be onlu next week
18:58:00 <nirik> how about we cancel them, and if something urgent comes up we can schedule a special session sometime.
18:58:05 <jds2001> sounds good.
18:58:16 <Kevin_Kofler> Well, we'd have quorum next week, it seems.
18:58:25 <sharkcz> s/onlu/online/
18:58:26 <jds2001> #agreed next two FESCo meetings are cancelled, unless something urgent comes up
18:58:30 <jds2001> Kevin_Kofler: nah
18:58:34 <jds2001> we'd have 4
18:58:34 <Kevin_Kofler> Unless dwmw2 would not be there.
18:58:39 <Kevin_Kofler> sharkcz too.
18:58:39 * notting is roughly in the same boat as skvidal. while i *could* be online, i would really really really really prefer not to
18:58:41 <Kevin_Kofler> Makes 5.
18:58:48 <dgilmore> skvidal: same.
18:58:57 <jds2001> same here
18:59:02 * dgilmore has to f9nish renovating his office by saturday
18:59:04 <jds2001> get black friday deals :D
18:59:20 <dgilmore> since its a 1st birthday party on sunday and wife dictates that office must be done
18:59:34 <jds2001> macy is 1 already?
18:59:37 <jds2001> time flies.
18:59:48 <Kevin_Kofler> But of course I'm OK with canceling the meeting.
18:59:48 <dgilmore> jds2001: she will be one in 10 days
19:00:13 <jds2001> anyhow, that's all I had.
19:00:17 <Kevin_Kofler> So the next meeting will be Nov 11?
19:00:25 <Kevin_Kofler> Uh, make that Dec 11.
19:00:36 <dgilmore> Kevin_Kofler: yes
19:00:45 <dgilmore> though we should try have something at fudcon
19:00:55 <dgilmore> at leasta  fesco session
19:01:01 <jds2001> #yeah
19:01:05 <Southern_Gentlem> meet the fesco
19:01:17 <jds2001> anyhow.....
19:01:22 <jds2001> are we done here?
19:01:34 <jds2001> im starving and have $DAYJOB matters to attend to :)
19:01:40 <skvidal> yez
19:01:43 <skvidal> +3
19:01:43 <nirik> jds2001: I had a thing for open floor, but if we are out of time then we are.
19:01:54 <jds2001> yeah, can it wait?
19:01:55 <Kevin_Kofler> I'm unhappy with FUDCon-based meetings, it's geographic discrimination.
19:02:03 <cjb> gosh, nearly a month away
19:02:05 <nirik> jds2001: probibly.
19:02:12 * cjb has a feature proposal ready for wrangling, but I guess there's no hurry.
19:02:25 <jds2001> cjb: yeah
19:02:27 <nirik> just to throw it out, from EvilBob (who had to leave): "Should upstream be the package owner, or should someone else be the owner and upstream be a co-maintainer? Making someone else responsible for checking for changes more or less."
19:02:53 <nirik> ie, should we look at adding non upstream co-maintainers to critical packages so they can help note changes for fedora, etc.
19:03:00 <nirik> but we can discuss that next time.
19:03:05 <jds2001> alright :)
19:03:16 <jds2001> #endmeeting