devel June 2009

devel@lists.fedoraproject.org

346 participants
290 discussions

Interested in scanning?
by Bastien Nocera 19 Jul '09

19 Jul '09

Heya, Yesterday, I was browsing Ubuntu's "Blueprints" for their next release, and saw this: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gnomescan gnome-scan is already packaged by Deji, but I gather that more integration work could be done to make setting up and using scanners easier in GNOME and Fedora in general. Any takers? I think a good start would be making a list of problems seen in setting up scanners (additional packages required, tweaks), and make sure that gnome-scan and the necessary plugins are installed in a default installation. Cheers /Bastien, who doesn't own a scanner

22 30

beagle
by Michael Schwendt 14 Jul '09

14 Jul '09

* Delivery to the following recipient failed permanently: beagle-owner AT fedoraproject DOT org Recipient address rejected: User unknown in local recipient table (state 14). * https://admin.fedoraproject.org/pkgdb/packages/name shows more than a dozen people on watchcommit+commit, but no package owner. It's an orphan. * https://admin.fedoraproject.org/pkgdb/packages/bugs shows more than a dozen open tickets, but nobody is subscribed to watchbugzilla. * "yum list beagle" shows beagle-0.3.9-6.fc11 in "fedora".

5 8

http://www.fsf.org/news/dont-depend-on-mono
by Frank Murphy 13 Jul '09

13 Jul '09

Is there any contingency plans in place, for a worst case scenario if C#, is lost? FesCo? Legal? Is there any searchable parameter, to work out what something is coded in\depending on (code wise) This is not the normal "**** mono" post. I hope, I worded it enough, that my concern is: Fedora and *All* our Users (http://fedoraproject.org/wiki/Overview#What_is_Fedora.3F) Frank -- jabber | msn | skype: frankly3d http://www.frankly3d.com

24 60

an update to automake-1.11?
by Owen Taylor 11 Jul '09

11 Jul '09

I was rather surprised to see: https://admin.fedoraproject.org/updates/F9/FEDORA-2009-6661 https://admin.fedoraproject.org/updates/F10/FEDORA-2009-6076 https://admin.fedoraproject.org/updates/F11/FEDORA-2009-6370 Where the automake was upgraded to 1.11 for F9, F10, and F11. In general automake hasn't had a very good track record of compatibility between 1.x and 1.y, though this has been getting better recently. I don't see any specific mentions of incompatible changes in a quick scan of: http://lists.gnu.org/archive/html/automake/2009-05/msg00093.html But it is also a pretty long release announcement so it wouldn't surprise me if there were some subtle incompatibilities. The only breakage I'm actually aware of in the gnome-common package; gnome-common-2.26 and earlier doesn't know that automake-1.11 is a valid replacement when automake-1.10 is asked for. So, we definitely need to release an update for gnome-common, or people aren't going to be able to do GNOME development on F11. But is this the type of upgrade that makes sense in general? It seems to me that we should be very conservative in upgrading build tools, especially in "maintenance mode" distributions like F9 and F10. - Owen

33 133

No sound in rawhide
by Paul F. Johnson 08 Jul '09

08 Jul '09

Hi, Prior to the big push to f12, my system had full audio. No problems. Lovely, lovely sounds. For some reason, alsa and pulseaudio are completely failing to pick up my sound card (either the onboard one or my soundblaster). This is despite them both being listed on lspci and lsmod. Any ideas on getting this to work again? TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen!

9 13

Re: Do we need split media CDs for F12?
by Robert 'Bob' Jensen 07 Jul '09

07 Jul '09

----- "Jesse Keating" <jkeating(a)redhat.com> wrote: > And this is what pisses me off, and why I say you're holding us > hostage. > Whether or not it is a good idea to continue to produce them, you > don't > care, you're just going to do it anyway. Great way to run a project. > Jesse, Both Fedora Project and Fedora Unity have users that want, need or download in error CD media. The simple difference in the future of CD media is that we, Fedora Unity, are choosing to not remove the users freedom of choice. Giving users freedom of choice is how we run our project. We have faith that Fedora Project will do what it feels is best for it's contributors and resources. Independent of what Fedora Project does we also will do what we feel is best for our users and also keep in mind our resources. No one should feel they are being held hostage. Without the hard work Fedora Project puts in to a release and the subsequent updates Fedora Unity could not produce any media. I feel it is in our best interest to work together to resolve issues, I have always felt this way, unfortunately history has shown that this is not often possible. I keep hoping it will someday happen. - Bob ------------------------------------------------------------------------ | Robert 'Bob' Jensen || Fedora Unity Founder | | bob(a)fedoraunity.org || http://fedoraunity.org/ | | http://bjensen.fedorapeople.org/ | | http://blogs.fedoraunity.org/bobjensen | ------------------------------------------------------------------------

2 1

Keyboard US Internacional
by Rodrigo Padula de Oliveira 07 Jul '09

07 Jul '09

Hello Guys! We have a problem with the keyboard Us Internacional. I'm using Fedora 11 in pt_BR Looking the file /lib/kbd/keymaps/i386/qwerty/us-acentos.map.gz, I found this: compose '\'' 'C' to 'Ç' compose '\'' 'c' to 'ç' This is correct, but, when I press ' + c or ' + C = ć or Ć. In portuguese we don't have acent in the c, the correct is ç (C + cedilla) So, how can We fix this problem ? -- Rodrigo Padula de Oliveira M.Sc. Student - COPPE/UFRJ Fedora Community Manager - Latin America Red Hat Community and Academy Relations http://www.proyectofedora.org http://twitter.com/rodrigopadula http://www.rodrigopadula.com

8 12

Re: http://www.fsf.org/news/dont-depend-on-mono
by Liang Suilong 04 Jul '09

04 Jul '09

>梁穗隆 wrote: >> I am using f-spot to export my photos to picasa web album. It is much >> better than Google Picasa for Linux. I know that gnote will replace >> tomboy. I hope solang will replace f-spot for the reason that sometimes >> after I upload photos to picasa web album f-spot would crash. >Try Digikam. >su -c "yum install digikam" > Kevin Kofler I more like gtk+ programs than qt4 programs.....Haha! So I really hope that solang will replace f-spot soon. And solang has more new features than f-spot. -- <url>http://liangsuilong.co.cc</url> Fight for freedom!!!!(3F） Ask not what your Linux distro can do for you! Ask what you can do for your Linux distro!

6 5

Building packages for EPEL
by Dennis Gilmore 04 Jul '09

04 Jul '09

EPEL is now using koji to build instead of plague. please make sure that you update th common directory in your checkout to pick up the needed changes to submit builds. Bodhi support will come early next week to issue updates. the buildroots are only populated by packages from stable if you need to build against something in testing or that you have just build please email your request to epel-releng(a)lists.fedoraproject.org thanks Dennis _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce

6 7

FESCo meeting summary for 2009-06-26
by Jon Stanley 02 Jul '09

02 Jul '09

