Interested in scanning?
by Bastien Nocera
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
14 years, 9 months
- 22
- 30
beagle
by Michael Schwendt
* 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".
14 years, 9 months
- 5
- 8
http://www.fsf.org/news/dont-depend-on-mono
by Frank Murphy
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
14 years, 9 months
- 24
- 60
an update to automake-1.11?
by Owen Taylor
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
14 years, 9 months
- 33
- 133
No sound in rawhide
by Paul F. Johnson
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!
14 years, 9 months
- 9
- 13
Re: Do we need split media CDs for F12?
by Robert 'Bob' Jensen
----- "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 |
------------------------------------------------------------------------
14 years, 9 months
- 2
- 1
Keyboard US Internacional
by Rodrigo Padula de Oliveira
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
14 years, 9 months
- 8
- 12
Re: http://www.fsf.org/news/dont-depend-on-mono
by Liang Suilong
>梁穗隆 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!
14 years, 9 months
- 6
- 5
Building packages for EPEL
by Dennis Gilmore
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
14 years, 9 months
- 6
- 7
FESCo meeting summary for 2009-06-26
by Jon Stanley
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.200...
Log: http://www.scrye.com/~kevin/fedora/Fedora-Meeting/2009/Fedora-Meeting.200...
----
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
14 years, 9 months
- 49
- 220