Here's the FESCo meeting summary and logs for 2009-06-26. The log is also below. Minutes: http://www.scrye.com/~kevin/fedora/Fedora-Meeting/2009/Fedora-Meeting.2009-… Log: http://www.scrye.com/~kevin/fedora/Fedora-Meeting/2009/Fedora-Meeting.2009-… ---- 17:02:00 <jds2001> #startmeeting 17:02:15 <jds2001> #meetingtopic FESCo meeting - 6-26-09 17:02:20 <jds2001> #chair dgilmore jwb notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler 17:02:27 <jds2001> FESCo meeting ping -- dgilmore, jwb, notting, nirik, sharkcz, jds2001, j-rod, skvidal, Kevin_Kofler 17:02:31 <Kevin_Kofler> Present. 17:02:31 * notting is here 17:02:32 * nirik is here. 17:02:35 * jwb is here 17:02:38 * sharkcz is here 17:02:48 * j-rod wakes up 17:03:47 <skvidal> yes 17:03:50 <jds2001> awesome. 17:04:05 <jds2001> first some administrative stuff. 17:04:11 <jds2001> #topic Meeting time 17:04:23 <jds2001> does the current time work for everyone? 17:04:31 * jds2001 hopes so, works great for him :D 17:04:32 <Kevin_Kofler> It's OK with me. 17:04:41 <nirik> I'm fine with it... 17:04:49 <skvidal> yeah 17:05:01 <notting> worksforme 17:05:11 <j-rod> it'll do 17:05:14 <jds2001> just to clarify, we dont change for DST either. 17:05:14 <sharkcz> WFM 17:05:19 <jwb> yeah 17:05:19 <jds2001> awesome 17:05:26 <skvidal> umm 17:05:27 <skvidal> jds2001: wait 17:05:30 <skvidal> we don't change for DST 17:05:38 <skvidal> so it'll be at noon on fridays in the future? 17:05:41 <jds2001> right, so it's 17:00UTC year round. 17:05:44 <jds2001> yes. 17:05:53 * skvidal stabs 'lunch meetings' through the heart 17:05:54 <skvidal> fine 17:06:03 <skvidal> I'm just going to bitch and moan about it in october 17:06:17 <jds2001> ok, we can change then if need be :) 17:06:22 * jds2001 likes 1pm too :) 17:06:59 <jds2001> #agreed Current meetimg time works for everyone, may revisit DST in October. 17:07:06 <jds2001> #topic Chair 17:07:13 <skvidal> quick question 17:07:17 <jds2001> sure 17:07:17 <skvidal> can everyone go through their real names 17:07:31 * jds2001 == Jon Stanley 17:07:32 <skvidal> so I know I've got the mental image of who I am directing psychic hate at? :) 17:07:41 * Kevin_Kofler 's real name should be obvious. ;-) 17:07:42 <nirik> nirik == Kevin Fenzi 17:07:45 * sharkcz = Dan Horak 17:07:47 <skvidal> skvidal = seth vidal 17:07:54 * jwb == Seth's Target 17:07:58 <notting> notting == Bill Nottingham 17:07:59 * j-rod is Jarod Wilson 17:08:47 <jds2001> Anyone want to step up as chair? 17:09:04 * jds2001 is willing to continue, but if someone else wants to, I'll cede to them :) 17:09:08 * nirik will be happy to if jds2001 doesn't want to do it again 17:09:30 <jwb> we have the same issue as last time 17:09:33 <jwb> :) 17:09:48 <j-rod> I'm game too 17:09:56 <j-rod> (just to keep it interesting) 17:10:03 <Kevin_Kofler> jwb: Barber's paradox? ;-) 17:10:10 <jds2001> ok, so how do we decide? :) 17:10:30 <jwb> paper rock scissor 17:10:31 <notting> MMA? RPS? 17:10:37 <j-rod> ooh, MMA 17:10:50 <nirik> jds2001: if you have time for it and want to keep doing it thats fine with me. 17:11:00 * jds2001 is afraid he doesn't know what MMA is, so I lose :D 17:11:18 <j-rod> Mixed Martial Arts... Cage-fighting... 17:11:24 <jds2001> aha 17:11:29 <jds2001> i defintely lose :) 17:11:43 <nirik> we could roll a dice? 17:12:02 * jds2001 doesn't keep dice at his desk :) 17:12:14 * nirik notes the bot has a dice. ;) 17:12:17 <nirik> @dice 3 17:12:22 <nirik> @dice d3 17:12:30 <nirik> @dice 1d3 17:12:31 * ianweller blinks 17:12:33 <Southern_Gentlem> @dice 6 17:12:56 <nirik> in any case, I don't care. I will cede to jds2001 if he wants to keep doing it. 17:13:03 <j-rod> me too 17:13:11 <notting> then i think it's decided 17:13:18 <jds2001> awesome 17:13:26 <jds2001> #agreed jds2001 will continue as chair 17:13:34 <jds2001> onto tickets.... 17:13:35 <nirik> you keep using that word. I do not think it means what you think it means. ;) 17:14:04 <jds2001> hehe 17:14:12 <jds2001> i use it all the time irl too :) 17:14:32 <jds2001> #topic LVM ACL's 17:14:37 <jds2001> agk____: you around? 17:14:42 <agk____> yes 17:14:45 <jds2001> .fesco 124 17:14:48 <zodbot> jds2001: #124 (Re: Packages with closed ACL's - LVM related items) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/124 17:15:09 <Kevin_Kofler> As I said in the comments, I don't see what sense it makes to keep LVM closed on security grounds when kernel etc. are open. 17:15:20 <jds2001> and openssh, etc. 17:15:21 <Kevin_Kofler> And I don't think we want to go back to a closed-ACL regime. 17:15:24 <agk____> I don';t think kernel should be open either, of course 17:15:33 <jds2001> but it is currently 17:15:36 <Kevin_Kofler> The provenpackager group is actually very strictly controlled, we can really expect to trust those people. That was already a compromise to alleviate security concerns. I think going back to an even stricter ACL regime would be really detrimental to our project and bring no actual added security. 17:15:37 <jds2001> and has been for months. 17:15:57 <sharkcz> and noone 17:16:11 <agk____> - from a security point of view, if *one* user's credentials are compromised, it should not be easy for them to compromise the distribution quickly 17:16:17 <jds2001> so if someone wants to mess w/lvm ,just mess with the dm code in the kernel. 17:16:25 <Kevin_Kofler> So can we just vote to force LVM to be open to provenpackager? 17:16:57 <jds2001> agk____: one would think that those users take care to protect their credentials. 17:16:57 <agk____> so picking up on my suggestion 2 higher up, I'm arguing there needs to be delay or multiple people involved to get changes out 17:17:00 <jds2001> I know that I do. 17:17:13 <notting> agk____: they can do that anyway - obsoletes: glibc in their xcowsay package, regardless of acls 17:17:15 <skvidal> agk____: that's for critpath - and yes 17:17:26 <agk____> eg separation of duty of commit and build 17:17:48 <jds2001> what about packages that have only one maintainer? 17:17:54 <agk____> so at least two people's credentials would have to be compromised *or* some enforced delay 17:17:55 <jds2001> i.e. most of them. 17:18:18 <nirik> agk____: If you would like to propose a new setup, feel free to write one up. Currently what we have seems to be working. Some people find it too open, others too closed. 17:18:21 <agk____> so there is time for others to spot and review the questionable change 17:18:26 <Kevin_Kofler> The thing is, judging from history, it's easier to just break into the infrastructure than to compromise packages by abusing ACLs. 17:18:47 <agk____> we need to protect against as many attacks as we can 17:18:50 <Kevin_Kofler> The intruder was just not clever enough to use the gained access to compromise our packages. 17:18:51 <skvidal> Kevin_Kofler: umm - that's not only incorrect, but out of line 17:19:04 <nirik> agk____: I would love to have qa on all commits. Where do we have the pile of qa people to do that though? 17:19:08 <skvidal> Kevin_Kofler: I think you're talking from a massive lack of knowledge. 17:19:23 <agk____> but *some* packages *do* have enough maintainers to do this 17:19:41 <nirik> agk____: agreed, and they do. Why does opening this to provenpackager change that? 17:19:41 <jwb> then they can do it if they want 17:20:04 <agk____> packages with enough maintainers do not need provenpackers 17:20:07 <nirik> if some provenpackager commits something to lvm packages without checking with you, revert it, and note that they shouldn't have done that? 17:20:12 <agk____> - if they want to submit changes, they submit it the normal way 17:21:03 <nirik> agk____: I agree to some extent, but I think it's weird to have lvm packages as the lone exception... 17:21:03 <skvidal> agk____: think of provenpackagers like a social saftey net 17:21:06 <jds2001> jsut to be clear, for months, the only items with closed ACL's has been the LVM stuff, and FF/TB/xulrunner for legal reasons. 17:21:12 <skvidal> agk____: not everyone needs it - but everyone gets it, just in case 17:21:15 <agk____> - if they are doing global search/replaces across all packages, then they have *temporary* access for the period necessary to do that 17:21:29 * nirik nods at skvidal 17:21:42 <Kevin_Kofler> I don't see why we should be putting up those barriers just for an imaginary security risk. 17:21:57 <agk____> it's not imaginary 17:22:04 <Kevin_Kofler> The set of provenpackagers is already kept small because of security concerns from people like you. 17:22:20 <jeremy> agk____: quite frankly, if you're going to argue that, then people need tobe more responsive with lvm2 bugs imho 17:22:25 <agk____> you already mentioned fedora had a problem last year - we need to do everything in our power to minimise the risk of future incidents 17:22:36 <notting> jeremy: ... not relevant to this discussion, though 17:22:44 <Kevin_Kofler> That incident had absolutely nothing to do with package ACLs. 17:22:47 <skvidal> agk____: the incident last year is not relevant, either 17:22:59 <Kevin_Kofler> Restricting ACLs will NOT help for that type of attacks. 17:23:16 <jwb> we're going in circles 17:23:19 <jwb> call for a vote 17:23:20 <agk____> it is relevant because it meant that 'theoretical' security problems may not remain theoretical 17:23:32 <notting> i agree that the risk isn't imaginary. but lvm is not more special than the other packages open to provenpackager to get an exception as it stands now 17:23:40 <notting> if someone wants to make a ew proposal... 17:23:45 <Kevin_Kofler> jwb: I already did... 17:23:46 <Kevin_Kofler> <Kevin_Kofler> So can we just vote to force LVM to be open to provenpackager? 17:23:49 <agk____> I'd argue all those other packages should have exceptions too 17:23:50 <jds2001> agk____: and lots of concrete changes took place as a result. 17:24:09 <jwb> agk____, your argument is duly noted 17:24:14 <jds2001> agk____: their maintainers certaintly didnt ask for them. 17:24:21 <agk____> until the process whereby a single developer can make a big change without reference to anyone else is addressed 17:24:36 <Kevin_Kofler> The single developer will get noticed quickly. 17:24:44 <Kevin_Kofler> Also note that update pushes are still manual. 17:24:58 <Kevin_Kofler> Only Rawhide could possibly get the stuff fully automatically. 17:25:01 <nirik> agk____: so that would be a new setup, different from what we have now. Perhaps you would write up a proposal on how you want it to work and we can look at that then? 17:25:08 <agk____> and only performed by credentials that cannot also commit+biuld? 17:25:11 <jds2001> if jwb notices something off kilter, he'll likely say something. 17:25:16 <agk____> i.e. I'm arguing for separation of roles 17:25:17 <skvidal> agk____: let's talk about that when we get to the critpath discussion 17:25:29 <skvidal> agk____: b/c for a number of important pkgs 17:25:40 <agk____> - anyway, some of this is on the agenda at fudcon here tomorrow afternoon 17:25:43 <skvidal> that will involve getting an additional person to check/sign off before the pkg is pushed 17:25:50 <Kevin_Kofler> Separation of commit and build is not going to work for the vast majority of the packages in our distro. 17:25:53 * nirik thinks that is much more change than this discussion, and would want to see a full proposal spelling out what agk____ is proposing. 17:25:54 <skvidal> agk____: some of _what_ is on the agenda? 17:25:56 <Kevin_Kofler> They don't even have comaintainers. 17:25:59 <jwb> skvidal, right. the point being that it doesn't scale to do that for everything 17:26:07 <skvidal> jwb: correct 17:26:15 <jds2001> but lvm is critpath 17:26:16 <skvidal> jwb: but for "critical" things it does scale 17:26:19 <skvidal> right 17:26:20 <skvidal> exactly 17:26:21 <Kevin_Kofler> It's hard enough to find a second person for a one-time review, having to find a permanent builder person is impossible. 17:26:38 <jwb> it's not impossible, but it's beside the point 17:26:52 <nirik> in the ideal world: a developer/packager, a builder/admin, and a qa person for every package. 17:27:00 <skvidal> nirik: well, sort of 17:27:01 <nirik> in our world: usually one maintainer that does everything. 17:27:10 <skvidal> nirik: developer/packager and builder are all one 17:27:11 <Kevin_Kofler> Can we vote on removing the special exception for LVM in the meantime? 17:27:16 <skvidal> qA is mostly automated -- or should be 17:27:28 <nirik> skvidal: they could be different if we had a ton of people working on things. ;) 17:27:29 <skvidal> and one additional person for critical pkgs to make sure they should be pushed 17:27:32 <agk____> where they are all one, an option is an enforced delay 17:27:39 <j-rod> no exception for LVM right now, multi-person security thingy will be addressed as part of the critical path package discussion 17:27:43 <jds2001> yeah, we do have to mvoe on :) 17:27:43 <notting> j-rod: +1 17:27:44 <skvidal> agk____: which does no good other than give a time when everyone will ignore it 17:27:49 <jds2001> j-rod: +1 17:27:53 <skvidal> j-rod: +1 17:27:54 <sharkcz> j-rod: +1 17:27:57 <nirik> +1 to j-rod's suggestion. 17:28:07 <Kevin_Kofler> j-rod: +1 17:28:14 <jds2001> I see six +1 17:28:23 <jwb> +1 17:28:29 <j-rod> well, I'm +1 for it as well 17:28:39 <j-rod> so 8 +1 now 17:28:47 <jds2001> #agreed no special exception for LVM right now, will be addressed via critical path package process. 17:29:04 * nirik would be happy to entertain proposals on how to revamp the acls/build/permissions system, but wants them in a complete proposal, not just 'change this one part' 17:29:22 <agk____> I'm happy to contibute to those discussions 17:29:35 <jds2001> #topic provenpackager request - devrim 17:29:39 * Kevin_Kofler doesn't see any need for change. 17:29:42 <nirik> agk____: if you want to write up a proposal, I would be happy to provide feedback. 17:29:59 <notting> +1 to devrim as provenpackager 17:30:00 <nirik> +1 to devrim. He's done good work on postgresql and tomcat 17:30:01 <j-rod> +1 for devrim 17:30:08 <sharkcz> +1 for devrim 17:30:22 <Kevin_Kofler> +1 to devrim. No objections here, and I haven't heard from any sponsor who'd object either. 17:30:32 <jds2001> +1 here 17:30:51 <jwb> +1 17:30:52 <jds2001> #agreed devrim provenpackager membership is approved. 17:31:12 <jds2001> I'll add him after the meeting. 17:31:52 <jds2001> #topic rename Desktop live image to GNOME live image 17:31:58 <jds2001> .fesco 170 17:32:01 <zodbot> jds2001: #170 (Rename "Desktop" live image to "GNOME" live image) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/170 17:32:06 <Kevin_Kofler> This one is my proposal. See the ticket for the rationale. 17:32:08 <nirik> I had some questions on this one. 17:32:36 <skvidal> we're adding a name to something which doesn't accurately describe it and it just adds complication where it is not necessary 17:32:48 <jds2001> yeah, my thoughts as well. 17:32:52 <skvidal> however, I would be fine saying 'fedora live cd, containing the gnome desktop' 17:33:00 <nirik> 1) do you expect all people using fedora to know what Gnome and KDE are? 2) What does this get us? 3) should this get more input from many people who are at fudcon this week instead of being added right before the meeting? 17:33:01 <Kevin_Kofler> I think it describes it very accurately, more than the current name. 17:33:02 <notting> "The current naming misleads users into either thinking GNOME is the only available desktop environment in Fedora or thinking the image also provides the other options." <- i don't really think either of these are accurate 17:33:26 <notting> skvidal: the download page already says 'featuring the gnome desktop' 17:33:29 <Kevin_Kofler> ad 1., I'd expect most of them to have heard of them already. 17:33:37 <skvidal> notting: great = then I'm already happy 17:33:45 <Kevin_Kofler> And those who haven't will just pick the first in the list. 17:33:55 <Kevin_Kofler> ad 2. see rationale 17:34:00 <jds2001> Kevin_Kofler: really? If I asked my mom, she'd think I was talking a foreign language. 17:34:03 <Kevin_Kofler> It stops misleading users about the contents of the image. 17:34:30 <skvidal> Kevin_Kofler: misleading? cmon, 1. it doesn't really matter and 2. do you think we're going to take a hit on false advertising? :P 17:34:35 <nirik> "welcome to fedora! You can download FOOBAR and fROMBIZ and GRAZ" many users will look at that and go huh? which is fedora? 17:34:42 <Kevin_Kofler> jds2001: Don't forget that we're talking about users about to install Fedora (without guidance from relatives ;-) ) here. 17:35:12 <jwb> so we don't care about aunt tillie? 17:35:20 <Kevin_Kofler> ad nirik's 3. I've been proposing this on the mailing list for ages. 17:35:33 <jwb> oh, we know :) 17:35:34 <Kevin_Kofler> It was also part of my electoral platform. 17:35:38 <Kevin_Kofler> It's not a secret to anybody. 17:35:39 <skvidal> jwb: well if that is ESR's aunt then I'd like to get her to ask some very serious question to his parents 17:35:46 <j-rod> http://fedoraproject.org/en/get-fedora doesn't look at all misleading to me 17:35:47 <notting> Kevin_Kofler: then why on earth didn't you send a fesco proposal until now? 17:35:58 <jds2001> add to that, I'm not exactly sure that this is FESCo's domain. 17:36:10 <Kevin_Kofler> notting: There has to be a time. :-) 17:36:27 <Kevin_Kofler> I was nagged about it very recently, I decided to bring this up right after the election. 17:36:31 <skvidal> proposal: keep things as they are ticket 170 is rejected 17:36:32 * jds2001 is happy to discuss it, and send it up to the Board, though. 17:36:40 <jwb> so i'm pretty much ambivalent on this one 17:36:42 <j-rod> +1 to skvidal's proposal 17:36:50 <jwb> 0 17:36:51 * bpepple give a peanut gallery +1 to skvidal's proposal. 17:36:58 <Kevin_Kofler> -1 to skvidal's proposal (i.e. +1 to mine) 17:37:01 <nirik> well, it does tie into the 'who is fedora for' that the board is I guess working on. 17:37:14 <jwb> nirik, sort of, yes 17:37:19 <skvidal> nirik: then we can let them decide it and we LEAVE IT ALONE until then 17:37:36 <nirik> ie, if the board says that fedora should not target non technicial users, I could see changing this. 17:37:39 <Kevin_Kofler> Give Fedora to "Aunt Tillie" and she'll end up with a broken yum when upgrading her F10 to F11. 17:37:42 <nirik> skvidal: agreed. 17:37:43 <Kevin_Kofler> I've seen it happen to a real person. 17:38:05 <Kevin_Kofler> We're deluding ourselves by targeting such a userbase. 17:38:10 <skvidal> Kevin_Kofler: yes, and if we gave it to aunt tillie in f9 they would not be able to use kde at all, next point? 17:38:29 <Kevin_Kofler> skvidal: This is nothing against yum. ;-) 17:38:33 <nirik> Kevin_Kofler: I have seen lots of people upgrade fine too. Anecdotes aren't helpfull here I don't think. 17:38:37 <skvidal> this is noting against kde 17:38:38 <skvidal> :) 17:38:47 <j-rod> 1) technical people are bright enough to know they want kde 2) they're bright enough to read 'featuring gnome' in the default live 3) they can't possibly miss the 'kde fans, go here' button 17:38:52 <skvidal> this is against unnecessary naming 17:39:36 <Kevin_Kofler> My proposal is against misleading and incorrect naming. 17:39:41 <rdieter> skvidal: are you saying that if naming was undecided *right now*, things would be different? (I find it hard to believe, but welcome surprises) 17:39:45 <j-rod> there's no misleading 17:39:46 <Kevin_Kofler> The current naming misleads users into either thinking GNOME is the only available desktop environment in Fedora or thinking the image also provides the other options. 17:39:53 <skvidal> rdieter: huh? 17:39:57 * thomasj thinks: ugh.. kde fans have to go there.. nice.. 17:40:05 <Kevin_Kofler> Either way, we mislead them big time with that "Desktop" naming. 17:40:26 <rdieter> skvidal: unnecessary naming => maybe I misunderstood your comment 17:40:32 <Kevin_Kofler> There's no one desktop, there are 4 ones (2 of which very popular), not counting WM-only solutions. 17:40:33 <j-rod> but it is a desktop 17:40:39 <skvidal> rdieter: adding unnecessary names to the livecd 17:41:01 <rdieter> ok (/me hides in peanut gallery again) 17:41:06 <Kevin_Kofler> j-rod: GNOME is A desktop, it's not THE desktop! 17:41:14 <j-rod> its our main one 17:41:14 * jds2001 is using Windows at work right now, but on my home desktop i use Xfce (I have to admit nirik got me hooked) :) 17:41:15 <Kevin_Kofler> So it should say "GNOME Desktop", not just "Desktop". 17:41:28 <j-rod> it says gnome in the description 17:41:31 <Kevin_Kofler> Saying just "Desktop" implies there's only one. 17:41:37 <skvidal> Kevin_Kofler: no it doesn't 17:41:48 <skvidal> no more than saying 'livecd' implies there is only one 17:41:53 <skvidal> that implication is just in your mind 17:42:08 <Kevin_Kofler> It's also in the mind of many other people. 17:42:12 * jds2001 agrees with skvidal 17:42:20 <skvidal> Kevin_Kofler: who all think the same way as you, apparently 17:42:21 <Kevin_Kofler> If there's more than one option, there needs to be a qualifying term to distinguish them. 17:42:23 <jds2001> Kevin_Kofler: really? 17:42:33 <jds2001> I never thought that there was only one option. 17:42:34 <skvidal> Kevin_Kofler: oh cmon 17:42:44 <skvidal> Kevin_Kofler: that's a grandiose statement 17:42:47 <jwb> Kevin_Kofler, and having KDE as that qualifier doesn't suffice? 17:43:10 <jds2001> so we have livecd1, livecd2, livecd3 then?\ 17:43:12 <Kevin_Kofler> There's the Desktop and there's the KDE Desktop, that's confusing and unfair. 17:43:17 <skvidal> unfair? 17:43:21 <skvidal> who said anything about fair 17:43:26 <Kevin_Kofler> Saying there's the GNOME Desktop and there's the KDE Desktop is both fair and clear. 17:43:26 <skvidal> there is NO FAIR HERE 17:43:42 <nirik> and confusing also. 17:43:47 <notting> i think we're going in circles 17:43:47 <skvidal> Kevin_Kofler: do you say Gnu/Linux , too? 17:43:52 <notting> should we call a vote? 17:43:53 <Kevin_Kofler> skvidal: Yes, of course! 17:43:57 <skvidal> notting: yes, we should 17:43:58 * nirik is +1 on skvidal's proposal for now. 17:43:59 <jwb> so this seems to be more about promoting KDE on equal ground than it does about calling Gnome Gnome 17:44:04 * skvidal is +1 on his proposal 17:44:14 <jwb> i'm still 0 17:44:15 <sharkcz> +1 for skvidal's proposal 17:44:19 * Kevin_Kofler is -1 on skvidal's proposal, as already written. 17:44:25 * notting is -1 to the ticket. i suppose that's +1 to skvidal's proposal 17:44:26 * zcat thinks it's not such a big deal to name them all {GNOME,KDE,XFCE,foo}-Desktop. more consistent, if slightly more verbose for the 'gnome' default. 17:44:30 * jds2001 is +1 on skvidal's proposal, pending board input on their ongoing discussion. 17:44:31 <nirik> If Kevin_Kofler is wanting to take it to the board thats cool. Or if the board comes up with a target audience we should revisit based on that. 17:44:33 <j-rod> +1 for skvidal's prop, -1 for the ticket 17:44:38 <Kevin_Kofler> And why are we voting on the proposal to shoot down proposal #170 instead of voting on #170 directly? ;-) 17:44:49 <j-rod> I wondered that too 17:44:50 <jds2001> Kevin_Kofler: :) 17:44:56 <jwb> we like confusion 17:45:00 <skvidal> Kevin_Kofler: b/c I like to be positive :) 17:45:07 <jwb> which is why we just call it 'Desktop' 17:45:08 <skvidal> +1 looks nicer than -1 :) 17:45:11 * jwb runs fast 17:45:18 * nirik is happy to vote on either, do you think it will change the votes? :) 17:45:21 <Kevin_Kofler> skvidal: That's misleading naming, just like "Desktop Live" is. 17:45:24 <skvidal> I think we have 6 17:45:36 <skvidal> Kevin_Kofler: what's really great is that I don't think you're right and yet I think I am :) 17:45:40 <jds2001> I see six +1's (-1's to ticket 170), so the ticket is rejected 17:45:47 <Kevin_Kofler> :-( 17:46:02 <Kevin_Kofler> Why can't you folks listen to reason instead of continuing the lies? 17:46:11 <jwb> Kevin_Kofler, as nirik said, feel free to go to the Board with it 17:46:12 <j-rod> yes. that *must* be it. 17:46:22 <Kevin_Kofler> It doesn't make sense to say "Desktop" when you mean "GNOME". 17:46:32 <Kevin_Kofler> I don't see how this has ever made sense or will ever make sense. 17:46:33 <j-rod> I mean Desktop. 17:46:34 <skvidal> Kevin_Kofler: keep up the public defamation like that and we'll have a whole OTHER PROPOSAL 17:46:42 <jds2001> #agreed The Desktop live spin will not be renamed. Board input on this topic is welcomed and solicited as part of the "What is Fedora" discussion. 17:46:45 <bpepple> skvidal: +1 17:46:46 <j-rod> It just happens that the Desktop is Gnome. 17:46:49 <skvidal> Kevin_Kofler: the drama and invective is NOT useful and not helpful 17:47:08 <jds2001> NEXT! 17:47:23 <jds2001> #topic Critical Path package proposal. 17:47:28 <Kevin_Kofler> I can escalate it to the board, but I have a feeling it will be basically equivalent to /dev/null. 17:47:31 <jds2001> .fesco 171 17:47:35 <zodbot> jds2001: #171 (Critical Path Package Proposal) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/171 17:47:48 <Kevin_Kofler> -1 to this proposal. 17:48:02 <jds2001> um, why? 17:48:15 <Kevin_Kofler> Or I suggest we vote on this later, when we actually know what the list of critical packages actually IS. 17:48:20 <Kevin_Kofler> Why should we vote for a black box? 17:48:21 <nirik> this seems pretty hand wavy right now. 17:48:22 <jwb> it's not about the packages 17:48:24 <skvidal> the list of pkgs is given to change 17:48:28 <skvidal> and it's not baout the specific pkgs 17:48:31 <jds2001> i think the list is very dynamic. 17:48:32 <jwb> it's about the fact that some are more important than others 17:48:41 <skvidal> jwb: exactly 17:48:48 <skvidal> let's pitch it from another direction 17:48:51 <jwb> you aren't voting on a package list. you are voting on that idea 17:48:53 <skvidal> does anyone here think that all pkgs are equal? 17:48:56 <nirik> I like the idea, but the procedure seems vuage. 17:49:05 <skvidal> nirik: which part of the procedure? 17:49:08 <jwb> nirik, it almost has to be 17:49:11 <notting> my concern is the procedure is somewhat tied to some of the other FAD proposals 17:49:13 <nirik> is the scope here rawhide? or all releases? 17:49:16 <Kevin_Kofler> I think the proposed bureaucracy is unneeded and unhelpful. 17:49:21 <jwb> nirik, all 17:49:25 <notting> so we can approve this, and it can't do anything until we approve the others 17:49:29 <Kevin_Kofler> nirik: That was also a question I pointed out in my ticket comments. 17:49:37 <jwb> notting, which ones? 17:49:50 <notting> jwb: the two rawhides one (or whatever it's called) 17:49:52 <skvidal> jwb: autoqa and israwhidebroken come to mind 17:49:53 <jwb> Kevin_Kofler, that question is answerd in the Talk page 17:49:53 <nirik> ok, and so bodhi will be used to submit updates and if they are critical path they will need some additional approval to go stable? 17:50:07 <jwb> nirik, yes 17:50:15 <nirik> and who approves them? 17:50:18 <jwb> skvidal, notting: i think for rawhide, perhaps. for releases, no 17:50:24 <skvidal> nirik: member of releng or QA 17:50:26 <jwb> nirik, the suggestions are QA/releng 17:50:41 <Kevin_Kofler> From the talk page: "notting It's for both the pre-release rawhide and for updates. It ties into the 'multiple rawhides' proposal as well." 17:50:47 <Kevin_Kofler> WTF, multiple rawhides??? 17:50:59 <jwb> no frozen rawhide 17:51:05 <skvidal> Kevin_Kofler: you should have read those links from the other day 17:51:09 <jwb> it ties into it. it is not dependent on it 17:51:13 <nirik> so, for rawhide, these packages would not auto add to the buildroot until approved? 17:51:21 <nirik> or not until approved and pushed the next day? 17:51:43 <nirik> I'm worried this could slow down package trees that have lots of dependencies. 17:51:46 <notting> i think that as it stands on its own, it does not apply to rawhide, only to updates 17:51:48 <Kevin_Kofler> Hmmm, OK, No Frozen Rawhide actually makes sense. :-) 17:51:57 <Kevin_Kofler> The Critical Packages stuff doesn't, though. ;-) 17:52:00 <skvidal> nirik: which isn't the goal - but a nice perk 17:52:02 <jwb> notting, yes 17:52:06 <notting> it would need to be in combination with the 'no frozen rawhide' proposal to affect rawhide 17:52:13 <jwb> yes 17:52:44 <jds2001> Kevin_Kofler: a lot of the slips that we have come from breakage in critical packages. 17:52:51 <nirik> and qa/rel-eng thinks they have enough folks to pull this off? there wouldn't be big delays getting things approved? 17:53:01 <jds2001> so there is defintely impetus to fix it. 17:53:09 <jwb> nirik, every active member of rel-eng was in the FAD that this proposal came out of. nobody objected 17:53:33 <notting> nirik: QA is supportive but concerned? 17:53:34 <jds2001> nirik: part of the proposal was to get more folks in qa/rel-eng :) 17:53:35 <skvidal> nirik: I do not think the crit packages is that huge a number, first off, and secondly QA is a group that can add more people from the community 17:53:45 <notting> jlaska: did i get that right? 17:53:46 <jwb> and i believe skvidal is officially recruited because of this, so we grew by a member :) 17:53:47 <nirik> also, since the list is subject to change, how can a maintainer know they have a critical path package? 17:53:52 <skvidal> jwb: that's cute 17:54:05 <jwb> skvidal, am i wrong? 17:54:09 * jlaska reads back 17:54:23 <skvidal> jwb: no - I just love being drafted :) 17:54:34 <skvidal> jwb: and I needed an excuse to be snarky to you 17:54:38 <skvidal> so, yay 17:54:41 <skvidal> I got one 17:54:52 <nirik> is there a way for them to know before they push an update? or when they push it? or ? 17:54:58 <jwb> wait... when did we start needing excuses to be snarky? :) 17:55:13 <skvidal> jwb: I have a quota, if I go over I need an excuse 17:55:18 <jds2001> i didnt know we need any excuses to be snarky :) 17:55:35 <jlaska> notting: that's accurate, I like the idea. But need to think more about what expectations there are from QA 17:56:03 <skvidal> nirik: ??? 17:56:06 <skvidal> nirik: them == QA 17:56:08 <jlaska> if it's a community building opportunity, that's a "good thing" ... but it still requires some planning, care & feeding 17:56:11 <skvidal> or them == the packagewr? 17:56:12 <jds2001> jlaska: I'll just have to get unbusy and do more QA :) 17:56:14 <nirik> skvidal: no, them == packager. 17:56:23 <skvidal> nirik: if we approve this 17:56:34 <skvidal> we'll be churning out the list of pkgs that are critical path 17:56:49 <skvidal> those packagers will get notice that they now have new responsibilities 17:56:50 <j-rod> who makes the final call on the list? 17:56:55 <Kevin_Kofler> Why don't you come up with the list FIRST so we know what we're voting for/against? 17:57:02 <skvidal> j-rod: I'd see no reason for it not to be fesco 17:57:05 <nirik> skvidal: how often does this list change? 17:57:16 <skvidal> nirik: whenever necessary 17:57:25 <skvidal> nirik: when new deps are added, new items pulled into base/core 17:57:28 <nirik> when it does then you mail maintainers? 17:57:30 <skvidal> excuse me @base @core 17:57:40 <j-rod> I'm fine with agreeing to the proposal with the caveat that the list will also be approved here 17:57:52 <notting> nirik: the usage cases that drive the list (can boot, can get updates, etc.) wouldn't change. i think the list would only change if the providers of those usage cases change (or change their deps) 17:57:55 <skvidal> nirik: when new pkgs are added they will be told and explained that they are now in the critical path 17:58:07 <skvidal> and that they have a couple of choices 17:58:12 <Kevin_Kofler> I still see this proposal as a solution looking for a problem. 17:58:12 <j-rod> It makes a ton of sense for kernel, anaconda, coreutils and a handful of other things at the very least 17:58:13 <notting> so, if someone rewrote yum in prolog, python would fall out of the list 17:58:15 <skvidal> 1. comply with the policies for pushing updates 17:58:31 <skvidal> 2. find another person to maintain the pkg who will comply with the policies 17:58:41 <skvidal> (2.5: just walk away from the pkg) 17:58:47 <j-rod> if someone pushes a busted kernel or anaconda, the tree is largely useless for testing 17:58:56 <skvidal> j-rod: or yum 17:58:57 <jds2001> Kevin_Kofler: the problem is very real. 17:58:59 <skvidal> or createrepo 17:59:04 <skvidal> or pungi 17:59:07 <skvidal> or mock 17:59:10 <skvidal> or rpm 17:59:13 <skvidal> or python 17:59:16 <jwb> j-rod, approving the list is sort of pointless 17:59:37 <Kevin_Kofler> jds2001: Where? In Rawhide? Having to wait for manual approval (outside of freezes) defeats the purpose of Rawhide. 17:59:39 <j-rod> jwb: well, for the most part, the things on the list should be no-brainers 17:59:40 <skvidal> jwb: well - approving the methodology to establish the list seems reasonable-ish 17:59:41 <notting> c.f. also the d-bus fun, which was a 'pushed stable w/o testing' issue; this is enforcing some level of testing/sanity on the packages that truly need it 17:59:47 <nirik> skvidal: yeah, thats fine. I didn't see any talk about how to communicate to maintainers that they have a critical path package in the proposal. 17:59:58 <j-rod> but there could be some fringe items, in theory 17:59:59 <Kevin_Kofler> In frozen Rawhide or updates, fatal breakage was already extremely rare. 18:00:13 <skvidal> umm 18:00:14 <Kevin_Kofler> I'm aware of only one big breakage in updates (that D-Bus "security fix"). 18:00:14 <skvidal> no it's not 18:00:22 <skvidal> rawhide is frequently not able to compose 18:00:25 <skvidal> for ALL sorts of reasons 18:00:26 <jwb> skvidal, yes. methodology is fine 18:00:27 <jwb> list is not 18:00:36 <skvidal> and it is VERY OFTEN not able to be installed 18:00:40 <Kevin_Kofler> That's unfrozen Rawhide. 18:00:45 <Kevin_Kofler> It's EXPECTED TO not compose. 18:00:55 <Kevin_Kofler> Adding extra manual steps defeats the purpose of Rawhide. 18:00:56 <j-rod> no, its expected to compose 18:00:57 <skvidal> and that's what we're trying to change 18:01:07 * mclasen doesn't think installing rawhide is the most important thing... 18:01:16 <Kevin_Kofler> Plus, your proposal as written doesn't even mention Rawhide. 18:01:28 <notting> Kevin_Kofler: that's a different proposal 18:01:28 <j-rod> I see this as being most useful for rawhide or frozen rawhide leading up to a release 18:01:34 <jds2001> Kevin_Kofler: that's where multiple rawhides come in. 18:01:49 <jwb> j-rod, it's quite useful post-release too 18:01:51 <j-rod> installing rawhide leading up to a release is rather important 18:01:55 <Kevin_Kofler> Well, it does at the beginning of "Overview", but "Scope" says: 18:01:59 <Kevin_Kofler> "QA/Releng to provide extra attention to update/freeze requests for packages within the critical path" 18:02:16 <j-rod> jwb: yeah, there too, but at least in my experience, rawhide is where things get tanked more often 18:02:17 <Kevin_Kofler> which appears to imply it applies to updates and freezes, not regular Rawhide. 18:02:25 <skvidal> so back to what I asked earlier - I just want a straw-man poll 18:02:25 <jwb> j-rod, yes 18:02:37 <Kevin_Kofler> jds2001: I don't think we should have multiple Rawhides outside of the final freeze. 18:02:40 <skvidal> does anyone think that some pkgs are more 'critical' to doing EVERYTHING else? 18:02:44 <Kevin_Kofler> It makes sense to start the next release's Rawhide early. 18:02:45 * jds2001 is +1 to this proposal. 18:02:52 <Kevin_Kofler> It doesn't make sense to put Rawhide into a permanent freeze. 18:02:53 <j-rod> +1 18:03:28 <j-rod> (that is, +1, some packages are more critical) 18:03:31 <skvidal> Kevin_Kofler: we're not putting it into a permanent freeze - we're only putting some pkgs into a "need closer attention" state 18:03:51 <Kevin_Kofler> As I wrote, I'm -1 to #171 in its current state, I'm doubtful about the usefulness and I think there are a lot of open interrogatives. 18:04:17 <skvidal> Kevin_Kofler: so to my question - that j-rod just answered 18:04:32 <skvidal> Kevin_Kofler: do you think some pkgs are more critical to doing everything else? 18:04:39 <sharkcz> +1 for the proposal 18:04:40 <nirik> yes, some packages are more critical... 18:04:55 <skvidal> nirik: do you think we should have more rigor in the process for those pkgs? 18:04:56 <Kevin_Kofler> Of course some packages are more critical than others, but that doesn't mean they need extra manual validation to reach even Rawhide. 18:05:21 <skvidal> Kevin_Kofler: do they need more validation to go to updates-released? 18:05:42 <Kevin_Kofler> Plus, what's critical? To me KDM is critical, if KDM fails, I have to unbreak things manually. 18:05:48 <nirik> skvidal: yes, I think this is a good idea. :) I like the proposal, but the proposal page seems lacking in some details to me. 18:05:58 <Kevin_Kofler> For other users, KDM isn't even installed. 18:06:11 <jds2001> Kevin_Kofler: you're more than welcome to make kdm subject to this. 18:06:13 <Kevin_Kofler> (some other users, not all other users, of course ;-) ) 18:06:18 <jwb> Kevin_Kofler, there is a common set 18:06:18 <nirik> Kevin_Kofler: if pungi didn't work, you have nothing to install, if the kernel doesn't boot you can't run kdm, if anaconda didn't run you couldn't install kdm 18:06:36 <Kevin_Kofler> I see these as being clearly critical. 18:06:43 <Kevin_Kofler> But there are plenty of others which can be argued. 18:06:45 <skvidal> nirik: I believe I am going to get tshirts made up: My code installs your code 18:06:54 <nirik> skvidal: ha. 18:07:02 <Kevin_Kofler> GDM, KDM, even XDM could be argued to be critical. 18:07:16 <skvidal> Kevin_Kofler: which is why we're following the default install for these purposes 18:07:19 <Kevin_Kofler> And then there's fun like bitmap-fonts on the current list. 18:07:20 <skvidal> which means GDM 18:07:36 <Kevin_Kofler> skvidal: And this once again assumes there's just one default install. 18:07:37 <skvidal> Kevin_Kofler: which is why we're not approving the list - just the proposal 18:07:43 <skvidal> Kevin_Kofler: there is. 18:07:46 <Kevin_Kofler> When actually the default depends on what you install from. 18:07:47 <jds2001> Kevin_Kofler: those fall into "login" 18:08:02 <nirik> in any case I am ok with the proposal, but I think it could use some additional details... mentioning the rawhide/release cases, note that maintainers get notified and have options, note that qa needs to be on board and staffed for it, etc. 18:08:36 <ajax> xdm is critical if kdm is critical, since kdm is broken and thinks xdm config files are an interface worthy of supporting 18:08:49 <nirik> also, I worry for rawhide especially at the end of a cycle for things like anaconda... say they fixed 20 bugs in a release, can qa really test all those before pushing the update? 18:09:06 <j-rod> for the record, I don't think gdm, kdm or xdm or fudm is critical path... 18:09:09 <Kevin_Kofler> ajax: Hmmm, that's true, KDM shares some files with XDM. 18:09:12 <Kevin_Kofler> It could be packaged not to. 18:09:27 <Kevin_Kofler> It's just packaged that way because sharing is better than copying. 18:09:32 <ajax> i am happy to give that package away to someone who cares 18:09:32 <jds2001> ok, so where are we on this? 18:09:36 <ajax> but this is aside 18:09:38 <notting> nirik: i think that the case is not always 'did all these bugs get fixed' as much as 'is it reasonable enough that it's not going to break everyone else in the process' 18:09:40 * jds2001 saw 3 +1's 18:09:45 * notting is +1 to the proposal 18:09:52 <jwb> +1 18:09:53 <nirik> notting: agreed... 18:10:06 * jds2001 sees 5 +1's 18:10:22 <skvidal> jds2001: did you count mine? :) 18:10:30 <jds2001> #agreed the critical path package proposal is approved. 18:10:33 <nirik> I guess I am +1 too, but would like to see the above points addressed on the page. ;) 18:10:34 <jds2001> skvidal: i think so. 18:10:46 <skvidal> nirik: it's on my list to do so now 18:10:51 <jds2001> either way, it's approved :) 18:10:52 <skvidal> nirik: (well, it's on my list, now, I'll do it shortly) 18:10:55 <nirik> also, if this doesn't work, we can said we tried and move on to trying something else... I don't see the harm in trying it. 18:10:57 <Kevin_Kofler> I'd like nirik's point addressed too (and that's one of the reasons for my dissent). 18:11:06 <jds2001> on to some features........ 18:11:18 <jds2001> #topic Better Webcam support 18:11:26 <jds2001> .fesco 172 18:11:30 <zodbot> jds2001: #172 (Better Webcam Support for F12 -http://tinyurl.com/nvymts) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/172 18:12:14 <Kevin_Kofler> +1 to #172, feature page looks complete, feature is worthwhile, doesn't break anything. 18:12:21 <nirik> +1 here. 18:12:24 <sharkcz> +1 18:12:26 <j-rod> +1 18:12:29 <jwb> so this is Better Better Webcam support? 18:12:30 <jds2001> +1 18:12:35 <jwb> we had this in F-10 18:12:38 <skvidal> jwb: better^2 18:12:40 <jds2001> jwb: yeah :) 18:12:43 <jwb> how many times are we going to keep saying better? 18:12:44 <notting> mo'better 18:12:46 <notting> +1 18:12:55 <jwb> i will be +1 only if we call it mo' better 18:12:55 <j-rod> better II: the rebettering 18:12:58 <jds2001> jwb: til it stops getting better :) 18:13:08 <Kevin_Kofler> jwb: Each time it gets better. ;-) 18:13:13 <skvidal> I'm +1'ing jwb's suggestion 18:13:14 <jds2001> but having a "worse webcam support" feature might not fly so well :) 18:13:16 <jwb> jds2001, how is that different from every other advancement we make in the distro? 18:13:20 <skvidal> rename feature to 'mo' better' 18:13:43 <jwb> sorry, the 'Better X' features annoy the crap out of me 18:14:02 <jds2001> maybe expanded webcam support? 18:14:10 <jds2001> it seems that they're adding support for new hardware here. 18:14:11 <Kevin_Kofler> -1 to "mo' better", that slang isn't internationally understood and it doesn't make sense. 18:14:27 <jds2001> Kevin_Kofler: it was a joke. 18:14:34 * skvidal was kidding too 18:14:34 <jwb> yes, it was 18:14:44 <j-rod> -1 to jokes, they aren't internationally understood either 18:14:51 <skvidal> but I think I have validated my test 18:14:54 <Kevin_Kofler> ;-) 18:14:57 * skvidal proposes that the sky is green 18:15:01 <jwb> jds2001, you have a passed Feature. 5 +1s 18:15:02 * skvidal waits for Kevin_Kofler to -1 the propsal 18:15:05 * nirik suggests we move on. 18:15:13 <jds2001> +1 to the sky being green when a tornado is around :) 18:15:31 <jds2001> and if you've never seen it, quite a sight :) 18:15:36 <Kevin_Kofler> LOL 18:15:42 <jds2001> anyhow...... 18:15:49 <j-rod> the snarkiness is palpable 18:16:04 <jwb> mmmm snarky tacos 18:16:09 <ajax> snarcos 18:16:27 <j-rod> with snarcohol 18:16:36 <notting> next? 18:16:37 <skvidal> okie doke 18:16:38 <skvidal> do we have more? 18:16:39 <jds2001> i see 7 +1's to the better webcam support feature 18:16:48 <skvidal> jds2001: do we need more? 18:16:48 * j-rod stops now... 18:16:53 <jds2001> #agreed Better webcam support F12 feature is approved 18:17:03 <jds2001> skvidal: nope, need 5 :) 18:17:10 * jds2001 is not the fastest typist sometimes :) 18:17:14 <skvidal> jds2001: I could throw in a couple more - you know - just ballot stuffing 18:17:34 <jds2001> .fesco 173 18:17:38 <zodbot> jds2001: #173 (DisplayPort - https://fedoraproject.org/wiki/Features/DisplayPort) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/173 18:17:41 <jds2001> #topic DisplayPort feature 18:18:01 <Kevin_Kofler> "Documentation: FIXME: None yet."? :-( 18:18:10 <ajax> it shouldn't need any. 18:18:11 <jds2001> yeah :( 18:18:17 <ajax> besides, you know, "DisplayPort works" 18:18:30 <ajax> it's not like we have documentation for DVI support 18:18:32 <jds2001> maybe something about why displayport is the bestest thing around? 18:18:35 <skvidal> ajax: if it continues to not work in f12 - does it make the world break for anything else? 18:18:38 <Kevin_Kofler> ajax: I think that's right, so should the feature page just say so? 18:18:45 <notting> jds2001: does not require paying HDMI consortium tax 18:18:52 <jds2001> tbh I'd never heard of it prior to adding the feature to the agenda. 18:18:52 <jwb> jds2001, which would be in the 'Benefit to Fedora' section 18:18:52 <Kevin_Kofler> Or should we just enter a link to the Wikipedia page about DisplayPort? ;-) 18:19:05 <ajax> skvidal: nope. 18:19:17 <skvidal> +1 to the proposal, then 18:19:30 <Kevin_Kofler> +1 to the DisplayPort feature (#173) 18:19:33 <notting> +1 18:19:35 <sharkcz> +1 18:19:35 <jds2001> +1 18:19:38 <jwb> ajax, is this realistically going to be complete by Beta? 18:19:45 <nirik> +1 18:19:59 <ajax> jwb: for intel and uniphy, probably. 18:20:00 <j-rod> "See this grid? Fill it in." awesome. 18:20:02 <j-rod> +1 18:20:09 <jds2001> i see six +1's, so the displayport feature is accepted. 18:20:10 <jwb> ajax, ok 18:20:11 <jwb> +1 18:20:31 <tibbs_> I'd love for someone to tell me what displayport hardware to buy so that I can test it. 18:20:33 <ajax> nv and kldscp, enh. but there's only two cards in the world in those sets, afaik, and i might be the only one with them. 18:20:47 <ajax> tibbs_: i can do that 18:20:56 <ajax> in fact, i should add that to the test matrix so everyone knows 18:21:14 <jds2001> #agreed the DisplayPort feature is accepted. 18:21:35 <jds2001> #topic NM Mobile broadband for F12 18:21:44 <jds2001> .fesco 174 18:21:47 <zodbot> jds2001: #174 (NetworkManager Mobile Broadband F12 - http://tinyurl.com/5wf6am) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/174 18:22:00 <Kevin_Kofler> Hmmm, I take it that NM 0.8 is backwards-API-compatible with 0.7 (unlike 0.7 was with 0.6)? 18:22:20 <jwb> how is that relevant? 18:22:34 <notting> presumably for knetworkmanager 18:22:46 <Kevin_Kofler> Rather kde-plasma-networkmanagement these days. 18:22:48 <jwb> no, seriously. how is that relevant to a Feature? 18:22:55 * jds2001 sees that as irrelevant as well. 18:23:03 <jds2001> I don't think it really is. 18:23:04 <Kevin_Kofler> Core system libs shouldn't break stuff. 18:23:09 <jwb> if we deny the Feature, do you think NM 0.8 won't happen? 18:23:13 <notting> jwb: well, if we're going to break it, we should know 18:23:24 <jwb> sure. outside the scope of the feature 18:23:41 <notting> ... not really, imo 18:24:03 <nirik> +1 here... I would love signal strength to work here. 18:24:09 <Kevin_Kofler> "Documentation: FIXME" doesn't look great either. 18:24:16 <jwb> notting, i think you're kidding yourself a bit 18:24:20 <jds2001> this feature simply says that NM will grow the ability to get signal strength and select networks. 18:24:35 * jds2001 sees nothing about API compatibility, nor any need for such. 18:25:06 <j-rod> who/what uses the API (I plead ignorance here, not trying to be an ass (this time)) 18:25:08 <Kevin_Kofler> And Summary should mention "nm-applet (from NetworkManager-gnome)", because that's the only UI supporting this yet. 18:25:44 <Kevin_Kofler> j-rod: kde-plasma-networkmanagement and Solid (KDE's hardware abstraction layer). 18:25:45 <notting> j-rod: nm-gnome, kde-plasma-networkmanagement, cnetworkmanager, networkmanager-netbook 18:26:09 <Kevin_Kofler> notting: Right, there's also cnetworkmanager and networkmanager-netbook. 18:26:24 <j-rod> I'd assumed NetworkManager-gnome was updated lockstep w/NetworkManager 18:26:39 <Kevin_Kofler> Of course, it's also part of this feature. 18:26:41 <jds2001> j-rod: it is. 18:26:45 <Kevin_Kofler> (That's where the UI is being implemented.) 18:26:50 <nirik> cnetworkmanager already sees the broadband card here fine... no idea if it can do signal strength... probibly not. 18:27:04 <Kevin_Kofler> But the other stuff is separate, thus my question about API compatibility. 18:27:05 <jds2001> j-rod: i think Kevin_Kofler is saying that the KDE stuff is not released in lockstep w/NM 18:27:19 <jwb> it's a fair question 18:27:20 <nirik> well, I guess it shows wireless network levels ok. 18:27:28 <jwb> it should be sorted one way or another 18:27:31 <Kevin_Kofler> jds2001: Exactly, and I guess neither is the command-line and netbook stuff. 18:27:39 <jwb> but i still don't see how it impacts the Feature 18:27:47 <notting> trying to get a hold of dcbw. we have other features, perhaps come back to this one? 18:27:59 <j-rod> ok, so would be good if it didn't bust those, but I presume its early enough to sort it out if it does 18:28:02 <Kevin_Kofler> I think we're through the meeting agenda, actually. 18:28:18 <jwb> notting, would you reject the Feature if it didn't work in KDE? 18:28:26 <jwb> or with one of the other applets? 18:28:52 <Kevin_Kofler> jwb: FWIW, I would and I'd also ask the actual upgrade to be blocked or reverted. 18:29:06 <jds2001> notting: yeah, this is the last one 18:29:18 <notting> jwb: i just want the question of whether it breaks other things answered, so things that it would break could react appropriately with time to do something, as opposed to finding out if/when it lands around feature freeze 18:29:19 <j-rod> if the feature doesn't work, but also doesn't break anything, I don't see an issue 18:29:36 <j-rod> (for !NM-gnome applets, that is) 18:29:41 <nirik> perhaps we could defer and ask dcbw those questions? 18:29:47 <jwb> notting, wow. that sounds almost like a critical path issue 18:30:04 <jds2001> and common sense. 18:30:51 <jds2001> anyhow, let's defer this. 18:30:54 <Kevin_Kofler> What should be clearly written in the summary or at least the detailed description is which UIs (AFAIK just NM-gnome's nm-applet) support this (or will support this at F12 release time). 18:31:07 <Kevin_Kofler> This is important information which needs to be part of the feature's description. 18:31:35 <jds2001> #agreed NM Mobile Broadband feature is deferred until clarification on hte non-breakage of other NM applets. 18:31:50 <jwb> agreed. good thing it's on a wiki so it can be updated by people implementing the support for other applets 18:31:50 <jds2001> #topic open floor 18:31:57 <jds2001> anything else? 18:32:02 <Kevin_Kofler> (Especially because the plan is to ship kde-plasma-nm on the KDE spin in F12, so NM-gnome won't be "the one frontend everyone uses" anymore.) 18:32:19 <jwb> neat 18:32:31 <jds2001> sounds like a feature to me :) 18:33:18 <Kevin_Kofler> A PS for my proposal which got shot down: why do you think I got voted into FESCo? My platform was clear... So IMHO you're going against the wills of your electors by shooting down the proposal that way. 18:33:42 <nirik> Kevin_Kofler: get the electors to elect another 4 people who feel as you do? 18:34:00 <Kevin_Kofler> First I'll need them to run... ;-) 18:34:06 <notting> ... if your sole reason for running was a single issue, you may want to re-examine your choices 18:34:14 <jds2001> notting: +1 18:34:22 <skvidal> Kevin_Kofler: and 3 other people got more votes than you 18:34:35 <skvidal> Kevin_Kofler: if you want to have a dicksize war - I think notting and I can take the cake 18:34:36 * mclasen just voted for kkofler to have more lively fesco meetings to watch :-) 18:34:42 <notting> hah 18:34:47 <Kevin_Kofler> LOL 18:34:49 <skvidal> mclasen: :) 18:35:13 * rdieter wants to vote for mclasen next time. :) 18:35:25 <skvidal> I think I'm going to write up a 'there is no anti-kde cabal' web page so I can just refer to it whenever the subject is brought up 18:35:27 <maxamillion> rdieter: you can vote for me next time :) 18:36:02 <skvidal> from standard_responses import no_anti_kde_cabal 18:36:09 <Kevin_Kofler> skvidal: Your platform wasn't "I'll make sure we'll call GNOME just 'Desktop' everywhere." though... 18:36:31 <Kevin_Kofler> So just saying you got more votes than me doesn't mean more people want GNOME named just "Desktop". 18:36:38 <skvidal> Kevin_Kofler: yes b/c I actually care about fedora as a whole 18:36:56 <skvidal> Kevin_Kofler: and correlation doesn't mean causation for why you got elected 18:37:06 * jds2001 too, and that includes KDE, btw - even though I don't personally use it. 18:37:09 <skvidal> so let's move along.... 18:37:23 <Kevin_Kofler> I care about Fedora as a whole. You're the one who appears to only care about a single desktop environment. 18:37:33 <skvidal> hahah 18:37:34 <jds2001> NEXT! 18:37:36 * skvidal loves this argument 18:37:37 <skvidal> so much 18:37:39 <jds2001> anything else? 18:37:43 <jwb> this is awesomely on topic... 18:37:56 <skvidal> jds2001: can I add a neener neener and waggle my tongue? :) 18:38:02 <notting> agk____: you still around? 18:38:03 <jds2001> ok, if you folks want to continue, i surely won't object :) 18:38:07 <skvidal> jds2001: :) 18:38:17 <notting> agk____: if so... what's this discussion you are mentioning is going on @ fudcon? 18:38:27 <skvidal> notting: good question 18:38:35 <jwb> notting, i think there is a pool of security people at FUDCon Berlin 18:38:49 <jwb> and they are discussing security-ish things 18:39:00 * thomasj votes next time for a better fedora webpage, with no "KDE Fans go there".. That would help more than a iso-rename 18:39:01 <skvidal> jwb: I know autosign was discussed 18:39:07 * nirik notes that if the critical path thing was in place, glibc in rawhide wouldn't have just started breaking builds. ;) 18:39:14 <skvidal> thomasj: talk to the websites people 18:39:18 <notting> nirik: heh 18:39:25 <thomasj> skvidal, thanks, will do 18:39:30 <skvidal> nirik: hmmm, I apologize we didn't work on this inside the time machine 18:39:30 <Kevin_Kofler> skvidal: Oh, and I also have opinions about other topics than just that "single issue", for example I don't like your "Critical Packages" stuff. ;-) 18:39:31 <jwb> skvidal, yeah. i don't know what the outcome was, but i saw that 18:39:40 <jds2001> thomasj: we actually discussed that a few weeks back. 18:39:44 <thomasj> oh 18:39:49 <nirik> skvidal: slacker. ;) 18:39:50 <jwb> Kevin_Kofler, seriously. not helpful 18:39:51 <thomasj> jds2001, rejected? 18:39:54 <skvidal> nirik: I know. 18:39:59 <jds2001> and deferred to the design team for implementation 18:40:10 <jds2001> and that's how the KDE Fans go here got put there. 18:40:11 <skvidal> design team is the new websites/arts people? 18:40:17 <jds2001> iirc 18:40:19 <jds2001> skvidal: yeah 18:40:22 <skvidal> cool 18:40:27 <Kevin_Kofler> thomasj: Make sure you clarify your proposal or they'll interpret it to mean to hide KDE entirely. :-( 18:40:51 <thomasj> I will do it the right way ;) 18:41:16 <jds2001> im sure they welcome patches :) 18:41:21 <thomasj> cool 18:41:30 <jds2001> but the concern that mizmo had was presenting a ton of options to the user. 18:41:35 <jds2001> our old page was utter fail. 18:42:02 <Kevin_Kofler> The options exist, they need to be shown. 18:42:08 <Kevin_Kofler> Sweeping them under the carpet is bad. 18:42:16 <Kevin_Kofler> I also hate how x86_64 is being hidden. 18:42:21 <nirik> presenting them all on the top page is also fail. 18:42:22 <jds2001> and I defer to her on design decisions, since I couldn't design my way out of a paper bag :) 18:42:29 <j-rod> hey, I was just going to mention x86_64 18:42:43 <nirik> perhaps we could come up with a better way somehow. I'm sure they are open to creative ideas. 18:43:08 <Kevin_Kofler> jds2001: The problem is, if you read her credentials (GNOME Women membership etc.), she's very biased. 18:43:13 <nirik> also, x86_64/i686 dual arch disks would be lovely. 18:43:33 <j-rod> so it should be "Get Fedora 11 GNOME Desktop Edition for Intel Pentium, Pentium II, Pentium III, early Pentium IV, Core Duo, AMD Athlon XP, Athlon MP, Via C3... Now!" 18:43:33 * thomasj will make a main page and send it to the website people, so they can decide if it's better or not. 18:43:56 <thomasj> eeww 18:44:07 <j-rod> (yes, I left some off, it got tiring typing that many ancient crappy processors) 18:44:36 <Kevin_Kofler> I think i686 should be deprecated and clearly advertised as only for old computers or netbooks, not catered for with dual-arch disks. 18:44:48 <j-rod> ha. powerpc is more obviously displayed than x86_64 is 18:44:57 <nirik> Kevin_Kofler: but how do people who don't know much know what cpu they have? 18:44:59 <skvidal> j-rod: b/c we like jwb :) 18:45:00 <j-rod> now *that* is giggles 18:45:29 * j-rod glances at the 3 ppc boxes in his cube, shudders slightly... 18:45:29 <Kevin_Kofler> j-rod: Indeed it is, and that's one of the big issues with the current download page. 18:45:33 <nirik> at least dual arch disks would let that get decided at install time. 18:45:42 <jds2001> i need to install a HD in my G4 and then jwb gets to be my personal "let's get Fedora on this" helper :D 18:45:55 <Kevin_Kofler> People don't even know x86_64 exists unless they click on the link to show all options, which doesn't indicate anywhere that it contains options not listed anywhere else. 18:46:08 <j-rod> that reminds me, both nv and nouveau are quite badly tanked on my own G4 18:46:17 <Kevin_Kofler> nirik: From the error message the default image (x86_64) spits out. ;-) 18:46:35 <ajax> or we could just make dual-arch dvds work 18:46:38 <nirik> Kevin_Kofler: so they downloaded a dvd, it doesn't work, and you think they would download another one? 18:46:43 <j-rod> +1 for dual-arch DVDs 18:46:50 <j-rod> you know, like ppc has 18:46:54 <skvidal> j-rod: +1 for unicorns 18:46:55 <j-rod> only better 18:46:57 <nirik> I would be willing to bet a pile of them would say screw it and move on to something else. 18:46:57 <Kevin_Kofler> If they really want Fedora, they will. 18:46:59 <skvidal> j-rod: and magical ponies 18:47:04 <j-rod> yesssss! 18:47:05 <Kevin_Kofler> If they don't, why should we force them to use it. 18:47:06 <skvidal> nirik: nod 18:47:17 <nirik> +1 to useless +1ings. 18:47:23 * nirik suspects the meeting was over a while ago. 18:47:31 <jds2001> yeah 18:47:32 <j-rod> Kevin_Kofler: now, that same logic can be applied to other things as well... 18:47:34 <notting> that was what i was wondering... we seem to have drifted off field 18:47:37 * jds2001 officially puts a fork in it. 18:47:44 <jds2001> #endmeeting

49 220

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel June 2009