1:50 p.m.
It's time to bite the bullet.
There will be no more releases of Fedora Core or Fedora Extras.
Wait! Where are you going? Come back!
I'm serious. We've talked all along about how there should be
no differences in how packages are treated whether they are
in Core, or they are in Extras; no differences depending on who
maintains the package. The best solution to this?
Eliminate the distinction between Core and Extras entirely.
Starting with Fedora 7, there is no more Core, and no more Extras;
there is only Fedora. One single repository, built in the community
on open source tools, assembled into whatever spins the Fedora community
desires.
Are we there yet right now? No. There's a lot of work to be done,
and we're looking for help. What's left of the Core Steering Committee
is going to work with the Fedora Board and FESCO to figure out just
how this new combined repository is going to be governed and managed.
In the meantime, just because we're not going to have a release of
Core or Extras doesn't mean we're not going to have a release.
Hence, Fedora 7. Name TBD, but probably not 'Bride of Zod'.
http://fedoraproject.org/wiki/Releases/7
The current schedule is:
23 January 2007 | F7 Test1 development freeze
30 January 2007 | F7 Test1 Release
20 February 2007 | F7 FEATURE Freeze
| F7 string freeze
| F7 Test2 development freeze
27 February 2007 | F7 Test2 release
19 March 2007 | F7 translation freeze
| F7 Test3 development freeze
26 March 2007 | F7 Test3 release
... Continual freeze. Only critical bugs fixed ...
5 April 2007 | Final devel freeze.
26 April 2007 | F7 General Availability
And, what would a release be without features. We've identified
28 features that we'd like to include in the release, available
at http://fedoraproject.org/wiki/Releases/7/Features:
- Modify the build system to support this new paradigm
- Merge Core and Extras in source control
- Use the new pungi tool to spin all releases
- A Fedora Desktop spin
- A Fedora Server spin
- A Fedora KDE spin
- Make LiveCDs as a part of the distribution release process
- Ability to customize non-packaging distrubution parameters
- Switch to libata drivers for PATA support
- Speedup of bootup and shutdown
- Make wireless rock-solid
- Add wireless firmware for all the chipsets we can
- CodecBuddy
- Fixing the proliferation of dictionary packages
- Support encrypted filesystems
- Fast user switching in the desktop
- Fix the firewire stack
- Switch to a tickless kernel by default
- Fix unnecessary wakeups across the distribution
- Add KVM virtualization support to our tools
- Investigate (but probably don't switch to) new init technologies
- Add the nouveau drivers for nVidia cards
- Speed up Yum and RPM
- Add support for RandR 1.2
- Switch to syslog-ng
- Make the update system useable by all
More information on each of these features is available on the
wiki, including responsible people and plans. If you'd like to
chip in on these features, please, do!
If you've got new features you'd like to add, and you are willing
to do the work, or have the ability to get others to do the work
for you, we can add them too. Note that Test2 is the feature freeze.
Here's to making Fedora 7 the best release yet!
Bill
2:56 p.m.
Good evening,
On Thu, 04 Jan 2007, Bill Nottingham wrote:
There will be no more releases of Fedora Core or Fedora Extras.
Sounds nice, even I'm curious whether this can be realized until April.
And What will be the release tagging of the new "Fedora 7"? Won't there be
no magic .fc7 dist any longer? IMHO .f7 looks odd and causes problem with
rpmvercmp. We could take this as reason to rename Fedora again ;-)
Wait! Where are you going? Come back!
Nope, why to drive Fedora's highway to hell? Just kidding. For Fedora 7 we
absolutely should fix the bugs #132925, #152435, #192854, #220265, #193475,
#206697, #212780 as they're longer open but unfortunately silent moved from
one Fedora release to another and most of them are tagged EasyFix, too.
- Add wireless firmware for all the chipsets we can
It doesn't match really, but can we please also get rid of bug #212890 for
Fedora 7, as this problem is related.
- Investigate (but probably don't switch to) new init
technologies
- Switch to syslog-ng
Aren't these two not the same and don't they conflict each other? Or did I
understand something wrong?
- Speed up Yum and RPM
Does this mean, we get the new magic RPM until April with the new community
as proposed by Max some time ago? Or do we really want ship the old and
nearly antiquaric and heavily patched RPM 4.4.2 for another Fedora release?
Hopefully not.
So far, so good. Anyway you all hopefully slipped very well into 2007.
Greetings,
Robert
3:12 p.m.
On Thu, 2007-01-04 at 21:56 +0100, Robert Scheck wrote:
> - Investigate (but probably don't switch to) new init technologies
> - Switch to syslog-ng
Aren't these two not the same and don't they conflict each other? Or did I
understand something wrong?
No. Init is init. syslog-ng is syslog. One serves as the init process
for the box, the other the logger.
josh
3:15 p.m.
Robert Scheck wrote:
Sounds nice, even I'm curious whether this can be realized until
April.
And What will be the release tagging of the new "Fedora 7"? Won't there be
no magic .fc7 dist any longer? IMHO .f7 looks odd and causes problem with
rpmvercmp. We could take this as reason to rename Fedora again ;-)
The %dist tag could be expanded to something like ".fedora7" instead (which is
greater than ".fc6" according to rpmvercmp.
> - Investigate (but probably don't switch to) new init
technologies
> - Switch to syslog-ng
Aren't these two not the same and don't they conflict each other? Or did I
understand something wrong?
syslog-ng is (may become) the new system logging daemon, to replace syslogd
as-is. The new init technologies referred to are ideas like InitNG or similar
that work with or replace the older SysVinit stuff to help increase the
boot time and efficiency by doing things such as preloading, asynchronous
startups where possible, potential D-Bus integration, etc. They are not the
same thing. :]
So far, so good. Anyway you all hopefully slipped very well into
2007.
Agreed. Go go go Fedora! WOO! :D
--
Peter Gordon (codergeek42)
This message was sent through a webmail
interface, and thus not signed.
3:37 p.m.
On Thu, Jan 04, 2007 at 01:15:17PM -0800, Peter Gordon wrote:
The %dist tag could be expanded to something like
".fedora7" instead (which is
greater than ".fc6" according to rpmvercmp.
I don't think we need every filename and package nevr to be 5 characters
longer....
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
1:21 a.m.
Peter Gordon wrote:
Robert Scheck wrote:
> Sounds nice, even I'm curious whether this can be realized until April.
> And What will be the release tagging of the new "Fedora 7"? Won't there
be
> no magic .fc7 dist any longer? IMHO .f7 looks odd and causes problem with
> rpmvercmp. We could take this as reason to rename Fedora again ;-)
The %dist tag could be expanded to something like ".fedora7" instead (which is
greater than ".fc6" according to rpmvercmp.
.fc7 could refer to "Fedora Collection 7".
Then .fcX would be more meaningful than .fc6 currently in Extras
packages too.
Warren Togami
wtogami(a)redhat.com
3:18 a.m.
Le Ven 5 janvier 2007 03:41, Bill Nottingham a écrit :
Nicolas Mailhot (nicolas.mailhot(a)laposte.net) said:
> What happened to the firefox3/xulruner plans ?
Utterly dependent on upstream. I suppose it's worth checking on.
This should be clarified ASAP. There are several problems¹ with the
current firefox2 packaging in devel, and I know people refrained from
commenting on it because it was announced as a transitionnal firefox3
placeholder.
We need to know what version of the main distro browser needs to be beaten
into shape.
¹ UI localization, pango ligature bug...
--
Nicolas Mailhot
1:42 p.m.
Le vendredi 05 janvier 2007 à 14:05 -0500, Bill Nottingham a écrit :
Nicolas Mailhot (nicolas.mailhot(a)laposte.net) said:
> We need to know what version of the main distro browser needs to be beaten
> into shape.
Judging by the published schedules, both XULRuner and FF3 aren't
going to make it for F7.
Ok, time to do some bugzilla-ing I guess
--
Nicolas Mailhot
4:08 p.m.
Once upon a time, Robert Scheck <fedora-devel-list.listman(a)linuxnetz.de> said:
Sounds nice, even I'm curious whether this can be realized until
April.
And What will be the release tagging of the new "Fedora 7"? Won't there be
no magic .fc7 dist any longer? IMHO .f7 looks odd and causes problem with
rpmvercmp. We could take this as reason to rename Fedora again ;-)
There was the thought at one point that there may be other Fedora OSes
than Linux (the FTP directory structure is fedora/linux/{core,extras}),
so the next release could be called "Fedora Linux 7" and use "fl7"
for
short.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
7 a.m.
Robert Scheck scripst:
one Fedora release to another and most of them are tagged EasyFix,
too.
To make it slightly more concise. Take a look at
http://preview.tinyurl.com/vj9j6 -- I am afraid 49 unclosed EasyFixes is
still 49 too many.
Matěj
--
http://www.ceplovi.cz/matej/blog/, Jabber: ceplma<at>jabber.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
A child can go only so far in life without potty training. It
is not mere coincidence that six of the last seven presidents
were potty trained, not to mention nearly half of the nation's
state legislators.
-- Dave Barry
9:01 a.m.
On Friday 05 January 2007 08:00, Matej Cepl wrote:
To make it slightly more concise. Take a look at
http://preview.tinyurl.com/vj9j6 -- I am afraid 49 unclosed EasyFixes is
still 49 too many.
Why are you including RHN and RHEL bugs in this? What do these have to do
with Fedora?
--
Jesse Keating
Release Engineer: Fedora
3:06 p.m.
On Thu, Jan 04, 2007 at 02:50:32PM -0500, Bill Nottingham wrote:
30 January 2007 | F7 Test1 Release
Just in time for FUDCon!
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
3:08 p.m.
On 1/4/07, Bill Nottingham <notting(a)redhat.com> wrote:
It's time to bite the bullet.
There will be no more releases of Fedora Core or Fedora Extras.
Wait! Where are you going? Come back!
...
And, what would a release be without features. We've identified
28 features that we'd like to include in the release, available
at http://fedoraproject.org/wiki/Releases/7/Features:
- Modify the build system to support this new paradigm
- Merge Core and Extras in source control
- Use the new pungi tool to spin all releases
- A Fedora Desktop spin
- A Fedora Server spin
- A Fedora KDE spin
So "Fedora Desktop" means "Fedora Gnome desktop" ?
- Make LiveCDs as a part of the distribution release process
Cool ! Is this installable like "Ubuntu livecd" ?
- Add the nouveau drivers for nVidia cards
"nouveau" ? :-)
- Speed up Yum and RPM
Yeah, nice
Thank you,
--
http://vnoss.org
3:10 p.m.
On Thu, 2007-01-04 at 22:08 +0100, Vnpenguin wrote:
So "Fedora Desktop" means "Fedora Gnome desktop"
?
Correct (we're a GNOME centric distribution).
> - Make LiveCDs as a part of the distribution release process
Cool ! Is this installable like "Ubuntu livecd" ?
That's the plan.
David
5:10 p.m.
On Thu, Jan 04, 2007 at 04:10:26PM -0500, David Zeuthen wrote:
> > - Make LiveCDs as a part of the distribution release
process
>
> Cool ! Is this installable like "Ubuntu livecd" ?
Installable? As in the unpacked tree on the CD will be copied to the
hard disk, keeping the RPM database updated correctly? Sounds
neat--it may be faster to install that way rather than installing RPMs
the normal way. The trick would be getting upgrades to work that way
too :-)
5:20 p.m.
On Thu, 2007-01-04 at 18:10 -0500, Chuck Anderson wrote:
Installable? As in the unpacked tree on the CD will be copied to the
hard disk, keeping the RPM database updated correctly? Sounds
neat--it may be faster to install that way rather than installing RPMs
the normal way. The trick would be getting upgrades to work that way
too :-)
Yes, it's much much much faster; we simply do "dd if=os.img
of=/dev/sda2" [1] and once that is done we "e2resizefs /dev/sda2" and
finally we configure the system. If you run the live CD from RAM then
the install time takes 3-4 minutes (on a 2GHz system with 1GB RAM). If
not running the live CD from RAM then it's around 7-8 minutes.
Some time next week I'll post an RPM (to fedora-livecd-list) that you
can install onto the FC6 live CD (remember it got a rw rootfs) so
testing can commence. The installer is text based right now but writing
a small GTK+ app for this is relatively easy.
David
[1] : where os.img stems from the live cd and is the ext3 fs..
and /dev/sda2 is the target partition
3:35 a.m.
On 1/5/07, David Zeuthen <david(a)fubar.dk> wrote:
Yes, it's much much much faster; we simply do "dd if=os.img
of=/dev/sda2" [1] and once that is done we "e2resizefs /dev/sda2" and
finally we configure the system. If you run the live CD from RAM then
the install time takes 3-4 minutes (on a 2GHz system with 1GB RAM). If
not running the live CD from RAM then it's around 7-8 minutes.
Some time next week I'll post an RPM (to fedora-livecd-list) that you
can install onto the FC6 live CD (remember it got a rw rootfs) so
testing can commence. The installer is text based right now but writing
a small GTK+ app for this is relatively easy.
David
[1] : where os.img stems from the live cd and is the ext3 fs..
and /dev/sda2 is the target partition
Thank you, David!
I'm waiting impatiently for your package :)
Cheers,
--
http://vnoss.org
8:42 p.m.
Chuck Anderson (cra(a)WPI.EDU) said:
Installable? As in the unpacked tree on the CD will be copied to the
hard disk, keeping the RPM database updated correctly?
Yes, that's the plan.
Sounds neat--it may be faster to install that way rather than
installing RPMs
the normal way. The trick would be getting upgrades to work that way
too :-)
Hahahahaha... no.
Bill
3:13 p.m.
On Thursday 04 January 2007 16:08, Vnpenguin wrote:
> - A Fedora Desktop spin
> - A Fedora Server spin
> - A Fedora KDE spin
So "Fedora Desktop" means "Fedora Gnome desktop" ?
Yes, Fedora Desktop and Fedora Server will probably be the official Fedora
Project spins of Fedora. Fedora KDE is the proof of concept, perhaps widely
used "community contributed" spin of Fedora. That's why (IMHO) its named
specifically with "KDE" whereas the official spin is just "Desktop".
If you
don't know what "KDE" or "GNOME" is, you wouldn't know to
choose it. Desktop
is a good generic name that is understandable. However if you already know
and prefer KDE, you know to get the KDE spin.
--
Jesse Keating
Release Engineer: Fedora
3:18 p.m.
On 1/4/07, Jesse Keating <jkeating(a)redhat.com> wrote:
On Thursday 04 January 2007 16:08, Vnpenguin wrote:
> > - A Fedora Desktop spin
> > - A Fedora Server spin
> > - A Fedora KDE spin
>
> So "Fedora Desktop" means "Fedora Gnome desktop" ?
Yes, Fedora Desktop and Fedora Server will probably be the official Fedora
Project spins of Fedora. Fedora KDE is the proof of concept, perhaps widely
used "community contributed" spin of Fedora. That's why (IMHO) its named
specifically with "KDE" whereas the official spin is just "Desktop".
If you
don't know what "KDE" or "GNOME" is, you wouldn't know to
choose it. Desktop
is a good generic name that is understandable. However if you already know
and prefer KDE, you know to get the KDE spin.
Thank you, I use Gnome (and GTK apps) since RH 5.0 and I don't want to
change it :)
Cheers,
--
http://vnoss.org
3:20 p.m.
On Thu, Jan 04, 2007 at 04:13:50PM -0500, Jesse Keating wrote:
Yes, Fedora Desktop and Fedora Server will probably be the official
Fedora
Are these for media only?
In other words, will there be Fedora Desktop/Server ISOs and
corresponding separate network installers? Or will there be separate ISOs, but
just one set of network install loaders and images, able to install
either (or any other spin, for that matter)?
None of the above is obvious from a rapid glance at the wiki.
--
Rudi
3:48 p.m.
On Thursday 04 January 2007 16:20, Rudi Chiarito wrote:
Are these for media only?
In other words, will there be Fedora Desktop/Server ISOs and
corresponding separate network installers? Or will there be separate ISOs,
but just one set of network install loaders and images, able to install
either (or any other spin, for that matter)?
None of the above is obvious from a rapid glance at the wiki.
We're still fleshing out the details. One idea is that the customized spins
will be iso only, the exploaded tree will have everything in it. Any
customized spin will have the ability to enable the full repo during the
install and gain access to all the software there, likewise minimal boot or
rescue isos could be used to install from the large repo as well.
The custom spin isos would include the images and such to be able to do
network installs, and the iso itself could be used over the network (nfs).
--
Jesse Keating
Release Engineer: Fedora
3:56 p.m.
On 1/4/07, Jesse Keating <jkeating(a)redhat.com> wrote:
We're still fleshing out the details. One idea is that the
customized spins
will be iso only, the exploaded tree will have everything in it.
So what about an 8GB DVD image with everything in it?
--
Jesse Keating
Release Engineer: Fedora
Regards,
Fabio
4 p.m.
On Thu, Jan 04, 2007 at 04:56:43PM -0500, Fabio Comolli wrote:
>We're still fleshing out the details. One idea is that the
customized
>spins
>will be iso only, the exploaded tree will have everything in it.
So what about an 8GB DVD image with everything in it?
Okay.
But probably the official Fedora mirrors don't want to carry it.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
8:44 p.m.
Matthew Miller (mattdm(a)mattdm.org) said:
On Thu, Jan 04, 2007 at 04:56:43PM -0500, Fabio Comolli wrote:
> >We're still fleshing out the details. One idea is that the customized
> >spins
> >will be iso only, the exploaded tree will have everything in it.
> So what about an 8GB DVD image with everything in it?
Okay.
But probably the official Fedora mirrors don't want to carry it.
It's entirely possible such a thing would be Bittorrent-only.
Bill
4:05 p.m.
On Thursday 04 January 2007 16:56, Fabio Comolli wrote:
So what about an 8GB DVD image with everything in it?
Feel free to burn it, I'm not about to ask that the mirrors carry around an
extra 8G per arch iso that just duplicates all the packages already on the
file system, and would be used by a very very small percentage of the
userbase.
--
Jesse Keating
Release Engineer: Fedora
4:20 p.m.
On 1/4/07, Jesse Keating <jkeating(a)redhat.com> wrote:
On Thursday 04 January 2007 16:56, Fabio Comolli wrote:
> So what about an 8GB DVD image with everything in it?
Feel free to burn it, I'm not about to ask that the mirrors carry around an
extra 8G per arch iso that just duplicates all the packages already on the
file system, and would be used by a very very small percentage of the
userbase.
I wasn't thinking of an "extra" 8GB: I was thinking of small ISOs for
people who use network boot and only an 8GB ISO for the distribution.
In this way you won't have to carry an ISO for "Fedora Desktop",
another on for "Fedora Server", "Fedora KDE" and so on.
Maybe in 8GB you can put both the i386 and x86-64 images, like
Solaris10 does for example.
However, it's just my 2¢ :-)
Fabio
--
Jesse Keating
Release Engineer: Fedora
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
4:27 p.m.
On Thursday 04 January 2007 17:20, Fabio Comolli wrote:
I wasn't thinking of an "extra" 8GB: I was thinking of
small ISOs for
people who use network boot and only an 8GB ISO for the distribution.
In this way you won't have to carry an ISO for "Fedora Desktop",
another on for "Fedora Server", "Fedora KDE" and so on.
Maybe in 8GB you can put both the i386 and x86-64 images, like
Solaris10 does for example.
However, it's just my 2¢ :-)
The targetted spins were for iso download, so you could carry it with you or
not have to hit the network for every package. Otherwise what would be the
point, you'd just select that group from the installer.
--
Jesse Keating
Release Engineer: Fedora
5:14 p.m.
On Thu, Jan 04, 2007 at 05:05:13PM -0500, Jesse Keating wrote:
On Thursday 04 January 2007 16:56, Fabio Comolli wrote:
> So what about an 8GB DVD image with everything in it?
Feel free to burn it, I'm not about to ask that the mirrors carry around an
extra 8G per arch iso that just duplicates all the packages already on the
file system, and would be used by a very very small percentage of the
userbase.
Well, we could use jigdo and just distribute template files for those
who wish to assemble the full 8G iso.
4:37 p.m.
Or a 4g dvd image with server and desktop combined (a sort of
equivilant to core now)
Peter
On 1/4/07, Fabio Comolli <fabio.comolli(a)gmail.com> wrote:
On 1/4/07, Jesse Keating <jkeating(a)redhat.com> wrote:
> We're still fleshing out the details. One idea is that the customized
spins
> will be iso only, the exploaded tree will have everything in it.
So what about an 8GB DVD image with everything in it?
> --
> Jesse Keating
> Release Engineer: Fedora
>
Regards,
Fabio
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
7:29 p.m.
Em Qui, 2007-01-04 às 16:56 -0500, Fabio Comolli escreveu:
So what about an 8GB DVD image with everything in it?
SUSE uses standard 4GB DVD with an extra repository on-line, but if you
buy their boxed version you can choose between 2 4G DVD set or 1 8GB
DVD. Mandriva also have a multi 4GB DVD release (IIRC, 2 DVD), but not
an 8GB DVD.
You just need to remember that in some countries (like Brazil, for
instance) it's really difficult (almost impossible) to find 8GB medias
(and if you find, they are *very* expensive). So if the distro vendor
doesn't provide it, you would be excluding a lot of users.
--
% Mauricio Teixeira (netmask) | Maceio/AL/BR %
% mteixeira{a}webset{d}net | http://smartpm.org %
% http://mteixeira.webset.net | http://pmping.sf.net %
9:32 p.m.
On 1/4/07, Mauricio Teixeira (netmask) <netmask(a)webset.net> wrote:
Em Qui, 2007-01-04 às 16:56 -0500, Fabio Comolli escreveu:
You just need to remember that in some countries (like Brazil, for
instance) it's really difficult (almost impossible) to find 8GB medias
(and if you find, they are *very* expensive). So if the distro vendor
doesn't provide it, you would be excluding a lot of users.
Honestly I think proper documentation or a script on how to build a
DVD would be more than sufficient.
-Mike
7:25 p.m.
Em Qui, 2007-01-04 às 16:48 -0500, Jesse Keating escreveu:
We're still fleshing out the details. One idea is that the
customized spins
will be iso only, the exploaded tree will have everything in it. Any
If that's the case, why not just having well designed
patterns/groups/selections/whatever so that the user can choose between
either one during install?
For that matter it would be needed to have a well defined 'base system'
and build the 'install types' on it, but I personally don't see the need
for a spin.
Just MHO.
--
% Mauricio Teixeira (netmask) | Maceio/AL/BR %
% mteixeira{a}webset{d}net | http://smartpm.org %
% http://mteixeira.webset.net | http://pmping.sf.net %
1:43 a.m.
Jesse Keating wrote:
We're still fleshing out the details. One idea is that the customized spins
will be iso only, the exploaded tree will have everything in it. Any
customized spin will have the ability to enable the full repo during the
install and gain access to all the software there, likewise minimal boot or
rescue isos could be used to install from the large repo as well.
Why not enable the entire repo by default in any install? Isn't that
most logical?
Warren Togami
wtogami(a)redhat.com
6:36 a.m.
On Saturday 06 January 2007 02:43, Warren Togami wrote:
Why not enable the entire repo by default in any install? Isn't
that
most logical?
Because that assumes that every install has network capabilities, and that
ever package in the entire repo comps would be marked as optional so that by
default nothing would get downloaded. Those are pretty heavy requirements.
--
Jesse Keating
Release Engineer: Fedora
6:28 p.m.
I'm pretty sure my idea of Destop/Workstation/Server is going to be
substantially different from other people's, probably every time I build
a box it'll change. So I hope it's just ISOs and the installed is
generic and allows for package groups to be selected. The network
installer right now is very flexible which is it's strength.
In other words, will there be Fedora Desktop/Server ISOs and
corresponding separate network installers? Or will there be separate ISOs, but
just one set of network install loaders and images, able to install
either (or any other spin, for that matter)?
None of the above is obvious from a rapid glance at the wiki.
--
Rudi
3:22 p.m.
Jesse Keating wrote:
Yes, Fedora Desktop and Fedora Server will probably be the official
Fedora
Project spins of Fedora. Fedora KDE is the proof of concept, perhaps widely
used "community contributed" spin of Fedora. That's why (IMHO) its named
specifically with "KDE" whereas the official spin is just "Desktop".
If you
don't know what "KDE" or "GNOME" is, you wouldn't know to
choose it. Desktop
is a good generic name that is understandable. However if you already know
and prefer KDE, you know to get the KDE spin.
It would be consistent to have something like
Fedora Desktop (GNOME edition) and
Fedora Desktop (KDE edition)
It's confusing and discriminatory to call one of the spins as the
desktop when you have more (which is likely to increase) than one
desktop oriented spins.
Rahul
3:53 p.m.
On Thursday 04 January 2007 16:22, Rahul Sundaram wrote:
It would be consistent to have something like
Fedora Desktop (GNOME edition) and
Fedora Desktop (KDE edition)
It's confusing and discriminatory to call one of the spins as the
desktop when you have more (which is likely to increase) than one
desktop oriented spins.
That's too many chars for a Volume ID, so it has to be a bit more terse.
Perhaps the isos could be named that, but I don't want () in iso names.
We are discriminatory by nature. We choose what we want in our package
collections, we choose what we want on our isos. Its no mystery that Fedora
is a Gnome centric distribution, and it should be no surprise that the Fedora
Desktop spin is Gnome based. What community folks choose to name their spins
is of not much concern, so long as it makes sense for that spin and doesn't
trample any trademarks. Should we go down the route of Fedora Desktop
(GNOME/Firefox/evince/OpenOffice.org/gaim/compiz/emacs edition)?
--
Jesse Keating
Release Engineer: Fedora
4:14 p.m.
Jesse Keating wrote:
On Thursday 04 January 2007 16:22, Rahul Sundaram wrote:
> It would be consistent to have something like
>
> Fedora Desktop (GNOME edition) and
> Fedora Desktop (KDE edition)
>
> It's confusing and discriminatory to call one of the spins as the
> desktop when you have more (which is likely to increase) than one
> desktop oriented spins.
That's too many chars for a Volume ID, so it has to be a bit more terse.
Perhaps the isos could be named that, but I don't want () in iso names.
The volume id can be different from the full name. Feel free to
abbreviate it in the volume id and drop the braces in the ISO filename.
I am just
We are discriminatory by nature. We choose what we want in our
package
collections, we choose what we want on our isos.
We dont need to be though. We can put every package in a DVD and make it
available in a different directory for mirrors to sync if they want to
or just make it a torrent only release. We have a sizable segment of
users who need packages to be in the media due to unavailability of
broadband connections and network access. It is not much of a burden for
us to produce a DVD release with everything in it. Please do consider it.
Its no mystery that Fedora
is a Gnome centric distribution, and it should be no surprise that
the Fedora
Desktop spin is Gnome based.
After opening up development we have really no need to do so since the
resources available to us has massively increased (more packagers,
pungi, pilgrim etc). The whole point of us doing different spins to move
off from this idea of being centric on some things.
What community folks choose to name their spins
is of not much concern, so long as it makes sense for that spin and
doesn't
trample any trademarks.
Good branding is very much a key concern. We are making major changes
here and have a chance to change past impressions. Let's get it right
this time.
Should we go down the route of Fedora Desktop
No but a desktop environment is not at the same level as rest of the
components here as clearly demonstrated by us planning to do two
different spins based on just that. If you are going to call one of the
spins Fedora KDE, it is no more confusing to call the other one Fedora
GNOME. Seriously.
Rahul
4:19 p.m.
>>>> "JK" == Jesse Keating
<jkeating(a)redhat.com> writes:
JK> Its no mystery that Fedora is a Gnome centric distribution, and it
JK> should be no surprise that the Fedora Desktop spin is Gnome based.
Umm, isn't the Fedora supposed to become the community's distribution,
and so isn't it up to the community to decide whether Fedora is
"anything"-centric?
I could care less about naming either way, but declaring up-front that
regardless of what the community does or wants, Fedora is still going
to favor any specific technology seems counterproductive in this new
spirit of complete community involvement.
- J<
4:23 p.m.
On Thursday 04 January 2007 17:19, Jason L Tibbitts III wrote:
I could care less about naming either way, but declaring up-front
that
regardless of what the community does or wants, Fedora is still going
to favor any specific technology seems counterproductive in this new
spirit of complete community involvement.
You're right, I think those writing software for Fedora and doing integration
work for Fedora are the ones who will decide what centric Fedora is, and to
this point, that's all been gnome/gtk, python, etc... Do you see that
changing drastically anytime soon?
--
Jesse Keating
Release Engineer: Fedora
4:27 p.m.
On Thursday 04 January 2007 16:23, Jesse Keating wrote:
On Thursday 04 January 2007 17:19, Jason L Tibbitts III wrote:
> I could care less about naming either way, but declaring up-front that
> regardless of what the community does or wants, Fedora is still going
> to favor any specific technology seems counterproductive in this new
> spirit of complete community involvement.
You're right, I think those writing software for Fedora and doing
integration work for Fedora are the ones who will decide what centric
Fedora is, and to this point, that's all been gnome/gtk, python, etc... Do
you see that changing drastically anytime soon?
Time to port everything to PyQT ;)
i dont see it changing but i do see other
things taking off.
--
,-._|\ Dennis Gilmore, RHCE
/Aussie\ Proud Australian
\_.--._/ | Aurora | Fedora |
v
4:33 p.m.
On Thu, 2007-01-04 at 17:23 -0500, Jesse Keating wrote:
On Thursday 04 January 2007 17:19, Jason L Tibbitts III wrote:
> I could care less about naming either way, but declaring up-front that
> regardless of what the community does or wants, Fedora is still going
> to favor any specific technology seems counterproductive in this new
> spirit of complete community involvement.
You're right, I think those writing software for Fedora and doing integration
work for Fedora are the ones who will decide what centric Fedora is, and to
this point, that's all been gnome/gtk, python, etc... Do you see that
changing drastically anytime soon?
We don't know. We haven't worked out anything yet. For example,
merging the Core cabal and FESCo. To declare anything before more
groundwork is completed is fairly pointless.
josh
8:46 p.m.
Josh Boyer (jwboyer(a)jdub.homelinux.org) said:
> You're right, I think those writing software for Fedora and
doing integration
> work for Fedora are the ones who will decide what centric Fedora is, and to
> this point, that's all been gnome/gtk, python, etc... Do you see that
> changing drastically anytime soon?
We don't know. We haven't worked out anything yet. For example,
merging the Core cabal and FESCo. To declare anything before more
groundwork is completed is fairly pointless.
There is a large subset of the Fedora community that has already
stepped up and is willing to do the work for a GNOME desktop spin. Ergo,
it's getting done. I don't see how stating that is a problem.
Bill
10:51 p.m.
On Thu, 2007-01-04 at 21:46 -0500, Bill Nottingham wrote:
Josh Boyer (jwboyer(a)jdub.homelinux.org) said:
> > You're right, I think those writing software for Fedora and doing
integration
> > work for Fedora are the ones who will decide what centric Fedora is, and to
> > this point, that's all been gnome/gtk, python, etc... Do you see that
> > changing drastically anytime soon?
>
> We don't know. We haven't worked out anything yet. For example,
> merging the Core cabal and FESCo. To declare anything before more
> groundwork is completed is fairly pointless.
There is a large subset of the Fedora community that has already
stepped up and is willing to do the work for a GNOME desktop spin. Ergo,
it's getting done. I don't see how stating that is a problem.
Neither do I. This isn't about GNOME or KDE or WindowMaker or whatever.
My comment was more about "those writing software for Fedora and doing
integration work for Fedora are the ones who will decide what centric
Fedora is.." I believe I took that a bit out of context and rather than
spiraling into a very long flame-war and embarrassing myself, I'll just
end it now.
josh
5:14 p.m.
On Thu, 2007-01-04 at 16:19 -0600, Jason L Tibbitts III wrote:
Umm, isn't the Fedora supposed to become the community's
distribution,
and so isn't it up to the community to decide whether Fedora is
"anything"-centric?
Sorry for being direct, but it's a little bit delusional to think that
just because Core + Extras is getting merged that it's now all community
controlled. In other words, I expect Red Hat employees to still be the
significant contributor for a long long time (would *love* to be proved
wrong!) and at Red Hat we have, at least, 25 times as many people
working on the GNOME than the KDE.
There's a reason most successful open source projects have benevolent
dictators and it's not all a democracy. Thanks.
David
5:50 p.m.
>>>> "DZ" == David Zeuthen
<david(a)fubar.dk> writes:
DZ> Sorry for being direct, but it's a little bit delusional to think
DZ> that just because Core + Extras is getting merged that it's now
DZ> all community controlled.
Well, thanks for deflating the hype. So, according to you, the hype
about the grand merge with the community is indeed just hype.
Look, either it's going to happen or people need to stop hyping it as
if it is going to happen. Since both positions are coming out of Red
Hat at the moment and those of us involved in community governance
(i.e. us in FESCo) are still somewhat in the dark, it will be really
nice to see the truth of the situation.
DZ> In other words, I expect Red Hat employees to still be the
DZ> significant contributor for a long long time (would *love* to be
DZ> proved wrong!) and at Red Hat we have, at least, 25 times as many
DZ> people working on the GNOME than the KDE.
So? My comments weren't about gnome versus kde. I have no reason to
expect other than that portions of the project which receive the
greater number of developers from wherever in the community will make
the most progress. My comments are about whether Red Hat plans to be
just a part of the community, and your comments seem to answer than in
the negative. Which is directly contradictory to what other folks
from Red Hat have been saying.
DZ> There's a reason most successful open source projects have
DZ> benevolent dictators and it's not all a democracy. Thanks.
This statement also contradicts statements from others at Red Hat. It
would be really nice to know just what is actually going to happen.
- J<
6:11 p.m.
On Thu, 2007-01-04 at 17:50 -0600, Jason L Tibbitts III wrote:
>>>>> "DZ" == David Zeuthen
<david(a)fubar.dk> writes:
DZ> Sorry for being direct, but it's a little bit delusional to think
DZ> that just because Core + Extras is getting merged that it's now
DZ> all community controlled.
Well, thanks for deflating the hype. So, according to you, the hype
about the grand merge with the community is indeed just hype.
Don't be a drama queen, of course it's not hype. I'm just saying, for
example, that many of the core desktop packages that I personally
maintain will still be under my control and there will still be a
desktop team at Red Hat where we decide on features for the next release
and coordinate the maintenance of said packages.
And now with Core being opened up.. to me it means that everyone can
apply patches but for my packages it still needs ACK / coordination from
me. How is this different from Extras today and why on earth should it
be different? Do you think the merge means that anyone can apply any
patch to any package? That's really naive.
We have an open mailing list too for contributors, sadly it doesn't
receive a lot of useful traffic. Maybe it's because we do our work
upstream as we all should. For the record, we also have close
relationship to many desktop community members for example Richard
Hughes which is an active Fedora user.
(and in the paragraph above 'we' means people working on desktop
packages and that's not restricted to RH employees though today it's
mostly only RH employees. To tell you the truth not a lot of Fedora
contributors have shown interest in the desktop apart from ranting about
it.)
DZ> In other words, I expect Red Hat employees to still be the
DZ> significant contributor for a long long time (would *love* to be
DZ> proved wrong!) and at Red Hat we have, at least, 25 times as many
DZ> people working on the GNOME than the KDE.
So? My comments weren't about gnome versus kde. I have no reason to
expect other than that portions of the project which receive the
greater number of developers from wherever in the community will make
the most progress. My comments are about whether Red Hat plans to be
just a part of the community, and your comments seem to answer than in
the negative. Which is directly contradictory to what other folks
from Red Hat have been saying.
DZ> There's a reason most successful open source projects have
DZ> benevolent dictators and it's not all a democracy. Thanks.
This statement also contradicts statements from others at Red Hat. It
would be really nice to know just what is actually going to happen.
You are implying I'm speaking for Red Hat which I'm clearly not. Don't
do that. Thanks.
David
7:38 p.m.
On 04 Jan 2007 17:50:50 -0600, Jason L Tibbitts III <tibbs(a)math.uh.edu> wrote:
DZ> There's a reason most successful open source projects
have
DZ> benevolent dictators and it's not all a democracy. Thanks.
This statement also contradicts statements from others at Red Hat. It
would be really nice to know just what is actually going to happen.
I haven't seen anything, anywhere, to suggest this is going to be a democracy.
The merger is going to be more like opening federally owned land for
homesteading. Basically everyone is going to rush out and stake some
claims for fertile pieces of unclaimed packaging space. From those
individual homesteaders packaging communities will be built, some
fated to thrive, and some fated to be ghost towns in a couple of
years. Did you know that homesteading was still going on in Alaska
till the 1980's?
The brave new merged world, is going to be more collaborative, and
certainly more supportive of community efforts which are not directly
inline with Red Hat directed initiatives. But don't get the wrong
idea, there will still be conflicts of interest, and at the end of the
day groups of package owners working in teams will be setting the
directions for that subgroup of packages and driving development
forward in conjunction of the rest of the packaging space. For
Gnome, the driver seat in the Fedora space is clearly filled by RedHat
engineers so don't expect that to change. The merger makes it
possible for new people to drive new initiatives in tangent with
current ones. Just don't expect to claim jump existing homesteads, and
forcibly change the direction.
But for other things, that RedHat doesn't have resources invested in,
the merger will definitely matter. For example we all want to see the
people who are interested in keeping KDE on Fedora sane have a chance
to work on it without undue frustrations. Its no big secret that
RedHat is not making an investment of engineering time into KDE, so
continuing to have it chained up inside a RedHat internal buildsystem
where none of the interested community members can get access to it
blocks that. The merger of the infrastructure absolutely is forward
progress towards fixing some of the problems with KDE in Fedora.
The real question is who is going to end up becoming the benevolent
dictators of the KDE space and is there enough community manpower to
keep KDE afloat. The merger provides the access, but there will
absolutely have to be strong doers to drive the work, instead of just
talkers. I certainly expect Rex to be involved because he has some
momentum here with his community built packages for KDE. And I also
expect people leading Fedora Unity to have a hand in the release
engineering aspects of pooping out a KDE-centric installer image since
they have already done livecd spins for KDE. Whomever the drivers of
KDE packaging and installable media end up being inside the Fedora
community, they will absolutely end up making decisions which piss off
some KDE users. Conflicts of interest are inevitable, even for
packaging drivers not sitting inside the RedHat fenceline.
-jef"The merger doesn't so much as change anything with regard to
control of existing things.
The merger provides access so the fedora project can better support
new community initiatives with fedora project infrastructure."spaleta
2:06 a.m.
Jason L Tibbitts III wrote:
So? My comments weren't about gnome versus kde. I have no reason to
expect other than that portions of the project which receive the
greater number of developers from wherever in the community will make
the most progress. My comments are about whether Red Hat plans to be
just a part of the community, and your comments seem to answer than in
the negative. Which is directly contradictory to what other folks
from Red Hat have been saying.
More broadly... Fedora is not a democracy.
Fedora is a meritocracy.
Those who have done good work and the respect of their peers gain
greater credibility in the project. These people who have earned trust
from others exist at varying levels within the organization help to make
decisions.
Red Hat employees just happen to have many inputs into the Fedora
Project as part of their regular jobs.
One issue however that I see with this, is historic lack of
inter-communication between the RH Desktop team and the community. The
recent explosion on fedora-art-list is a salient example of this kind of
conflict. A perceived corporate "outsider" who had not attempted to
participate in the community prior, appeared suddenly with a
heavy-handed power play, attempting to subvert the already in-progress
community process. I did not appreciate David's attitude in that
instance, and I think David has blown his response in this thread out of
proportion.
Really, please folks, just calm down.
Fedora Desktop and Fedora KDE spins. Is that really so bad?
Warren Togami
wtogami(a)redhat.com
2:34 a.m.
Warren Togami wrote:
Fedora Desktop and Fedora KDE spins. Is that really so bad?
Yes it is. This kind of biased branding would lead to the perception
GNOME is always going to be favored regardless of whether there is a
active community around other desktop environments within Fedora.
Granted, the number of GNOME developers within Fedora from Red Hat is
going to ensure that we have a very well integrated GNOME desktop on
Fedora but having a separate KDE (or XFCE, GNUStep, Enlightenment et
all) releases gives more space for other active contributors to do the
hard work they can and try to compete fiercely to provide the best
possible experience within Fedora. Dont strike down that opportunity.
I am not biased against GNOME or anything. I use it all the time. Doesnt
mean we shouldnt strive to accommodate other preferences more.
Rahul
2:59 a.m.
Rahul Sundaram schrieb:
Warren Togami wrote:
> Fedora Desktop and Fedora KDE spins. Is that really so bad?
Yes it is. This kind of biased branding would lead to the perception
GNOME is always going to be favored regardless of whether there is a
active community around other desktop environments within Fedora.
Granted, the number of GNOME developers within Fedora from Red Hat is
going to ensure that we have a very well integrated GNOME desktop on
Fedora but having a separate KDE (or XFCE, GNUStep, Enlightenment et
all) releases gives more space for other active contributors to do the
hard work they can and try to compete fiercely to provide the best
possible experience within Fedora. Dont strike down that opportunity.
Fully agreed!
Cu
thl (gnome user)
5:03 p.m.
Le samedi 06 janvier 2007 à 09:59 +0100, Thorsten Leemhuis a écrit :
Rahul Sundaram schrieb:
> Warren Togami wrote:
>> Fedora Desktop and Fedora KDE spins. Is that really so bad?
> Yes it is. This kind of biased branding would lead to the perception
> GNOME is always going to be favored regardless of whether there is a
> active community around other desktop environments within Fedora.
>
> Granted, the number of GNOME developers within Fedora from Red Hat is
> going to ensure that we have a very well integrated GNOME desktop on
> Fedora but having a separate KDE (or XFCE, GNUStep, Enlightenment et
> all) releases gives more space for other active contributors to do the
> hard work they can and try to compete fiercely to provide the best
> possible experience within Fedora. Dont strike down that opportunity.
Fully agreed!
So do I !
Cu
thl (gnome user)
ThomasCanniot (gnome user)
6:34 a.m.
On Saturday 06 January 2007 03:34, Rahul Sundaram wrote:
Yes it is. This kind of biased branding would lead to the perception
GNOME is always going to be favored regardless of whether there is a
active community around other desktop environments within Fedora.
Granted, the number of GNOME developers within Fedora from Red Hat is
going to ensure that we have a very well integrated GNOME desktop on
Fedora but having a separate KDE (or XFCE, GNUStep, Enlightenment et
all) releases gives more space for other active contributors to do the
hard work they can and try to compete fiercely to provide the best
possible experience within Fedora. Dont strike down that opportunity.
I am not biased against GNOME or anything. I use it all the time. Doesnt
mean we shouldnt strive to accommodate other preferences more.
No, it really doesn't. Calling it Fedora Desktop means that this is the best
desktop we're putting forward. This is where the vast majority of
integration work happens, where upstream participation is geared toward,
where the majority of QA goes, etc, etc...
In some magical world where a few years down the road this changes and we put
it all into KDE for a while and KDE gets to the same level as GNOME for us,
we make the switch in our Fedora Desktop spin, as now KDE is where all the
above happens. End users continue to want a well oiled integrated desktop,
and thus choose the Fedora Desktop spin. We want to name based on
functionality, not on what particular software is used. Take a look at your
menu system for example, Calculator, Dictionary, Terminal, Web Browser,
etc... End users need not care what actual app their using, and if they did
care, Help -> About. We need to get easily translatable names for the things
we do, so that it isn't a mystery what a spin is for, it is very clear.
--
Jesse Keating
Release Engineer: Fedora
6:52 a.m.
Jesse Keating wrote:
No, it really doesn't. Calling it Fedora Desktop means that this
is the best
desktop we're putting forward. This is where the vast majority of
integration work happens, where upstream participation is geared toward,
where the majority of QA goes, etc, etc...
In some magical world where a few years down the road this changes and we put
it all into KDE for a while and KDE gets to the same level as GNOME for us,
we make the switch in our Fedora Desktop spin, as now KDE is where all the
above happens.
Are we aiming for a equivalent footing or not? If we are then the
branding should be a reflection of that. The problem with selecting a
release name based on a alleged current shortage of community resources
is that the perception would make it a permanent thing. Like calling
Fedora a beta would make it a excuse for bad bugs in the release. You
dont get much of a second chance to change perception some time in the
future yet again. Heck, we are *still* getting badly burned by poor
messaging in the past. Have we not learned anything from that?
End users continue to want a well oiled integrated desktop,
and thus choose the Fedora Desktop spin. We want to name based on
functionality, not on what particular software is used.
So why is one of the spins called Fedora KDE? How is it *not* a Fedora
Desktop? What about when someone wants to do a Fedora Desktop spin based
on another of those alternative desktop environments, windows managers?
Take a look at your
menu system for example, Calculator, Dictionary, Terminal, Web
Browser,
etc... End users need not care what actual app their using, and if they did
care, Help -> About.
That's true for GNOME currently. Not for the KDE menu in Fedora. Do take
a look.
We need to get easily translatable names for the things
we do, so that it isn't a mystery what a spin is for, it is very
clear.
Sure. I have been a translator before. Have release names such as Fedora
GNOME Desktop and Fedora KDE Desktop is very well translatable. No, I am
not talking about volume ids and iso filenames here.
Rahul
7:13 a.m.
On Saturday 06 January 2007 07:52, Rahul Sundaram wrote:
Are we aiming for a equivalent footing or not? If we are then the
branding should be a reflection of that. The problem with selecting a
release name based on a alleged current shortage of community resources
is that the perception would make it a permanent thing. Like calling
Fedora a beta would make it a excuse for bad bugs in the release. You
dont get much of a second chance to change perception some time in the
future yet again. Heck, we are *still* getting badly burned by poor
messaging in the past. Have we not learned anything from that?
You and I just disagree that this is bad messaging. Whether we're aiming for
equal footing or not, it just isn't there right now. And to be honest,
putting a lot of effort into making them equal is not going to happen from
the Red Hat resources. We've picked our desktop, what we want to put our
efforts behind for our RHEL product line. For our product, multiple desktops
just fractures our userbase, doubles our support needs, weakens the product
overall as it takes away resources better spent on total integration. For
that reason, the vast majority of Red Hat contribution to the Fedora
Community is going to be around the gnome desktop. I don't likely see this
changing in the foreseeable future. Will there come a time that the non Red
Hat contribution to the Fedora Community around KDE will outsurpass and
outshine the Red Hat contribution to the Fedora community around Gnome? I
don't think so, any time soon.
End users continue to want a well oiled integrated desktop,
> and thus choose the Fedora Desktop spin. We want to name based on
> functionality, not on what particular software is used.
So why is one of the spins called Fedora KDE?
Because it is a targetted spin for a particular peice of software, much like
an eclipse spin or XFCE spin or asterisk spin.
How is it *not* a Fedora
Desktop?
At this point it is not THE Fedora desktop. Its not what we want to flaunt,
have reviews written about, be judged upon, etc. It is a startup, and needs
a lot of work/time to get to the polish / integration level we have with
gnome, our premier desktop.
What about when someone wants to do a Fedora Desktop spin based
on another of those alternative desktop environments, windows managers?
ee above.
Take a look at your
> menu system for example, Calculator, Dictionary, Terminal, Web Browser,
> etc... End users need not care what actual app their using, and if they
> did care, Help -> About.
That's true for GNOME currently. Not for the KDE menu in Fedora. Do take
a look.
You say this as if it's a good thing, I see this as another fact that KDE
isn't really designed for the mass userbase. How in gods green earth is
somebody supposed to look at a KDE menu and know that Konqueror is for
browsing the web? That "Kate" is for writing text files?
--
Jesse Keating
Release Engineer: Fedora
7:31 a.m.
Jesse Keating wrote:
You and I just disagree that this is bad messaging. Whether we're aiming for
equal footing or not, it just isn't there right now. And to be honest,
putting a lot of effort into making them equal is not going to happen from
the Red Hat resources.
That may be true but I am not expecting Red Hat to do all the work in
Fedora. We dont have a community if that was true. Luckily there is a
enthusiastic and active community around KDE in Fedora.
http://fedoraproject.org/wiki/Extras/SIGs/KDE
We've picked our desktop, what we want to put our
efforts behind for our RHEL product line. For our product, multiple
desktops
just fractures our userbase, doubles our support needs, weakens the product
overall as it takes away resources better spent on total integration.
RHEL includes both GNOME and KDE. Red Hat is going to have to support
them both. It might not make sense of engineering to do the additional
work. Yes, it does escalate support costs but we already have made that
choice due to customer demands. The same case for including three
different MTA's - sendmail, postfix and exim or anything in which we
provide more than one implementation of similar technologies.
For
that reason, the vast majority of Red Hat contribution to the Fedora
Community is going to be around the gnome desktop. I don't likely see this
changing in the foreseeable future.
Yes. I am already aware of that.
Will there come a time that the non Red
Hat contribution to the Fedora Community around KDE will outsurpass
and
outshine the Red Hat contribution to the Fedora community around Gnome? I
don't think so, any time soon.
Maybe but what we are doing now is not going to encourage them.
Because it is a targetted spin for a particular peice of software,
much like
an eclipse spin or XFCE spin or asterisk spin.
Yes, thats true for both a server and GNOME spin. Every different spin
is targeted towards a particular set of users.
> How is it *not* a Fedora
> Desktop?
At this point it is not THE Fedora desktop. Its not what we want to flaunt,
have reviews written about, be judged upon, etc. It is a startup, and needs
a lot of work/time to get to the polish / integration level we have with
gnome, our premier desktop.
Just because you call the spin, Fedora KDE doesnt mean people arent
going to flaunt, review or judge it.
You say this as if it's a good thing, I see this as another fact
that KDE
isn't really designed for the mass userbase. How in gods green earth is
somebody supposed to look at a KDE menu and know that Konqueror is for
browsing the web? That "Kate" is for writing text files?
So why havent we fixed up the menu to be meaningful? Yeah right, because
we didnt have enough resources or we just have not cared. This is
exactly the sort of things opening it up to the community and doing a
targeted spin is supposed to fix.
Rahul
7:42 a.m.
On Saturday 06 January 2007 08:31, Rahul Sundaram wrote:
So why havent we fixed up the menu to be meaningful? Yeah right,
because
we didnt have enough resources or we just have not cared. This is
exactly the sort of things opening it up to the community and doing a
targeted spin is supposed to fix.
Or it could possibly be that upstream doesn't WANT the menu to be "fixed".
Perhaps they don't agree with our views. In Fedora we try to stay with
upstream, and make our changes there, or make sure our changes get there.
What we don't want to get to again is calling something KDE but changing it
drastically from what the upstream KDE looks/feels like. That doesn't win
you any users, all it does is piss off the people who want the real KDE.
I'm tired of this argument already. I'll call the spin whatever the board
decides they want it references as. It shows up at installer boot time,
sometimes during the install, and whatever materials reference the iso set.
Not that huge of a deal, you have my opinion on the matter.
--
Jesse Keating
Release Engineer: Fedora
8:12 a.m.
Rahul Sundaram wrote:
Jesse Keating wrote:
> You say this as if it's a good thing, I see this as another
fact that
> KDE isn't really designed for the mass userbase. How in gods green
> earth is somebody supposed to look at a KDE menu and know that
> Konqueror is for browsing the web? That "Kate" is for writing text
> files?
So why havent we fixed up the menu to be meaningful?
KDE doesn't *need* fixing, it isn't broke. Konq already (can) display as
Konqueror Web Browswer
IMO, the fact that other apps (and gnome) in Fedora does this
differently by abusing
Name=
vs.
GenericName=
in .desktip files is bad/wrong/silly/bug. As long as I have any input
on it,
* KDE will not go down that road, ever.
* Packaging Guidelines should be updated highlight/avoid such abuse
-- Rex
11:13 a.m.
Rex Dieter wrote:
KDE doesn't *need* fixing, it isn't broke. Konq already
(can) display as
Konqueror Web Browswer
Yes. I am aware of that which makes Jesse Keating's argument about
Fedora following upstream a weak one.
IMO, the fact that other apps (and gnome) in Fedora does this
differently by abusing
Name=
vs.
GenericName=
in .desktip files is bad/wrong/silly/bug. As long as I have any input
on it,
* KDE will not go down that road, ever.
* Packaging Guidelines should be updated highlight/avoid such abuse
I dont particular care where the bug is. Inconsistency in approach
between desktop environments is probably a bug which should get fixed
anyhow. I think you have mentioned earlier on a few occasions that you
were planning to get the guidelines altered to avoid this problem. That
should help.
Rahul
11:23 a.m.
On Saturday 06 January 2007 12:13, Rahul Sundaram wrote:
I dont particular care where the bug is. Inconsistency in approach
between desktop environments is probably a bug which should get fixed
anyhow. I think you have mentioned earlier on a few occasions that you
were planning to get the guidelines altered to avoid this problem. That
should help.
You're still thinking in Fedora we want to alter the upstream to make it look
like Gnome, or vice versa. When in reality, they should look like upstream.
We put a lot of effort into getting the upstream gnome to work the way we
think it should, whereas KDE we don't have that kind of presence. We
shouldn't be stomping on their software in our distribution, it should stick
to upstream. That's WHY there is choice, as the KDE upstream doesn't
necessarily agree with the GNOME upstream on how things should be done.
--
Jesse Keating
Release Engineer: Fedora
11:49 a.m.
Jesse Keating wrote:
You're still thinking in Fedora we want to alter the upstream to make it look
like Gnome, or vice versa. When in reality, they should look like upstream.
Since we are talking about the menu, let me note that KDE does provide
multiple choices and one of them is a good fit to make it match what you
want from it. Picking a good defaults (which doesnt require intrusive
patches) that integrates well within Fedora is our job. We cant punt
that upstream.
We put a lot of effort into getting the upstream gnome to work the
way we
think it should, whereas KDE we don't have that kind of presence. We
shouldn't be stomping on their software in our distribution, it should stick
to upstream. That's WHY there is choice, as the KDE upstream doesn't
necessarily agree with the GNOME upstream on how things should be done.
Agreed. It does happen on many occasions.
Rahul
8:53 p.m.
On Sat, 2007-01-06 at 08:12 -0600, Rex Dieter wrote:
Rahul Sundaram wrote:
> Jesse Keating wrote:
>> You say this as if it's a good thing, I see this as another fact that
>> KDE isn't really designed for the mass userbase. How in gods green
>> earth is somebody supposed to look at a KDE menu and know that
>> Konqueror is for browsing the web? That "Kate" is for writing text
>> files?
>
> So why havent we fixed up the menu to be meaningful?
KDE doesn't *need* fixing, it isn't broke. Konq already (can) display as
Konqueror Web Browswer
IMO, the fact that other apps (and gnome) in Fedora does this
differently by abusing
Name=
vs.
GenericName=
in .desktip files is bad/wrong/silly/bug. As long as I have any input
on it,
* KDE will not go down that road, ever.
* Packaging Guidelines should be updated highlight/avoid such abuse
Rex, not every design decision made by the desktop team can be reverted
via the packaging guidelines. Committees work best if they don't try to
grab too much power.
10:34 p.m.
New subject: Fedora 7: .desktop files, Name vs. GenericName
Matthias Clasen wrote:
On Sat, 2007-01-06 at 08:12 -0600, Rex Dieter wrote:
> Rahul Sundaram wrote:
>> Jesse Keating wrote:
>>> You say this as if it's a good thing, I see this as another fact that
>>> KDE isn't really designed for the mass userbase. How in gods green
>>> earth is somebody supposed to look at a KDE menu and know that
>>> Konqueror is for browsing the web? That "Kate" is for writing
text
>>> files?
>> So why havent we fixed up the menu to be meaningful?
> KDE doesn't *need* fixing, it isn't broke. Konq already (can) display as
> Konqueror Web Browswer
> IMO, the fact that other apps (and gnome) in Fedora does this
> differently by abusing
> Name=
> vs.
> GenericName=
> in .desktip files is bad/wrong/silly/bug. As long as I have any input
> on it,
> * KDE will not go down that road, ever.
> * Packaging Guidelines should be updated highlight/avoid such abuse
Rex, not every design decision made by the desktop team can be
reverted
via the packaging guidelines. Committees work best if they don't try to
grab too much power.
I just *knew* someone would take my rant the wrong way. (:
fdo .desktop standards allow for what the desktop team was aiming for
(simplified menus, afaict), but, it's the implementation of said goal
that was, imho, ill-conceived. I'm merely hoping to make that clear,
and by codifying/clarifying the Packaging Guidelines on the topic to
avoid such folly in the future.
-- Rex
-- Rex
3:04 p.m.
On 1/6/07, Jesse Keating <jkeating(a)redhat.com> wrote:
Because it is a targetted spin for a particular peice of software,
much like
an eclipse spin or XFCE spin or asterisk spin.
Or to but it another way. Is the door open for a pure gnome spin using
community power in the future? Where we have the default browser be
gnome's default browser.. and use the gnome specific office
applications instead of open office? I know this isn't practical, but
I think it should be pointed out that what the best-of-breed 'Desktop'
looks like right now is not strictly gnome, it does deviate in
significant ways at the application layer to take advantage of
best-of-breed applications. Because of this it does make sense to
avoid calling it Fedora Gnome, because it is not a faithful
integration of the gnome application set as invisioned by upstream. I
don't think the pool of gnome purists is particularly large so I doubt
we will see a push for a spin of a vanilla gnome, ever.. but there is
room for it in the spin-space. And besides, 4 years from now the
Fedora Desktop will be using the Sugar interface with the
dolphin-accessibility extensions so this how debate is really
short-sighted.
-jef"As a card carrying member of Gnome Purists Anonymous, the
best-of-breed approach to RedHat's view of how to build a desktop
sickens me. Having firefox as the default browser is a perversion of
the sanctity of the gnome ui."spaleta
3:26 p.m.
On Sat, 2007-01-06 at 12:04 -0900, Jeff Spaleta wrote:
On 1/6/07, Jesse Keating <jkeating(a)redhat.com> wrote:
> Because it is a targetted spin for a particular peice of software, much like
> an eclipse spin or XFCE spin or asterisk spin.
Or to but it another way. Is the door open for a pure gnome spin using
community power in the future? Where we have the default browser be
gnome's default browser.. and use the gnome specific office
applications instead of open office?
I think the Fedora project should be open to this kind of thing; I think
we want to make it extremely easy to do "spins" including having some
kind of hosting space provided by the Fedora Project for "blessed"
spins.
Anyone should be able to easily start up a "spin" (even large
corporations for internal deployments but I'm thinking more of Fedora
Special Interest Group (SIG) like XFCE, E17, Music, Games, Eclipse etc.)
and once it has proved itself perhaps it can be officially hosted by the
Fedora Project.
What all this means is probably too early to discuss (I'm thinking out
loud!) but after F7 is out it would be good to see some guidelines on
how all this is going to work out. We want to ensure, for one thing,
that it doesn't grow out of bounds, e.g. we have 100 little used spins;
I think rather we want < 10 high quality and maintained spins.
The governance structure of who controls a spin needs to be thought
about too including guidelines when for resolving conflicts when a
package is needed by more than one spin and there is divergence on how
the package should be packaged up.
With guidelines and thinking of all this... we can start building tools
to easily enable people to do spins. It will take a lot of time to write
all this down though. It's not too early to start I think.
Btw, as a bad analogy, I see
Fedora Package Collection ~= Debian
Fedora Desktop ~= Ubuntu
Fedora KDE ~= Kubuntu
e.g. "spins" are derived Fedora distributions in their very own sense. I
think that's somewhat worth pointing out as it helps put things in
perspective. But let's start with Desktop, Server and KDE as the three
first spins! God knows, we have enough on our plate for F7.
(Btw, I'd welcome a purist GNOME spin - note that our Fedora 6 live CD
uses GNOME office!)
David
3:36 p.m.
On Sat, 2007-01-06 at 16:26 -0500, David Zeuthen wrote:
(Btw, I'd welcome a purist GNOME spin - note that our Fedora 6
live CD
uses GNOME office!)
+1
/B
--
Brian Pepple <bpepple(a)fedoraproject.org>
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
3:45 p.m.
On 1/6/07, David Zeuthen <david(a)fubar.dk> wrote:
(Btw, I'd welcome a purist GNOME spin - note that our Fedora 6 live CD
uses GNOME office!)
With some changes of your scripts, I could make a LiveCD with Xfce
desktop too :)
FYI,
Cheers,
--
http://vnoss.org
3:50 p.m.
On 1/6/07, David Zeuthen <david(a)fubar.dk> wrote:
I think the Fedora project should be open to this kind of thing; I
think
we want to make it extremely easy to do "spins" including having some
kind of hosting space provided by the Fedora Project for "blessed"
spins.
I am just trying to recast the discussion, to show that the issue over
spin branding isn't really
a strict Desktop spin == Gnome spin versus KDE spin. The reality is
Desktop spin == FrankeinFood spin.
Anyone should be able to easily start up a "spin" (even
large
corporations for internal deployments but I'm thinking more of Fedora
Special Interest Group (SIG) like XFCE, E17, Music, Games, Eclipse etc.)
and once it has proved itself perhaps it can be officially hosted by the
Fedora Project.
We may get 'easily' from a toolset point of view. But I personally
have significant concerns that community SIGS will be able to meet my
reasonable expectations with regard to quality integration work. I
will say that the work the FedoraUnity people have been doing with
their livecds and re-spins assuages some of my deeper fears and should
be looked to as a model on how people in the fedora community can
self-organize to get things done.
The governance structure of who controls a spin needs to be thought
about too including guidelines when for resolving conflicts when a
package is needed by more than one spin and there is divergence on how
the package should be packaged up.
Conflicts will always happen, people will have to be willing to work
within a defined conflict resolution process and abide by the
decisions. I expect the biggest pain associated with the merger,
across a number of fronts, will be integrating the in-house culture
surrounding how plans for Core are made, with the external culture
that has been developing for the last 2 or 3 years. I hope there is a
chance for internal and external leads to meet up at FudCon, over some
pizza and beer and some high-spirited wii-sports competitions, and get
to know each other beyond what they see in mailinglist conflicts.
-jef"patiently waiting for FUDCon Fairbanks"spaleta
9:15 a.m.
New subject: Fedora Desktop vs. Fedora Desktop {GNOME, KDE}
Jeff Spaleta wrote:
On 1/6/07, Jesse Keating <jkeating(a)redhat.com> wrote:
> Because it is a targetted spin for a particular peice of software, much
> like an eclipse spin or XFCE spin or asterisk spin.
Or to put it another way. Is the door open for a pure gnome spin using
community power in the future? Where we have the default browser be
gnome's default browser.. and use the gnome specific office
applications instead of open office? I know this isn't practical, but
I think it should be pointed out that what the best-of-breed 'Desktop'
looks like right now is not strictly gnome, it does deviate in
significant ways at the application layer to take advantage of
best-of-breed applications. Because of this it does make sense to
avoid calling it Fedora Gnome
As usual Jeff, you make *way* too much sense for most people (ok, maybe just
me) to comprehend sometimes. (:
-- Rex
10:32 a.m.
On Jan 6, 2007, at 3:06 AM, Warren Togami wrote:
More broadly... Fedora is not a democracy.
Fedora is a meritocracy.
Yes, and it's worth expanding on this. For example, a democracy is
one where people with, say, too much time on their hands are able to
build a community of peers (because most people like to be followed)
and get elected into office based on e.g. the amount of mails the
write and how well they crush their opposition. In a meritocracy we
don't do this, we still let the most competent person (or persons)
make decisions. Of course in some cases it's difficult for outsiders
(who cannot judge, for a given subject matter, who is competent and
who is not) to understand why some decisions are made and some are
not. The day Fedora becomes a democracy is the day I'll contributing
to Fedora.
One issue however that I see with this, is historic lack of inter-
communication between the RH Desktop team and the community.
Not sure what you had in mind (examples?) but it's not exactly true
(which is an understatement) though of course relations between RH
employees and non-RH employees wanting to help out too can be
improved. We always tell people to help out upstream; the only
patches we carry are for defaults really. It's just like the kernel,
we tell Fedora people to hack on kernel.org kernels.
David
11:06 a.m.
David Zeuthen wrote:
Not sure what you had in mind (examples?) but it's not exactly
true
(which is an understatement) though of course relations between RH
employees and non-RH employees wanting to help out too can be improved.
We always tell people to help out upstream; the only patches we carry
are for defaults really. It's just like the kernel, we tell Fedora
people to hack on kernel.org kernels.
Fedora-desktop list is not getting much traffic. All of the desktop team
plans usually happen in a internal list and is completely opaque till
it hits the development tree. One of the problems with that is it
wrongly appears that there is no desktop development work going on
within Fedora.
Very few folks participate here or in any fedora list but that isnt a
problem isolated to one specific team. Please consider having regular
open irc development discussions, post meeting minutes updates, as many
of the sub project like extras,ambassadors, infrastructure etc have been
doing.
Also the only plan for the GNOME desktop spin (not talking about KDE
spin as Rex Dieter is the owner) listed is the detailed spec about fast
user switching. Other than the new icon theme, do we have additional
things to look at? Telepathy? PulseAudio? There has been several other
things discussed in earlier releases and now such as evaluating init
replacements, codec buddy, GDM early login, stateless linux. home user
backup etc which the team might want to keep track of.
Rahul
11:27 a.m.
On Jan 6, 2007, at 12:06 PM, Rahul Sundaram wrote:
David Zeuthen wrote:
> Not sure what you had in mind (examples?) but it's not exactly
> true (which is an understatement) though of course relations
> between RH employees and non-RH employees wanting to help out too
> can be improved. We always tell people to help out upstream; the
> only patches we carry are for defaults really. It's just like the
> kernel, we tell Fedora people to hack on kernel.org kernels.
Fedora-desktop list is not getting much traffic.
True, it's mostly people who ask support questions / asking for
misguided features. Sadly.
All of the desktop team plans usually happen in a internal list
and is completely opaque till it hits the development tree.
Not entirely true; Rahul, you have access to that list and not a lot
of _Fedora_ planning is going on so stop spreading misinformation.
It's mainly used for RHEL stuff. It's true that we have some mails
sometimes discussing early features for Fedora and, sure, in some
instances we still need to move the last 5% to the external list. Wrt
to IRC we also have many discussions externally on #fedora-desktop.
You also need to realize that we have hallway conversations, that's
unavoidable but sometimes high-bandwidth communications are needed.
For example, I did post the f-u-s proposal; it didn't receive much
feedback at all. My take is that the Fedora community largely isn't
very interested in the desktop (I would loved to be proved wrong,
don't take this in a non-constructive way); in that way we're
succesful, for example an avid Fedora user is Richard Hughes and I
deal a lot with him on upstream lists discussing features in hal and
g-p-m.
One of the problems with that is it wrongly appears that there is
no desktop development work going on within Fedora.
The desktop team is understaffed, we spend a lot of time in bugzilla
and doing packaging rather than development. I think you don't
realize this and this is bad as you should know such things being an
RH employee. And this is bad.
PulseAudio?
As Matthias said earlier, Monty is still finalizing that plan for
external consumption; it's just at very early stages of design and at
this point bringing it up on a Fedora list is just not productive; of
course people should feel free to ping him on IRC (nickname xiphmont)
on #fedora-desktop. No one have really, so I guess that there is
little interest? Please come forward.
There has been several other things discussed in earlier releases
and now such as evaluating init replacements, codec buddy, GDM
early login, stateless linux. home user backup etc which the team
might want to keep track of.
This is all something the desktop team cares about but we have not
have time to do anything about it. You're making it sound like we're
working on this in secret chambers. It is not so. Please stop the FUD
about the RH desktop team being secretive, especially when you, as a
RH employee, should know better as you have access to read our
internal list. Also, we all hangout on #fedora-desktop on GimpNet so
it's not like we're difficult to reach. Please join that channel and
starting _talking_ to us instead of treating us like we want to do
things secret. Thanks.
David
Rahul
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
11:47 a.m.
David Zeuthen wrote:
> Fedora-desktop list is not getting much traffic.
True, it's mostly people who ask support questions / asking for
misguided features. Sadly.
Calling it fedora-desktop-devel list might have avoided that problem to
some extent.
Not entirely true; Rahul, you have access to that list and not a lot
of
_Fedora_ planning is going on so stop spreading misinformation. It's
mainly used for RHEL stuff. It's true that we have some mails sometimes
discussing early features for Fedora and, sure, in some instances we
still need to move the last 5% to the external list. Wrt to IRC we also
have many discussions externally on #fedora-desktop.
I dont really have access to all of the internal lists. I could update
the external wiki pages with the information in some of the lists that I
do have access to but that would risk putting out confidential stuff.
Who knows about these fedora-desktop irc discussions apart from the
desktop team itself? Would you consider moving it from Gimpnet to
Freenode along with the rest of the channels? When any considerable
discussions happen on irc, it needs to be posted on the Fedora wiki page
(preferably with meeting mins) for folks to look back. If noone within
the team has time for this, send me the logs and I will do it.
You also need to
realize that we have hallway conversations, that's unavoidable
but
sometimes high-bandwidth communications are needed.
I think we still need to find a way to make the essential parts of those
conversations more public. Fedora Project Board has regular meetings on
phone but we do post meetings mins on the wiki and we have real time
updates on #fedora-board irc channel these days.
For example, I did post the f-u-s proposal; it didn't receive
much
feedback at all. My take is that the Fedora community largely isn't very
interested in the desktop (I would loved to be proved wrong, don't take
this in a non-constructive way); in that way we're succesful, for
example an avid Fedora user is Richard Hughes and I deal a lot with him
on upstream lists discussing features in hal and g-p-m.
I think that's because not many people know about fedora-desktop list.
Would you think merging it with fedora-devel list would be a good thing?
The desktop team is understaffed, we spend a lot of time in bugzilla
and
doing packaging rather than development. I think you don't realize this
and this is bad as you should know such things being an RH employee. And
this is bad.
Ahem. I think you are forgetting our earlier irc conversations. You cant
reasonably expect me to keep track of all the development work happening
more than I do so now. I bet I know more about it than maybe less than
half a dozen people in India. Telling me that I am somehow spreading FUD
might shut me up but is not going to help solve the problem that some of
the development is not as transparent as it could be.
Rahul
12:05 p.m.
On Sat, 2007-01-06 at 23:17 +0530, Rahul Sundaram wrote:
David Zeuthen wrote:
>> Fedora-desktop list is not getting much traffic.
>
> True, it's mostly people who ask support questions / asking for
> misguided features. Sadly.
Calling it fedora-desktop-devel list might have avoided that problem to
some extent.
Maybe. I just don't think people who need support etc. bother (See: this
list).
> Not entirely true; Rahul, you have access to that list and not a
lot of
> _Fedora_ planning is going on so stop spreading misinformation. It's
> mainly used for RHEL stuff. It's true that we have some mails sometimes
> discussing early features for Fedora and, sure, in some instances we
> still need to move the last 5% to the external list. Wrt to IRC we also
> have many discussions externally on #fedora-desktop.
I dont really have access to all of the internal lists. I could update
the external wiki pages with the information in some of the lists that I
do have access to but that would risk putting out confidential stuff.
My point was that little or no interesting Fedora conversations are
going on at that list. You are able to verify this my looking at the
internal Red Hat mailman archives for said list. But you didn't, you
assumed - and posted that to a Fedora community list - that we're
talking about a lot of secretive stuff. Which is wrong. That's what so
bad.
(And of course you should never post information from one internal list
to another, you're missing the point if that's what you think I'm asking
you to do.)
Who knows about these fedora-desktop irc discussions apart from the
desktop team itself? Would you consider moving it from Gimpnet to
Freenode along with the rest of the channels? When any considerable
discussions happen on irc, it needs to be posted on the Fedora wiki page
(preferably with meeting mins) for folks to look back. If noone within
the team has time for this, send me the logs and I will do it.
Not sure it's worthwhile moving it; I for one want it to stay on GimpNet
such as to stay close to upstream IRC channels. Posting minutes is a lot
of work; if people use IRC for such activitites (and we don't I think)
it's better to discuss on a mailing list.
My point was that if someone wants to make Fedora a better desktop,
start by jumping on IRC and interactive with us! I'd be thrilled to see
Fedora users come out and say "hey, I want to write this or that app".
> For example, I did post the f-u-s proposal; it didn't
receive much
> feedback at all. My take is that the Fedora community largely isn't very
> interested in the desktop (I would loved to be proved wrong, don't take
> this in a non-constructive way); in that way we're succesful, for
> example an avid Fedora user is Richard Hughes and I deal a lot with him
> on upstream lists discussing features in hal and g-p-m.
I think that's because not many people know about fedora-desktop list.
Would you think merging it with fedora-devel list would be a good thing?
No way, it needs to be developers solely interested in the _development_
of the desktop, not this forum we have on this list which is more
packaging-entry. It's way too noisy to get any desktop development done
on this list I think.
Again, people should get involved in upstream GNOME and upstream fd.o
development. People just _don't_ seem to get this - just look at the NM
sub-thread of this thread. This surely belongs on
networkmanager-list(a)gnome.org and _people_ still don't get it. Well,
maybe I'm ranting but the thread here did show good ideas - why not take
it to the upstream list where we have more NM wizards that Dan Williams?
> The desktop team is understaffed, we spend a lot of time in
bugzilla and
> doing packaging rather than development. I think you don't realize this
> and this is bad as you should know such things being an RH employee. And
> this is bad.
Ahem. I think you are forgetting our earlier irc conversations. You cant
reasonably expect me to keep track of all the development work happening
more than I do so now. I bet I know more about it than maybe less than
half a dozen people in India. Telling me that I am somehow spreading FUD
might shut me up but is not going to help solve the problem that some of
the development is not as transparent as it could be.
Well, just get the facts before posting because spreading misinformation
(which I'm accusing you of) is bad.
There's not a lot of desktop development going in _Fedora_ and it's not
because the RH Desktop team is being secretive about it. It's because we
either do Bugzilla / Packaging work (which I personally hate as I think
my time is much better spent on writing code) or have the
conversations / do development upstream like we should.
On a constructive note, how can we raise awareness in the Fedora
community that development needs to happen upstream if possible? How can
we easily direct people to gnome.org mailing lists and IRC channels?
(Of course, for some things Fedora _is_ the upstream, see e.g. the
livecd development work. That's open and going well.)
David
12:19 p.m.
David Zeuthen wrote:
My point was that if someone wants to make Fedora a better desktop,
start by jumping on IRC and interactive with us! I'd be thrilled to see
Fedora users come out and say "hey, I want to write this or that app".
People usually realise the existence of irc channels because of the
frequent updates from them. For example, Fedora Extras Steering
Committee has a public schedule and post summaries from all the meetings
they have on a weekly basis.
http://fedoraproject.org/wiki/Extras
No way, it needs to be developers solely interested in the
_development_
of the desktop, not this forum we have on this list which is more
packaging-entry. It's way too noisy to get any desktop development done
on this list I think.
Well, the moment you start posting anything substantial, more people are
going to subscribe and start posting. We can't help. On the other hand
even if some of it is noise (I deserve the blame in some cases), it does
show interest. You might able to turn that interest into contributions -
testing, triaging, development work etc. Fedora-art list is a good
example here.
Again, people should get involved in upstream GNOME and upstream
fd.o
development. People just _don't_ seem to get this - just look at the NM
sub-thread of this thread. This surely belongs on
networkmanager-list(a)gnome.org and _people_ still don't get it. Well,
maybe I'm ranting but the thread here did show good ideas - why not take
it to the upstream list where we have more NM wizards that Dan Williams?
Users would see that as part of Fedora development rather than wanting
to post to all the different upstream mailing lists. I can talk about NM
here but I am not inclined to subscribe to another mailing list just to
post a few points.
On a constructive note, how can we raise awareness in the Fedora
community that development needs to happen upstream if possible?
Having a easily accessible documented policy like
http://fedoraproject.org/wiki/Extras/Policy would help here.
How can
we easily direct people to gnome.org mailing lists and IRC channels?
Might have a sub page in http://fedoraproject.org/wiki/Communicate to
point to the upstream projects that we actively work on and care about.
(Of course, for some things Fedora _is_ the upstream, see e.g. the
livecd development work. That's open and going well.)
Yes. It does. Much appreciated. Thank you.
Rahul
12:42 p.m.
On Sat, 2007-01-06 at 23:49 +0530, Rahul Sundaram wrote:
David Zeuthen wrote:
> My point was that if someone wants to make Fedora a better desktop,
> start by jumping on IRC and interactive with us! I'd be thrilled to see
> Fedora users come out and say "hey, I want to write this or that app".
People usually realise the existence of irc channels because of the
frequent updates from them. For example, Fedora Extras Steering
Committee has a public schedule and post summaries from all the meetings
they have on a weekly basis.
http://fedoraproject.org/wiki/Extras
It's comparing apple's and orange's. Extras has very concrete needs to
be that organized because if the repo is not consistent it breaks for
everybody. Desktop _development_ as opposed to packaging is just
different.
> Again, people should get involved in upstream GNOME and upstream
fd.o
> development. People just _don't_ seem to get this - just look at the NM
> sub-thread of this thread. This surely belongs on
> networkmanager-list(a)gnome.org and _people_ still don't get it. Well,
> maybe I'm ranting but the thread here did show good ideas - why not take
> it to the upstream list where we have more NM wizards that Dan Williams?
Users would see that as part of Fedora development rather than wanting
to post to all the different upstream mailing lists. I can talk about NM
here but I am not inclined to subscribe to another mailing list just to
post a few points.
Well, sorry but software development is just damn hard and it requires
that you actually engage with the community at hand rather than just
post hand-wavy comments. If you cannot engage yourself enough to
subscribe to an upstream list to provide feedback then so be it. Yes,
this is harsh but I'm really tired of this attitude.
Suggest to just post your points in Bugzilla at least so it's tracked;
I've seen way too many people decrease the S/N ratio on e.g. this list
with misguided feature requests and rants about upstream software
components.
It's definitely not useful, it's scaring away core Fedora contributors
(TBH I've thought of unsubscribing from this list several times), it
creates tons of flame wars and it's _not_ something we should encourage.
Please, everyone, in the future please _do_ direct people to appropriate
upstream lists / Bugzilla. If people are too lazy or busy to do that
then so be it, it's a loss I can live with.
Btw, I'd rather just fix the technical problem of not having to
subscribe to a list to post comments. E.g. if you are subscribed to one
@redhat.com list you should be able to post to all. Heck, perhaps that
even gives you posting privileges to the appropriate fd.o and gnome
lists too. And the lists shouldn't cut out Cc's either like we do today.
Our lists are not set up to be friendly in that regard... but that can
change.
All this talk about Fedora community is good. But I think people are
missing out that there's a world beyond Fedora (upstream) that you
_need_ to interact with if you want to make a difference. It also scales
a helluva better.
(sorry if I'm being an ass about things but sometimes it's better to say
what you think.)
David
1:25 p.m.
Le samedi 06 janvier 2007 à 13:42 -0500, David Zeuthen a écrit :
It's comparing apple's and orange's. Extras has very
concrete needs to
be that organized because if the repo is not consistent it breaks for
everybody.
Because the desktop does not need to be consistent?
All this talk about Fedora community is good. But I think people are
missing out that there's a world beyond Fedora (upstream) that you
_need_ to interact with if you want to make a difference. It also scales
a helluva better.
I think you are missing out that
1. people can not interact directly with all the upstreams Fedora builds
on (do you? not just the parts you're working on but all the other bits
you use). Even a dozen upstream MLs is sufficient to saturate any inbox.
2. rahul is one of the few people that tries to be active on the various
Fedora channels and put everything together, if you find him clueless
why I can't begin to imagine what your opinion of a basic community
contributor is
3. you complain the desktop team is misunderstood but as far as I know
its only frontend is http://fedora.redhat.com/About/Projects/desktop/
(almost no info, retired wiki, no reference to the famous irc channel
everyone should know of)
4. you feel you spend too much time on packaging work yet you totally
ignore all the non-redhat people packaging desktop bits in current
Extras. They're not going to help you if you persist being in stealth
mode.
I've been seriously asked in the past if the Fedora Desktop Team
actually existed. That sums up the current situation pretty well.
--
Nicolas Mailhot
1:38 p.m.
On Sat, 2007-01-06 at 20:25 +0100, Nicolas Mailhot wrote:
1. people can not interact directly with all the upstreams Fedora
builds on (do you? not just the parts you're working on but all the
other bit you use).
It's not that bad really; desktop-devel-list(a)gnome.org ,
xdg-list(a)freedesktop.org and so forth. Just reading people's blogs are
often enough.
Even a dozen upstream MLs is sufficient to saturate any inbox.
Well, software development is hard and specialized, sorry. It's just
_not_ _useful_ that people use fedora-devel-list instead of getting
involved in upstream projects. See my other mail for details.
2. rahul is one of the few people that tries to be active on the
various
Fedora channels and put everything together, if you find him clueless
why I can't begin to imagine what your opinion of a basic community
contributor is
I didn't say that; I said he was spreading misinformation that the
desktop team does things in secret. Rahul does a lot of useful stuff but
when I see things like that I need to respond.
3. you complain the desktop team is misunderstood but as far as I
know
its only frontend is http://fedora.redhat.com/About/Projects/desktop/
(almost no info, retired wiki, no reference to the famous irc channel
everyone should know of)
That should probably be fixed, sure. There used to be a nice page on
fedora.redhat.com with this including pointers to upstream lists. Why
the Community Relations (Warren? Rahul?) people involved in Fedora
haven't fixed that I don't know; perhaps they expected the software
developers in the RH desktop team to do that? Perhaps there's some
misunderstanding about responsibilities that needs to be sorted out.
I'll ask my manager to sort this out.
I'm not saying we're perfect, just that most members of the RH desktop
team is focused on upstream work because.. that's where the decisions
are made. That's just reality. And one Fedora mantra is to do things
upstream. (It's interesting that the kernel people don't take the same
flame as us for this attitude)
4. you feel you spend too much time on packaging work yet you
totally
ignore all the non-redhat people packaging desktop bits in current
Extras. They're not going to help you if you persist being in stealth
mode.
True. This discussion is way to heated so I can see I wasn't being
constructive there; apologies to those that felt hurt. Sorry.
David
2:35 p.m.
Le samedi 06 janvier 2007 à 14:38 -0500, David Zeuthen a écrit :
On Sat, 2007-01-06 at 20:25 +0100, Nicolas Mailhot wrote:
> 1. people can not interact directly with all the upstreams Fedora
> builds on (do you? not just the parts you're working on but all the
> other bit you use).
It's not that bad really; desktop-devel-list(a)gnome.org ,
xdg-list(a)freedesktop.org and so forth. Just reading people's blogs are
often enough.
Create a Fedora Desktop Team planet then. Right now there is no
identified Fedora Desktop Team web presence (like there was for the rh
labs in a long-forgotten era)
I'm not saying we're perfect, just that most members of the
RH desktop
team is focused on upstream work because.. that's where the decisions
are made. That's just reality. And one Fedora mantra is to do things
upstream. (It's interesting that the kernel people don't take the same
flame as us for this attitude)
That's because davej has done an awesome job communicating on both ends
(upstream *and* fedora-side). He's not an upstream developer that
happens to be paid by Red Hat, he always pays attention to both agendas.
Likewise ajax seems to have no problem being the Fedora guy upstream and
the xorg guy on Fedora channels (following in mharris steps)
True. This discussion is way to heated so I can see I wasn't
being
constructive there; apologies to those that felt hurt. Sorry.
You're taking the heat for all the Fedora Desktop Team members we don't
ever see Fedora-side, don't take it personal.
Regards,
--
Nicolas Mailhot
2:58 p.m.
On Sat, 2007-01-06 at 21:35 +0100, Nicolas Mailhot wrote:
Le samedi 06 janvier 2007 à 14:38 -0500, David Zeuthen a écrit :
> On Sat, 2007-01-06 at 20:25 +0100, Nicolas Mailhot wrote:
> > 1. people can not interact directly with all the upstreams Fedora
> > builds on (do you? not just the parts you're working on but all the
> > other bit you use).
>
> It's not that bad really; desktop-devel-list(a)gnome.org ,
> xdg-list(a)freedesktop.org and so forth. Just reading people's blogs are
> often enough.
Create a Fedora Desktop Team planet then. Right now there is no
identified Fedora Desktop Team web presence (like there was for the rh
labs in a long-forgotten era)
That's not a bad idea at all though most of the people are on Fedora
People and Planet Gnome. Not all is good at blogging regularly, I'll
certainly admit to not being as communicative as I could be.
Perhaps just someone from the team (like jrb since he's managing the
team) should post a weekly status report about who in the team have been
up what to every week - we have this internally (as do most companies)
but it includes boring RHEL crap as well. Anyway, this person would then
be responsible for collecting status reports from non-RH people too -
that might help foster community involvement a lot. Accountability helps
or somethings. I'll poke some people about that (See: I've added jrb to
the Cc.)
(I also like how you changed to "Fedora Desktop Team" rather than the
"RH Desktop Team" I was using previously.)
You're taking the heat for all the Fedora Desktop Team members we
don't
ever see Fedora-side, don't take it personal.
Oh, I don't (I have burn-proof pants) but I do appreciate that comment,
thanks.
Despite all the flames... getting all the kinks worked out on how the
Brave Merged World is going to look like might actually be beneficial
for the project as a whole. At the end of the day we all want the
project to be successful. And we're getting there.
David
3:22 p.m.
David Zeuthen wrote:
That should probably be fixed, sure. There used to be a nice page on
fedora.redhat.com with this including pointers to upstream lists. Why
the Community Relations (Warren? Rahul?) people involved in Fedora
haven't fixed that I don't know; perhaps they expected the software
developers in the RH desktop team to do that? Perhaps there's some
misunderstanding about responsibilities that needs to be sorted out.
I'll ask my manager to sort this out
fedora.redhat.com is a deprecated website and there is loads of outdated
information in there. If you can just get all the content needed on
fedoraproject.org/wiki, I am happy with that. We would need some more
basic information on who the team is. some contact information like
#fedora-desktop on gimpnet which I honestly only vaguely knew ever
existed and any plans and schedules of importance. That should cover the
basic needs.
Rahul
1:51 p.m.
On Sat, 2007-01-06 at 20:25 +0100, Nicolas Mailhot wrote:
Le samedi 06 janvier 2007 à 13:42 -0500, David Zeuthen a écrit :
> It's comparing apple's and orange's. Extras has very concrete needs to
> be that organized because if the repo is not consistent it breaks for
> everybody.
Because the desktop does not need to be consistent?
Btw, it mostly is, and, for the record, there are huge collaboration
zones called gnome.org, freedesktop.org and kde.org that does this for
us. And several RH employees are actively participating in those fora.
And I think we're mostly doing a good job. Likewise for the kernel,
there is a dude called Linus Torvalds that does the same kind of stuff
for our operating system kernel.
Upstream. Now with more vitamin C.
David
12:29 p.m.
On Sat, 2007-01-06 at 23:17 +0530, Rahul Sundaram wrote:
I think that's because not many people know about fedora-desktop
list.
Would you think merging it with fedora-devel list would be a good thing?
It will be a bad thing. fedora-devel already has a lot of spam for us
poor desktop-oriented guys.
Rename fedora-desktop to fedora-desktop-devel, fine, but the only way to
fix the problem you have may be making people to communicate more on the
list. And the way it currently goes, most of the discussion is going on
in upstream lists, the bugzillas (freedesktop, gnome, and redhat), and
IRC. May look bad from your side, but as the involvement in desktop
seems to need to be quite long-term, this may be necessary to some
degree. Desktop development is not a very rushy business...
An important spot that may be fixable is the packaging problem. If the
desktop team is doing more packaging and eating less cake, let us (the
extra horde?) help them in packaging and let them do the coding (lot of
that may happen gradually after the union). We can't help them with RHEL
of course, but we don't expect to.
Personally speaking, as an untouchable (with regard to RH) Iranian, I
find it rather fine the way things are working with the Fedora Desktop
team currently. I can easily contribute, things match the upstream
closely, people can be found on #fedora-desktop, etc.
Roozbeh
8:12 a.m.
On Sat, 2007-01-06 at 21:59 +0330, Roozbeh Pournader wrote:
I find it rather fine the way things are working with the Fedora
Desktop team currently. I can easily contribute, things match the
upstream closely, people can be found on #fedora-desktop, etc.
Me too. The fedora and redhat guys are great in this respect, I really
don't know what all the fuss is about.
Richard.
12:50 p.m.
David Zeuthen wrote:
On Jan 6, 2007, at 12:06 PM, Rahul Sundaram wrote:
> David Zeuthen wrote:
>
>> Not sure what you had in mind (examples?) but it's not exactly true
>> (which is an understatement) though of course relations between RH
>> employees and non-RH employees wanting to help out too can be
>> improved. We always tell people to help out upstream; the only
>> patches we carry are for defaults really. It's just like the kernel,
>> we tell Fedora people to hack on kernel.org kernels.
>
> Fedora-desktop list is not getting much traffic.
True, it's mostly people who ask support questions / asking for
misguided features. Sadly.
This is due to a lack of leadership. I've been asking Havoc and then
Jrb for *YEARS* for someone in RH desktop to provide adequate and
responsible community outreach and leadership on fedora-desktop-list.
Without direction, the list remained utterly useless.
> One of the problems with that is it wrongly appears that there is
no
> desktop development work going on within Fedora.
The desktop team is understaffed, we spend a lot of time in bugzilla and
doing packaging rather than development. I think you don't realize this
and this is bad as you should know such things being an RH employee. And
this is bad.
This is a weak excuse, for lack of trying.
Recall when Red Hat had no perl maintainer for more than a year? Red
Hat reached out to the community, created a Fedora perl team with a
responsive perl caretaker providing effective outreach to that
community. The resulting combination of thin Red Hat resource with
effective collaboration with a few leading Fedora developers magnified
many times fold the amount of work done.
on this in secret chambers. It is not so. Please stop the FUD about the
RH desktop team being secretive, especially when you, as a RH employee,
should know better as you have access to read our internal list. Also,
The attitude of the desktop team has always been one of an exclusive
club, making little attempts to engage the Fedora community. While the
work was done in the open (upstream at GNOME), decisions and discussions
happened only internally.
This has been a problem of attitude. Your recent attempt to subvert the
community driven Fedora 7 art creation process with heavy-handed "This
is my job" authority is just yet another example of this.
Warren Togami
wtogami(a)redhat.com
1:23 p.m.
On Sat, 2007-01-06 at 13:50 -0500, Warren Togami wrote:
> on this in secret chambers. It is not so. Please stop the FUD
about the
> RH desktop team being secretive, especially when you, as a RH employee,
> should know better as you have access to read our internal list. Also,
The attitude of the desktop team has always been one of an exclusive
club, making little attempts to engage the Fedora community. While the
work was done in the open (upstream at GNOME), decisions and discussions
happened only internally.
Oh my. It's come to posting conspiracy theories? Warren, this is out of
line. You, and a few other people, are so extremely obsessed with
creating / building a community around Fedora that you fail to take into
account
a) what the world looks like (we do / want to do the work
upstream); and
b) what is actually out there in the community (not a whole lot
of useful input today desktop-wise).
It's fine to get more community involvement. It does DO NOT happen
overnight and sacrificing quality is not an option. It happens
gradually. Please wake up.
This has been a problem of attitude. Your recent attempt to subvert
the
community driven Fedora 7 art creation process with heavy-handed "This
is my job" authority is just yet another example of this.
It is my job to maintain the artwork packages and, yes, I'm deeply
troubled by the attitude on that list. That list is a place where the
guy with the biggest stereo wins (e.g. democracy, not what we do).
That's not a way to get the best result so of course I'm concerned. It's
my god damn job to be concerned about that.
If you want to discuss further take your fucking conspiracy theories off
list and mail me directly.
David
1:51 p.m.
David Zeuthen wrote:
> This has been a problem of attitude. Your recent attempt to subvert the
> community driven Fedora 7 art creation process with heavy-handed "This
> is my job" authority is just yet another example of this.
It is my job to maintain the artwork packages and, yes, I'm deeply
troubled by the attitude on that list. That list is a place where the
guy with the biggest stereo wins (e.g. democracy, not what we do).
fedora-art-list is not a democracy, but rather a meritocracy. The vast
majority of the work there has been done by volunteers, with Máirín
Duffy doing most of the community outreach and communication. Not
everyone there has equal decision making power. Those who have done
work and gained respect from others gain greater authority. From merit,
some clear community leaders have emerged like Nicu Buculei.
Is this not how a Fedora Project should be run?
https://www.redhat.com/archives/fedora-art-list/2006-December/msg00178.html
The Fedora Project Board decided, the community process is to be
followed and the result of that will be used in Fedora 7 pending the
Board's approval.
This is NOT YOUR DECISION. This is the Board's decision.
That's not a way to get the best result so of course I'm
concerned. It's
my god damn job to be concerned about that.
If you want to discuss further take your fucking conspiracy theories off
list and mail me directly.
I will discuss this in public, because the Fedora Project should be
transparent and open.
Warren Togami
wtogami(a)redhat.com
2:02 p.m.
On Sat, 2007-01-06 at 14:51 -0500, Warren Togami wrote:
fedora-art-list is not a democracy, but rather a meritocracy.
It is not. It's run by very loud people who are not afraid to resort to
personal attacks and forming fractions and alliances.
The vast
majority of the work there has been done by volunteers, with Máirín
Duffy doing most of the community outreach and communication. Not
everyone there has equal decision making power. Those who have done
work and gained respect from others gain greater authority. From merit,
some clear community leaders have emerged like Nicu Buculei.
"Communication" is not the only deciding factor. I think the work on
that list is not up to Fedora release quality. As the maintainer of the
artwork packages plus dealing with graphics people both in this and past
jobs I can make that statement. I doubt that you can.
(This is harsh, but sorry, Warren pushed me to say such things.)
This is NOT YOUR DECISION. This is the Board's decision.
I know, but I am free to disagree with the board. I think they are
trading quality for building "community". They are in this case, I
think, hurting the quality of Fedora by turning the art selection
process into a democracy. It's a shame and it makes believe less in the
board.
I will discuss this in public, because the Fedora Project should be
transparent and open.
You are just naive (and you should know better) that this is a good
forum to discuss such matters in. Most of the issues in this case are
personal so it's even bad form to bring it up here. You should be really
ashamed of yourself Warren. I'm positive no constructive discussion can
follow so I'm replying to any of your replies. Thanks.
David
2:22 p.m.
David Zeuthen wrote:
On Sat, 2007-01-06 at 14:51 -0500, Warren Togami wrote:
> fedora-art-list is not a democracy, but rather a meritocracy.
It is not. It's run by very loud people who are not afraid to resort to
personal attacks and forming fractions and alliances.
One of us is trying to build a community with a meritocracy governance
model. The other is using heavy-handed tactics in protectionism,
appealing to the fallacy of authority 'this is my job'. Only one of
these paths is what is best for the community.
Please consider the possibility, that what you are doing is selfish and
wrong.
> The vast
> majority of the work there has been done by volunteers, with Máirín
> Duffy doing most of the community outreach and communication. Not
> everyone there has equal decision making power. Those who have done
> work and gained respect from others gain greater authority. From merit,
> some clear community leaders have emerged like Nicu Buculei.
"Communication" is not the only deciding factor. I think the work on
that list is not up to Fedora release quality. As the maintainer of the
artwork packages plus dealing with graphics people both in this and past
jobs I can make that statement. I doubt that you can.
(This is harsh, but sorry, Warren pushed me to say such things.)
> This is NOT YOUR DECISION. This is the Board's decision.
I know, but I am free to disagree with the board. I think they are
trading quality for building "community". They are in this case, I
think, hurting the quality of Fedora by turning the art selection
process into a democracy.
I have made it pretty clear that this is NOT a democracy. You seem to
think that anything where the decision is out of your hands is a
democracy. You are free to have that as a personal opinion.
It's a shame and it makes believe less in the board.
You don't need to believe in the Board. The project will move forward
with or without your belief.
Warren Togami
wtogami(a)redhat.com
3 p.m.
On Sat, 2007-01-06 at 15:02 -0500, David Zeuthen wrote:
On Sat, 2007-01-06 at 14:51 -0500, Warren Togami wrote:
> fedora-art-list is not a democracy, but rather a meritocracy.
It is not. It's run by very loud people who are not afraid to resort to
personal attacks and forming fractions and alliances.
This is exactly what I've noticed as well. Not what I expected to see,
but that's ok, been there done that, they can bring it.
> The vast
> majority of the work there has been done by volunteers, with Máirín
> Duffy doing most of the community outreach and communication. Not
> everyone there has equal decision making power. Those who have done
> work and gained respect from others gain greater authority. From merit,
> some clear community leaders have emerged like Nicu Buculei.
"Communication" is not the only deciding factor. I think the work on
that list is not up to Fedora release quality. As the maintainer of the
artwork packages plus dealing with graphics people both in this and past
jobs I can make that statement. I doubt that you can.
(This is harsh, but sorry, Warren pushed me to say such things.)
I don't think it's harsh, I just think it's the truth.
> This is NOT YOUR DECISION. This is the Board's decision.
I know, but I am free to disagree with the board. I think they are
trading quality for building "community". They are in this case, I
think, hurting the quality of Fedora by turning the art selection
process into a democracy. It's a shame and it makes believe less in the
board.
I see alot of things that don't ring true; for instance, in this
discussion there has been absolutely no mention of technical merit with
regard to your contributions. To the contrary, there has only been
discussion of authority and overriding decisions. To me this smacks of
elitism; "We agree with you as long as you say what we like. Otherwise
we don't want to hear what you say."
> I will discuss this in public, because the Fedora Project should be
> transparent and open.
You are just naive (and you should know better) that this is a good
forum to discuss such matters in. Most of the issues in this case are
personal so it's even bad form to bring it up here. You should be really
ashamed of yourself Warren. I'm positive no constructive discussion can
follow so I'm replying to any of your replies. Thanks.
David
But you know what? This is exactly the forum to discuss in, because
from here we get a good idea of what Warren is all about. Personal or
no, one guy locked in a room with 50 assailants is not going to promote
progress.
This is the arena of ideas. Let the users help sort this out. Trust
them to help you because, it is, after all, for their benefit that all
these things take place.
You are not the first one to have problems of this nature with the, eh,
"meritocracy".
LX
2:45 p.m.
On Sat, 2007-01-06 at 14:51 -0500, Warren Togami wrote:
I will discuss this in public, because the Fedora Project should be
transparent and open.
Hmmmm. Well alrighty.
David Zeuthen wrote:
>
>> This has been a problem of attitude. Your recent attempt to subvert the
>> community driven Fedora 7 art creation process with heavy-handed "This
>> is my job" authority is just yet another example of this.
>
> It is my job to maintain the artwork packages and, yes, I'm deeply
> troubled by the attitude on that list. That list is a place where the
> guy with the biggest stereo wins (e.g. democracy, not what we do).
fedora-art-list is not a democracy, but rather a meritocracy. The vast
majority of the work there has been done by volunteers, with Máirín
Duffy doing most of the community outreach and communication. Not
everyone there has equal decision making power. Those who have done
work and gained respect from others gain greater authority. From merit,
some clear community leaders have emerged like Nicu Buculei.
The big question is, who decides who has the "merit". I see potential
ideological problems here even if someone works their ass off, but then
isn't necessarily considered to be, for example, 'a good socialist'. Or
a good "Stallmanist". Or is that Stalinist? Sorry, I get those two
confused.
In such cases, a harder worker could potentially be punished for not
"towing the party line". The general excuse could be, "well, we have
guys with greater merit. This is a meritocracy."
Maybe it is a meritocracy. But it should be technical merit, not
anything else. One guy with a better idea should triumph over 10 guys
with stupid ideas.
Is this not how a Fedora Project should be run?
https://www.redhat.com/archives/fedora-art-list/2006-December/msg00178.html
The Fedora Project Board decided, the community process is to be
followed and the result of that will be used in Fedora 7 pending the
Board's approval.
This is NOT YOUR DECISION. This is the Board's decision.
Which will work as long as the Board a) acknowledges the existence of
users b) takes it's cues from the users first and c) prioritizes
technical merit over ideology.
It is also useful to examine the success of your competition. As other
open source gods have already suggested here.
> That's not a way to get the best result so of course I'm concerned.
It's
> my god damn job to be concerned about that.
>
> If you want to discuss further take your fucking conspiracy theories off
> list and mail me directly.
>
Warren Togami
wtogami(a)redhat.com
LX
3:05 p.m.
Lyvim Xaphir wrote:
The big question is, who decides who has the "merit". I see potential
"Merit" is earned through hard work.
"Hard work" should speak for itself.
Sometimes disagreements happen, then the tough decision must go up the
leadership chain to a deciding body. In Fedora we have multiple levels
like:
FESCO (to be renamed) - technical/packaging governance issues
FAB - issues recommendations, does not decide
FPB - ultimate decider if lower levels cannot agree
ideological problems here even if someone works their ass off, but
then
isn't necessarily considered to be, for example, 'a good socialist'. Or
a good "Stallmanist". Or is that Stalinist? Sorry, I get those two
confused.
Calling names is intellectually lazy. Please describe with specificity
how the desire to create a community where people earn respect through
their hard work is Stalin-like?
I don't see the connection between Stalin and Stallman either.
>
https://www.redhat.com/archives/fedora-art-list/2006-December/msg00178.html
> The Fedora Project Board decided, the community process is to be
> followed and the result of that will be used in Fedora 7 pending the
> Board's approval.
>
> This is NOT YOUR DECISION. This is the Board's decision.
Which will work as long as the Board a) acknowledges the existence of
users b) takes it's cues from the users first and c) prioritizes
technical merit over ideology.
What ideology are you referring to?
If you have criticisms of the Board not doing what is best for the
users, then please speak in specifics instead of intellectually lazy
generalizations.
Warren Togami
wtogami(a)redhat.com
3:25 p.m.
On Saturday 06 January 2007 16:05, Warren Togami wrote:
"Merit" is earned through hard work.
"Hard work" should speak for itself.
Lets not forget that it is hard _CORRECT_ work. You do all the hard work you
want, but if the product of that work is not as good as something else, guess
what, we're going to go with the something else. This isn't about quantity
of work done (or emails sent, or volume of speakers), it's about quality of
produced products.
--
Jesse Keating
Release Engineer: Fedora
1:32 p.m.
On Sat, 2007-01-06 at 13:50 -0500, Warren Togami wrote:
The attitude of the desktop team has always been one of an exclusive
club, making little attempts to engage the Fedora community. While
the work was done in the open (upstream at GNOME), decisions and
discussions happened only internally.
I don't think this is the case at all, and that's from an "upstream
GNOME maintainer, who uses Fedora" point of view. I also don't think
this is the sort of stuff we should be discussing on list, as it's not
productive in any way.
Richard.
11:42 a.m.
On Sat, 2007-01-06 at 22:36 +0530, Rahul Sundaram wrote:
Also the only plan for the GNOME desktop spin (not talking about KDE
spin as Rex Dieter is the owner) listed is the detailed spec about fast
user switching. Other than the new icon theme, do we have additional
things to look at? Telepathy? PulseAudio? There has been several other
things discussed in earlier releases and now such as evaluating init
replacements, codec buddy, GDM early login, stateless linux. home user
backup etc which the team might want to keep track of.
Most of the Telepathy framework is already in Extras. I think the only
missing piece right now is the IRC connection manager. Of course, there
aren't many clients right now that make use of it in Extras (Cohoba
being the only one I can think of).
/B
--
Brian Pepple <bpepple(a)fedoraproject.org>
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
3:21 p.m.
Warren Togami wrote:
Warren Togami wrote:
>
> Fedora Desktop and Fedora KDE spins. Is that really so bad?
>
How big would a "Desktop" spin that contains both GNOME and KDE be?
depends on the packages
Too big?
I doubt it, It should be smaller as the former "Core" spin, because
server packages are not in it.
Warren Togami
wtogami(a)redhat.com
5:28 p.m.
On 04 Jan 2007 16:19:11 -0600, Jason L Tibbitts III <tibbs(a)math.uh.edu> wrote:
Umm, isn't the Fedora supposed to become the community's
distribution,
and so isn't it up to the community to decide whether Fedora is
"anything"-centric?
The community has spoken... Fedora 7 will be dolphin-centric.
-jef
5:35 p.m.
On Thu, Jan 04, 2007 at 02:28:40PM -0900, Jeff Spaleta wrote:
The community has spoken... Fedora 7 will be dolphin-centric.
I thought it was seal-centric?
http://fedoraproject.org/wiki/Releases/FeatureFixWakeups?highlight=%28Cat...
9:16 p.m.
Jason L Tibbitts III (tibbs(a)math.uh.edu) said:
JK> Its no mystery that Fedora is a Gnome centric distribution,
and it
JK> should be no surprise that the Fedora Desktop spin is Gnome based.
Umm, isn't the Fedora supposed to become the community's distribution,
and so isn't it up to the community to decide whether Fedora is
"anything"-centric?
I could care less about naming either way, but declaring up-front that
regardless of what the community does or wants, Fedora is still going
to favor any specific technology seems counterproductive in this new
spirit of complete community involvement.
Well, it may be presumptive to speak for 'Fedora-the-project', however,
there seems to be an underlying assumption in this mail, that there
is:
Red Hat | Community
If that's not intended to be there, I'm sorry - that's just the
impression I got.
Rather, I believe there is a large Fedora community that includes
many people from Red Hat. In this community, right now, there is
a large developer community that is interested in working on GNOME
- it's not being deceptive to say that at the moment, it's larger
than the community currently working on KDE, XFCE, E, or whatever.
That GNOME community has stated that they want a desktop spin of Fedora
that includes GNOME, and has stepped up to do it. So it's on the
feature list.
I'm not going to lie to you - Red Hat has significant interests that
are going to drive the resources we assign to Fedora, as Fedora is
the upstream of RHEL; the fact that Red Hat has these interests and
allocates resources this way isn't going to change. What we're trying
to change is make it easy for Fedora to be used for *even more than
RHEL*, whether it be Yellow Dog, or OLPC, or whatever.
Not to talk about 'the other guys', but much in the way that
there is Ubuntu and Kubuntu.
Bill
10:28 p.m.
On 1/4/07, Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
Jesse Keating wrote:
> Yes, Fedora Desktop and Fedora Server will probably be the official Fedora
> Project spins of Fedora. Fedora KDE is the proof of concept, perhaps widely
> used "community contributed" spin of Fedora. That's why (IMHO) its
named
> specifically with "KDE" whereas the official spin is just
"Desktop". If you
> don't know what "KDE" or "GNOME" is, you wouldn't know
to choose it. Desktop
> is a good generic name that is understandable. However if you already know
> and prefer KDE, you know to get the KDE spin.
It would be consistent to have something like
Fedora Desktop (GNOME edition) and
Fedora Desktop (KDE edition)
It's confusing and discriminatory to call one of the spins as the
desktop when you have more (which is likely to increase) than one
desktop oriented spins.
I don't think it is descriminatory at all.
Actually, what would be consistent would be for the Gnome community to
name something "This does Foo" that has functionality Foo and the KDE
community to name something "KBar" that has the functionality Bar (and
I have a whole bunch of KStuff in my Gnome menu to prove it). Jesse's
original suggestion is more inline with that since KFedora is a bit
unweildy.
KDE folk seem to like their brand stuck on every piece of software
made for that desktop. Gnome folk tend not to go that route and name
their apps random obscure words and put localized descriptions in the
menus. To each their own.
/Mike
3:32 a.m.
On Friday 05 January 2007 4:28 am, Michael Wiktowy wrote:
I don't think it is descriminatory at all.
I do. Please take what follows in a light mood, at least I did.
Actually, what would be consistent would be for the Gnome community
to
name something "This does Foo" that has functionality Foo and the KDE
community to name something "KBar" that has the functionality Bar (and
I have a whole bunch of KStuff in my Gnome menu to prove it). Jesse's
original suggestion is more inline with that since KFedora is a bit
unweildy.
I would call that more an historical accident that a planned strategy.
Please don't forget as well gedit, gaim, gphoto...
OTHO I use gwenview - Simple image viewer for KDE.
KDE folk seem to like their brand stuck on every piece of software
made for that desktop. Gnome folk tend not to go that route and name
their apps random obscure words and put localized descriptions in the
menus. To each their own.
The plan (and practice) for KDE 4 is not to add a k preffix in a gratuitous
way. FWIW the only new project that I remember now that starts with k, for
KDE 4, is KDE 4 itself. :-)
Certainly the existing projects will retain their names, it would be foolish
to do it otherwise, but please don't put intention where it is not.
/Mike
--
José Abílio
9:14 a.m.
On 1/5/07, José Matos <jamatos(a)fc.up.pt> wrote:
On Friday 05 January 2007 4:28 am, Michael Wiktowy wrote:
> I don't think it is descriminatory at all.
I do. Please take what follows in a light mood, at least I did.
Ya ... my intent was not to stir up flame wars but to poke a little
fun at both communities and point out this this is a non-issue since
each community can name things how they like to. In the end, it is up
to the content creators to name the content.
> Actually, what would be consistent would be for the Gnome
community to
> name something "This does Foo" that has functionality Foo and the KDE
> community to name something "KBar" that has the functionality Bar (and
> I have a whole bunch of KStuff in my Gnome menu to prove it). Jesse's
> original suggestion is more inline with that since KFedora is a bit
> unweildy.
I would call that more an historical accident that a planned strategy.
Please don't forget as well gedit, gaim, gphoto...
OTHO I use gwenview - Simple image viewer for KDE.
I was aware of those apps (except for gwenview) but I took a look in
my application menu before sending my original message and didn't see
any reference to them since they were hidden behind names like Text
Editor, Instant Messenger and Photo Viewer whereas all the KDE apps
kind of stood out.
> KDE folk seem to like their brand stuck on every piece of
software
> made for that desktop. Gnome folk tend not to go that route and name
> their apps random obscure words and put localized descriptions in the
> menus. To each their own.
The plan (and practice) for KDE 4 is not to add a k preffix in a gratuitous
way. FWIW the only new project that I remember now that starts with k, for
KDE 4, is KDE 4 itself. :-)
Certainly the existing projects will retain their names, it would be foolish
to do it otherwise, but please don't put intention where it is not.
Fair enough. Like I said, I have plenty of KApps in my Gnome menu and
like them so I was basing my thoughts on observation from the outside
of both camps. I am glad that there are efforts to make both desktop
apps work together and not drive them apart. In the end, having things
Just Work (TM) is what is best for the end user.
/Mike
11:02 a.m.
On Friday 05 January 2007 3:14 pm, Michael Wiktowy wrote:
Fair enough. Like I said, I have plenty of KApps in my Gnome menu
and
like them so I was basing my thoughts on observation from the outside
of both camps. I am glad that there are efforts to make both desktop
apps work together and not drive them apart. In the end, having things
Just Work (TM) is what is best for the end user.
I agree and I applaud the effort make by the different teams under
freedesktops.org umbrella. It is not easy but we are the winners in the
end. :-)
/Mike
--
José Abílio
12:55 a.m.
New subject: Fedora Desktop vs. Fedora Desktop {GNOME,KDE} (was: Re: Fedora 7)
On 04.01.2007 22:22, Rahul Sundaram wrote:
Jesse Keating wrote:
> Yes, Fedora Desktop and Fedora Server will probably be the official Fedora
> Project spins of Fedora. Fedora KDE is the proof of concept, perhaps widely
> used "community contributed" spin of Fedora. That's why (IMHO) its
named
> specifically with "KDE" whereas the official spin is just
"Desktop". If you
> don't know what "KDE" or "GNOME" is, you wouldn't know to
choose it. Desktop
> is a good generic name that is understandable. However if you already know
> and prefer KDE, you know to get the KDE spin.
It would be consistent to have something like
Fedora Desktop (GNOME edition) and
Fedora Desktop (KDE edition)
It's confusing and discriminatory to call one of the spins as the
desktop when you have more (which is likely to increase) than one
desktop oriented spins.
+1 from me to this as a long term Gnome user that's not much interested
in KDE; but I know others are.
This issue brings up a interesting question: Which board has the power
to influence and adjust this particular naming scheme in our new
"merged" world? FESCo or the Fedora Board?
CU
thl
8:42 a.m.
New subject: Fedora Desktop vs. Fedora Desktop {GNOME, KDE} (was: Re: Fedora 7)
On Fri, 2007-01-05 at 07:55 +0100, Thorsten Leemhuis wrote:
This issue brings up a interesting question: Which board has the
power
to influence and adjust this particular naming scheme in our new
"merged" world? FESCo or the Fedora Board?
Ultimately, the Board has to own this issue.
Jeremy
8:44 a.m.
New subject: Fedora Desktop vs. Fedora Desktop {GNOME, KDE} (was: Re: Fedora 7)
On Friday 05 January 2007 01:55, Thorsten Leemhuis wrote:
This issue brings up a interesting question: Which board has the
power
to influence and adjust this particular naming scheme in our new
"merged" world? FESCo or the Fedora Board?
Ultimately I feel it should be the Fedora board. FESCo is really responsible
for making sure the full repo is there, and the Distribution cabal (hopefully
there will be more than just me) is responsible for taking content from that
repository and creating installable iso sets from it.
--
Jesse Keating
Release Engineer: Fedora
9:01 a.m.
New subject: Fedora Desktop vs. Fedora Desktop {GNOME, KDE} (was: Re: Fedora 7)
On Fri, 2007-01-05 at 09:44 -0500, Jesse Keating wrote:
On Friday 05 January 2007 01:55, Thorsten Leemhuis wrote:
> This issue brings up a interesting question: Which board has the power
> to influence and adjust this particular naming scheme in our new
> "merged" world? FESCo or the Fedora Board?
Ultimately I feel it should be the Fedora board. FESCo is really responsible
for making sure the full repo is there, and the Distribution cabal (hopefully
there will be more than just me) is responsible for taking content from that
repository and creating installable iso sets from it.
I think it's a little more complicated than that. Or maybe not. If
there are two committees, one for the repo and one for the release, they
need to work really closely together. The release cabal needs a stable
set of packages to build the releases from and the repo cabal would need
to enforce that. E.g. feature freeze, string freeze, etc.
Personally, I'd rather see the current FESCo and Core cabal merged into
a single entity that shares both responsibilities. The Packaging
Committee would certainly still exist to come up with the packaging
guidelines, so that wouldn't change. And you immediately get community
involvement in the content of the release isos, which is what I think
Jessie meant by "hopefully there will be more than just me". Just my
$0.02.
josh
9:09 a.m.
New subject: Fedora Desktop vs. Fedora Desktop {GNOME, KDE} (was: Re: Fedora 7)
On Friday 05 January 2007 10:01, Josh Boyer wrote:
Personally, I'd rather see the current FESCo and Core cabal
merged into
a single entity that shares both responsibilities. The Packaging
Committee would certainly still exist to come up with the packaging
guidelines, so that wouldn't change. And you immediately get community
involvement in the content of the release isos, which is what I think
Jessie meant by "hopefully there will be more than just me". Just my
$0.02.
Keep in mind that it's just adding more people to a committee who may not care
about other things such as sponsorship stuff, policy related to packages,
various other stuff that FESCO current has to vote on. Its adding more
people, making quorum harder to reach, especially when they might not have
any interest/knowledge of whats being voted on.
Personally I don't like a "commitee" for each little task that needs done.
I'm much more a fan of "hey these are the people doing the work, make sure
they talk to eachother, and report progress somewhere". So to that end, I'm
going to continue doing work, and reporting progress to places like the
Fedora Board, mailing lists, blogs, whatever.
--
Jesse Keating
Release Engineer: Fedora
9:27 a.m.
New subject: Fedora Desktop vs. Fedora Desktop {GNOME, KDE} (was: Re: Fedora 7)
On Fri, 2007-01-05 at 10:09 -0500, Jesse Keating wrote:
On Friday 05 January 2007 10:01, Josh Boyer wrote:
> Personally, I'd rather see the current FESCo and Core cabal merged into
> a single entity that shares both responsibilities. The Packaging
> Committee would certainly still exist to come up with the packaging
> guidelines, so that wouldn't change. And you immediately get community
> involvement in the content of the release isos, which is what I think
> Jessie meant by "hopefully there will be more than just me". Just my
> $0.02.
Keep in mind that it's just adding more people to a committee who may not care
about other things such as sponsorship stuff, policy related to packages,
various other stuff that FESCO current has to vote on. Its adding more
people, making quorum harder to reach, especially when they might not have
any interest/knowledge of whats being voted on.
I said their responsibilities should be merged. I didn't say they
should necessarily be merged in in their current states.
Personally I don't like a "commitee" for each little
task that needs done.
Enforcement of policies and release engineering aren't little tasks.
You know that.
I'm much more a fan of "hey these are the people doing the
work, make sure
they talk to eachother, and report progress somewhere". So to that end, I'm
going to continue doing work, and reporting progress to places like the
Fedora Board, mailing lists, blogs, whatever.
Sure. Great. Yet unless you plan on being the benevolent dictator of
the iso releases, you will need to know what you're working towards.
Which includes package selections, etc. Do you plan on deciding the
content all by yourself? I doubt it.
josh
9:32 a.m.
New subject: Fedora Desktop vs. Fedora Desktop {GNOME, KDE} (was: Re: Fedora 7)
On Fri, 2007-01-05 at 09:27 -0600, Josh Boyer wrote:
On Fri, 2007-01-05 at 10:09 -0500, Jesse Keating wrote:
> On Friday 05 January 2007 10:01, Josh Boyer wrote:
> > Personally, I'd rather see the current FESCo and Core cabal merged into
> > a single entity that shares both responsibilities. The Packaging
> > Committee would certainly still exist to come up with the packaging
> > guidelines, so that wouldn't change. And you immediately get community
> > involvement in the content of the release isos, which is what I think
> > Jessie meant by "hopefully there will be more than just me". Just
my
> > $0.02.
>
> Keep in mind that it's just adding more people to a committee who may not care
> about other things such as sponsorship stuff, policy related to packages,
> various other stuff that FESCO current has to vote on. Its adding more
> people, making quorum harder to reach, especially when they might not have
> any interest/knowledge of whats being voted on.
I said their responsibilities should be merged. I didn't say they
should necessarily be merged in in their current states.
Actually, re-reading my own email I really did say "the current FESCo
and Core cabal..". I meant the responsibilities though, not necessarily
the actual committees themselves. Sorry for the confusion.
josh
9:28 a.m.
New subject: Fedora Desktop vs. Fedora Desktop {GNOME, KDE}
Jesse Keating schrieb:
On Friday 05 January 2007 10:01, Josh Boyer wrote:
> Personally, I'd rather see the current FESCo and Core cabal merged into
> a single entity that shares both responsibilities. The Packaging
> Committee would certainly still exist to come up with the packaging
> guidelines, so that wouldn't change. And you immediately get community
> involvement in the content of the release isos, which is what I think
> Jessie meant by "hopefully there will be more than just me". Just my
> $0.02.
Keep in mind that it's just adding more people to a committee who may not care
about other things such as sponsorship stuff, policy related to packages,
various other stuff that FESCO current has to vote on. Its adding more
people, making quorum harder to reach, especially when they might not have
any interest/knowledge of whats being voted on.
Yeah, true, that problematic.
Personally I don't like a "commitee" for each little
task that needs done.
I'm much more a fan of "hey these are the people doing the work, make sure
they talk to eachother, and report progress somewhere". [...]
Yes, in an ideal world that should work. In a small Core-world it seems
to have worked well, too. But I don't think it will work in a big
community project...
Just my 2 cent.
Cu
thl
9:16 a.m.
New subject: Fedora Desktop vs. Fedora Desktop {GNOME, KDE}
Josh Boyer schrieb:
On Fri, 2007-01-05 at 09:44 -0500, Jesse Keating wrote:
> On Friday 05 January 2007 01:55, Thorsten Leemhuis wrote:
>> This issue brings up a interesting question: Which board has the power
>> to influence and adjust this particular naming scheme in our new
>> "merged" world? FESCo or the Fedora Board?
> Ultimately I feel it should be the Fedora board. FESCo is really responsible
> for making sure the full repo is there, and the Distribution cabal (hopefully
> there will be more than just me) is responsible for taking content from that
> repository and creating installable iso sets from it.
I think it's a little more complicated than that.
I think it is.
Or maybe not. If
there are two committees, one for the repo and one for the release, they
need to work really closely together.
And that often sucks. Even with FESCo and the Packaging Committee (they
are practically on the same level currently, so none of the two can give
the other orders [yes, we normally should not give orders, but sometimes
it might be helpfull]) there were some situations where one was pointing
to the other "you have to solve this particular issue". That was a bit
problematic, and I'd like to avoid a similar situations in the future as
much as possible.
The release cabal needs a stable
set of packages to build the releases from and the repo cabal would need
to enforce that. E.g. feature freeze, string freeze, etc.
Personally, I'd rather see the current FESCo and Core cabal merged into
a single entity that shares both responsibilities.
+1
The Packaging
Committee would certainly still exist to come up with the packaging
guidelines, so that wouldn't change.
It should be clear that it remains FESCo's job to enforce the stuff the
packaging committee decides. But FESCo should be able to say "Packaging
Committee, work out rules for foo, as we have a packaging problem here
that needs to be solved, and you guys know best about this kind of stuff
is handled"
[...]
CU
thl
9:24 a.m.
New subject: Fedora Desktop vs. Fedora Desktop {GNOME, KDE} (was: Re: Fedora 7)
Le Ven 5 janvier 2007 16:01, Josh Boyer a écrit :
On Fri, 2007-01-05 at 09:44 -0500, Jesse Keating wrote:
> On Friday 05 January 2007 01:55, Thorsten Leemhuis wrote:
> > This issue brings up a interesting question: Which board has the power
> > to influence and adjust this particular naming scheme in our new
> > "merged" world? FESCo or the Fedora Board?
>
> Ultimately I feel it should be the Fedora board. FESCo is really
> responsible
> for making sure the full repo is there, and the Distribution cabal
> (hopefully
> there will be more than just me) is responsible for taking content from
> that
> repository and creating installable iso sets from it.
I think it's a little more complicated than that. Or maybe not. If
there are two committees, one for the repo and one for the release, they
need to work really closely together. The release cabal needs a stable
set of packages to build the releases from and the repo cabal would need
to enforce that. E.g. feature freeze, string freeze, etc.
My feeling is somehow different. I'd really love to have a clear
separation between the group that makes long-term transverse decisions and
the group responsible for driving a particular release (with perhaps given
Fedora's short lifecycle & usual manager burnout different groups for
different releases).
That's the only way you'll get clear release focus
Regards,
--
Nicolas Mailhot
9:08 a.m.
New subject: Fedora Desktop vs. Fedora Desktop {GNOME, KDE}
Jesse Keating schrieb:
On Friday 05 January 2007 01:55, Thorsten Leemhuis wrote:
> This issue brings up a interesting question: Which board has the power
> to influence and adjust this particular naming scheme in our new
> "merged" world? FESCo or the Fedora Board?
Ultimately I feel it should be the Fedora board.
Nearly the same wording as jeremy two minutes earlier ;-)
Well, I can live with that, but could one of the Board members (I'm sure
at least Rahul, Jeremy and rdieter will read this mail) bring this issue
up in the next Board meeting please?
FESCo is really responsible
for making sure the full repo is there, and the Distribution cabal (hopefully
there will be more than just me) is responsible for taking content from that
repository and creating installable iso sets from it.
/me in that case I'm really wondering why I got two rough ACKs from
rdieter and gdk when I wrote "the things that the Core cabal did and
does (release process, bring the tree in shape for release, plan feature
to work on or the next release, ...) somehow need to be done by FESCo
then" at
https://www.redhat.com/archives/fedora-advisory-board/2006-November/msg00...
/me more and more feels uncomfortable with the situation and now is even
more confused -- its getting more and more unclear who is responsible
for what in this whole game. Hopefully we sort this out soon...
CU
thl
9:14 a.m.
New subject: Fedora Desktop vs. Fedora Desktop {GNOME, KDE}
Thorsten Leemhuis wrote:
Jesse Keating schrieb:
> On Friday 05 January 2007 01:55, Thorsten Leemhuis wrote:
>> This issue brings up a interesting question: Which board has the power
>> to influence and adjust this particular naming scheme in our new
>> "merged" world? FESCo or the Fedora Board?
> Ultimately I feel it should be the Fedora board.
Nearly the same wording as jeremy two minutes earlier ;-)
Well, I can live with that, but could one of the Board members (I'm sure
at least Rahul, Jeremy and rdieter will read this mail) bring this issue
up in the next Board meeting please?
Yes. I will. My opinion as I have already expressed before several times
is that we need to replace the core cabal and FESCo with a technical
steering committee with public irc weekly meetings and only escalate
issues to the board if there is heavy conflict. The more board members
are involved in micro management, the less we will be thinking about
long term changes.
Rahul
9:47 a.m.
New subject: Fedora Desktop vs. Fedora Desktop {GNOME, KDE}
Rahul Sundaram schrieb:
Thorsten Leemhuis wrote:
> Jesse Keating schrieb:
>> On Friday 05 January 2007 01:55, Thorsten Leemhuis wrote:
>>> This issue brings up a interesting question: Which board has the power
>>> to influence and adjust this particular naming scheme in our new
>>> "merged" world? FESCo or the Fedora Board?
>> Ultimately I feel it should be the Fedora board.
> Nearly the same wording as jeremy two minutes earlier ;-)
> Well, I can live with that, but could one of the Board members (I'm sure
> at least Rahul, Jeremy and rdieter will read this mail) bring this issue
> up in the next Board meeting please?
Yes. I will.
Many thanks.
My opinion as I have already expressed before several times
is that we need to replace the core cabal and FESCo with a technical
steering committee with public irc weekly meetings and only escalate
issues to the board if there is heavy conflict. The more board members
are involved in micro management, the less we will be thinking about
long term changes.
Fully agreed.
CU
thl
9:20 a.m.
New subject: Fedora Desktop vs. Fedora Desktop {GNOME, KDE} (was: Re: Fedora 7)
Thorsten Leemhuis wrote:
On 04.01.2007 22:22, Rahul Sundaram wrote:
> It would be consistent to have something like
> Fedora Desktop (GNOME edition) and
> Fedora Desktop (KDE edition)
> It's confusing and discriminatory to call one of the spins as the
> desktop when you have more (which is likely to increase) than one
> desktop oriented spins.
+1 from me to this as a long term Gnome user that's not much interested
in KDE; but I know others are.
This issue brings up a interesting question: Which board has the power
to influence and adjust this particular naming scheme in our new
"merged" world? FESCo or the Fedora Board?
Sounds like the consensus (so far) is the Board. You can now count 2 Board
members (Rahul and me) for being in favor of this. (:
-- Rex
11:09 a.m.
New subject: Fedora Desktop vs. Fedora Desktop {GNOME, KDE}
Rex Dieter schrieb:
Thorsten Leemhuis wrote:
> On 04.01.2007 22:22, Rahul Sundaram wrote:
>> It would be consistent to have something like
>> Fedora Desktop (GNOME edition) and
>> Fedora Desktop (KDE edition)
>> It's confusing and discriminatory to call one of the spins as the
>> desktop when you have more (which is likely to increase) than one
>> desktop oriented spins.
> +1 from me to this as a long term Gnome user that's not much interested
> in KDE; but I know others are.
>
> This issue brings up a interesting question: Which board has the power
> to influence and adjust this particular naming scheme in our new
> "merged" world? FESCo or the Fedora Board?
Sounds like the consensus (so far) is the Board.
BTW, in case it wasn't clear from my other mails: I actually agree that
the Boards is the best place for this sort of decision, as it's more a
political "big picture" thing. Nevertheless I think it's FESCo (or
better: it not yet defined successor) job to work out the details (maybe
in a FESCo-distribution-sub-committee) and present it to the Boards to
get an ACK from it.
You can now count 2 Board
members (Rahul and me) for being in favor of this. (:
thx.
Cu
thl
3:15 p.m.
Vnpenguin wrote:
> - Add the nouveau drivers for nVidia cards
"nouveau" ? :-)
I am not sure whether that was a serious question or a joke I didnt
understand. If its a serious question OP did refer to
http://fedoraproject.org/wiki/Releases/7/Features which has the details.
If it's a joke I would be curious to know what it is.
Rahul
4:21 a.m.
Le vendredi 05 janvier 2007 à 02:45 +0530, Rahul Sundaram a écrit :
Vnpenguin wrote:
>> - Add the nouveau drivers for nVidia cards
>
> "nouveau" ? :-)
I am not sure whether that was a serious question or a joke I didnt
understand. If its a serious question OP did refer to
http://fedoraproject.org/wiki/Releases/7/Features which has the details.
If it's a joke I would be curious to know what it is.
Rahul
I think it can be a pun... As "nouveau" means "new" in French, I
first
understood it as : "Add the new drivers for nVidia cards".
The term nouveau here refers to the name of the new nVidia driver, which
is a new technology. I think finding a word of French origin was seen
odd from Vnpenguin and that he thought it was a mistake in the writing.
"Add the new nouveau drivers for nVidia cards"
... is gorgeous to read :p
--
Thomas Canniot
http://fedoraproject.org/wiki/ThomasCanniot
4:48 a.m.
On Friday 05 January 2007 10:21 am, Thomas Canniot wrote:
I think it can be a pun... As "nouveau" means
"new" in French, I first
understood it as : "Add the new drivers for nVidia cards".
FWIW and due to the strange relations between French and English, nouveau is
also an English word:
http://www.m-w.com/dictionary/nouveau
--
José Abílio
4:52 a.m.
On 1/5/07, José Matos wrote:
FWIW and due to the strange relations between French and English,
nouveau is
also an English word:
http://www.m-w.com/dictionary/nouveau
Some of the core team of nouveau are french, that may be the reason :)
http://nouveau.freedesktop.org/wiki/
This is the homepage of nouveau, a project which aims at producing
Open Source 3D drivers for nVidia cards. "nouveau" [nuvo] is the
french word for "new"
http://icps.u-strasbg.fr/~marchesin/perso/
Chitlesh
--
http://clunixchit.blogspot.com
5:57 a.m.
On 1/5/07, Thomas Canniot <thomas.canniot(a)laposte.net> wrote:
>
I think it can be a pun... As "nouveau" means "new" in French, I
first
understood it as : "Add the new drivers for nVidia cards".
The term nouveau here refers to the name of the new nVidia driver, which
is a new technology. I think finding a word of French origin was seen
odd from Vnpenguin and that he thought it was a mistake in the writing.
"Add the new nouveau drivers for nVidia cards"
... is gorgeous to read :p
Thank you Thomas, I see now it's the _name_ of new driver :) Cool !
Cheers,
--
http://vnoss.org
3:13 p.m.
New subject: Fedora 7 (TeTeX)
Bill Nottingham wrote:
And, what would a release be without features. We've identified
28 features that we'd like to include in the release, available
at http://fedoraproject.org/wiki/Releases/7/:
Don't forget that TeTeX needs to be replaced (see #215497).
jpo
--
José Pedro Oliveira
* mailto: jpo(a)di.uminho.pt * http://gsd.di.uminho.pt/jpo *
* gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B *
3:12 p.m.
New subject: Fedora 7 (TeTeX)
Jose Pedro Oliveira wrote:
Bill Nottingham wrote:
> And, what would a release be without features. We've identified
> 28 features that we'd like to include in the release, available
> at http://fedoraproject.org/wiki/Releases/7/:
Don't forget that TeTeX needs to be replaced (see #215497).
... and we need to decide on whether we need to use cdrkit or stay
with the current version of cdrecord in Fedora. Let me know if a RFE is
required.
Rahul
3:27 p.m.
New subject: Fedora 7 (TeTeX)
On Thursday 04 January 2007 16:12, Rahul Sundaram wrote:
... and we need to decide on whether we need to use cdrkit or stay
with the current version of cdrecord in Fedora. Let me know if a RFE is
required.
Or libburn, which is in Extras.
--
Jesse Keating
Release Engineer: Fedora
4:15 p.m.
New subject: Fedora 7 (TeTeX)
On Thu, 2007-01-04 at 16:27 -0500, Jesse Keating wrote:
On Thursday 04 January 2007 16:12, Rahul Sundaram wrote:
> ... and we need to decide on whether we need to use cdrkit or stay
> with the current version of cdrecord in Fedora. Let me know if a RFE is
> required.
Or libburn, which is in Extras.
libburn is only a library, and a slowly progressing one (latest release
was in Feb 2004). There was a project takeover at some point (some
unknown guy suddenly announced a project revival and a new web site at
libburn.pykix.org, not minding that the project was still active...)
which instead resulted in a fork called libburnia which integrates a
cdrecord-like frontend. I'm not sure how usable it is, but it's
certainly far from being as mature as cdrtools (or cdrkit.)
4:17 p.m.
New subject: Fedora 7 (TeTeX)
On Thursday 04 January 2007 17:15, Mark Rosenstand wrote:
There was a project takeover at some point (some
unknown guy suddenly announced a project revival and a new web site at
libburn.pykix.org, not minding that the project was still active...)
which instead resulted in a fork called libburnia which integrates a
cdrecord-like frontend. I'm not sure how usable it is, but it's
certainly far from being as mature as cdrtools (or cdrkit.)
Yes, this is what is in Extras right now, I packaged it up at the request of
these folks. http://libburnia.pykix.org/ is the "new" URL now.
They've been progressing quite well from what I can tell. Sure, probably not
ready for Fedora by F7, but something to investigate by more knowledgeable
people.
--
Jesse Keating
Release Engineer: Fedora
4:54 p.m.
New subject: Fedora 7 (TeTeX)
On Thu, 2007-01-04 at 17:17 -0500, Jesse Keating wrote:
On Thursday 04 January 2007 17:15, Mark Rosenstand wrote:
> There was a project takeover at some point (some
> unknown guy suddenly announced a project revival and a new web site at
> libburn.pykix.org, not minding that the project was still active...)
> which instead resulted in a fork called libburnia which integrates a
> cdrecord-like frontend. I'm not sure how usable it is, but it's
> certainly far from being as mature as cdrtools (or cdrkit.)
Yes, this is what is in Extras right now, I packaged it up at the request of
these folks. http://libburnia.pykix.org/ is the "new" URL now.
Heh. I've been the maintainer of the real libburn
(http://icculus.org/burn/) for another distro for a long time, and the
forker claimed that my package was broken since it referenced the "old"
URL of the project.
That was after calling for project revival[0] and after the libburn
project leader dismissed it[1]. It's cool that they now switched to
another name, perhaps the Fedora package could do the same.
They've been progressing quite well from what I can tell. Sure,
probably not
ready for Fedora by F7, but something to investigate by more knowledgeable
people.
Agreed. The idea of a generic CD-writing library seems like a worthy
long-term goal, but for FL7, cdrkit, being a free drop-in replacement of
S(ch)illy's programs, could probably do the trick.
[0] http://lists.freedesktop.org/archives/libburn/2006-July/000434.html
[1]
http://lists.freedesktop.org/archives/libburn/2006-August/000444.html
8:54 p.m.
New subject: Fedora 7 (TeTeX)
Rahul Sundaram (sundaram(a)fedoraproject.org) said:
Jose Pedro Oliveira wrote:
>Bill Nottingham wrote:
>>And, what would a release be without features. We've identified
>>28 features that we'd like to include in the release, available
>>at http://fedoraproject.org/wiki/Releases/7/:
>
>Don't forget that TeTeX needs to be replaced (see #215497).
... and we need to decide on whether we need to use cdrkit or stay
with the current version of cdrecord in Fedora. Let me know if a RFE is
required.
What needs to happen is that someone needs to Step Up and claim
repsonsibility for these things with a plan for fixing them (on
fedora-devel-list, and then on the wiki). I'm perfectly willing
to add features to the list, but we need people who are going
to be accountable for them.
Bill
6:47 a.m.
New subject: Fedora 7 (TeTeX)
On Thu, 2007-01-04 at 21:54 -0500, Bill Nottingham wrote:
Rahul Sundaram (sundaram(a)fedoraproject.org) said:
> Jose Pedro Oliveira wrote:
> >Bill Nottingham wrote:
> >>And, what would a release be without features. We've identified
> >>28 features that we'd like to include in the release, available
> >>at http://fedoraproject.org/wiki/Releases/7/:
> >
> >Don't forget that TeTeX needs to be replaced (see #215497).
>
> ... and we need to decide on whether we need to use cdrkit or stay
> with the current version of cdrecord in Fedora. Let me know if a RFE is
> required.
What needs to happen is that someone needs to Step Up and claim
repsonsibility for these things with a plan for fixing them (on
fedora-devel-list, and then on the wiki). I'm perfectly willing
to add features to the list, but we need people who are going
to be accountable for them.
Please do. Feel free to add the Releases/FeatureTexLive to the list of
features for F7 assigning me there as an owner, with "Needs done by:
Test2".
Thanks,
Jindrich
1:07 p.m.
New subject: Fedora 7 (TeTeX)
Jindrich Novy (jnovy(a)redhat.com) said:
> What needs to happen is that someone needs to Step Up and claim
> repsonsibility for these things with a plan for fixing them (on
> fedora-devel-list, and then on the wiki). I'm perfectly willing
> to add features to the list, but we need people who are going
> to be accountable for them.
Please do. Feel free to add the Releases/FeatureTexLive to the list of
features for F7 assigning me there as an owner, with "Needs done by:
Test2".
*cough* It's a wiki. :)
Bill
9:46 a.m.
New subject: Fedora 7 (TeTeX)
On Fri, 2007-01-05 at 14:07 -0500, Bill Nottingham wrote:
Jindrich Novy (jnovy(a)redhat.com) said:
> > What needs to happen is that someone needs to Step Up and claim
> > repsonsibility for these things with a plan for fixing them (on
> > fedora-devel-list, and then on the wiki). I'm perfectly willing
> > to add features to the list, but we need people who are going
> > to be accountable for them.
>
> Please do. Feel free to add the Releases/FeatureTexLive to the list of
> features for F7 assigning me there as an owner, with "Needs done by:
> Test2".
*cough* It's a wiki. :)
heh, done ;-)
3:29 p.m.
New subject: Fedora 7 (TeTeX)
* Jose Pedro Oliveira (2007-01-04 21:13 +0000) said:
^^^^^^^^^^^^^^^^^^^
Bill Nottingham wrote:
> And, what would a release be without features. We've identified
> 28 features that we'd like to include in the release, available
> at http://fedoraproject.org/wiki/Releases/7/:
Don't forget that TeTeX needs to be replaced (see #215497).
It will be a pity if it is not fixed for Fedora 7 ;)
--
Leo <sdl.web AT gmail.com> (GPG Key: 9283AA3F)
6:34 a.m.
New subject: Fedora 7 (TeTeX)
On Thu, 2007-01-04 at 21:13 +0000, Jose Pedro Oliveira wrote:
Bill Nottingham wrote:
> And, what would a release be without features. We've identified
> 28 features that we'd like to include in the release, available
> at http://fedoraproject.org/wiki/Releases/7/:
Don't forget that TeTeX needs to be replaced (see #215497).
There was a private discussion among teTeX maintainers from mainline
distributions related to teTeX replacement involving TeXLive upstream
which resulted in a series of TeXLive styles which should function as a
teTeX replacement, you can find out more at:
http://tug.org/svn/texlive/trunk/Master/texmf/tpm/
(look for tetex)
I'm still in close contact with TeXLive upstream and the current work is
focused on how to package it in the best way.
Jindrich
4:45 p.m.
New subject: Fedora 7 (TeTeX)
On 1/5/07, Jindrich Novy <jnovy(a)redhat.com> wrote:
I'm still in close contact with TeXLive upstream and the current
work is
focused on how to package it in the best way.
Are you looking for community co-maintainers to help you out with this
after the core+extras merge? The tex stack is pretty important for
scientific publications, there are probably several competent
contributors out here on the other side of the fenceline who are
concerned enough to invest time in keeping the functionality working.
-jef
10 a.m.
New subject: Fedora 7 (TeTeX)
On Fri, 2007-01-05 at 13:45 -0900, Jeff Spaleta wrote:
On 1/5/07, Jindrich Novy <jnovy(a)redhat.com> wrote:
> I'm still in close contact with TeXLive upstream and the current work is
> focused on how to package it in the best way.
Are you looking for community co-maintainers to help you out with this
after the core+extras merge? The tex stack is pretty important for
scientific publications, there are probably several competent
contributors out here on the other side of the fenceline who are
concerned enough to invest time in keeping the functionality working.
Definitely, the community involvement here is appreciated as I cannot
cover all the TeX features because of their vast range, so I'm really
open to any suggestions/testings/proposals from you guys.
Feel free to subscribe to freshly created feature page if you want to
help or to stay informed:
http://fedoraproject.org/wiki/Releases/FeatureTexLive
Jindrich
3:37 p.m.
Bill Nottingham wrote,
If you've got new features you'd like to add, and you are
willing
to do the work, or have the ability to get others to do the work
for you, we can add them too. Note that Test2 is the feature freeze.
NetworkManager 0.7? Allegedly due RSN, with a set of new and updated
features which looks like it'll finally make NM usable (by me, at
least),
http://live.gnome.org/NetworkManagerToDo
Cheers,
Miles
4:47 p.m.
On Thursday 04 January 2007 13:50, Bill Nottingham wrote:
And, what would a release be without features. We've identified
28 features that we'd like to include in the release, available
at http://fedoraproject.org/wiki/Releases/7/Features:
Whats needed to add Fedora Directory Server to the List? that would be a
great additional tool to have in F7
--
,-._|\ Dennis Gilmore, RHCE
/Aussie\ Proud Australian
\_.--._/ | Aurora | Fedora |
v
4:49 p.m.
On Thursday 04 January 2007 17:47, Dennis Gilmore wrote:
Whats needed to add Fedora Directory Server to the List? that would
be a
great additional tool to have in F7
Somebody to be on the hook to make sure it gets done in time for the
deadlines.
From Releases/7 page:
I've got this great feature idea!
OK. Are you going to work on it? Can you cajole/force someone else to be
Accountable? Then we'll add it!
--
Jesse Keating
Release Engineer: Fedora
10:42 a.m.
On Thursday 04 January 2007 16:49, Jesse Keating wrote:
On Thursday 04 January 2007 17:47, Dennis Gilmore wrote:
> Whats needed to add Fedora Directory Server to the List? that would be a
> great additional tool to have in F7
Somebody to be on the hook to make sure it gets done in time for the
deadlines.
From Releases/7 page:
I've got this great feature idea!
OK. Are you going to work on it? Can you cajole/force someone else to be
Accountable? Then we'll add it!
Jarod Wilson and I will be accountable to
ensure that Fedora Directory Server
is available in F7
--
,-._|\ Dennis Gilmore, RHCE
/Aussie\ Proud Australian
\_.--._/ | Aurora | Fedora |
v
1:48 a.m.
Jesse Keating wrote:
On Thursday 04 January 2007 17:47, Dennis Gilmore wrote:
> Whats needed to add Fedora Directory Server to the List? that would be a
> great additional tool to have in F7
Somebody to be on the hook to make sure it gets done in time for the
deadlines.
From Releases/7 page:
I've got this great feature idea!
OK. Are you going to work on it? Can you cajole/force someone else to be
Accountable? Then we'll add it!
http://wtogami.livejournal.com/12517.html
This todo list still applies to get FDS into Fedora proper. Toshio
already did one part.
Warren Togami
wtogami(a)redhat.com
8:53 a.m.
On Saturday 06 January 2007 1:48 am, Warren Togami wrote:
Jesse Keating wrote:
> OK. Are you going to work on it? Can you cajole/force someone
else to be
> Accountable? Then we'll add it!
Ive added FDS to the list ;)
http://wtogami.livejournal.com/12517.html
This todo list still applies to get FDS into Fedora proper. Toshio
already did one part.
When talking to the developers of FDS yesterday We may hit a
snag. the java
bits. still need suns java. Red Hat's Java team have made them build with
gcj but they don't run 100% yet with it. So we will have everything for
the ldap server in but we may not be able to get the admin tools in.
So if we have any Java developers looking for something to do. We could use
help porting the admin console to gcj.
--
Dennis Gilmore, RHCE
Proud Australian
9:47 a.m.
On Sat, 2007-06-01 at 08:53 -0600, Dennis Gilmore wrote:
When talking to the developers of FDS yesterday We may hit a snag.
the java
bits. still need suns java. Red Hat's Java team have made them build with
gcj but they don't run 100% yet with it.
I'm pretty sure Tom Fitzsimmons told me that things do indeed work.
Tom?
Andrew
5:21 p.m.
On Saturday 06 January 2007 9:47 am, Andrew Overholt wrote:
On Sat, 2007-06-01 at 08:53 -0600, Dennis Gilmore wrote:
> When talking to the developers of FDS yesterday We may hit a snag. the
> java bits. still need suns java. Red Hat's Java team have made them
> build with gcj but they don't run 100% yet with it.
I'm pretty sure Tom Fitzsimmons told me that things do indeed work.
Tom?
Andrew,
I really hope that they do.
--
Dennis Gilmore, RHCE
Proud Australian
9:22 a.m.
Andrew Overholt wrote:
On Sat, 2007-06-01 at 08:53 -0600, Dennis Gilmore wrote:
> When talking to the developers of FDS yesterday We may hit a snag. the java
> bits. still need suns java. Red Hat's Java team have made them build with
> gcj but they don't run 100% yet with it.
I'm pretty sure Tom Fitzsimmons told me that things do indeed work.
Tom?
I'm not sure what is meant by "100%" here. There is an issue with the
console
script that causes gij to OOM on startup:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183962
Once that problem is fixed (early this year, according to the bug report), the
tools will run well -- I did some smoke testing just before FC-6 was released.
If there are other issues running FDS on GCJ, please file them in Red Hat
Bugzilla against the java-1.4.2-gcj-compat component.
Tom
4:56 p.m.
On Thu, Jan 04, 2007 at 02:50:32PM -0500, Bill Nottingham wrote:
And, what would a release be without features. We've identified
28 features that we'd like to include in the release, available
at http://fedoraproject.org/wiki/Releases/7/Features:
It seemed to me that java 1.5 was also planned for fc7. Is it right?
Also, maybe it could be worth considering allowing to use fcron
instead of anacron+cron.
--
Pat
5:10 p.m.
On Thursday 04 January 2007 10:56 pm, Patrice Dumas wrote:
It seemed to me that java 1.5 was also planned for fc7. Is it right?
I remember the opposite. :-)
March is a too tight schedule for F7, and java is heavy-weight by any
account. ;-) (I am referring the package relations not run-time...)
--
Pat
--
José Abílio
5:24 p.m.
On Thu, 2007-01-04 at 23:10 +0000, José Matos wrote:
On Thursday 04 January 2007 10:56 pm, Patrice Dumas wrote:
> It seemed to me that java 1.5 was also planned for fc7. Is it right?
I remember the opposite. :-)
March is a too tight schedule for F7, and java is heavy-weight by any
account. ;-) (I am referring the package relations not run-time...)
FYI: Jpackage [1] has been packaging SUN's java (distributed as
a .nosrc.rpm that reuires SUN's .bin file to build the .rpm) for a long
time. Seems to play nice with alternatives, naming, location of files
etc. Perhaps worth a look for Fedora 7?
[1]
http://mirrors.dotsrc.org/jpackage/1.6/generic/non-free/repodata/repoview...
--
Saikat
3:31 p.m.
>>>> ">" == Saikat Guha
<saikat(a)cs.cornell.edu> writes:
> FYI: Jpackage [1] has been packaging SUN's java (distributed
as
> a .nosrc.rpm that reuires SUN's .bin file to build the .rpm) for a long
> time. Seems to play nice with alternatives, naming, location of files
> etc. Perhaps worth a look for Fedora 7?
It isn't free software.
We'll be taking a close look at OpenJDK once all the bits have been
released. I'm pretty sure this will miss Fedora 7 and have to wait
for Fedora 8.
Tom
8:57 p.m.
Patrice Dumas (pertusus(a)free.fr) said:
Also, maybe it could be worth considering allowing to use fcron
instead of anacron+cron.
IIRC, fcron natively supports SELinux. Maybe get the Extras fcron
maintainer (aportal(a)univ-montp2.fr) and the Core vixie-cron/anacron
maintainer (mmaslano(a)redhat.com) together and see what would need
to be done to migrate and see what the benefits would be?
Bill
11:21 a.m.
* Patrice Dumas <pertusus(a)free.fr> [2007-01-04 18:01]:
On Thu, Jan 04, 2007 at 02:50:32PM -0500, Bill Nottingham wrote:
>
> And, what would a release be without features. We've identified
> 28 features that we'd like to include in the release, available
> at http://fedoraproject.org/wiki/Releases/7/Features:
It seemed to me that java 1.5 was also planned for fc7. Is it right?
On a somewhat related note, we put the Eclipse plans for F7 here:
http://fedoraproject.org/wiki/F7EclipsePlans
I've added the category to make it appear on the above page.
Andrew
12:04 p.m.
On Friday 05 January 2007 12:21, Andrew Overholt wrote:
On a somewhat related note, we put the Eclipse plans for F7 here:
http://fedoraproject.org/wiki/F7EclipsePlans
I've added the category to make it appear on the above page.
Can the n-v-r be fixed to adhere to the guidelines sooner rather than later?
(:
--
Jesse Keating
Release Engineer: Fedora
9:48 a.m.
On Fri, 2007-05-01 at 13:04 -0500, Jesse Keating wrote:
On Friday 05 January 2007 12:21, Andrew Overholt wrote:
> On a somewhat related note, we put the Eclipse plans for F7 here:
>
> http://fedoraproject.org/wiki/F7EclipsePlans
>
> I've added the category to make it appear on the above page.
Can the n-v-r be fixed to adhere to the guidelines sooner rather than later?
(:
It already is and has been for a while. It's JPackage-inherited
packages that need fixing.
Andrew
10:04 a.m.
On Saturday 06 January 2007 10:48, Andrew Overholt wrote:
> Can the n-v-r be fixed to adhere to the guidelines sooner rather
than
> later? (:
It already is and has been for a while. It's JPackage-inherited
packages that need fixing.
I must have been looking at an old version, sorry about that.
--
Jesse Keating
Release Engineer: Fedora
12:06 p.m.
Hi,
Andrew Overholt wrote:
On a somewhat related note, we put the Eclipse plans for F7 here:
http://fedoraproject.org/wiki/F7EclipsePlans
I've added the category to make it appear on the above page.
FYI, I have renamed this page to
http://fedoraproject.org/wiki/Releases/FeatureEclipsePlugins to match
the template and other specifications.
Rahul
1:50 a.m.
Patrice Dumas wrote:
On Thu, Jan 04, 2007 at 02:50:32PM -0500, Bill Nottingham wrote:
> And, what would a release be without features. We've identified
> 28 features that we'd like to include in the release, available
> at http://fedoraproject.org/wiki/Releases/7/Features:
It seemed to me that java 1.5 was also planned for fc7. Is it right?
All parts of Sun Java will not be released until a time where it is far
too late to be usable in Fedora 7. Sun Java might require additional
work to be properly integrated, which is perhaps likely in Fedora 8.
Warren Togami
wtogami(a)redhat.com
9:47 a.m.
On Sat, 2007-06-01 at 02:50 -0500, Warren Togami wrote:
Patrice Dumas wrote:
> On Thu, Jan 04, 2007 at 02:50:32PM -0500, Bill Nottingham wrote:
>> And, what would a release be without features. We've identified
>> 28 features that we'd like to include in the release, available
>> at http://fedoraproject.org/wiki/Releases/7/Features:
>
> It seemed to me that java 1.5 was also planned for fc7. Is it right?
All parts of Sun Java will not be released until a time where it is far
too late to be usable in Fedora 7. Sun Java might require additional
work to be properly integrated, which is perhaps likely in Fedora 8.
I think he means 1.5 language support in gcj et al.
Andrew
5:10 p.m.
Bill Nottingham írta:
It's time to bite the bullet.
...
- Add wireless firmware for all the chipsets we can
Speaking of hardware that needs firmware to work at all,
how about adding the foo2zjs driver and the firmware for
the cheap HP LaserJet series like 1000/1015/1018/1020?
Best regards,
Zoltán Böszorményi
7:44 p.m.
On Fri, 2007-01-05 at 00:10 +0100, Zoltan Boszormenyi wrote:
Bill Nottingham írta:
> It's time to bite the bullet.
> ...
> - Add wireless firmware for all the chipsets we can
>
Speaking of hardware that needs firmware to work at all,
how about adding the foo2zjs driver and the firmware for
the cheap HP LaserJet series like 1000/1015/1018/1020?
Is it freely redistributable? URL?
josh
11:27 p.m.
Josh Boyer írta:
On Fri, 2007-01-05 at 00:10 +0100, Zoltan Boszormenyi wrote:
> Bill Nottingham írta:
>
>> It's time to bite the bullet.
>> ...
>> - Add wireless firmware for all the chipsets we can
>>
>>
> Speaking of hardware that needs firmware to work at all,
> how about adding the foo2zjs driver and the firmware for
> the cheap HP LaserJet series like 1000/1015/1018/1020?
>
Is it freely redistributable? URL?
josh
http://foo2zjs.rkkda.com/
http://foo2zjs.rkkda.com/foo2zjs.tar.gz
The COPYING file says:
-----------------8<----------------------------
Copyright HP...
sihp1000.img (2001)
sihp1005.img (2002)
sihp1018.img (2005)
sihp1020.img (2005)
hpclj2600n-0.icm (2003) 3700
Copyright Konica Minolta...
CPWL12W.icm (1998)
CPWL24W.icm (1998)
CPWL6W.icm (1998)
DL2200RGB.icm (1999)
DL2312.icm (2001)
DL2324.icm (2001)
km2430_0.icm (2003)
km2430_1.icm (2003)
km2430_2.icm (2003)
Copyright Rick Richardson. All Rights Reserved.
hpclj2600n-1.icm (2006)
Everything else is...
-----------------------------------------------------------------------------
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
... (regular GPLv2 COPYING continues)
-----------------8<----------------------------
So, the same treatment would apply to the HP
firmwares and HP/Minolta ICM files as to
the wireless firmwares: find lawyers and
have the vendors to make them redistributable.
Anyway, these files are on their respective driver CDs,
with the slight exception of the sihp* files above.
In my case, on the driver disk for the HP 1020,
these files can be found:
hp1020.img
hp1022.img
hp1022n.img
These have to be run through the "arm2hpdl"
program which foo2zjs provides and which
prepends a small PJL header:
And I know that the driver is in Livna,
but it provides neither the HP firmware files
nor the needed hotplug/udev scripts to
upload them when the system encounters
such a printer on boot or when the printer
is turned on. foo2zjs has them in the .tar.gz.
Well, for the case of HP 1020, it carries an older
firmware release (20040929) and the newer
one (20050318) that's on the driver disk
makes the printer speedier.
And in case you wonder, the whole ZJStream
protocol is open so a GPL driver could have
been written. Link can be found on the
foo2zjs homepage.
Best regards,
Zoltán Böszörményi
11:34 p.m.
On 1/5/07, Zoltan Boszormenyi <zboszor(a)freemail.hu> wrote:
Josh Boyer írta:
> On Fri, 2007-01-05 at 00:10 +0100, Zoltan Boszormenyi wrote:
>
>> Bill Nottingham írta:
>>
>>> It's time to bite the bullet.
>>> ...
>>> - Add wireless firmware for all the chipsets we can
>>>
>>>
>> Speaking of hardware that needs firmware to work at all,
>> how about adding the foo2zjs driver and the firmware for
>> the cheap HP LaserJet series like 1000/1015/1018/1020?
>>
>
> Is it freely redistributable? URL?
>
> josh
>
http://foo2zjs.rkkda.com/
http://foo2zjs.rkkda.com/foo2zjs.tar.gz
The COPYING file says:
...
And in case you wonder, the whole ZJStream
protocol is open so a GPL driver could have
been written. Link can be found on the
foo2zjs homepage.
It depends on jbigkit, which is allegedly patent encumbered.
Deji
12:32 a.m.
Deji Akingunola írta:
On 1/5/07, Zoltan Boszormenyi <zboszor(a)freemail.hu> wrote:
> Josh Boyer írta:
> > On Fri, 2007-01-05 at 00:10 +0100, Zoltan Boszormenyi wrote:
> >
> >> Bill Nottingham írta:
> >>
> >>> It's time to bite the bullet.
> >>> ...
> >>> - Add wireless firmware for all the chipsets we can
> >>>
> >>>
> >> Speaking of hardware that needs firmware to work at all,
> >> how about adding the foo2zjs driver and the firmware for
> >> the cheap HP LaserJet series like 1000/1015/1018/1020?
> >>
> >
> > Is it freely redistributable? URL?
> >
> > josh
> >
>
> http://foo2zjs.rkkda.com/
> http://foo2zjs.rkkda.com/foo2zjs.tar.gz
> The COPYING file says:
...
>
> And in case you wonder, the whole ZJStream
> protocol is open so a GPL driver could have
> been written. Link can be found on the
> foo2zjs homepage.
>
It depends on jbigkit, which is allegedly patent encumbered.
Deji
Of which half of them is expired already, some of
them are pending (they aren't valid yet) and for the rest
(which _might apply_, not known apply) HP and
Konica/Minolta must have payed the bill already and
the driver is for their printers.
Until proper support for all HP printers,
hplip is literally only a lip service. :-(
Best regards,
Zoltán Böszörményi
5:25 p.m.
On 1/4/07, Bill Nottingham <notting(a)redhat.com> wrote:
And, what would a release be without features. We've identified
28 features that we'd like to include in the release, available
at http://fedoraproject.org/wiki/Releases/7/Features:
<snip>
Nothing about anaconda?
In particular, the partitioning phase is (more or less) the same since
FC1 and not having something in place to resize an existing (most
likely ntfs) partition is a big drawback when compared to other
distros.
Just for the records, I used ntfsresize successfully with the last
laptop I installed FC6 onto.
8:59 p.m.
On Fri, 2007-01-05 at 00:25 +0100, Gianluca Sforna wrote:
On 1/4/07, Bill Nottingham <notting(a)redhat.com> wrote:
> And, what would a release be without features. We've identified
> 28 features that we'd like to include in the release, available
> at http://fedoraproject.org/wiki/Releases/7/Features:
<snip>
Nothing about anaconda?
In particular, the partitioning phase is (more or less) the same since
FC1 and not having something in place to resize an existing (most
likely ntfs) partition is a big drawback when compared to other
distros.
Handling resize nicely is going to require a bit of rethinking and
reworking of the entire partitioning interface (not to mention the
backend code). Given resource constraints, there's just not really a
good way to get to something that's feature complete without losing big
pieces in time for the feature freeze at test2.
It's definitely something on the bigger picture roadmap for anaconda,
but this just isn't going to be the release where it's reasonable for it
to happen.
Jeremy
1:58 a.m.
On 1/5/07, Jeremy Katz <katzj(a)redhat.com> wrote:
Handling resize nicely is going to require a bit of rethinking and
reworking of the entire partitioning interface
What if someone (ie. me) provide
some mockups of a potential interface
for doing that?
Is there a dedicated development list for anaconda to interact with?
(not to mention the
backend code).
Which admittedly, I did never look at...
Given resource constraints, there's just not really a
good way to get to something that's feature complete without losing big
pieces in time for the feature freeze at test2.
I see. However, I think this is important enough so it deserves to be
started, so at least it could be ready for proper testing in time from
F8
It's definitely something on the bigger picture roadmap for anaconda,
but this just isn't going to be the release where it's reasonable for it
to happen.
ACK
5:32 a.m.
On Fri, 2007-01-05 at 08:58 +0100, Gianluca Sforna wrote:
On 1/5/07, Jeremy Katz <katzj(a)redhat.com> wrote:
> Handling resize nicely is going to require a bit of rethinking and
> reworking of the entire partitioning interface
What if someone (ie. me) provide some mockups of a potential interface
for doing that?
Is there a dedicated development list for anaconda to interact with?
Yes:
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Keith.
8:45 a.m.
On Fri, 2007-01-05 at 08:58 +0100, Gianluca Sforna wrote:
On 1/5/07, Jeremy Katz <katzj(a)redhat.com> wrote:
> Handling resize nicely is going to require a bit of rethinking and
> reworking of the entire partitioning interface
What if someone (ie. me) provide some mockups of a potential interface
for doing that?
Is there a dedicated development list for anaconda to interact with?
Yep, there's anaconda-devel-list and I'm all for starting some
discussion around it now, getting some mockups going, etc.
Thanks!
Jeremy
5:49 a.m.
On 05.01.2007 03:59, Jeremy Katz wrote:
On Fri, 2007-01-05 at 00:25 +0100, Gianluca Sforna wrote:
[...]
> <snip>
> Nothing about anaconda?
> In particular, the partitioning phase is (more or less) the same since
> FC1 and not having something in place to resize an existing (most
> likely ntfs) partition is a big drawback when compared to other
> distros.
Handling resize nicely is going to require a bit of rethinking and
reworking of the entire partitioning interface (not to mention the
backend code). Given resource constraints, there's just not really a
good way to get to something that's feature complete without losing big
pieces in time for the feature freeze at test2.
It's definitely something on the bigger picture roadmap for anaconda,
but this just isn't going to be the release where it's reasonable for it
to happen.
Just FYI: Vista will afaik be able to resize NTFS filesystems on it own.
Thus you should be able to free some space on a hard-disk with Vista and
install Linux to it. So I'm wondering if we need the resize-feature in
the future as much as we do today.
Sure, there are a lot of XP machines out in the wild, but most of the
*new* machines (where the ability to resize NTFS is mostly needed) will
ship with Vista by F8.
CU
thl
6:07 a.m.
On 1/5/07, Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
On 05.01.2007 03:59, Jeremy Katz wrote:
> On Fri, 2007-01-05 at 00:25 +0100, Gianluca Sforna wrote:
> [...]
>> <snip>
>> Nothing about anaconda?
>> In particular, the partitioning phase is (more or less) the same since
>> FC1 and not having something in place to resize an existing (most
>> likely ntfs) partition is a big drawback when compared to other
>> distros.
> Handling resize nicely is going to require a bit of rethinking and
> reworking of the entire partitioning interface (not to mention the
> backend code). Given resource constraints, there's just not really a
> good way to get to something that's feature complete without losing big
> pieces in time for the feature freeze at test2.
>
> It's definitely something on the bigger picture roadmap for anaconda,
> but this just isn't going to be the release where it's reasonable for it
> to happen.
Just FYI: Vista will afaik be able to resize NTFS filesystems on it own.
I was not aware. thanks.
Thus you should be able to free some space on a hard-disk with Vista
and
install Linux to it. So I'm wondering if we need the resize-feature in
the future as much as we do today.
Given that, I guess there will be less pressure to add that feature.
However, I think it's global value is still quite the same, because it
gives users the ability to install Fedora on a brand new PC without
intermediate steps in an external environment: just insert the install
DVD and boot.
6:12 p.m.
tor, 04 01 2007 kl. 14:50 -0500, skrev Bill Nottingham:
And, what would a release be without features. We've identified
28 features that we'd like to include in the release, available
at http://fedoraproject.org/wiki/Releases/7/Features:
There was for a long time interest in replacing the much hated esd with
another solution. Pulseaudio was suggested and is already in Extras. To
be a drop in replacement I think all we need is a package for the
gstreamer sink.
Would this be feasble for Fedora 7?
Here's to making Fedora 7 the best release yet!
No objections
- David Nielsen
--
"Ridicule is the only weapon that can be used against unintelligible
propositions. Ideas must be distinct before reason can act upon them.”
-Thomas Jefferson
6:25 p.m.
On Fri, 2007-01-05 at 01:12 +0100, David Nielsen wrote:
tor, 04 01 2007 kl. 14:50 -0500, skrev Bill Nottingham:
> And, what would a release be without features. We've identified
> 28 features that we'd like to include in the release, available
> at http://fedoraproject.org/wiki/Releases/7/Features:
There was for a long time interest in replacing the much hated esd with
another solution. Pulseaudio was suggested and is already in Extras. To
be a drop in replacement I think all we need is a package for the
gstreamer sink.
Would this be feasble for Fedora 7?
I had some issues with pulseaudio playing with other apps that I
regrettably didn't file (reinstalled with FC6 soon after and forgot
about it.) I think esd releases the sound device after a period of
inactivity which allows other applications to use it whereas pulseaudio
doesn't. Not sure though as I tried running padsp <PROGRAM> and some
other things with no change.
Regardless, we should evaluate how well pulseaudio plays with other
programs early in the cycle so we have a chance to find and fix any
little compatibility issues that crop up.
-Toshio
6:34 p.m.
On Thu, 2007-01-04 at 16:25 -0800, Toshio Kuratomi wrote:
Regardless, we should evaluate how well pulseaudio plays with other
programs early in the cycle so we have a chance to find and fix any
little compatibility issues that crop up.
This is on Monty's TODO list for F7. I don't know if he put the
writeup of his "fix audio" plans in the wiki yet (he has recently been
distracted by more important things), but I'm sure he'll be happy
about any help with testing and evaluation.
Matthias
6:51 p.m.
tor, 04 01 2007 kl. 19:34 -0500, skrev Matthias Clasen:
On Thu, 2007-01-04 at 16:25 -0800, Toshio Kuratomi wrote:
> Regardless, we should evaluate how well pulseaudio plays with other
> programs early in the cycle so we have a chance to find and fix any
> little compatibility issues that crop up.
This is on Monty's TODO list for F7. I don't know if he put the
writeup of his "fix audio" plans in the wiki yet (he has recently been
distracted by more important things), but I'm sure he'll be happy
about any help with testing and evaluation.
Monty, Please shine your rays of enlightenment on us, your meager
subjects. Also I'll happily test anything so long as it's reasonably
easily installable.
- David
--
"Ridicule is the only weapon that can be used against unintelligible
propositions. Ideas must be distinct before reason can act upon them.”
-Thomas Jefferson
7:36 p.m.
Bill Nottingham wrote:
30 January 2007 | F7 Test1 Release
I'm torn between really wanting to test the Test Releases on my
hardware, and the need to have an at least relatively stable OS to do my
work.
So if y'all could add a Live CD to the Fedora Test releases, that would
be awesome. It won't test the installer or the disk storage, but it will
be able to test pretty much everything else.
--
Florin Andrei
http://florin.myip.org/
9:08 p.m.
On Thu, 2007-01-04 at 17:36 -0800, Florin Andrei wrote:
So if y'all could add a Live CD to the Fedora Test releases, that
would
be awesome. It won't test the installer or the disk storage, but it will
be able to test pretty much everything else.
That's the plan. http://fedoraproject.org/wiki/FedoraLiveCD
Jeremy
7:48 p.m.
Bill Nottingham wrote:
20 February 2007 | F7 FEATURE Freeze
Maybe I'm partial to this topic, but I really like the idea of an
inotify daemon:
http://incron.aiken.cz/
https://www.redhat.com/archives/fedora-extras-list/2007-January/thread.ht...
Let's say - if I whip up an RPM tonight and submit it to Extras, what
would be the chances to get a sponsor and push the package to Extras in
time for the F7 feature freeze?
Pretty please? :-)
--
Florin Andrei
http://florin.myip.org/
7:51 p.m.
On Thu, 2007-01-04 at 17:48 -0800, Florin Andrei wrote:
Bill Nottingham wrote:
> 20 February 2007 | F7 FEATURE Freeze
Maybe I'm partial to this topic, but I really like the idea of an
inotify daemon:
http://incron.aiken.cz/
https://www.redhat.com/archives/fedora-extras-list/2007-January/thread.ht...
Let's say - if I whip up an RPM tonight and submit it to Extras, what
would be the chances to get a sponsor and push the package to Extras in
time for the F7 feature freeze?
That needs to be worked out yet. Extras is a rolling release at the
moment. In the Brave New World, we'll need to seriously look at that
and figure out what to do.
josh
8:02 p.m.
On 1/4/07, Florin Andrei <florin(a)andrei.myip.org> wrote:
Let's say - if I whip up an RPM tonight and submit it to Extras,
what
would be the chances to get a sponsor
If you do not want to wait for a sponsor I will take lead
maintainership of the package and work with you through the review
process. You can be co-maintainer and get and file bugreports and can
send any potential cvs commits to me for me to process via bugzilla.
This will get it into extras asap, but does not address the question
of release engineering such an item into publishable install targets.
-jef
8:20 p.m.
Jeff Spaleta wrote:
If you do not want to wait for a sponsor I will take lead
maintainership of the package and work with you through the review
process. You can be co-maintainer and get and file bugreports and can
send any potential cvs commits to me for me to process via bugzilla.
Sounds good to me.
This will get it into extras asap, but does not address the question
of release engineering such an item into publishable install targets.
Well, at least it's there so people can play with it and try and see
just how far it can go.
--
Florin Andrei
http://florin.myip.org/
9:01 p.m.
On Thu, 2007-01-04 at 18:20 -0800, Florin Andrei wrote:
Jeff Spaleta wrote:
> If you do not want to wait for a sponsor I will take lead
> maintainership of the package and work with you through the review
> process. You can be co-maintainer and get and file bugreports and can
> send any potential cvs commits to me for me to process via bugzilla.
Sounds good to me.
> This will get it into extras asap, but does not address the question
> of release engineering such an item into publishable install targets.
Well, at least it's there so people can play with it and try and see
just how far it can go.
This would be awesome. I know that I want to look at it some and this
will save me some up-front effort ;)
Jeremy
10:02 p.m.
On Thursday 04 January 2007 21:02, Jeff Spaleta wrote:
but does not address the question
of release engineering such an item into publishable install targets.
Show that the software works and is desireable to have in say Desktop or
Server spins, and we'll make it happen.
--
Jesse Keating
Release Engineer: Fedora
10:18 p.m.
On 1/4/07, Jesse Keating <jkeating(a)redhat.com> wrote:
Show that the software works and is desireable to have in say Desktop
or
Server spins, and we'll make it happen.
I doubt that those two bins will be big enough to fill the space of
interest 2 years out. Does a completely open source version of
k12ltsp fit in either bin? Does a professional open source audio
studio operating system fit in either bin? Does a home media
center-centric open operating system fit into either bin? Does an open
source orbiting deathray operating system fit into either bin?
-jef
10:28 p.m.
On Thursday 04 January 2007 23:18, Jeff Spaleta wrote:
I doubt that those two bins will be big enough to fill the space of
interest 2 years out. Does a completely open source version of
k12ltsp fit in either bin? Does a professional open source audio
studio operating system fit in either bin? Does a home media
center-centric open operating system fit into either bin? Does an open
source orbiting deathray operating system fit into either bin?
Sure, farther down the road there might be other targets. For F7, we're
focusing on Desktop and Server, and a KDE.
--
Jesse Keating
Release Engineer: Fedora
11:19 p.m.
New subject: Fedora 7 - Desktop and Server spins.
Is the core problem simply one of space? If all packages fit on HD-DVD
(Blu-Ray) for example then we no longer need separate spins? (forgetting
for now that there is no mass market penetration of said devices).
Will there ever be a removable storage unit large enough to hold all
available packages, probably, as flash moves along.
I have not bothered with DVDs for a long time, preferring instead to use
network boot as it's just cleaner/faster for me. It can be handy though
to build ones own DVDs with specific package sets.
Although with 8,16,32GB flash memory more common I'd rather just use a
simple application to select the packages I want a "burn" then to a USB
storage device, from which I could then boot/install.
7:05 a.m.
New subject: Fedora 7 - Desktop and Server spins.
On Friday 05 January 2007 00:19, Naoki wrote:
Is the core problem simply one of space? If all packages fit on
HD-DVD
(Blu-Ray) for example then we no longer need separate spins? (forgetting
for now that there is no mass market penetration of said devices).
Not space on medium, but amount to download. Why should somebody download
8gigs worth for an install that would fit on one/two CDs?
--
Jesse Keating
Release Engineer: Fedora
6:07 p.m.
New subject: Fedora 7 - Desktop and Server spins.
On Fri, 2007-01-05 at 08:05 -0500, Jesse Keating wrote:
On Friday 05 January 2007 00:19, Naoki wrote:
> Is the core problem simply one of space? If all packages fit on HD-DVD
> (Blu-Ray) for example then we no longer need separate spins? (forgetting
> for now that there is no mass market penetration of said devices).
Not space on medium, but amount to download. Why should somebody download
8gigs worth for an install that would fit on one/two CDs?
If download size is the overriding issue, we should think about beefing
up repotrack and publishing recommended configs for its use for various
cases - if the differences in emphasis and audience for desktop and
server are the issue, we'd probably want to think beyond a pared down
package set.
David
8:05 p.m.
Em Qui, 2007-01-04 às 14:50 -0500, Bill Nottingham escreveu:
- Make wireless rock-solid
- Add wireless firmware for all the chipsets we can
I'm quite new to Fedora (came from other distros), and some things I'll
be discussing bellow may already be implemented somehow, but I couldn't
easily find them. If that's the case, please ignore me.
Speaking about wireless, I would have two suggestions:
#1 - Having some *very* easy way to switch between NetworkManager and
regular 'ifup'. I know SUSE has something similar: you just go into
their network configuration tool and select a radio box (Use NM / Use
ifup). It would be cool for laptop users that roam a lot (like me). If
there is nobody available to work on that, I would be glad to if you
point me the directions on whom should I coordinate with.
#2 - Improving the system-config-securitylevel. This I need to split in
two:
#2.1 - The current way of setting up firewall rules is excessively
simple, and makes it very difficult to have simple things like internet
connection sharing for a home network. It would be very cool to have the
ability to configure a simple 1:N NAT and some port redirection.
#2.2 - The local firewall has no logging feature. It's quite difficult
for a user/home admin to know why something is not working if you don't
have any kind of logs about what is being dropped because of the
firewall blocking. Probably having logging enabled by default could be
just overkill (most end-users won't care about it), but having a way to
enable/configure logging would help those people a lot.
I think I can help with most things suggested, I just need to know where
to start. :)
--
% Mauricio Teixeira (netmask) | Maceio/AL/BR %
% mteixeira{a}webset{d}net | http://smartpm.org %
% http://mteixeira.webset.net | http://pmping.sf.net %
8:59 p.m.
Mauricio Teixeira (netmask) (netmask(a)webset.net) said:
#1 - Having some *very* easy way to switch between NetworkManager
and
regular 'ifup'. I know SUSE has something similar: you just go into
their network configuration tool and select a radio box (Use NM / Use
ifup). It would be cool for laptop users that roam a lot (like me). If
there is nobody available to work on that, I would be glad to if you
point me the directions on whom should I coordinate with.
I'm not sure this is the right answer - it's certainly the wrong
question to be asking the user in general. For the cases that NM hits
now, we'd want to fix any cases that would cause people to want to switch
to ifup, at least.
Bill
9:18 p.m.
On Thursday 04 January 2007 8:59 pm, Bill Nottingham wrote:
Mauricio Teixeira (netmask) (netmask(a)webset.net) said:
> #1 - Having some *very* easy way to switch between NetworkManager and
> regular 'ifup'. I know SUSE has something similar: you just go into
> their network configuration tool and select a radio box (Use NM / Use
> ifup). It would be cool for laptop users that roam a lot (like me). If
> there is nobody available to work on that, I would be glad to if you
> point me the directions on whom should I coordinate with.
I'm not sure this is the right answer - it's certainly the wrong
question to be asking the user in general. For the cases that NM hits
now, we'd want to fix any cases that would cause people to want to switch
to ifup, at least.
I think the right Answer is to make NM cover all cases. where
you don't need
to go to other tools. I use entirely NM. but i could see instances where
i need to choose between multiple static wired configs that NM may not be
the easiest tool to use.
--
Dennis Gilmore, RHCE
Proud Australian
9:21 p.m.
On Thu, Jan 04, 2007 at 09:18:00PM -0600, Dennis Gilmore wrote:
> I'm not sure this is the right answer - it's certainly
the wrong
> question to be asking the user in general. For the cases that NM hits
> now, we'd want to fix any cases that would cause people to want to switch
> to ifup, at least.
I think the right Answer is to make NM cover all cases.
The biggest hurdle afaics, is that NM treats a network connection
as a per-user thing rather than a system wide thing.
Having to log in before you can use the network is busted.
Dave
--
http://www.codemonkey.org.uk
9:25 p.m.
On Thursday 04 January 2007 9:21 pm, Dave Jones wrote:
On Thu, Jan 04, 2007 at 09:18:00PM -0600, Dennis Gilmore wrote:
> > I'm not sure this is the right answer - it's certainly the wrong
> > question to be asking the user in general. For the cases that NM hits
> > now, we'd want to fix any cases that would cause people to want to
> > switch to ifup, at least.
>
> I think the right Answer is to make NM cover all cases.
The biggest hurdle afaics, is that NM treats a network connection
as a per-user thing rather than a system wide thing.
Having to log in before you can use the network is busted.
according to the TODO
list for 0.7 working before you log in is one of the
goals. Which will help when using network authentication.
--
Dennis Gilmore, RHCE
Proud Australian
10:42 p.m.
On Thu, 2007-01-04 at 21:25 -0600, Dennis Gilmore wrote:
On Thursday 04 January 2007 9:21 pm, Dave Jones wrote:
> On Thu, Jan 04, 2007 at 09:18:00PM -0600, Dennis Gilmore wrote:
> > > I'm not sure this is the right answer - it's certainly the wrong
> > > question to be asking the user in general. For the cases that NM hits
> > > now, we'd want to fix any cases that would cause people to want to
> > > switch to ifup, at least.
> >
> > I think the right Answer is to make NM cover all cases.
>
> The biggest hurdle afaics, is that NM treats a network connection
> as a per-user thing rather than a system wide thing.
> Having to log in before you can use the network is busted.
according to the TODO list for 0.7 working before you log in is one of the
goals. Which will help when using network authentication.
It would be nice if NM supported profiles too. Like "Home" and
"Office"
where it sets up /etc/hosts and /etc/resolv.conf to be what you'd want
for the two different networks.
Maybe that isn't one of the goals, but it'd make moving around a hell of
a lot easier.
josh
10:48 p.m.
On Thu, 2007-01-04 at 23:42 -0500, Bill Nottingham wrote:
Josh Boyer (jwboyer(a)jdub.homelinux.org) said:
> It would be nice if NM supported profiles too. Like "Home" and
"Office"
> where it sets up /etc/hosts and /etc/resolv.conf to be what you'd want
> for the two different networks.
Shouldn't resolve.conf be pulled from DNS?
you mean dhcp, not dns.
and overrides for both are common in most network configuration
applications.
-sv
10:58 p.m.
On Thu, 2007-01-04 at 23:42 -0500, Bill Nottingham wrote:
Josh Boyer (jwboyer(a)jdub.homelinux.org) said:
> It would be nice if NM supported profiles too. Like "Home" and
"Office"
> where it sets up /etc/hosts and /etc/resolv.conf to be what you'd want
> for the two different networks.
Shouldn't resolve.conf be pulled from DNS?
DHCP, yes. However some companies, and personal home routers for that
matter, totally suck in that regard.
My router decides to assign itself as the primary DNS server and then
routinely pukes after a few minutes of that. So I pre-pend something
in /etc/dhclient-eth0.conf to work around that, but then my laptop sucks
at work because it isn't using the site DNS servers.
And at home, my router is doesn't actually resolve the machine names, so
I add names to /etc/hosts. Which again breaks when I switch networks.
It's very annoying. Having something like a "Home" profile that would
switch to the right settings when selected vs. an "Office" or
"External"
profile would be highly welcome.
josh
11:04 p.m.
On Thursday 04 January 2007 23:58, Josh Boyer wrote:
And at home, my router is doesn't actually resolve the machine
names, so
I add names to /etc/hosts. Which again breaks when I switch networks.
It's very annoying. Having something like a "Home" profile that would
switch to the right settings when selected vs. an "Office" or
"External"
profile would be highly welcome.
I actually wrote an app that did this for me, before NM was created. It was a
neat way to learn some pygtk/glade stuff. Of course, it only made sense to
me so I never really let the code see the light of day.
--
Jesse Keating
Release Engineer: Fedora
5:53 a.m.
On Fri, 2007-01-05 at 00:04 -0500, Jesse Keating wrote:
On Thursday 04 January 2007 23:58, Josh Boyer wrote:
> And at home, my router is doesn't actually resolve the machine names, so
> I add names to /etc/hosts. Which again breaks when I switch networks.
> It's very annoying. Having something like a "Home" profile that
would
> switch to the right settings when selected vs. an "Office" or
"External"
> profile would be highly welcome.
I actually wrote an app that did this for me, before NM was created. It was a
neat way to learn some pygtk/glade stuff. Of course, it only made sense to
me so I never really let the code see the light of day.
Share the source man! Or send it to Dan and tell him to integrate it
into NM :)
josh
7:18 a.m.
On Friday 05 January 2007 06:53, Josh Boyer wrote:
Share the source man! Or send it to Dan and tell him to integrate
it
into NM
Oh no, this was horrible stuff. A very simple UI that was a radio button
between work and home, with an apply/cancel button under it. The backend
would do a series of os.system calls to iwconfig, dhclient, echos into
resolve.conf, stuff like that. It wouldn't be very useful, and I think the
code for it is long lost in one of my reinstalls.
--
Jesse Keating
Release Engineer: Fedora
8:28 a.m.
On Fri, 2007-01-05 at 08:18 -0500, Jesse Keating wrote:
On Friday 05 January 2007 06:53, Josh Boyer wrote:
> Share the source man! Or send it to Dan and tell him to integrate it
> into NM
Oh no, this was horrible stuff. A very simple UI that was a radio button
between work and home, with an apply/cancel button under it. The backend
would do a series of os.system calls to iwconfig, dhclient, echos into
resolve.conf, stuff like that. It wouldn't be very useful, and I think the
code for it is long lost in one of my reinstalls.
Config for 0.7 will be much more flexible in addition to allowing
system-wide configuration. The page here explains at least the
_conceptual_ structure of how the configuration should work. Some of
the implementation details are up in the air until we figure out how
they relate to/fit in with PolicyKit, which we're looking at now.
http://live.gnome.org/NetworkManagerConfiguration
One note should be that 'dns-search' should probably be a string array
and not just a string item. But once the details are figured out
there'll be a spec for these key/value pairs and their type.
Really, it's just an array of "connection" objects, each of which itself
is an array of dictionary objects that contains key/value pairs that
describe the settings. It doesn't really matter how they are stored,
whether in GConf, KConfig, LDAP, text files, on a smartcard, or
whatever, as long as it can be spit back out in this pretty simple
format.
Dan
8:54 a.m.
On Fri, Jan 05, 2007 at 09:28:48AM -0500, Dan Williams wrote:
Config for 0.7 will be much more flexible in addition to allowing
system-wide configuration. The page here explains at least the
_conceptual_ structure of how the configuration should work. Some of
the implementation details are up in the air until we figure out how
they relate to/fit in with PolicyKit, which we're looking at now.
http://live.gnome.org/NetworkManagerConfiguration
Hmmm, looks like this kind of definition is going to have a hard time
working in real setups. Lemme give you some examples of what I use on
a regular basis:
- eth0 has a static IP in 192.44.78/24, DNS, gw, etc, and also has a
static route allowing to use the interface for 192.168.87.0/24 using
its static IP which is not in 192.168.*
- eth0 has a static IP in 192.44.78/24, DNS, gw. eth1 has an IP in
192.168.87/24.
- eth0 and eth1 have the same static IP in 192.168.87/24, eth1 has the
route for 192.168.87/24, eth0 has only a route for 192.44.78/24.
To that you can sometimes add another interface on another private
network for iSCSI. Interfaces, addresses, routes, gateways and
upper-level services (DNS, NIS...) are orthogonal for a reason. NM
needs to keep this orthogonality at the lower configuration level
otherwise there is no chance it will work in real-world setups.
Nobody has the intellectual capacity to imagine all the possible
setups that exist out there, especially when historical reasons are
involved.
Even on laptops you can have fun scenarios, for instance I've more
than once used my laptop which was connected to an hotel's internet
through ethernet as a wifi relay for my SO's laptop. So don't forget
ad-hoc wifi connections, masquerading and forwarding ;-)
OG.
9:46 a.m.
On Fri, 2007-01-05 at 15:54 +0100, Olivier Galibert wrote:
On Fri, Jan 05, 2007 at 09:28:48AM -0500, Dan Williams wrote:
> Config for 0.7 will be much more flexible in addition to allowing
> system-wide configuration. The page here explains at least the
> _conceptual_ structure of how the configuration should work. Some of
> the implementation details are up in the air until we figure out how
> they relate to/fit in with PolicyKit, which we're looking at now.
>
> http://live.gnome.org/NetworkManagerConfiguration
Hmmm, looks like this kind of definition is going to have a hard time
working in real setups. Lemme give you some examples of what I use on
a regular basis:
Which is why it's good to have feedback :) So at least the 'gateway'
item needs to be re-thought, since that's route-based and not
interface/connection specific underneath. Though to many users it
appears so, because they do not have complex setups, the flexibility
needs to be there underneath.
- eth0 has a static IP in 192.44.78/24, DNS, gw, etc, and also has a
static route allowing to use the interface for 192.168.87.0/24 using
its static IP which is not in 192.168.*
Can you explain the configuration for these in a bit more detail? So in
this example, eth0 has a static IP and DNS, gw, etc are _also_ in the
same 192.44.78/24 network. But you've added a route that pushes traffic
for the 192.168.87.0/24 network over eth0 (which has no IP address in
that network range), correct?
- eth0 has a static IP in 192.44.78/24, DNS, gw. eth1 has an IP in
192.168.87/24.
I think the config would cover that, no? Each interface can obviously
have different IP settings (addr, mask, bcast). DNS is a bit different
because the order of resolvers in resolv.conf determines some of the
behavior, even if the routing rules determine which interface the
requests against a particular server actually go out on.
What does the output of /sbin/route -n look like for this case?
- eth0 and eth1 have the same static IP in 192.168.87/24, eth1 has
the
route for 192.168.87/24, eth0 has only a route for 192.44.78/24.
I'm not sure the configuration mentioned above excludes this
possibility, can you be more specific on how you couldn't configure your
interfaces this way in the proposed config structure? (keeping in mind
that gateway should be handled differently than the config structure
says)
Dan
To that you can sometimes add another interface on another private
network for iSCSI. Interfaces, addresses, routes, gateways and
upper-level services (DNS, NIS...) are orthogonal for a reason. NM
needs to keep this orthogonality at the lower configuration level
otherwise there is no chance it will work in real-world setups.
Well, there's certainly a relationship between interfaces and addresses
Nobody has the intellectual capacity to imagine all the possible
setups that exist out there, especially when historical reasons are
involved.
Even on laptops you can have fun scenarios, for instance I've more
than once used my laptop which was connected to an hotel's internet
through ethernet as a wifi relay for my SO's laptop. So don't forget
ad-hoc wifi connections, masquerading and forwarding ;-)
OG.
10 a.m.
On Fri, Jan 05, 2007 at 10:46:49AM -0500, Dan Williams wrote:
On Fri, 2007-01-05 at 15:54 +0100, Olivier Galibert wrote:
> - eth0 has a static IP in 192.44.78/24, DNS, gw, etc, and also has a
> static route allowing to use the interface for 192.168.87.0/24 using
> its static IP which is not in 192.168.*
Can you explain the configuration for these in a bit more detail? So in
this example, eth0 has a static IP and DNS, gw, etc are _also_ in the
same 192.44.78/24 network. But you've added a route that pushes traffic
for the 192.168.87.0/24 network over eth0 (which has no IP address in
that network range), correct?
Yep. These are the desktop boxes, which want to be able to talk to
the boxes on the internal network.
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:08:74:a8:7c:f8 brd ff:ff:ff:ff:ff:ff
inet 192.44.78.23/24 brd 192.44.78.255 scope global eth0
inet6 fe80::208:74ff:fea8:7cf8/64 scope link
valid_lft forever preferred_lft forever
192.168.87.0/24 dev eth0 scope link
192.44.78.0/24 dev eth0 proto kernel scope link src 192.44.78.23
169.254.0.0/16 dev eth0 scope link
default via 192.44.78.22 dev eth0
> - eth0 has a static IP in 192.44.78/24, DNS, gw. eth1 has an IP
in
> 192.168.87/24.
I think the config would cover that, no? Each interface can obviously
have different IP settings (addr, mask, bcast). DNS is a bit different
because the order of resolvers in resolv.conf determines some of the
behavior, even if the routing rules determine which interface the
requests against a particular server actually go out on.
Yeah, it's globally more standard. It was to show that it's not a
given every interface has dns/nis/etc. These are the servers which
are connected to both networks equally.
Note btw that the internal network has a (friggin' fast) secondary NIS
server, and the configuration is broadcast. So most of the times
these boxes use the NIS server on eth1 rather than eth0.
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:30:48:5a:c3:ee brd ff:ff:ff:ff:ff:ff
inet 192.44.78.93/24 brd 192.44.78.255 scope global eth0
inet6 fe80::230:48ff:fe5a:c3ee/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:30:48:5a:c3:ef brd ff:ff:ff:ff:ff:ff
inet 192.168.87.89/24 brd 192.168.87.255 scope global eth1
inet6 fe80::230:48ff:fe5a:c3ef/64 scope link
valid_lft forever preferred_lft forever
192.168.87.0/24 dev eth1 proto kernel scope link src 192.168.87.89
192.44.78.0/24 dev eth0 proto kernel scope link src 192.44.78.93
169.254.0.0/16 dev eth1 scope link
224.0.0.0/4 dev eth1 scope link
default via 192.44.78.22 dev eth0
What does the output of /sbin/route -n look like for this case?
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.87.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.44.78.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
224.0.0.0 0.0.0.0 240.0.0.0 U 0 0 0 eth1
0.0.0.0 192.44.78.22 0.0.0.0 UG 0 0 0 eth0
> - eth0 and eth1 have the same static IP in 192.168.87/24, eth1
has the
> route for 192.168.87/24, eth0 has only a route for 192.44.78/24.
I'm not sure the configuration mentioned above excludes this
possibility, can you be more specific on how you couldn't configure your
interfaces this way in the proposed config structure? (keeping in mind
that gateway should be handled differently than the config structure
says)
I'm not sure it doesn't, I'm not sure it does, but the orthogonality
between address and route is interesting. These are the internal
boxes, with no gw access (they're not routable anyway).
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:14:5e:86:81:58 brd ff:ff:ff:ff:ff:ff
inet 192.168.87.171/24 brd 192.168.87.255 scope global eth0
inet6 fe80::214:5eff:fe86:8158/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:14:5e:86:81:59 brd ff:ff:ff:ff:ff:ff
inet 192.168.87.171/24 scope global eth1
inet6 fe80::214:5eff:fe86:8159/64 scope link
valid_lft forever preferred_lft forever
192.168.87.0/24 dev eth1 proto kernel scope link src 192.168.87.171
192.44.78.0/24 dev eth0 scope link
169.254.0.0/16 dev eth1 scope link
224.0.0.0/4 dev eth1 scope link
OG.
10:09 a.m.
Dan Williams wrote:
On Fri, 2007-01-05 at 15:54 +0100, Olivier Galibert wrote:
> On Fri, Jan 05, 2007 at 09:28:48AM -0500, Dan Williams wrote:
>>
>> http://live.gnome.org/NetworkManagerConfiguration
>
> Hmmm, looks like this kind of definition is going to have a hard time
> working in real setups. Lemme give you some examples of what I use on
> a regular basis:
Which is why it's good to have feedback :) So at least the 'gateway'
item needs to be re-thought, since that's route-based and not
interface/connection specific underneath. Though to many users it
appears so, because they do not have complex setups, the flexibility
needs to be there underneath.
It is at least important to be able to add multiple addresses to one
(physical) interface.
I personally don't like the old eth0:0 eth0:1 (...), but prefer the new
iproute2 style, but I guess I can live with aliases as long as it is
easy to add/remove them.
Rgds.
--
_,--', _._.--._____
.--.--';_'-.', ";_ _.,-' Ola Thoresen
.'--'. _.' {`'-;_ .-.>.'
'-:_ ) / `' '=. It is easier to fix Unix
) > {_/, /~) than to live with Windows
|/ `^ .'
10:27 a.m.
On Fri, 2007-01-05 at 17:09 +0100, Ola Thoresen wrote:
Dan Williams wrote:
> On Fri, 2007-01-05 at 15:54 +0100, Olivier Galibert wrote:
>> On Fri, Jan 05, 2007 at 09:28:48AM -0500, Dan Williams wrote:
>>>
>>> http://live.gnome.org/NetworkManagerConfiguration
>>
>> Hmmm, looks like this kind of definition is going to have a hard time
>> working in real setups. Lemme give you some examples of what I use on
>> a regular basis:
>
> Which is why it's good to have feedback :) So at least the 'gateway'
> item needs to be re-thought, since that's route-based and not
> interface/connection specific underneath. Though to many users it
> appears so, because they do not have complex setups, the flexibility
> needs to be there underneath.
>
It is at least important to be able to add multiple addresses to one
(physical) interface.
Yep! That's obviously required.
I personally don't like the old eth0:0 eth0:1 (...), but prefer
the new
That format is vile.
iproute2 style, but I guess I can live with aliases as long as it is
easy to add/remove them.
Dan
2:17 p.m.
On 1/5/07, Dan Williams <dcbw(a)redhat.com> wrote:
On Fri, 2007-01-05 at 17:09 +0100, Ola Thoresen wrote:
> It is at least important to be able to add multiple addresses to one
> (physical) interface.
Yep! That's obviously required.
> I personally don't like the old eth0:0 eth0:1 (...), but prefer the new
That format is vile.
> iproute2 style, but I guess I can live with aliases as long as it is
> easy to add/remove them.
Could someone illuminate me on the non-vile iproute2 style of doing
this (give me the right jargon to Google)? Is it that you can call the
aliases anything you want with a mapping/iface combo in
/etc/network/interfaces?
Apparently, I was being vile and didn't know it and want to reform.
/Mike
3:10 p.m.
Michael Wiktowy (michael.wiktowy(a)gmail.com) said:
Could someone illuminate me on the non-vile iproute2 style of doing
this (give me the right jargon to Google)? Is it that you can call the
aliases anything you want with a mapping/iface combo in
/etc/network/interfaces?
Apparently, I was being vile and didn't know it and want to reform.
Just 'ip addr add dev eth0 192.168.1.1/24'.
Bill
3:49 p.m.
Bill Nottingham wrote:
Michael Wiktowy (michael.wiktowy(a)gmail.com) said:
> Could someone illuminate me on the non-vile iproute2 style of doing
> this (give me the right jargon to Google)? Is it that you can call the
> aliases anything you want with a mapping/iface combo in
> /etc/network/interfaces?
> Apparently, I was being vile and didn't know it and want to reform.
Just 'ip addr add dev eth0 192.168.1.1/24'.
Not having done aliases via iproute2 shouldn't that be 192.168.1.1/32 above?
--
Eric Feldhusen
3:56 p.m.
Eric J. Feldhusen (efeldhusen.lists(a)gmail.com) said:
>> Apparently, I was being vile and didn't know it and want
to reform.
>
> Just 'ip addr add dev eth0 192.168.1.1/24'.
>
Not having done aliases via iproute2 shouldn't that be 192.168.1.1/32 above?
Well, /<whatever your netmask is>.
Bill
6:04 p.m.
On 1/5/07, Bill Nottingham <notting(a)redhat.com> wrote:
Michael Wiktowy (michael.wiktowy(a)gmail.com) said:
> Could someone illuminate me on the non-vile iproute2 style of doing
> this (give me the right jargon to Google)? Is it that you can call the
> aliases anything you want with a mapping/iface combo in
> /etc/network/interfaces?
> Apparently, I was being vile and didn't know it and want to reform.
Just 'ip addr add dev eth0 192.168.1.1/24'.
Thanks ... I'll have to investigate how this survives the DHCP client
as my point to using aliases in the past was to ensure that I had a
static IP that I can reach from the outside via port forwarded ssh
through a router that seems to mysteriously change internal IP
assignments when it uses DHCP.
/Mike
7:29 a.m.
Hi Bill,
On Fri, 05 Jan 2007, Bill Nottingham wrote:
Michael Wiktowy (michael.wiktowy(a)gmail.com) said:
> Could someone illuminate me on the non-vile iproute2 style of doing
> this (give me the right jargon to Google)? Is it that you can call the
> aliases anything you want with a mapping/iface combo in
> /etc/network/interfaces?
> Apparently, I was being vile and didn't know it and want to reform.
Just 'ip addr add dev eth0 192.168.1.1/24'.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132925 time to get rid
of this bug until Fedora 7. And maybe you're able to fix the problem with
aliases (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132912), too.
;-)
Greetings,
Robert
3:09 p.m.
Ola Thoresen (redhat(a)olen.net) said:
It is at least important to be able to add multiple addresses to one
(physical) interface.
I personally don't like the old eth0:0 eth0:1 (...), but prefer the new
iproute2 style, but I guess I can live with aliases as long as it is
easy to add/remove them.
Aliases (eth0:0) need to die. Of course, I've been saying that for years
and haven't killed them yet. :/
Bill
5:03 p.m.
New subject: Fedora 7 (IP aliases)
On Fri, 2007-01-05 at 16:09 -0500, Bill Nottingham wrote:
Ola Thoresen (redhat(a)olen.net) said:
> It is at least important to be able to add multiple addresses to one
> (physical) interface.
> I personally don't like the old eth0:0 eth0:1 (...), but prefer the new
> iproute2 style, but I guess I can live with aliases as long as it is
> easy to add/remove them.
Aliases (eth0:0) need to die. Of course, I've been saying that for years
and haven't killed them yet. :/
SUSE moved to iproute2 style aliases awhile back and it would be nice to
have one less difference in distributions (especially for me, since I
write books covering Linux distros).
The only drawback is you can no longer depend on /sbin/ifconfig to show
you the all the IPs bound to a NIC. This is especially jarring for sys
admins moving from a-flavor-of-UNIX to Linux. It would be nice if
ifconfig displayed iproute2 style aliases.
Dax Kelson
Guru Labs
8:44 a.m.
New subject: NetworkManager use cases (was: Re: Fedora 7)
On Fri, Jan 05, 2007 at 03:54:17PM +0100, Olivier Galibert wrote:
Even on laptops you can have fun scenarios, for instance I've
more
than once used my laptop which was connected to an hotel's internet
through ethernet as a wifi relay for my SO's laptop. So don't forget
ad-hoc wifi connections, masquerading and forwarding ;-)
Yep. I have fun scenarios
on laptops all the time
Wireless is usually the way out, and when I plug something into the
wired port it's often just a point-to-point connection to some device that
I need to talk to. Some times there might be a dhcp/tftp server running on
that interface (so, say I can do a PXE network install of my laptop),
That or I want to transfer a file fast from some machine on the wired
network over GigE, some times configuring the interface manually, some times
with DHCP.
Since this happens pretty regularly, I can't really use NM. + bugzilla
#209009 + something bad with NM & aironet scanning, so it only sees one AP
for a long time after resuming the laptop (iwlist eth1 scan shows
everything. Not sure if it's actually an applet thing, if I manually
tell it to join a network that works fine.
Maybe some command line scripts for controlling NM would be useful.
nm-join-network <network> <wep key (optional, should look in the keyring too if
that's available)>
and it'd then try very hard to connect to that network.
nm-freeze-config and it'd stop trying to change the network config even if I
plug/unplug a cable.
Well, those are my use cases, probably pretty rare in general, but it's
what I need personally ;)
Well ok, occasionally there's the need for having an ad-hoc wlan + sharing
a GPRS/3G bluetooth connection. Typically requiring some RTFM to figure
out what the iptables masquerade syntax was again :) I would love some
connection sharing configuration thingy. Outside the scope of NM, sure,
but if NM is to be the way to configure all network devices at some point,
such an application should interact well with it :)
--
Pekka Pietikainen
11:07 p.m.
On Thu, Jan 04, 2007 at 11:42:27PM -0500, Bill Nottingham wrote:
> It would be nice if NM supported profiles too. Like
"Home" and "Office"
> where it sets up /etc/hosts and /etc/resolv.conf to be what you'd want
> for the two different networks.
Shouldn't resolve.conf be pulled from DNS?
From DNS? How's *that* gonna work without a resolv.conf? :)
But anyway, man do I hate it when a DHCP connection overrides the default
search path I put in there. When I type an unqualified name on my laptop, I
expect it to always mean the same thing. Sigh.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
4:23 p.m.
New subject: Fedora 7 (Network Manager)
On Fri, 2007-01-05 at 00:07 -0500, Matthew Miller wrote:
On Thu, Jan 04, 2007 at 11:42:27PM -0500, Bill Nottingham wrote:
> > It would be nice if NM supported profiles too. Like "Home" and
"Office"
> > where it sets up /etc/hosts and /etc/resolv.conf to be what you'd want
> > for the two different networks.
> Shouldn't resolve.conf be pulled from DNS?
>From DNS? How's *that* gonna work without a resolv.conf? :)
But anyway, man do I hate it when a DHCP connection overrides the default
search path I put in there. When I type an unqualified name on my laptop, I
expect it to always mean the same thing. Sigh.
I agree fully. I don't mind (in fact, I'm glad) that the name server
changes. However, don't touch my DNS search path.
It would be great if NetworkManager allowed defining a DNS domain that
could be prepended to whatever the DHCP sent (if any). Windows allows
this.
This can be done with dhclient-XXX.conf
Dax Kelson
Guru Labs
9:24 p.m.
On Thursday 04 January 2007 9:18 pm, Dennis Gilmore wrote:
I think the right Answer is to make NM cover all cases. where you
don't
need to go to other tools. I use entirely NM. but i could see instances
where i need to choose between multiple static wired configs that NM may
not be the easiest tool to use.
I should add i use NM on laptops only. servers and desktops I dont use it.
--
Dennis Gilmore, RHCE
Proud Australian
3:34 a.m.
On Thu, 2007-01-04 at 21:24 -0600, Dennis Gilmore wrote:
On Thursday 04 January 2007 9:18 pm, Dennis Gilmore wrote:
> I think the right Answer is to make NM cover all cases. where you don't
> need to go to other tools. I use entirely NM. but i could see instances
> where i need to choose between multiple static wired configs that NM may
> not be the easiest tool to use.
I should add i use NM on laptops only. servers and desktops I dont use it.
FWIW: I
have never managed to get NM working anywhere for me.
After having played with it on laptops, desktops/network-clients and my
home network's server, I found my myself having disabled NM everywhere.
Ralf
6:24 a.m.
Ralf Corsepius wrote:
On Thu, 2007-01-04 at 21:24 -0600, Dennis Gilmore wrote:
> On Thursday 04 January 2007 9:18 pm, Dennis Gilmore wrote:
>> I think the right Answer is to make NM cover all cases. where you don't
>> need to go to other tools. I use entirely NM. but i could see instances
>> where i need to choose between multiple static wired configs that NM may
>> not be the easiest tool to use.
> I should add i use NM on laptops only. servers and desktops I dont use it.
FWIW: I have never managed to get NM working anywhere for me.
After having played with it on laptops, desktops/network-clients and my
home network's server, I found my myself having disabled NM everywhere.
I use it on both laptops and desktops. I still get frequent cases of
having to select my wireless network multiple times until it
successfully connects, and the fact it doesn't connect until the user
logs in means once I'm logged I have to restart some services such as
squid. NM has the thankless job of having to deal with wireless drivers
of extremely varying quality and stability.
My laptop chipset is well suppobrted (aironet), but on the desktop it's
a nightmare. I have a PCI madwifi-based card that's stable but yields
horrible signal strength, and two of those little USB wifi adapters. One
(Netgear MA111v2) works with ndiswrapper but systematically crashes
the kernel on shutdown, the other (a Sagem XG-760N) is only supported by
the very unstable zd1211b driver. *sigh*.
11:29 a.m.
#2 - Improving the system-config-securitylevel. This I need to split
in
two:
I maintain s-c-securitylevel, so I'll address this.
#2.1 - The current way of setting up firewall rules is excessively
simple, and makes it very difficult to have simple things like internet
connection sharing for a home network. It would be very cool to have the
ability to configure a simple 1:N NAT and some port redirection.
These sorts of features would be handy, I agree. If they can be simple
one checkbox sorts of things, that's even better. Getting into the port
redirection stuff takes s-c-securitylevel down a path I don't think we
want to go, though. It's my understanding that it's never been
developed as the be-all firewall configuration tool that does everything
you'd want to do. I certainly have not maintained it as such.
A checkbox for enabling NAT would be decent, but I don't know how much
farther beyond that I want to go.
#2.2 - The local firewall has no logging feature. It's quite
difficult
for a user/home admin to know why something is not working if you don't
have any kind of logs about what is being dropped because of the
firewall blocking. Probably having logging enabled by default could be
just overkill (most end-users won't care about it), but having a way to
enable/configure logging would help those people a lot.
I have an open bug about this (151647 - it's fairly old at this point)
but have never gotten around to working on it since I didn't see it as a
huge feature. Of course, I can go in and add it if there's that much
demand. I can see it being useful for debugging firewalls.
The trick with both of these features is to add them without making the
UI a nightmare to use and maintain. Maybe I should spend a while
thinking about how to do it.
Two things I want to do in s-c-securitylevel (and if I ever get done
reworking pykickstart, I'll get these in for 7) are:
(1) Rewrite lokkit in Python. I can hack C but I'm slower at it and I
don't see it as particularly well suited to this sort of program,
especially with the goofy newt stuff.
(2) Make s-c-securitylevel not destroy any customizations you make by
hand. I think this is the biggest problem affecting the program right
now and if I can come up with a good way to deal with it, I'll put the
fix in right away. There's an open bug for this - 138143.
- Chris
4:18 p.m.
New subject: Fedora 7 (improving s-c-securitylevel)
On Thu, 2007-01-04 at 23:05 -0300, Mauricio Teixeira (netmask) wrote:
Em Qui, 2007-01-04 às 14:50 -0500, Bill Nottingham escreveu:
> - Make wireless rock-solid
> - Add wireless firmware for all the chipsets we can
I'm quite new to Fedora (came from other distros), and some things I'll
be discussing bellow may already be implemented somehow, but I couldn't
easily find them. If that's the case, please ignore me.
Speaking about wireless, I would have two suggestions:
#2 - Improving the system-config-securitylevel. This I need to split in
two:
#2.1 - The current way of setting up firewall rules is excessively
simple, and makes it very difficult to have simple things like internet
connection sharing for a home network. It would be very cool to have the
ability to configure a simple 1:N NAT and some port redirection.
Simple is good.
I'd be OK with a "NAT all traffic leaving interface X" setting, but
please, do not morph it into the SuSEfirewall2 monster.
Dax Kelson
Guru Labs
8:24 p.m.
This is going to sound really stupid but what the heck; The nice thing
about the "core" and "extras" differentiation was you knew what was
"core" and what was "extra".
Without this distinction how does average Joe know that compiz is
preferred over beryl, or that xmms is the option to Rhythmbox not the
other way around? Just the definition inside comps.xml or something
more complex?
We can give access to well over 5,000 packages in the same place but
won't it be a bit of a jumble?
Also, how will this help the creation of RHEL? If Fedora is to remain
the basis for RHEL will this not slightly confuse things?
9:06 p.m.
On Fri, 2007-01-05 at 11:24 +0900, Naoki wrote:
This is going to sound really stupid but what the heck; The nice
thing
about the "core" and "extras" differentiation was you knew what was
"core" and what was "extra".
Without this distinction how does average Joe know that compiz is
preferred over beryl, or that xmms is the option to Rhythmbox not the
other way around? Just the definition inside comps.xml or something
more complex?
How does Joe user know this now? They're just using the graphical tools
which (intentionally) don't show this. It's definitely an area that
could deal with improvement, but differentiation based on repo isn't
really the answer. There's a real opportunity to explore some new ways
of showing the defaults[1]
Jeremy
[1] as well as other "interesting" information that isn't contained in
the package itself, think reviews, screenshots, etc)
9:39 p.m.
On 1/4/07, Jeremy Katz <katzj(a)redhat.com> wrote:
There's a real opportunity to explore some new ways
of showing the defaults[1]
The definition of a "default" gets really really murky, if we are
opening up installer image space and allowing the opportunity for
community to step-in and attempt to maintain alternative installer
target images. What's default in the Gnome-centric desktop installer
target and what is default in my garunteed to be hugely popular Emacs
as desktop interface installer target or to a niche installer target
like a KDE desktop.... will be totally different.
-jef"replace Emacs with vi, as needed"spaleta
11:07 p.m.
On Thu, 2007-01-04 at 22:06 -0500, Jeremy Katz wrote:
On Fri, 2007-01-05 at 11:24 +0900, Naoki wrote:
> This is going to sound really stupid but what the heck; The nice thing
> about the "core" and "extras" differentiation was you knew what
was
> "core" and what was "extra".
>
> Without this distinction how does average Joe know that compiz is
> preferred over beryl, or that xmms is the option to Rhythmbox not the
> other way around? Just the definition inside comps.xml or something
> more complex?
How does Joe user know this now?
Good point, my idea of Joe user is obviously different the the "normal"
My Joe user only ever uses the command line (servers).
They're just using the graphical tools
which (intentionally) don't show this. It's definitely an area that
could deal with improvement, but differentiation based on repo isn't
really the answer. There's a real opportunity to explore some new ways
of showing the defaults[1]
Cool.
10:45 p.m.
On Fri, 2007-01-05 at 11:24 +0900, Naoki wrote:
This is going to sound really stupid but what the heck; The nice
thing
about the "core" and "extras" differentiation was you knew what was
"core" and what was "extra".
<snip>
Also, how will this help the creation of RHEL? If Fedora is to
remain
the basis for RHEL will this not slightly confuse things?
Why is this a concern for Fedora? It's not. It's something Red Hat
will have to figure out. Though I doubt it will be very hard for them
to do so.
Besides, RHEL already contains a package set that spans today's Core and
Extras. Exim is an example. It's in RHEL, and it's in Extras. Let the
engineers at Red Hat decide what to put in RHEL. They seem to be doing
a fine job already.
josh
10:47 p.m.
Josh Boyer (jwboyer(a)jdub.homelinux.org) said:
> Also, how will this help the creation of RHEL? If Fedora is to
remain
> the basis for RHEL will this not slightly confuse things?
Why is this a concern for Fedora? It's not. It's something Red Hat
will have to figure out. Though I doubt it will be very hard for them
to do so.
Right.
Besides, RHEL already contains a package set that spans today's
Core and
Extras. Exim is an example. It's in RHEL, and it's in Extras. Let the
engineers at Red Hat decide what to put in RHEL. They seem to be doing
a fine job already.
I'm sure someone will be willing to argue with you on that. :)
Bill
3:30 a.m.
> This is going to sound really stupid but what the heck; The nice
thing
> about the "core" and "extras" differentiation was you knew what
was
> "core" and what was "extra".
>
<snip>
> Also, how will this help the creation of RHEL? If Fedora is to remain
> the basis for RHEL will this not slightly confuse things?
Why is this a concern for Fedora? It's not. It's something Red Hat
will have to figure out. Though I doubt it will be very hard for them
to do so.
Besides, RHEL already contains a package set that spans today's Core and
Extras. Exim is an example. It's in RHEL, and it's in Extras. Let the
engineers at Red Hat decide what to put in RHEL. They seem to be doing
a fine job already.
I suspect it will be just another spin of the Fedora package tree like
Desktop or Server that is then further stabilised so not much
different to now. Most of the stuff that's happening in Fedora is just
as relevant to rhel as it is fedora.
Peter
9:08 p.m.
On Fri, 2007-01-05 at 03:01 +0000, Bojan Smojver wrote:
Bill Nottingham <notting <at> redhat.com> writes:
> - Add KVM virtualization support to our tools
Does this mean that Xen is gone?
No; there's no reason the tools can't support multiple types of
virtualization. That's why libvirt was started in the first place
Jeremy
9:17 p.m.
Bojan Smojver (bojan(a)rexursive.com) said:
> No; there's no reason the tools can't support multiple
types of
> virtualization. That's why libvirt was started in the first place
Thanks.
That being said, if Xen can't be beaten into shape to reasonably
follow upstream kernels, or get upstream itself....
Bill
10:18 p.m.
Once upon a time, Bill Nottingham <notting(a)redhat.com> said:
Starting with Fedora 7, there is no more Core, and no more Extras;
there is only Fedora. One single repository, built in the community
on open source tools, assembled into whatever spins the Fedora community
desires.
How will this be distributed? Will ISOs still be available that cover
the whole repository? Right now, Core has release targets (and then
updates), while Extras is a rolling target. Lots of users (and
potential users) don't have high speed or even reliable Internet access;
they need everything they install to be on physical media.
I've said this before because of previous experiences trying to help a
friend with only modem access, but now I'm mailing DVDs to another
friend stationed in Iraq. Having a "GNOME DVD" and a "KDE DVD" and a
"Server DVD" doesn't really help, since I can't anticipate what
he'll
want (and all three DVDs would have a bunch in common, wasting space).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
10:30 p.m.
On Thursday 04 January 2007 23:18, Chris Adams wrote:
I've said this before because of previous experiences trying to
help a
friend with only modem access, but now I'm mailing DVDs to another
friend stationed in Iraq. Having a "GNOME DVD" and a "KDE DVD" and
a
"Server DVD" doesn't really help, since I can't anticipate what
he'll
want (and all three DVDs would have a bunch in common, wasting space).
A "kitchen-sink" DVD set may be possible, but I don't expect it to be hosted
by our mirror system. Perhaps bittorrent only or an easy script to generate
one yourself.
--
Jesse Keating
Release Engineer: Fedora
10:34 p.m.
On Thu, Jan 04, 2007 at 10:18:54PM -0600, Chris Adams wrote:
How will this be distributed? Will ISOs still be available that
cover
the whole repository? Right now, Core has release targets (and then
There will be tools that make it easy to make ISOs that cover any subset of
the whole repository -- including, if for some reason you need it, the
entire thing.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
3:56 a.m.
Bill Nottingham wrote:
[..]
- A Fedora Desktop spin
- A Fedora Server spin
- A Fedora KDE spin
what about updating from fc6 -> f7 ?
lets say some has
gnome+kde+server packages installed
is it possible to upgrade to f7 *without* requiring a network connection
during install?
seems not until we have a Fedora 7 DVD similar to Fedora Core now.
[..]
Here's to making Fedora 7 the best release yet!
go for it!
Bill
7:20 a.m.
On Friday 05 January 2007 04:56, dragoran wrote:
what about updating from fc6 -> f7 ?
lets say some has
gnome+kde+server packages installed
is it possible to upgrade to f7 *without* requiring a network connection
during install?
seems not until we have a Fedora 7 DVD similar to Fedora Core now.
How many Fedora 6 installs do you know of that have JUST core installed, no
extras? We've long needed to be able to access Extras at upgrade time, now
more than ever. Look at the crapstorm that ubuntu went through when their
upgrade feature didn't take universe into account.
--
Jesse Keating
Release Engineer: Fedora
8:16 a.m.
Jesse Keating wrote:
On Friday 05 January 2007 04:56, dragoran wrote:
> what about updating from fc6 -> f7 ?
> lets say some has
> gnome+kde+server packages installed
> is it possible to upgrade to f7 *without* requiring a network connection
> during install?
> seems not until we have a Fedora 7 DVD similar to Fedora Core now.
>
How many Fedora 6 installs do you know of that have JUST core installed, no
extras? We've long needed to be able to access Extras at upgrade time, now
more than ever. Look at the crapstorm that ubuntu went through when their
upgrade feature didn't take universe into account.
so we need a everything DVD "Fedora 7 Complete"
mirros can have the iso file and loopback mount it to get the "normal
tree" saving diskspace. but I doubt that many mirror will do it.
we could also ship it only over bittorent.
9:01 a.m.
On Fri, Jan 05, 2007 at 03:16:04PM +0100, dragoran wrote:
so we need a everything DVD "Fedora 7 Complete"
mirros can have the iso file and loopback mount it to get the "normal
tree" saving diskspace. but I doubt that many mirror will do it.
we could also ship it only over bittorent.
Many of those packages are just going to need to get updated to the latest
versions over the network eventually. If you've got the bandwidth for
bittorrent, you've got the bandwidth to do a network install.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
9:04 a.m.
Matthew Miller wrote:
On Fri, Jan 05, 2007 at 03:16:04PM +0100, dragoran wrote:
> so we need a everything DVD "Fedora 7 Complete"
> mirros can have the iso file and loopback mount it to get the "normal
> tree" saving diskspace. but I doubt that many mirror will do it.
> we could also ship it only over bittorent.
Many of those packages are just going to need to get updated to the latest
versions over the network eventually. If you've got the bandwidth for
bittorrent, you've got the bandwidth to do a network install.
You are making a assumption that the same person is using bittorrent and
the installation. That's far from true. I can download using bittorrent
and burn several thousand copies for friends who dont have network access.
Rahul
9:29 a.m.
On Fri, Jan 05, 2007 at 08:34:52PM +0530, Rahul Sundaram wrote:
>Many of those packages are just going to need to get updated to
the latest
>versions over the network eventually. If you've got the bandwidth for
>bittorrent, you've got the bandwidth to do a network install.
You are making a assumption that the same person is using bittorrent and
the installation. That's far from true. I can download using bittorrent
and burn several thousand copies for friends who dont have network access.
True, but in my experience, that's not the typical case. I think it'd be
better to make an easy way for you to generate the DVD iso for this specific
purpose than to provide a general one which will get downloaded millions of
times by people who would have been better off with a network install.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
10:42 a.m.
Matthew Miller wrote:
On Fri, Jan 05, 2007 at 08:34:52PM +0530, Rahul Sundaram wrote:
>> Many of those packages are just going to need to get updated to the latest
>> versions over the network eventually. If you've got the bandwidth for
>> bittorrent, you've got the bandwidth to do a network install.
> You are making a assumption that the same person is using bittorrent and
> the installation. That's far from true. I can download using bittorrent
> and burn several thousand copies for friends who dont have network access.
True, but in my experience, that's not the typical case.
You are in a place with tons of bandwidth. I am not surprised by this
thinking but please dont assume this is common scenario.
I think it'd be
better to make an easy way for you to generate the DVD iso for this
specific
purpose than to provide a general one which will get downloaded millions of
times by people who would have been better off with a network install.
The solution to people picking the wrong choice for their purpose is
good documentation and guidance with tools where applicable. The only
objection I heard to putting up a DVD is mirror space but we can avoid
that problem by using a different name space so mirrors would have to
pull it explicitly and in bittorrent. Considering that several
distributions like Debian with large ISO sets has managed to get lots of
mirrors, I dont think the problem of mirror space would affect us much.
We should discuss this with mirror administrators rather than assuming
its a problem.
Rahul
11:19 a.m.
Rahul Sundaram schrieb:
The solution to people picking the wrong choice for their purpose is
good documentation and guidance with tools where applicable. The only
objection I heard to putting up a DVD is mirror space but we can avoid
that problem by using a different name space so mirrors would have to
pull it explicitly and in bittorrent. Considering that several
distributions like Debian with large ISO sets has managed to get lots of
mirrors, I dont think the problem of mirror space would affect us much.
We should discuss this with mirror administrators rather than assuming
its a problem.
What I'd like to see is some sort of yum-proxy to save bandwidth for
users. E.g. let some sort of yum-procy run on a local network server;
fill it's cache with what you have already from the distribution cd;
clients connect to the proxy; if the package is in the cache send it
back; otherwise download it from the web, send it over, and put it in
the cache; now and then check if a package is still in the upstream
repos; if not, drop it from the cache.
I don't think something like that exists for yum. Or did I miss that?
Debian has something similar iirc -- ohh boy, I should learn python
properly and implement above proxy myself...
CU
thl
11:26 a.m.
Thorsten Leemhuis wrote:
Rahul Sundaram schrieb:
> The solution to people picking the wrong choice for their purpose is
> good documentation and guidance with tools where applicable. The only
> objection I heard to putting up a DVD is mirror space but we can avoid
> that problem by using a different name space so mirrors would have to
> pull it explicitly and in bittorrent. Considering that several
> distributions like Debian with large ISO sets has managed to get lots of
> mirrors, I dont think the problem of mirror space would affect us much.
> We should discuss this with mirror administrators rather than assuming
> its a problem.
What I'd like to see is some sort of yum-proxy to save bandwidth for
users. E.g. let some sort of yum-procy run on a local network server;
fill it's cache with what you have already from the distribution cd;
clients connect to the proxy; if the package is in the cache send it
back; otherwise download it from the web, send it over, and put it in
the cache; now and then check if a package is still in the upstream
repos; if not, drop it from the cache.
I don't think something like that exists for yum. Or did I miss that?
Debian has something similar iirc -- ohh boy, I should learn python
properly and implement above proxy myself...
Have you looked at mrepo? http://dag.wieers.com/home-made/mrepo/
Rahul
1:43 p.m.
Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
[...]
Have you looked at mrepo? http://dag.wieers.com/home-made/mrepo/
Interesting, but it doesn't look exactly like what was asked...
I'd like to do the following: Net-installing machine #1 gets the stuff
required for that install (only!) and caches it, from cache install
machines #2 .. #30. Now update machine #1, cache updates (so they can be
used to update #2 .. #30, or even for fresh installs of #31 .. #35).
If machine #20 needs some extra package, get and cache that one. If some
machine asks for a package, look if what is up to date and hand that over;
if not, get the last version.
Sort of local-net /var/cache/yum (with a bit smarter handling ;-). Sure,
it'll need some smarts to figure out that a package is obsoleted by another
(version) to free space, but this might be handled by hand. Disk space is
inexpensive, international network access is limited and expensive here
(and it is probably much worse elsewhere). And it is not fun downloading
the same files 30 times, or mirroring 10 files that aren't used locally to
get the one you'll install 30 times.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
1:49 p.m.
On Friday 05 January 2007 14:43, Horst H. von Brand wrote:
I'd like to do the following: Net-installing machine #1 gets the
stuff
required for that install (only!) and caches it, from cache install
machines #2 .. #30. Now update machine #1, cache updates (so they can be
used to update #2 .. #30, or even for fresh installs of #31 .. #35).
If machine #20 needs some extra package, get and cache that one. If some
machine asks for a package, look if what is up to date and hand that over;
if not, get the last version.
Sort of local-net /var/cache/yum (with a bit smarter handling ;-). Sure,
it'll need some smarts to figure out that a package is obsoleted by another
(version) to free space, but this might be handled by hand. Disk space is
inexpensive, international network access is limited and expensive here
(and it is probably much worse elsewhere). And it is not fun downloading
the same files 30 times, or mirroring 10 files that aren't used locally to
get the one you'll install 30 times.
Er, how is this not possible with a sufficiently large squid caching proxy?
--
Jesse Keating
Release Engineer: Fedora
3:39 p.m.
...... Original Message .......
On Fri, 5 Jan 2007 14:49:09 -0500 "Jesse Keating" <jkeating(a)redhat.com>
wrote:
On Friday 05 January 2007 14:43, Horst H. von Brand wrote:
> I'd like to do the following: Net-installing machine #1 gets the stuff
> required for that install (only!) and caches it, from cache install
> machines #2 .. #30. Now update machine #1, cache updates (so they can be
> used to update #2 .. #30, or even for fresh installs of #31 .. #35).
> If machine #20 needs some extra package, get and cache that one. If some
> machine asks for a package, look if what is up to date and hand that
over;
> if not, get the last version.
>
> Sort of local-net /var/cache/yum (with a bit smarter handling ;-). Sure,
> it'll need some smarts to figure out that a package is obsoleted by
another
> (version) to free space, but this might be handled by hand. Disk
space is
> inexpensive, international network access is limited and expensive here
> (and it is probably much worse elsewhere). And it is not fun downloading
> the same files 30 times, or mirroring 10 files that aren't used locally
to
> get the one you'll install 30 times.
Er, how is this not possible with a sufficiently large squid caching proxy?
It isn't that simple.
The problem is that if client1 fetches an RPM from one mirror and client2
tries to fetch the same RPM from a different mirror, no caching is done.
As I recall, Squid uses the MD5 of the entire URI as the unique object
identifier.
You need to have all the clients fetching from the same mirror AND ideally,
this should happen automatically without config change on the clients.
If I bring my laptop to the office, then it should use the local network
cache automatically. When I go home, it should use the mirrors like normal.
I figure I can implement that at the office with DNS hijacking plus using
Squid as a transparent proxy. It is on my TODO list.
___
Dax Kelson
Guru Labs
Sent with my Treo
(please pardon any brevity)
1:17 p.m.
Thorsten Leemhuis (fedora(a)leemhuis.info) said:
What I'd like to see is some sort of yum-proxy to save bandwidth
for
users. E.g. let some sort of yum-procy run on a local network server;
fill it's cache with what you have already from the distribution cd;
clients connect to the proxy; if the package is in the cache send it
back; otherwise download it from the web, send it over, and put it in
the cache; now and then check if a package is still in the upstream
repos; if not, drop it from the cache.
I don't think something like that exists for yum. Or did I miss that?
Debian has something similar iirc -- ohh boy, I should learn python
properly and implement above proxy myself...
Well, you *could* just do this with any specially configured web cache.
Bill
2:01 p.m.
On Fri, Jan 05, 2007 at 06:19:20PM +0100, Thorsten Leemhuis wrote:
What I'd like to see is some sort of yum-proxy to save bandwidth
for
users. E.g. let some sort of yum-procy run on a local network server;
fill it's cache with what you have already from the distribution cd;
clients connect to the proxy; if the package is in the cache send it
back; otherwise download it from the web, send it over, and put it in
the cache; now and then check if a package is still in the upstream
repos; if not, drop it from the cache.
Even better would be the use of mDNS and DNS-SD to search for such a
proxy. This way, you don't need to hardcode anything in configuration
files.
I don't know if yum provides enough hooks to implement such a plugin,
but ideally it would look for a local proxy and fallback to the
"original" repository URL if none can be found. That'd useful if you are
a laptop user and only sometimes have fast local access to such a proxy.
Or it would allow for graceful degradation if the proxy has died or is
undergoing maintenance. Or, in a network with many systems, it can
provide for load balancing, by using more than one proxy (I guess you
can look at all the services discovered on the local network, not just
the first one replying to your broadcast request). All you'd need to do
is installing the plugin's RPM or make a convincing case for its
inclusion in yum itself - not likely to happen today, but maybe in a
few years the use case won't be as uncommon as it is now.
Instead of a proxy, one could also use DNS-SD to implement something
closer to the P2P model, where machines on a local network search for
any neighbour systems that have already downloaded updates, basically
sharing the yum cache.
--
Rudi
5:59 p.m.
On Fri, 2007-01-05 at 21:01 +0100, Rudi Chiarito wrote:
Even better would be the use of mDNS and DNS-SD to search for such a
proxy. This way, you don't need to hardcode anything in configuration
files.
I think misa's service discovery plugin [1] would be a good starting
point. Probably needs some dusting off.
David
[1]
https://lists.dulug.duke.edu/pipermail/yum-devel/2006-May/002194.html
7:39 a.m.
Rudi Chiarito ha scritto:
On Fri, Jan 05, 2007 at 06:19:20PM +0100, Thorsten Leemhuis wrote:
> What I'd like to see is some sort of yum-proxy to save bandwidth for
> users. E.g. let some sort of yum-procy run on a local network server;
> fill it's cache with what you have already from the distribution cd;
> clients connect to the proxy; if the package is in the cache send it
> back; otherwise download it from the web, send it over, and put it in
> the cache; now and then check if a package is still in the upstream
> repos; if not, drop it from the cache.
Even better would be the use of mDNS and DNS-SD to search for such a
proxy. This way, you don't need to hardcode anything in configuration
files.
FYI: http://freshmeat.net/projects/apt-zeroconf/
Instead of a proxy, one could also use DNS-SD to implement something
closer to the P2P model, where machines on a local network search for
any neighbour systems that have already downloaded updates, basically
sharing the yum cache.
--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor:
Problemi di Liquidità? Con Logos Finanziaria 30.000 in 24 ore a dipendenti e lavoratori
autonomi con rimborsi fino a 120 mesi clicca qui
*
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2907&d=6-1
9:06 a.m.
Matthew Miller wrote:
On Fri, Jan 05, 2007 at 03:16:04PM +0100, dragoran wrote:
> so we need a everything DVD "Fedora 7 Complete"
> mirros can have the iso file and loopback mount it to get the "normal
> tree" saving diskspace. but I doubt that many mirror will do it.
> we could also ship it only over bittorent.
>
Many of those packages are just going to need to get updated to the latest
versions over the network eventually. If you've got the bandwidth for
bittorrent, you've got the bandwidth to do a network install.
I have a 6Mbit flatrate thats not the point, I have many boxes (4) (not
connected to the internet) they should be able to be updated to.
also I think a media install is faster(I prefer hdd installs but since I
am using md raid its no longer possible) and safer than a
networkinstall(or even worse update) over internet.
9:18 a.m.
Matthew Miller schrieb:
On Fri, Jan 05, 2007 at 03:16:04PM +0100, dragoran wrote:
> so we need a everything DVD "Fedora 7 Complete"
> mirros can have the iso file and loopback mount it to get the "normal
> tree" saving diskspace. but I doubt that many mirror will do it.
> we could also ship it only over bittorent.
Many of those packages are just going to need to get updated to the latest
versions over the network eventually. If you've got the bandwidth for
bittorrent, you've got the bandwidth to do a network install.
But maybe you have the bandwidth on one machine, want to burn a dvd,
travel home, and install/use it there...
CU
thl
9:52 p.m.
New subject: Fedora 7 - USB Install method - Everything ISO.
DVDs are a pain, they are cumbersome and too small to fit a full OS
necessitating the separate Desktop/Server/KDE spins that are currently
garnering so much attention.
Fedora Core started supporting installation from a USB device with core
6, which is excellent. Although the procedure as documented
( http://fedora.redhat.com/docs/install-guide/fc6/en/sn-preparing-usb-media... ) states
you need to download and 'burn' the diskboot image with dd to the device. But
doesn't seem to explain much after that, do you use HDD install from that device?
Considering for ~$100 you can get an 8GB USB flash or 20G HDD storage
device, and USB ports have appeared on every computer since about the
same time as DVD came out (USB 1.0 spec released in January 1996) it's
now considerably cheaper and more practical than the combination of a
DVD burner on a network attached machine, DVD-ROM drives on all the
client machines, and DVD media.
So would it not make sense to have an "everything" ISO for use on
removable USB devices?
10:24 p.m.
New subject: Fedora 7 - USB Install method - Everything ISO.
Naoki (naoki(a)valuecommerce.com) said:
DVDs are a pain, they are cumbersome and too small to fit a full OS
... then perhaps that the OS is so big is the problem. :)
More seriously...
So would it not make sense to have an "everything" ISO for
use on
removable USB devices?
*Shrug*. Wouldn't really make sense for it to be an ISO, from a
raw FS standpoint. You could have a torrent that just makes
a directory, even.
Bill
9:36 a.m.
New subject: Fedora 7 - USB Install method - Everything ISO.
On Mon, 2007-01-15 at 23:24 -0500, Bill Nottingham wrote:
Naoki (naoki(a)valuecommerce.com) said:
> DVDs are a pain, they are cumbersome and too small to fit a full OS
... then perhaps that the OS is so big is the problem. :)
More seriously...
> So would it not make sense to have an "everything" ISO for use on
> removable USB devices?
*Shrug*. Wouldn't really make sense for it to be an ISO, from a
raw FS standpoint. You could have a torrent that just makes
a directory, even.
ISOs are convenient from a distribution standpoint just to ensure that
things were downloaded correctly[1]. I can see how spending some time
to make the "install from a USB device" a little bit easier could
definitely have advantages. At the same time, I don't think that the
areas for which DVDs are a problem will be better off with large USB
storage devices.
Jeremy
[1] Also, for ensuring that people don't delete things because "I don't
need that" then leading to install problems. Not that such a thing ever
happened with hd tree installs :-)
10:42 a.m.
New subject: Fedora 7 - USB Install method - Everything ISO.
On Tuesday 16 January 2007 08:36am, Jeremy Katz wrote:
On Mon, 2007-01-15 at 23:24 -0500, Bill Nottingham wrote:
> Naoki (naoki(a)valuecommerce.com) said:
> > DVDs are a pain, they are cumbersome and too small to fit a full OS
>
> ... then perhaps that the OS is so big is the problem. :)
>
> More seriously...
>
> > So would it not make sense to have an "everything" ISO for use on
> > removable USB devices?
>
> *Shrug*. Wouldn't really make sense for it to be an ISO, from a
> raw FS standpoint. You could have a torrent that just makes
> a directory, even.
ISOs are convenient from a distribution standpoint just to ensure that
things were downloaded correctly[1]. I can see how spending some time
to make the "install from a USB device" a little bit easier could
definitely have advantages.
Agree. But perhaps it's not an ISO, but just a "usb-disk.cpio" that's
8GB+
(whatever) in size. That could be downloaded and extracted to wherever, be
it a USB disk or a file server (NFS, etc.).
At the same time, I don't think that the
areas for which DVDs are a problem will be better off with large USB
storage devices.
Agreed. For those environments, network installs typically make much more
sense. Even on my home systems, I do network installs when I can because
it's typically faster and easier than swapping CDs or burning DVDs.
However, to set up a network installation with all available packages, I would
probably just continue to create my own mirror of the released packages and
of the updates repo. But I agree that having a single file to download for
initial setup of such file servers would be advantageous. It could also be
the "roll-your-own-fedora-spin-kit" with all fedora packages + the spin tools
(to build DVD and CD ISOs).
Jeremy
[1] Also, for ensuring that people don't delete things because "I don't
need that" then leading to install problems. Not that such a thing ever
happened with hd tree installs :-)
Yup.
--
Lamont Peterson <lamont(a)gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
NOTE: All messages from this email address should be digitally signed with my
0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as
well as other keyservers that sync with MIT's.
11:08 a.m.
New subject: Fedora 7 - USB Install method - Everything ISO.
On Tue, 2007-01-16 at 09:42 -0700, Lamont Peterson wrote:
On Tuesday 16 January 2007 08:36am, Jeremy Katz wrote:
> On Mon, 2007-01-15 at 23:24 -0500, Bill Nottingham wrote:
> > Naoki (naoki(a)valuecommerce.com) said:
> > > DVDs are a pain, they are cumbersome and too small to fit a full OS
> >
> > ... then perhaps that the OS is so big is the problem. :)
> >
> > More seriously...
> >
> > > So would it not make sense to have an "everything" ISO for use
on
> > > removable USB devices?
> >
> > *Shrug*. Wouldn't really make sense for it to be an ISO, from a
> > raw FS standpoint. You could have a torrent that just makes
> > a directory, even.
>
> ISOs are convenient from a distribution standpoint just to ensure that
> things were downloaded correctly[1]. I can see how spending some time
> to make the "install from a USB device" a little bit easier could
> definitely have advantages.
Agree. But perhaps it's not an ISO, but just a "usb-disk.cpio" that's
8GB+
(whatever) in size. That could be downloaded and extracted to wherever, be
it a USB disk or a file server (NFS, etc.).
We support having the ISO being accessed over NFS. And you can loopback
mount for HTTP/FTP. In the interest of our mirrors not hunting me down
and killing me, I'd prefer to have as few different copies of the "same"
bits as possible :-)
Jeremy
11:23 a.m.
New subject: Fedora 7 - USB Install method - Everything ISO.
On Tuesday 16 January 2007 12:08, Jeremy Katz wrote:
We support having the ISO being accessed over NFS. And you can
loopback
mount for HTTP/FTP. In the interest of our mirrors not hunting me down
and killing me, I'd prefer to have as few different copies of the "same"
bits as possible :-)
In the interest of having the compose finish in anything possibly considered
reasonable time, I'd rather not repackage up the same bits in many different
containers.
--
Jesse Keating
Release Engineer: Fedora
11:25 a.m.
New subject: Fedora 7 - USB Install method - Everything ISO.
On Tuesday 16 January 2007 10:08am, Jeremy Katz wrote:
On Tue, 2007-01-16 at 09:42 -0700, Lamont Peterson wrote:
> On Tuesday 16 January 2007 08:36am, Jeremy Katz wrote:
> > On Mon, 2007-01-15 at 23:24 -0500, Bill Nottingham wrote:
> > > Naoki (naoki(a)valuecommerce.com) said:
> > > > DVDs are a pain, they are cumbersome and too small to fit a full OS
> > >
> > > ... then perhaps that the OS is so big is the problem. :)
> > >
> > > More seriously...
> > >
> > > > So would it not make sense to have an "everything" ISO for
use on
> > > > removable USB devices?
> > >
> > > *Shrug*. Wouldn't really make sense for it to be an ISO, from a
> > > raw FS standpoint. You could have a torrent that just makes
> > > a directory, even.
> >
> > ISOs are convenient from a distribution standpoint just to ensure that
> > things were downloaded correctly[1]. I can see how spending some time
> > to make the "install from a USB device" a little bit easier could
> > definitely have advantages.
>
> Agree. But perhaps it's not an ISO, but just a "usb-disk.cpio"
that's
> 8GB+ (whatever) in size. That could be downloaded and extracted to
> wherever, be it a USB disk or a file server (NFS, etc.).
We support having the ISO being accessed over NFS. And you can loopback
mount for HTTP/FTP. In the interest of our mirrors not hunting me down
and killing me, I'd prefer to have as few different copies of the "same"
bits as possible :-)
Very good point.
So, I'll just keep using the full os/ + updates repo. I think that's the best
solution for both network and hard drive installs when people want the full
distribution.
--
Lamont Peterson <lamont(a)gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
NOTE: All messages from this email address should be digitally signed with my
0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as
well as other keyservers that sync with MIT's.
8:37 p.m.
New subject: Fedora 7 - USB Install method - Everything ISO.
Agree. But perhaps it's not an ISO, but just a
"usb-disk.cpio" that's 8GB+
(whatever) in size. That could be downloaded and extracted to wherever, be
it a USB disk or a file server (NFS, etc.).
The point of an ISO, is you can "dd" it and have a bootable device in
one step. Just an ease of use thing really. Although see comments
below ..
Agreed. For those environments, network installs typically make much
more
sense. Even on my home systems, I do network installs when I can because
it's typically faster and easier than swapping CDs or burning DVDs.
I've often argued about dropping ISOs altogether in favor of just
network installs. That tends to catch of lot of flack from the "I
download at the office and install at home", or, "I live in X where
broad band is too costly" crowds. All of which are valid points I might
add. So if we're making ISOs already, how about one that would be far
more practical than DVD for many people.
With a large ISO for other storage mediums I envisage something like
this :
* Download it.
* "dd" it to device.
* Write my custom kickstart file.
* Go to server / home box / whatever
* Plug in / Boot / Go play with the dogs.
And changing the kickstart file doesn't require more cost (media).
The same could probably be done by just copying the mirror to a
removable device, making it bootable etc, but that's not a currently
documented install method.
However, to set up a network installation with all available
packages, I would
probably just continue to create my own mirror of the released packages and
of the updates repo. But I agree that having a single file to download for
initial setup of such file servers would be advantageous. It could also be
the "roll-your-own-fedora-spin-kit" with all fedora packages + the spin tools
(to build DVD and CD ISOs).
Now here is where I really start to like the idea. I also very much
agree with the point made by Mr Katz when he says "I'd prefer to have as
few different copies of the "same" bits as possible".
If there was a simple tool could download selected packages (and package
groups) from selected repos, and then 'burn' it to a bootable device it
would be the holy grail. It would allow totally flexible/custom builds.
Although it's nothing that can't already be done with a network install
setup, but as discussed that isn't always feasible for people.
Part of 'system-config-kickstart' ?
8:42 p.m.
New subject: Fedora 7 - USB Install method - Everything ISO.
On Tuesday 16 January 2007 21:37, Naoki wrote:
If there was a simple tool could download selected packages (and
package
groups) from selected repos, and then 'burn' it to a bootable device it
would be the holy grail. It would allow totally flexible/custom builds.
Although it's nothing that can't already be done with a network install
setup, but as discussed that isn't always feasible for people.
http://hosted.fedoraproject.org/projects/pungi
--
Jesse Keating
Release Engineer: Fedora
10:35 p.m.
New subject: Fedora 7 - USB Install method - Everything ISO.
On Tue, 2007-01-16 at 21:42 -0500, Jesse Keating wrote:
On Tuesday 16 January 2007 21:37, Naoki wrote:
> If there was a simple tool could download selected packages (and package
> groups) from selected repos, and then 'burn' it to a bootable device it
> would be the holy grail. It would allow totally flexible/custom builds.
> Although it's nothing that can't already be done with a network install
> setup, but as discussed that isn't always feasible for people.
http://hosted.fedoraproject.org/projects/pungi
Aha!! That sounds wonderful :
"We'll need to do five basic tasks:
1) Gather packages from repos into a directory tree
2) Run anaconda tools (buildinstall) on said directory tree
3) Split tree into CD iso size chunks
4) Create isos of the chunks
5) Sanity check the tree"
I'd suggest variable sized ISO chunks rather than CD specific, but I
understand it's pretty much a work in progress.
In the interim though, see any merit in an everything ISO? Or is that
just too big for mirrors and networks to deal with?
By the sounds of things there is an non-documented alternative of grab
mirror, stick on storage device and (somehow) make your own bootable,
installable image that functions like a DVD.
If anybody knows the "somehow" bit I'd love to know and would be happy
to document.
10:54 p.m.
New subject: Fedora 7 - USB Install method - Everything ISO.
On Tuesday 16 January 2007 23:35, Naoki wrote:
I'd suggest variable sized ISO chunks rather than CD specific,
but I
understand it's pretty much a work in progress.
Well, presumably one could make the "CD Size" configurable, so you could ask
for 4gig size "CDs" or whatnot. Right now I think it is hardcoded, but a
sensable patch to make it a semi-hidden option would be acceptable to me.
In the interim though, see any merit in an everything ISO? Or is
that
just too big for mirrors and networks to deal with?
Mostly too big for mirrors, for the little use it would be for.
--
Jesse Keating
Release Engineer: Fedora
11:59 p.m.
New subject: Fedora 7 - USB Install method - Everything ISO.
-----Original Message-----
From: fedora-devel-list-bounces(a)redhat.com [mailto:fedora-devel-list-
bounces(a)redhat.com] On Behalf Of Jesse Keating
Sent: Tuesday, January 16, 2007 9:54 PM
To: fedora-devel-list(a)redhat.com
Subject: Re: Fedora 7 - USB Install method - Everything ISO.
On Tuesday 16 January 2007 23:35, Naoki wrote:
> I'd suggest variable sized ISO chunks rather than CD specific, but I
> understand it's pretty much a work in progress.
Well, presumably one could make the "CD Size" configurable, so you could
ask
for 4gig size "CDs" or whatnot. Right now I think it is hardcoded, but a
sensable patch to make it a semi-hidden option would be acceptable to me.
> In the interim though, see any merit in an everything ISO? Or is that
> just too big for mirrors and networks to deal with?
Mostly too big for mirrors, for the little use it would be for.
--
Jesse Keating
Release Engineer: Fedora
I looked at putting Linux on a USB flash drive and from what I have read
they don't always work. And if you get larger than 1 Gig then you have
problems or have to have multiple partitions. Most things I have read want
to use FAT16 for compatibility. So great idea, just don't think the
hardware is that stable/compatible.
Here is a Knoppix how to http://www.knoppix.net/wiki/Bootable_USB_Key
I would think this would fit better into the Fedora Live CD project.
The only other thought I have is maybe to get around the boot problem is to
use the small boot cd and then do a hard drive install from the usb device.
So you could install on old hardware that doesn't boot from usb and have the
ability to change the content on the usb device.
2:58 a.m.
New subject: Fedora 7 - USB Install method - Everything ISO.
On Tue, 2007-01-16 at 22:59 -0700, Jerry Williams wrote:
> -----Original Message-----
> From: fedora-devel-list-bounces(a)redhat.com [mailto:fedora-devel-list-
> bounces(a)redhat.com] On Behalf Of Jesse Keating
> Sent: Tuesday, January 16, 2007 9:54 PM
> To: fedora-devel-list(a)redhat.com
> Subject: Re: Fedora 7 - USB Install method - Everything ISO.
>
> On Tuesday 16 January 2007 23:35, Naoki wrote:
> > I'd suggest variable sized ISO chunks rather than CD specific, but I
> > understand it's pretty much a work in progress.
>
> Well, presumably one could make the "CD Size" configurable, so you could
> ask
> for 4gig size "CDs" or whatnot. Right now I think it is hardcoded, but a
> sensable patch to make it a semi-hidden option would be acceptable to me.
>
> > In the interim though, see any merit in an everything ISO? Or is that
> > just too big for mirrors and networks to deal with?
>
> Mostly too big for mirrors, for the little use it would be for.
>
> --
> Jesse Keating
> Release Engineer: Fedora
I looked at putting Linux on a USB flash drive and from what I have read
they don't always work. And if you get larger than 1 Gig then you have
problems or have to have multiple partitions. Most things I have read want
to use FAT16 for compatibility. So great idea, just don't think the
hardware is that stable/compatible.
I would somewhat disagree here, there is always the problem with older
BIOSes but since USB boot has been pretty standard for motherboard
manufacturers for a while now that would be a special case, not the
norm. I've been installing windows from USB for a while now so the
hardware is stable (IME). Size also shouldn't be an issue, if the BIOS
can handle 750GB HDDs it can handle 8-16GB on a flash disk.
And the FS is a matter of what the kernel supports. The BIOS is only
interested in boot sectors, not what file system is there.
Here is a Knoppix how to
http://www.knoppix.net/wiki/Bootable_USB_Key
I would think this would fit better into the Fedora Live CD project.
The only other thought I have is maybe to get around the boot problem is to
use the small boot cd and then do a hard drive install from the usb device.
So you could install on old hardware that doesn't boot from usb and have the
ability to change the content on the usb device.
The boot process is the same for anything, be it CD/DVD/HDD/Flash with
the only difference being at the hardware enumeration level. In theory
you can make any device act the same so a boot and install should be
easily possible from USB storage.
We already know we can run an installation from USB, we know we can make
USB rescue disks. But so far it seems there has been no interest in
installing from USB, which is a shame as it's easier and cheaper than
CD/DVD.
If so, I'd like to document and add to the supported list of install
methods.
9:20 a.m.
Once upon a time, Matthew Miller <mattdm(a)mattdm.org> said:
Many of those packages are just going to need to get updated to the
latest
versions over the network eventually. If you've got the bandwidth for
bittorrent, you've got the bandwidth to do a network install.
That makes a big assumption: that they location with bandwidth is the
location being installed.
Even with DSL at home, I often download large things at work (OC3 >>
DSL) and carry them home on DVD (or notebook hard drive).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
9:30 a.m.
On Fri, Jan 05, 2007 at 09:20:36AM -0600, Chris Adams wrote:
Even with DSL at home, I often download large things at work (OC3
>>
DSL) and carry them home on DVD (or notebook hard drive).
Okay, but can't you also decide what you want at work?
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
9:38 a.m.
Matthew Miller wrote:
On Fri, Jan 05, 2007 at 09:20:36AM -0600, Chris Adams wrote:
> Even with DSL at home, I often download large things at work (OC3 >>
> DSL) and carry them home on DVD (or notebook hard drive).
Okay, but can't you also decide what you want at work?
I use the DVD downloaded from work to install both my desktop box and my
server box at home...
Paul.
9:46 a.m.
Once upon a time, Matthew Miller <mattdm(a)mattdm.org> said:
On Fri, Jan 05, 2007 at 09:20:36AM -0600, Chris Adams wrote:
> Even with DSL at home, I often download large things at work (OC3 >>
> DSL) and carry them home on DVD (or notebook hard drive).
Okay, but can't you also decide what you want at work?
I install my computers (server, desktop, notebook) and some family
computers. I also give media to several friends that can't reasonably
download anything (some on dialup, one in Iraq). Each has different
preferences.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
11:08 a.m.
Folks,
Perhaps I missed it - now that "Core" is being dropped, does that mean
that trademark issues with the original open source Fedora project
(www.fedora.info) have now been resolved?
Thanks,
Mike
1:23 p.m.
Matthew Miller <mattdm(a)mattdm.org> wrote:
On Fri, Jan 05, 2007 at 03:16:04PM +0100, dragoran wrote:
> so we need a everything DVD "Fedora 7 Complete"
> mirros can have the iso file and loopback mount it to get the "normal
> tree" saving diskspace. but I doubt that many mirror will do it.
> we could also ship it only over bittorent.
Many of those packages are just going to need to get updated to the
latest
versions over the network eventually. If you've got the bandwidth for
bittorrent,
Yep.
you've got the bandwidth to do a network install.
Nope.
It doesn't matter if getting the image(s) takes a day or so (with a half
dozen network problems requiring restarting the download thrown in just for
fun), it /does/ matter greatly for an install.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
4:09 p.m.
New subject: Fedora 7 (Everything installs)
...... Original Message .......
On Thu, 4 Jan 2007 14:50:32 -0500 "Bill Nottingham" <notting(a)redhat.com>
wrote:
It's time to bite the bullet.
Eliminate the distinction between Core and Extras entirely.
Can we please restore the 'Everything' install package selection that
RHL/FC had for years?
___
Dax Kelson
Sent with my Treo
(please pardon any brevity)
4:27 p.m.
New subject: Fedora 7 (Everything installs)
On Fri, 2007-01-05 at 15:09 -0700, Dax Kelson wrote:
...... Original Message .......
On Thu, 4 Jan 2007 14:50:32 -0500 "Bill Nottingham" <notting(a)redhat.com>
wrote:
>It's time to bite the bullet.
>
>Eliminate the distinction between Core and Extras entirely.
Can we please restore the 'Everything' install package selection that
RHL/FC had for years?
I'm going to bite the bullet here based on *way* too many historical
threads and say, "Um, no." I don't think merging the repos makes any of
the existing reasons for doing away with this selection any less sound.
Refer to countless archives for said reasons, although I'm sure any
sufficiently compelling, *brand-new* reason to put this back in will be
happily debated here. It's not like this thread was long enough already
or anything! ;-D
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Project Board: http://fedoraproject.org/wiki/Board
Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject
4:43 p.m.
New subject: Fedora 7 (Everything installs)
On Fri, 2007-01-05 at 17:27 -0500, Paul W. Frields wrote:
I don't think merging the repos makes any of
the existing reasons for doing away with this selection any less sound.
Of course it does. The major argument bandied about for the removal of
'Everything' was the creation of extras.
It is useful for a variety of situations. Many, many, people have asked
for it back. Now that the merge is happening, let's *restore* the
feature that existed for years.
Dax Kelson
Guru Labs
8:22 p.m.
New subject: Fedora 7 (Everything installs)
On Fri, Jan 05, 2007 at 03:43:58PM -0700, Dax Kelson wrote:
On Fri, 2007-01-05 at 17:27 -0500, Paul W. Frields wrote:
> I don't think merging the repos makes any of
> the existing reasons for doing away with this selection any less sound.
Of course it does. The major argument bandied about for the removal of
'Everything' was the creation of extras.
It is useful for a variety of situations.
Examples?
What problem are you actually trying to solve?
Many, many, people have asked for it back.
That doesn't mean it's the right thing to do.
Many people have asked for all sorts of misguided features.
Thankfully most of the time, sanity has prevailed.
Now that the merge is happening, let's *restore* the
feature that existed for years.
The merge makes the case for not doing it even stronger.
Before it was feasible that someone might not have extras configured,
and might want everything from core.
core+extras today is around 5000 packages iirc. This is only going
to get bigger. How can possibly make sense to install every package
known to man? How do you deal with conflicting packages that want
to do the same thing (like say, binding to a network socket).
How do you navigate a gnome application menu with thousands
of applications? Given a typical install today takes way too long,
an everything install of 5000 packages must be hurrendous.
And god, if people think yum takes too long now, installing
updates for 5000 packages sounds like a world of unfun.
It's a seriously bad idea that makes less sense over time.
Dave
--
http://www.codemonkey.org.uk
8:26 p.m.
New subject: Fedora 7 (Everything installs)
On Fri, Jan 05, 2007 at 09:22:04PM -0500, Dave Jones wrote:
core+extras today is around 5000 packages iirc. This is only going
to get bigger. How can possibly make sense to install every package
known to man?
What makes you think the installation is pointed at a full core+extras
mirror instead of a selected subset? Not everybody is stupid you
know.
OG.
8:40 p.m.
New subject: Fedora 7 (Everything installs)
On Sat, Jan 06, 2007 at 03:26:34AM +0100, Olivier Galibert wrote:
On Fri, Jan 05, 2007 at 09:22:04PM -0500, Dave Jones wrote:
> core+extras today is around 5000 packages iirc. This is only going
> to get bigger. How can possibly make sense to install every package
> known to man?
What makes you think the installation is pointed at a full core+extras
mirror instead of a selected subset? Not everybody is stupid you
know.
I wish I shared your faith in humanity.
Some people _will_ see an everything button and try it on a core+extras dist.
Probably more than the alternative scenario you propose.
A better solution to subsets than using 'everything' would be to
use the same mechanism we'll be using for the server spin
or the kde spin or whatever.
Dave
--
http://www.codemonkey.org.uk
8:49 p.m.
New subject: Fedora 7 (Everything installs)
On Friday 05 January 2007 21:26, Olivier Galibert wrote:
What makes you think the installation is pointed at a full
core+extras
mirror instead of a selected subset? Not everybody is stupid you
know.
Because that's not "everything" and saying it is just puts us back into that
confusing place where everything doesn't mean everything. We don't install
kenrel.i586 kernel.i686 kernel-xen etc... on systems that don't support it. A
yum install \* would do this, and bam, your box won't boot. How fun is that?
Now, when you bring up a selected subset, these spins could be "everything" by
default, as in you're getting the Desktop CD set, it could list all packages
that were targetted for this spin as default (some manditory) and you've
got "everything". Deselect what you don't want.
Will we do this for Fedora Desktop/Server/KDE? Probably not.
--
Jesse Keating
Release Engineer: Fedora
8:50 p.m.
New subject: Fedora 7 (Everything installs)
On Sat, Jan 06, 2007 at 03:26:34AM +0100, Olivier Galibert wrote:
What makes you think the installation is pointed at a full
core+extras
mirror instead of a selected subset? Not everybody is stupid you
know.
But, in what way is that "everything", then? It's not at all!
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
2:11 p.m.
New subject: Fedora 7 (Everything installs)
On 1/5/07, Olivier Galibert <galibert(a)pobox.com> wrote:
On Fri, Jan 05, 2007 at 09:22:04PM -0500, Dave Jones wrote:
> core+extras today is around 5000 packages iirc. This is only going
> to get bigger. How can possibly make sense to install every package
> known to man?
What makes you think the installation is pointed at a full core+extras
mirror instead of a selected subset? Not everybody is stupid you
know.
To be honest, because people (myself included) are morons. We are sure
that we are being gipped by the packagers and unless we have it ALL we
may be missing some secret tool, item that they are keeping away from
us. [God the number of bugs we used to get on "I clicked on
Everything and found out that it didnt install all the files because
of my language choice. This is a stop critical bug!"]
80% of the people who opened tickets during 7 did everything installs
when asked. The problems they had were mostly due to having everything
installed (running out disk, wondering why tux was conflicting with
httpd (or something like that).
--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
1:33 a.m.
New subject: Fedora 7 (Everything installs)
On 1/6/07, Dave Jones <davej(a)redhat.com> wrote:
That doesn't mean it's the right thing to do.
Many people have asked for all sorts of misguided features.
Thankfully most of the time, sanity has prevailed.
> Now that the merge is happening, let's *restore* the
> feature that existed for years.
The merge makes the case for not doing it even stronger.
Before it was feasible that someone might not have extras configured,
and might want everything from core.
core+extras today is around 5000 packages iirc. This is only going
to get bigger. How can possibly make sense to install every package
known to man? How do you deal with conflicting packages that want
to do the same thing (like say, binding to a network socket).
How do you navigate a gnome application menu with thousands
of applications? Given a typical install today takes way too long,
an everything install of 5000 packages must be hurrendous.
And god, if people think yum takes too long now, installing
updates for 5000 packages sounds like a world of unfun.
It's a seriously bad idea that makes less sense over time.
Completely agree with you !
--
http://vnoss.org
2:05 p.m.
New subject: Fedora 7 (Everything installs)
On 1/5/07, Dave Jones <davej(a)redhat.com> wrote:
On Fri, Jan 05, 2007 at 03:43:58PM -0700, Dax Kelson wrote:
> On Fri, 2007-01-05 at 17:27 -0500, Paul W. Frields wrote:
> > I don't think merging the repos makes any of
> > the existing reasons for doing away with this selection any less sound.
>
> Of course it does. The major argument bandied about for the removal of
> 'Everything' was the creation of extras.
>
> It is useful for a variety of situations.
Examples?
What problem are you actually trying to solve?
> Many, many, people have asked for it back.
That doesn't mean it's the right thing to do.
Many people have asked for all sorts of misguided features.
Thankfully most of the time, sanity has prevailed.
Yes, one of the most requested items we got after 5.0 was "Could you
make it so passwords were not needed for root default?" this later
morphed into "Please make it so that anyone can run anything by
default" ... and the routine that someone wanted us to have so that if
you pinged a port it would reset all the passwords on the system.
"Great for our ISP to manage boxes when the owner has locked himself
out."
--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
2:53 p.m.
New subject: Fedora 7 (Everything installs)
Dax Kelson wrote:
On Fri, 2007-01-05 at 17:27 -0500, Paul W. Frields wrote:
> I don't think merging the repos makes any of
> the existing reasons for doing away with this selection any less sound.
Of course it does. The major argument bandied about for the removal of
'Everything' was the creation of extras.
It was more about anaconda supporting installations from any number of
yum repositories.
As stated many many many times in the past, Everything cannot be defined
when we allow people to install from an arbitrary number of repositories.
And if we did install everything we found (and assuming the backend
didn't crash when resolving dependencies), people would complain that
the install took too long.
It is useful for a variety of situations. Many, many, people have
asked
for it back. Now that the merge is happening, let's *restore* the
feature that existed for years.
Of all of the complaints that have come in just in the past year
regarding the removal of the Everything install, only *one* was
reasonable, IMHO. And solving that was a matter of educating the user
on how to set up kickstart to provision systems (and we still support
Everything installs via kickstart using '*' under %packages). In their
case, systems were provisioned and then carried in to a secure DoD
research environment without any Internet connectivity. They wanted to
set up the systems with everything installed up front and not have to
install later since they _couldn't_ do that.
My solution was to set up kickstart to do a normal install, mirror all
the packages to the /var/cache/yum tree and then let them use yum later
on if they need to install things. It worked well.
--
David Cantrell
Red Hat / Westford, MA
3:12 p.m.
New subject: Fedora 7 (Everything installs)
On 1/6/07, David Cantrell <dcantrell(a)redhat.com> wrote:
Of all of the complaints that have come in just in the past year
regarding the removal of the Everything install, only *one* was
reasonable, IMHO. And solving that was a matter of educating the user
on how to set up kickstart to provision systems (and we still support
Everything installs via kickstart using '*' under %packages).
+1
How do we do this for the Fedora community in general? How do we
effectively educate people concerning the use of kickstart, so they
will be willing to reach for kickstart as a solution for legitimate
niche install scenarios? Do we need to start compiling well commented
examples of useful kickstart files into the wiki and point to them
from the release notes? What will it take to get people stop looking
for the UI to be encumbered with unnecessary flexibility and to have
them start reaching for kickstart to be the flexible solution that it
was meant to be?
-jef
6:50 p.m.
New subject: Fedora 7 (Everything installs)
On Sat, Jan 06, 2007 at 12:12:42PM -0900, Jeff Spaleta wrote:
On 1/6/07, David Cantrell <dcantrell(a)redhat.com> wrote:
>Of all of the complaints that have come in just in the past year
>regarding the removal of the Everything install, only *one* was
>reasonable, IMHO. And solving that was a matter of educating the user
>on how to set up kickstart to provision systems (and we still support
>Everything installs via kickstart using '*' under %packages).
+1
How do we do this for the Fedora community in general? How do we
effectively educate people concerning the use of kickstart, so they
will be willing to reach for kickstart as a solution for legitimate
niche install scenarios? Do we need to start compiling well commented
examples of useful kickstart files into the wiki and point to them
from the release notes? What will it take to get people stop looking
for the UI to be encumbered with unnecessary flexibility and to have
them start reaching for kickstart to be the flexible solution that it
was meant to be?
Ok, I burn a standard fedora iso, I boot on it, please do tell me
where is the command line or whatever I can use to input kickstart
commands.
Why do you have any package choices in anaconda anyway? You can do it
all after the install, isn't it? If what you people want is a minimal
install that only gives a reliable network and/or cdrom afterwards and
have the real install being done after having booted on it, just do
it. But stop pussyfooting around. Make a damn decision.
OG.
11:58 p.m.
New subject: Fedora 7 (Everything installs)
On 1/7/07, Olivier Galibert <galibert(a)pobox.com> wrote:
Ok, I burn a standard fedora iso, I boot on it, please do tell me
where is the command line or whatever I can use to input kickstart
commands.
Have a look at:
http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/ch-kic...
HTH
--
http://vnoss.org
7:53 a.m.
New subject: Fedora 7 (Everything installs)
On Sun, Jan 07, 2007 at 06:58:58AM +0100, Vnpenguin wrote:
On 1/7/07, Olivier Galibert <galibert(a)pobox.com> wrote:
>
>Ok, I burn a standard fedora iso, I boot on it, please do tell me
>where is the command line or whatever I can use to input kickstart
>commands.
>
Have a look at:
http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/ch-kic...
HTH
No it doesn't, sorry. Please re-read what you quoted, and realize
that I do know about kickstart. AFAIK, you can't give any kickstart
commands when you're doing a cdrom install using a standard fedora
iso.
OG.
7:57 a.m.
New subject: Fedora 7 (Everything installs)
Olivier Galibert wrote:
No it doesn't, sorry. Please re-read what you quoted, and
realize
that I do know about kickstart. AFAIK, you can't give any kickstart
commands when you're doing a cdrom install using a standard fedora
iso.
The whole point of kickstart is to *automate* that steps so you dont
have to do a standard installation or click any buttons.
Rahul
8:53 a.m.
New subject: Fedora 7 (Everything installs)
On 1/7/07, Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
Olivier Galibert wrote:
> No it doesn't, sorry. Please re-read what you quoted, and realize
> that I do know about kickstart. AFAIK, you can't give any kickstart
> commands when you're doing a cdrom install using a standard fedora
> iso.
The whole point of kickstart is to *automate* that steps so you dont
have to do a standard installation or click any buttons.
I use kickstart with "interactive" option. So all selections were
defined as defaults. I could "click" without any problem to change any
value.
--
http://vnoss.org
11:50 a.m.
New subject: Fedora 7 (Everything installs)
On Sunday 07 January 2007 08:53, Olivier Galibert wrote:
No it doesn't, sorry. Please re-read what you quoted, and
realize
that I do know about kickstart. AFAIK, you can't give any kickstart
commands when you're doing a cdrom install using a standard fedora
iso.
You can with a remote kickstart file or a file on a floppy, or (do we support
ks on a USB stick yet?)
--
Jesse Keating
Release Engineer: Fedora
12:14 p.m.
New subject: Fedora 7 (Everything installs)
On Sun, Jan 07, 2007 at 12:50:15PM -0500, Jesse Keating wrote:
You can with a remote kickstart file or a file on a floppy, or (do we
support
ks on a USB stick yet?)
I don't know if you support it, but I've already used this with RHEL4 ;-).
--
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
1:50 p.m.
New subject: Fedora 7 (Everything installs)
On 1/7/07, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
On 1/7/07, Jesse Keating <jkeating(a)redhat.com> wrote:
> You can with a remote kickstart file or a file on a floppy, or (do we support
> ks on a USB stick yet?)
computers still come with floppy drives?
Yeah, my box (which runs FC1..FC6) has one and it works well :)
Sorry for OT,
--
http://vnoss.org
2:11 p.m.
New subject: Fedora 7 (Everything installs)
On Sunday 07 January 2007 14:14, Jeff Spaleta wrote:
On 1/7/07, Jesse Keating <jkeating(a)redhat.com> wrote:
> You can with a remote kickstart file or a file on a floppy, or (do we
> support ks on a USB stick yet?)
computers still come with floppy drives?
Some do, there are USB floppies too.
I wouldn't be opposed to having a set of kickstart config files on the isos
too, interactive of course, but I'll wait for those to be submitted.
--
Jesse Keating
Release Engineer: Fedora
2:24 p.m.
New subject: Fedora 7 (Everything installs)
Once upon a time Sunday 07 January 2007 2:11 pm, Jesse Keating wrote:
On Sunday 07 January 2007 14:14, Jeff Spaleta wrote:
> On 1/7/07, Jesse Keating <jkeating(a)redhat.com> wrote:
> > You can with a remote kickstart file or a file on a floppy, or (do we
> > support ks on a USB stick yet?)
>
> computers still come with floppy drives?
Some do, there are USB floppies too.
I wouldn't be opposed to having a set of kickstart config files on the isos
too, interactive of course, but I'll wait for those to be submitted.
What would be nice for kickstart files on iso's namely DVD iso is pre-defined
installs for postfix mail server, sendmail mail server, mysql database
server , postgresql server etc. Ones that install a predefined set of
packages. but have the user set partitioning, root password etc.
2:32 p.m.
New subject: Fedora 7 (Everything installs)
On Sunday 07 January 2007 15:24, Dennis Gilmore wrote:
What would be nice for kickstart files on iso's namely DVD iso
is
pre-defined installs for postfix mail server, sendmail mail server, mysql
database server , postgresql server etc. Ones that install a
predefined set of packages. but have the user set partitioning, root
password etc.
Well, one could have different comps files used based upon which option you
select, so if you select a mailserver in anaconda, it would use the comps
file for that which has the right stuff mandatory/default. Something to
think about for say F8.
--
Jesse Keating
Release Engineer: Fedora
12:03 p.m.
New subject: Fedora 7 (Everything installs)
On Sun, 2007-01-07 at 15:32 -0500, Jesse Keating wrote:
On Sunday 07 January 2007 15:24, Dennis Gilmore wrote:
> What would be nice for kickstart files on iso's namely DVD iso is
> pre-defined installs for postfix mail server, sendmail mail server, mysql
> database server , postgresql server etc. Ones that install a
> predefined set of packages. but have the user set partitioning, root
> password etc.
Well, one could have different comps files used based upon which option you
select, so if you select a mailserver in anaconda, it would use the comps
file for that which has the right stuff mandatory/default. Something to
think about for say F8.
Why would you need different comps files ? Wouldn't it be enough to have
separate 'sendmail mailserver' and 'postfix mailserver' groups ?
In general, I am not convinced that basing this on tools that are mainly
meant for interactive use (like comps) is really all that useful in the
server world - what we want is something like kickstart, but with a
clean separation between the stuff that is site-independent (e.g. which
packages go on a postfix mailserver) and the stuff that is very site
dependent (storage setup, authentication, backup, ...)
For servers, you quickly get into questions that are more config mgmt
questions than install/provisioning questions. Either way, having a good
list of the most popular server setups and/or package lists for them
would be a very good start.
David
3:11 p.m.
New subject: Fedora 7 (Everything installs)
On 1/7/07, Dennis Gilmore <dennis(a)ausil.us> wrote:
What would be nice for kickstart files on iso's namely DVD iso
is pre-defined
installs for postfix mail server, sendmail mail server, mysql database
server , postgresql server etc. Ones that install a predefined set of
packages. but have the user set partitioning, root password etc.
I think its time to start compiling a selection of contributed
kickstart files, so they can be gone over and culled into a group that
can be considered for inclusion into iso images or prettied up for
consumption from the wiki as standard reference kickstart scenarios.
Who has semi-useful kickstart files they can drop into the wiki with a
short description of the situation you use it for?
-jef
12:10 p.m.
New subject: Fedora 7 (Everything installs)
On Sun, 2007-01-07 at 14:24 -0600, Dennis Gilmore wrote:
Once upon a time Sunday 07 January 2007 2:11 pm, Jesse Keating
wrote:
> On Sunday 07 January 2007 14:14, Jeff Spaleta wrote:
> > On 1/7/07, Jesse Keating <jkeating(a)redhat.com> wrote:
> > > You can with a remote kickstart file or a file on a floppy, or (do we
> > > support ks on a USB stick yet?)
> >
> > computers still come with floppy drives?
>
> Some do, there are USB floppies too.
>
> I wouldn't be opposed to having a set of kickstart config files on the isos
> too, interactive of course, but I'll wait for those to be submitted.
What would be nice for kickstart files on iso's namely DVD iso is pre-defined
installs for postfix mail server, sendmail mail server, mysql database
server , postgresql server etc. Ones that install a predefined set of
packages. but have the user set partitioning, root password etc.
That I think is where a Ferdora Server spin would add a lot of value: if
it came with the tools that are necessary to set up various 'server
personalities' (for lack of a better word)
There's a good amount of overlap with this idea and the 'virtual
appliances' that everybody likes these days. From a sysadmin's point of
view, the two should be very similar.
David
7:22 p.m.
New subject: Fedora 7 (Everything installs)
On Sat, Jan 06, 2007 at 12:12:42PM -0900, Jeff Spaleta wrote:
niche install scenarios? Do we need to start compiling well
commented
examples of useful kickstart files into the wiki and point to them
from the release notes? What will it take to get people stop looking
Put them on the install CDs.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
1:20 p.m.
New subject: Fedora 7 (Everything installs)
On Sat, 2007-01-06 at 20:22 -0500, Matthew Miller wrote:
On Sat, Jan 06, 2007 at 12:12:42PM -0900, Jeff Spaleta wrote:
> niche install scenarios? Do we need to start compiling well commented
> examples of useful kickstart files into the wiki and point to them
> from the release notes? What will it take to get people stop looking
Put them on the install CDs.
A good collection would be useful for other purposes, too, e.g. for
cobbler[1] or prm[2] - basically, what everybody wants is answers to
common setup/config questions that can be consumed by tools. A
collection of kickstart files would definitely be a good first step
towards that.
David
[1] http://cobbler.et.redhat.com/
[2] http://et.redhat.com/emd/prm/
1:35 p.m.
New subject: Fedora 7 (Everything installs)
On 1/8/07, David Lutterkort <dlutter(a)redhat.com> wrote:
A good collection would be useful for other purposes, too, e.g. for
cobbler[1] or prm[2] - basically, what everybody wants is answers to
common setup/config questions that can be consumed by tools. A
collection of kickstart files would definitely be a good first step
towards that.
Do you have any kickstart files on hand we can use as a starting
putting for a raw collection?
-jef
4:32 p.m.
New subject: Fedora 7 (Everything installs)
On Fri, 2007-01-05 at 15:09 -0700, Dax Kelson wrote:
...... Original Message .......
On Thu, 4 Jan 2007 14:50:32 -0500 "Bill Nottingham" <notting(a)redhat.com>
wrote:
>It's time to bite the bullet.
>
>Eliminate the distinction between Core and Extras entirely.
Can we please restore the 'Everything' install package selection that
RHL/FC had for years?
While an "everything" install may have made some sense in the pre-Extras
days, it's just silly now. There are so many packages in Core+Extras,
many of which duplicate functionality. I mean you'll get at least three
SMTP servers (sendmail, exim, postfix), probably four or five window
managers/desktop environments, and who knows what else.
Jeff
4:43 p.m.
New subject: Fedora 7 (Everything installs)
Jeffrey C. Ollie <jeff(a)ocjtech.us>:
While an "everything" install may have made some sense in
the pre-Extras
days, it's just silly now. There are so many packages in Core+Extras,
many of which duplicate functionality.
Nebvertheless, there are real uses for "install everything". Notably,
one can be working tools that are designed to audit the entire distribution.
When I test doclifter, I want the largest possible corpus of man pages to
work on.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
8:51 p.m.
New subject: Fedora 7 (Everything installs)
On Fri, Jan 05, 2007 at 05:43:31PM -0500, Eric S. Raymond wrote:
Nebvertheless, there are real uses for "install
everything". Notably,
one can be working tools that are designed to audit the entire distribution.
When I test doclifter, I want the largest possible corpus of man pages to
work on.
That's what "yum install '*'" is for.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
2:36 a.m.
New subject: Fedora 7 (Everything installs)
Eric S. Raymond wrote:
Jeffrey C. Ollie <jeff(a)ocjtech.us>:
> While an "everything" install may have made some sense in the pre-Extras
> days, it's just silly now. There are so many packages in Core+Extras,
> many of which duplicate functionality.
Nebvertheless, there are real uses for "install everything". Notably,
one can be working tools that are designed to audit the entire distribution.
When I test doclifter, I want the largest possible corpus of man pages to
work on.
There are easy ways to do this with yum or kickstart even now.
Rahul
4:55 p.m.
New subject: Fedora 7 (Everything installs)
On Fri, 2007-01-05 at 16:32 -0600, Jeffrey C. Ollie wrote:
While an "everything" install may have made some sense in
the pre-Extras
days, it's just silly now. There are so many packages in Core+Extras,
many of which duplicate functionality. I mean you'll get at least three
SMTP servers (sendmail, exim, postfix), probably four or five window
managers/desktop environments, and who knows what else.
Jeff
I disagree. Just because you can't envision a use for it doesn't mean
that others cant.
The alternatives system deployed in RHL ages ago (1999) so that you can
have multiple "conflicting' packages installed at the same time.
For a "production" box that is performing some defined task(s), I agree
that "everything" is a bad idea.
For a "power user"/developer/consultant/helpdesk box, I don't see any
problem with an "everything" install. Hard disk space is cheap and
plentiful (note that 1TB drives were announced yesterday).
There are numerous situations where an application dynamically gets
extra functionality and features if other *addon* or *plugin* packages
get installed.
Dax Kelson
Guru Labs
4:50 p.m.
New subject: Fedora 7 (Everything installs)
On Friday 05 January 2007 16:09, Dax Kelson wrote:
...... Original Message .......
On Thu, 4 Jan 2007 14:50:32 -0500 "Bill Nottingham" <notting(a)redhat.com>
wrote:
>It's time to bite the bullet.
>
>Eliminate the distinction between Core and Extras entirely.
Can we please restore the 'Everything' install package selection that
RHL/FC had for years?
You really want over 3500 packages on your system? and
even if you could
have that its not possible some packages are mutually exclusive
--
,-._|\ Dennis Gilmore, RHCE
/Aussie\ Proud Australian
\_.--._/ | Aurora | Fedora |
v
5:09 p.m.
New subject: Fedora 7 (Everything installs)
On Fri, 2007-01-05 at 16:50 -0600, Dennis Gilmore wrote:
"even if you could have that its not possible some packages are
mutually exclusive."
Sendmail and Postfix both have "/sbin/sendmail", but you can have them
both installed at the same time.
Any mutually exclusive cases should be considered a bug(1). See
update-alternatives(8).
Dax Kelson
Guru Labs
(1) A class of bug that RHL/FC did without for 15 years or so because
Everything installs existed.
5:22 p.m.
New subject: Fedora 7 (Everything installs)
On Fri, Jan 05, 2007 at 03:09:34PM -0700, Dax Kelson wrote:
>
>Eliminate the distinction between Core and Extras entirely.
Can we please restore the 'Everything' install package selection that
RHL/FC had for years?
Doesn't this boil down to running 'yum install \*' just
after installation ?
Emmanuel
5:57 p.m.
New subject: Fedora 7 (Everything installs)
On 1/5/07, Emmanuel Seyman <emmanuel.seyman(a)club-internet.fr> wrote:
On Fri, Jan 05, 2007 at 03:09:34PM -0700, Dax Kelson wrote:
> >
> >Eliminate the distinction between Core and Extras entirely.
>
> Can we please restore the 'Everything' install package selection that
> RHL/FC had for years?
Doesn't this boil down to running 'yum install \*' just
after installation ?
I would suspect so. Your machine might explode soon after though :]
yum install \*.i386
and/or
yum install \*.`uname -m`
might make it explode less.
It is simple to do this once you have a net connection.
For those people who want "install everything" on removable media I am
wondering what removable media they are going to store "everything"
on?
Maybe a compomise would be to have an option to "install everything
available on media". That makes more sense than a straight "install
everything" in this yum-enabled-anaconda world. Kinda.
/Mike
2:21 a.m.
New subject: Fedora 7 (Everything installs)
Dax Kelson wrote:
...... Original Message .......
On Thu, 4 Jan 2007 14:50:32 -0500 "Bill Nottingham" <notting(a)redhat.com>
wrote:
> It's time to bite the bullet.
>
> Eliminate the distinction between Core and Extras entirely.
Can we please restore the 'Everything' install package selection that
RHL/FC had for years?
For which release? Server, GNOME, KDE? Tell us more details.
Rahul
9:09 p.m.
At 2:50 PM -0500 1/4/07, Bill Nottingham wrote:
Hence, Fedora 7. Name TBD, but probably not 'Bride of Zod'.
How about "Corson, the demon child of the unholy marriage of Core and
Extras"? (Google "corson" and feel lucky.)
--
____________________________________________________________________
TonyN.:' <mailto:tonynelson@georgeanelson.com>
' <http://www.georgeanelson.com/>
9:47 a.m.
Bill Nottingham wrote:
[...]
- Modify the build system to support this new paradigm
- Merge Core and Extras in source control
- Use the new pungi tool to spin all releases
- A Fedora Desktop spin
- A Fedora Server spin
- A Fedora KDE spin
- Make LiveCDs as a part of the distribution release process
- Ability to customize non-packaging distrubution parameters
- Switch to libata drivers for PATA support
- Speedup of bootup and shutdown
- Make wireless rock-solid
- Add wireless firmware for all the chipsets we can
- CodecBuddy
- Fixing the proliferation of dictionary packages
- Support encrypted filesystems
- Fast user switching in the desktop
- Fix the firewire stack
- Switch to a tickless kernel by default
- Fix unnecessary wakeups across the distribution
- Add KVM virtualization support to our tools
- Investigate (but probably don't switch to) new init technologies
- Add the nouveau drivers for nVidia cards
- Speed up Yum and RPM
- Add support for RandR 1.2
- Switch to syslog-ng
- Make the update system useable by all
can we add this to the list:
make yum/pirut able to install software from media (cd/dvd) ?
This was on the TODO list since FC5 is out and its still not fixed
I know that this works by setting up a local repo but this isn't really
a option (for new users) and requiring a broadband connection to install
software will let some users switch to <insertdistrowiththisfeature> or
even back to windows.
11:35 a.m.
On Sat, 2007-01-06 at 16:47 +0100, dragoran wrote:
can we add this to the list:
make yum/pirut able to install software from media (cd/dvd) ?
This was on the TODO list since FC5 is out and its still not fixed
I know that this works by setting up a local repo but this isn't really
a option (for new users) and requiring a broadband connection to install
software will let some users switch to <insertdistrowiththisfeature> or
even back to windows.
It's one of the big-ish things I'm hoping to get done; I have the start
of poking some infrastructure down into yum lying around from right
after Thanksgiving, I need to just flesh it out and send a proposal to
yum-devel on how it should work. I'll try to add it to the wiki list
later today. Of course, that depends on if I ever finish reading my
mail ;-)
Jeremy
5:47 a.m.
On 1/4/07, Bill Nottingham <notting(a)redhat.com> wrote:
- A Fedora Desktop spin
- A Fedora Server spin
- A Fedora KDE spin
Two things here:
1) Is there going to be further effort towards a minimalistic install
as official release option? I seem to here/see people asking for a 1-2
CD media install option (as in they can safely download only the first
two cd isos and get a Fedora install up)
2) The Desktop Environment catch 22 seems to be continuing: KDE gets
less love since the measurable KDE using community is small, while the
measurable KDE community is small since those who heavily use KDE go
elsewhere to get their KDE fix (Kubuntu, SuSe). And with the recent
bad press, there may be a few who would like another distro to use KDE
on.
Might also mention (for no particular reason) that I actually like the
fact that the system-config tools are in Gtk and look different from
my desktop (Qt) application
- Make LiveCDs as a part of the distribution release process
Any insight if these LiveCDs will be an adequate replacement for a Knoppix CD?
- Speedup of bootup and shutdown
I've never worried about this too much, but i suppose that would be nice.
- Add wireless firmware for all the chipsets we can
I would be just happy for a way of reliably knowing that I even need a
code - as opposed to modules (drivers) just failing to work.
- Fixing the proliferation of dictionary packages
This is a Linux wide need
I vote for keeping Fedora 7 unreleased till at least 90% of these
features are implemented, they seem to be worth the wait.
--
Fedora Core 6 and proud
11:55 a.m.
On Sunday 07 January 2007 06:47, Arthur Pemberton wrote:
Two things here:
1) Is there going to be further effort towards a minimalistic install
as official release option? I seem to here/see people asking for a 1-2
CD media install option (as in they can safely download only the first
two cd isos and get a Fedora install up)
Yes, one, two CDs are the size mark for these spins. Without X we could get
really small with the Server spin, but we'll see where we go.
2) The Desktop Environment catch 22 seems to be continuing: KDE gets
less love since the measurable KDE using community is small, while the
measurable KDE community is small since those who heavily use KDE go
elsewhere to get their KDE fix (Kubuntu, SuSe). And with the recent
bad press, there may be a few who would like another distro to use KDE
on.
So how does 'Fedora KDE' vs 'Fedora Desktop' differ from 'Ubuntu'
vs 'Kubuntu' ? We don't even force a different project name.
Might also mention (for no particular reason) that I actually like
the
fact that the system-config tools are in Gtk and look different from
my desktop (Qt) application
> - Make LiveCDs as a part of the distribution release process
Any insight if these LiveCDs will be an adequate replacement for a Knoppix
CD?
We hope so. We'd like it to be even better than the Ubuntu live CD.
--
Jesse Keating
Release Engineer: Fedora
2:01 p.m.
On 1/8/07, Jesse Keating <jkeating(a)redhat.com> wrote:
On Sunday 07 January 2007 06:47, Arthur Pemberton wrote:
> Two things here:
>
> 1) Is there going to be further effort towards a minimalistic install
> as official release option? I seem to here/see people asking for a 1-2
> CD media install option (as in they can safely download only the first
> two cd isos and get a Fedora install up)
Yes, one, two CDs are the size mark for these spins. Without X we could get
really small with the Server spin, but we'll see where we go.
For a server cd, I don't mind doing yum install xorg and xfce is
necessary post install, however. That brings up the other point where
I notice that a lot of usefule/semi useful commands have no man pages.
(I guess I should take the initiative and at least writeup a script to
search these apps up) one example would be lshal (recently found out
about it)
[ snip ]
> > - Make LiveCDs as a part of the distribution release
process
>
> Any insight if these LiveCDs will be an adequate replacement for a Knoppix
> CD?
We hope so. We'd like it to be even better than the Ubuntu live CD.
The only live CD I'm familiar with is Knoppix, but I'll assume from
your comment that the Ubuntu live CD is as good or better.
--
Jesse Keating
Release Engineer: Fedora
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Fedora Core 6 and proud
2:33 p.m.
On Sunday 07 January 2007 15:01, Arthur Pemberton wrote:
For a server cd, I don't mind doing yum install xorg and xfce is
necessary post install, however. That brings up the other point where
I notice that a lot of usefule/semi useful commands have no man pages.
(I guess I should take the initiative and at least writeup a script to
search these apps up) one example would be lshal (recently found out
about it)
Well, I think we should still include the xorg libs, so that one could run the
gui system config tools over ssh.
--
Jesse Keating
Release Engineer: Fedora
2:09 p.m.
On 1/8/07, Jesse Keating <jkeating(a)redhat.com> wrote:
On Sunday 07 January 2007 06:47, Arthur Pemberton wrote:
[ snip ]
> 2) The Desktop Environment catch 22 seems to be continuing: KDE
gets
> less love since the measurable KDE using community is small, while the
> measurable KDE community is small since those who heavily use KDE go
> elsewhere to get their KDE fix (Kubuntu, SuSe). And with the recent
> bad press, there may be a few who would like another distro to use KDE
> on.
So how does 'Fedora KDE' vs 'Fedora Desktop' differ from
'Ubuntu'
vs 'Kubuntu' ? We don't even force a different project name.
I don't know... I am/was trying to consider things from those who see
this as a problem. Write now the lack of KDE in the name isn't
preventing me from using Fedora. But from reading around the internet,
it seems a non-ignorable percentage simply do not consider Fedora when
looking for a distro to use KDE on - while it is obviously not really
a popularity content, more users don't add that much more load to a
project (I would think) while with more users, more helpers should
come - there by spreading the work and love around.
--
Fedora Core 6 and proud
12:06 p.m.
On 1/7/07, Arthur Pemberton <pemboa(a)gmail.com> wrote:
2) The Desktop Environment catch 22 seems to be continuing: KDE gets
less love since the measurable KDE using community is small, while the
measurable KDE community is small since those who heavily use KDE go
elsewhere to get their KDE fix (Kubuntu, SuSe). And with the recent
bad press, there may be a few who would like another distro to use KDE
on.
Hmm I guess you are wrong here
knowing the fact there aren't many statistics to prove me wrong, there
are a lot of Fedora KDE users around than you can imagine. If there
are many leaving fedora kde for something, It might be because fedora
doesn't love much kde and work needs to be here!
To be honest, as a fedora ambassador, I see 3 of 5 fedora installs are
KDE installs.
Chitlesh
--
http://clunixchit.blogspot.com
6:10 a.m.
On 1/4/07, Bill Nottingham <notting(a)redhat.com> wrote:
And, what would a release be without features. We've identified
28 features that we'd like to include in the release, available
at http://fedoraproject.org/wiki/Releases/7/Features:
Two more things:
1) Is there any plan to have some sort of Fedora recommends hardware
of manufacturer X,Y,Z? I'm not thinking of hardware certification,
just recommendations. I think this would be very beneficial.
2) I haven't heard much of Python 2.5 for Fedora 7. Comments would be
appreciated.
--
Fedora Core 6 and proud
6:55 a.m.
Arthur Pemberton wrote:
On 1/4/07, Bill Nottingham <notting(a)redhat.com> wrote:
> And, what would a release be without features. We've identified
> 28 features that we'd like to include in the release, available
> at http://fedoraproject.org/wiki/Releases/7/Features:
Two more things:
1) Is there any plan to have some sort of Fedora recommends hardware
of manufacturer X,Y,Z? I'm not thinking of hardware certification,
just recommendations. I think this would be very beneficial.
we should create some sort of hw db where people can check which hw is
supported by fedora and which not
2) I haven't heard much of Python 2.5 for Fedora 7. Comments
would be
appreciated.
its in rawhide so it should be in F7
6:54 a.m.
dragoran wrote:
Arthur Pemberton wrote:
> On 1/4/07, Bill Nottingham <notting(a)redhat.com> wrote:
>> And, what would a release be without features. We've identified
>> 28 features that we'd like to include in the release, available
>> at http://fedoraproject.org/wiki/Releases/7/Features:
>
> Two more things:
>
> 1) Is there any plan to have some sort of Fedora recommends hardware
> of manufacturer X,Y,Z? I'm not thinking of hardware certification,
> just recommendations. I think this would be very beneficial.
>
we should create some sort of hw db where people can check which hw is
supported by fedora and which not
See http://fedoraproject.org/wiki/MikeMcGrath/HardwareProfiler
Rahul
2:04 p.m.
On 1/8/07, dragoran <drago01(a)gmail.com> wrote:
Arthur Pemberton wrote:
> On 1/4/07, Bill Nottingham <notting(a)redhat.com> wrote:
>> And, what would a release be without features. We've identified
>> 28 features that we'd like to include in the release, available
>> at http://fedoraproject.org/wiki/Releases/7/Features:
>
> Two more things:
>
> 1) Is there any plan to have some sort of Fedora recommends hardware
> of manufacturer X,Y,Z? I'm not thinking of hardware certification,
> just recommendations. I think this would be very beneficial.
>
we should create some sort of hw db where people can check which hw is
supported by fedora and which not
That's great. I don't even ask for the word 'support' to be used, I
would be happy with:
* works with clean fedora (no binary blob drivers or firmware required)
* works with non fedora worthy firmware
* works in Linux, but not Fedora ready (or clean enough)
* no idea
* doesn't work
> 2) I haven't heard much of Python 2.5 for Fedora 7. Comments
would be
> appreciated.
>
its in rawhide so it should be in F7
--
Fedora Core 6 and proud
5:35 p.m.
Arthur Pemberton <pemboa(a)gmail.com> wrote:
On 1/8/07, dragoran <drago01(a)gmail.com> wrote:
> Arthur Pemberton wrote:
> > On 1/4/07, Bill Nottingham <notting(a)redhat.com> wrote:
> >> And, what would a release be without features. We've identified
> >> 28 features that we'd like to include in the release, available
> >> at http://fedoraproject.org/wiki/Releases/7/Features:
> >
> > Two more things:
> >
> > 1) Is there any plan to have some sort of Fedora recommends hardware
> > of manufacturer X,Y,Z? I'm not thinking of hardware certification,
> > just recommendations. I think this would be very beneficial.
> >
> we should create some sort of hw db where people can check which hw is
> supported by fedora and which not
That's great. I don't even ask for the word 'support'
to be used, I
would be happy with:
* works with clean fedora (no binary blob drivers or firmware required)
* works with non fedora worthy firmware
* works in Linux, but not Fedora ready (or clean enough)
* no idea
* doesn't work
Who would compile and keep this up to date? Have you any idea of how many
brands and models of different pieces are around?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
10:37 p.m.
On 1/8/07, Horst H. von Brand <vonbrand(a)inf.utfsm.cl> wrote:
Arthur Pemberton <pemboa(a)gmail.com> wrote:
> On 1/8/07, dragoran <drago01(a)gmail.com> wrote:
> > Arthur Pemberton wrote:
> > > On 1/4/07, Bill Nottingham <notting(a)redhat.com> wrote:
> > >> And, what would a release be without features. We've identified
> > >> 28 features that we'd like to include in the release, available
> > >> at http://fedoraproject.org/wiki/Releases/7/Features:
> > >
> > > Two more things:
> > >
> > > 1) Is there any plan to have some sort of Fedora recommends hardware
> > > of manufacturer X,Y,Z? I'm not thinking of hardware certification,
> > > just recommendations. I think this would be very beneficial.
> > >
> > we should create some sort of hw db where people can check which hw is
> > supported by fedora and which not
> That's great. I don't even ask for the word 'support' to be used, I
> would be happy with:
>
> * works with clean fedora (no binary blob drivers or firmware required)
> * works with non fedora worthy firmware
> * works in Linux, but not Fedora ready (or clean enough)
> * no idea
> * doesn't work
Who would compile and keep this up to date? Have you any idea of how many
brands and models of different pieces are around?
The community would. For example:
1) I install F7
2) My tv card works immediately without any additional drivers
3) I pull the card info from available sources
4) I add it to the db if it isn't already there
The process would just need to have to peer review/dispute
Another exmaple:
1) I instal FC6
2) I try a sound interface card (Echo Gina 24)
3) I realise the drivers are in the FC6 kernel (gina24.ko)
4) I realise that I need firmware not availabe in the official fedora
repos to get the device to work with alsa
5) I gather the info on the card (including the fac that it is a
discontinued model)
6) I add it to the db if it isn't ther
All I'm asking for a Fedora blessed infrastructure to be put in place,
not for any one person to be responsible for populating it
The benefit of this being that next time I'm buying hardware, I can
scurry over to the db and check what the best options are.
--
Fedora Core 6 and proud
9:03 a.m.
Arthur Pemberton wrote:
The community would. For example:
1) I install F7
2) My tv card works immediately without any additional drivers
3) I pull the card info from available sources
4) I add it to the db if it isn't already there
The process would just need to have to peer review/dispute
Another exmaple:
1) I instal FC6
2) I try a sound interface card (Echo Gina 24)
3) I realise the drivers are in the FC6 kernel (gina24.ko)
4) I realise that I need firmware not availabe in the official fedora
repos to get the device to work with alsa
5) I gather the info on the card (including the fac that it is a
discontinued model)
6) I add it to the db if it isn't ther
All I'm asking for a Fedora blessed infrastructure to be put in place,
not for any one person to be responsible for populating it
The benefit of this being that next time I'm buying hardware, I can
scurry over to the db and check what the best options are.
Since we're talking pie in the sky, I give to you Hardware Buddy.
1) Install FC7+
2) Opt in to "Automated Fedora-Compatibile Hardware Reporting" (in
firstboot?)
3) for every piece of hardware that's ever detected on this machine,
including removable devices like USB keys, etc.
a) Hardware Buddy compiles a report on the device
b) checks that the device hasn't been reported from this machine
c) asks user to confirm if device is working correctly
d) submits the report to some wiki with optional user comments
In the wiki, such votes are automatically analyzed by kernel/etc
version, and percentage working device reports out of all reports.
(B) would cut down on duplicates. Although the definitition of "machine"
can be foggy, we could operationalize this as just a file in /var that
keeps a log of what's been reported.
(C) is crucial, because just being able to detect a device isn't the
same as being able to confirm that it works. Some confirming could be
automated (it's easy to tell if a network card or a USB drive work),
some would have to be manual. Ideally, one would present the user with a
suggested testing scenario, e.g., for a printer, does this test page
look OK?
For devices both working and non, Hardware Buddy could automatically
collect info like the output of lspci, etc.
For bonus points, the wiki can automatically cheer Linux-friendly
manufacturers (lots of compatible devices), and jeer unfriendly ones
(lots of incompatible hardware) on its front page.
Lots of interesting questions remain. If a new kernel comes out with new
drivers supporting some piece of hardware, what happens to old reports
in the wiki? Perhaps they expire after some time. Or perhaps not, since
we can just keep them as cumulative statistics. What if some device is
"partially" supported? But it seems like this could be a fruitful direction.
9:24 a.m.
On 1/8/07, Jack Tanner <ihok(a)hotmail.com> wrote:
[snip some more detailed usage scenarios]
Since we're talking pie in the sky, I give to you Hardware
Buddy.
1) Install FC7+
2) Opt in to "Automated Fedora-Compatibile Hardware Reporting" (in
firstboot?)
3) for every piece of hardware that's ever detected on this machine,
including removable devices like USB keys, etc.
a) Hardware Buddy compiles a report on the device
b) checks that the device hasn't been reported from this machine
c) asks user to confirm if device is working correctly
d) submits the report to some wiki with optional user comments
Perhaps a modification of "sysreport", which already exists? 3b-3d
could be done outside of the tool on a server and sysreport could be
modified to submit to this hypothetical server instead of to RH
support. 3a would obviously require running the tool each time dbus
reports some new hardware.
"Description :
Sysreport is a utility that gathers information about a system's
hardware and configuration. The information can then be used for
diagnostic purposes and debugging. Sysreport is commonly used to help
support technicians and developers by providing a "snapshot" of a
system's current layout."
Oisin Feeley
10:02 a.m.
Le Lun 8 janvier 2007 16:24, Oisin Feeley a écrit :
Perhaps a modification of "sysreport", which already
exists?
IMHO klive (http://klive.cpushare.com/) is closer to what's needed
Regards,
--
Nicolas Mailhot
9:59 a.m.
Le Lun 8 janvier 2007 16:03, Jack Tanner a écrit :
Since we're talking pie in the sky, I give to you Hardware Buddy.
1. You don't want an install-time check because
a. in our brave new hotplug world hardware composition of a system
evolves over time
b. just because something does not work *today* does not mean it won't
work a month later when the software part is updated (unfortunately, the
reverse is true). The user must have the possibility to change his
evaluation
2. You don't want to cull failing devices too - knowing the installed
hardware base available to linux systems is crucial to focus new driver
development/manufacturer evangelization
3. You should allow fully automated non-interactive mode - non reviewed
data is better than no data and most users will get sick reporting every
time they plug a new usb bit on their system
4. Feeds to other projects (for example pciid database feed) would be
beneficial both to the community and as Fedora advertising.
Unfortunately, we're both a bit late for Christmas.
--
Nicolas Mailhot
10:44 a.m.
Nicolas Mailhot wrote:
1. You don't want an install-time check because
a. in our brave new hotplug world hardware composition of a system
evolves over time
Obviously. No, what I suggested for firstboot was that the user would
get to opt in to the whole reporting procedure. I'm not sure that
firstboot is the best place for even that. Ideally, you want to ask the
person who's actually the console user. Perhaps this should be per user,
even.
b. just because something does not work *today* does not mean it
won't
work a month later when the software part is updated (unfortunately, the
reverse is true). The user must have the possibility to change his
evaluation
Yup.
2. You don't want to cull failing devices too - knowing the
installed
hardware base available to linux systems is crucial to focus new driver
development/manufacturer evangelization
Yup.
3. You should allow fully automated non-interactive mode - non
reviewed
data is better than no data and most users will get sick reporting every
time they plug a new usb bit on their system
Sure. Fully automated should still be opted into. So:
( ) Prompt me for comments whenever Hardware Buddy wants to report a new
device
(*) Don't ask for comments, just report automatically (What info is
included?)
( ) Disable Hardware Buddy altogether
4. Feeds to other projects (for example pciid database feed) would
be
beneficial both to the community and as Fedora advertising.
Yup.
Unfortunately, we're both a bit late for Christmas.
Yup. Hm. Anyone want to play cupid? Valentine's Day is coming up, and I
could fall in love with my Hardware Buddy. :)
6:22 p.m.
Arthur Pemberton <pemboa(a)gmail.com> wrote:
On 1/8/07, Horst H. von Brand <vonbrand(a)inf.utfsm.cl> wrote:
> Arthur Pemberton <pemboa(a)gmail.com> wrote:
[...]
> > That's great. I don't even ask for the word
'support' to be used, I
> > would be happy with:
> >
> > * works with clean fedora (no binary blob drivers or firmware required)
> > * works with non fedora worthy firmware
> > * works in Linux, but not Fedora ready (or clean enough)
> > * no idea
> > * doesn't work
> Who would compile and keep this up to date? Have you any idea of
how many
> brands and models of different pieces are around?
The community would. For example:
1) I install F7
OK.
2) My tv card works immediately without any additional drivers
Or it doesn't.
3) I pull the card info from available sources
Which ones?
4) I add it to the db if it isn't already there
Who checks your entry is correct? What happens if you reported it didn't
work, and it works fine for me, or viceversa?
[...]
All I'm asking for a Fedora blessed infrastructure to be put in
place,
not for any one person to be responsible for populating it
This requires manpower (to check for junk, to clean up entries, to
discriminate among conclicting entries, ...). Ask the people at
<http://www.linuxprinting.org> if this is a trivial job. And printers are
outside the box, so it is /simple/ compared to all possible strange
interactions among in-box pieces.
The benefit of this being that next time I'm buying hardware, I
can
scurry over to the db and check what the best options are.
For higher-end stuff the data is usually at hand, for el-cheapo not (and
better stay away from that in any case).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
4:49 p.m.
On 1/9/07, Horst H. von Brand <vonbrand(a)inf.utfsm.cl> wrote:
> 4) I add it to the db if it isn't already there
Who checks your entry is correct? What happens if you reported it didn't
work, and it works fine for me, or viceversa?
Inevitably some hardware will work for all, some will work for a
proportion of users and some won't work at all. If I'm looking at the
DB, I'd like to see something like "works for X% of users."
You could also add info on whether or not it work OOTB too.
Personally, I'm happy trying to get some of my hardware configured,
but others I just wouldn't know where to start.
7:46 p.m.
On 1/10/07, Horst H. von Brand <vonbrand(a)inf.utfsm.cl> wrote:
[...]
[...]
> All I'm asking for a Fedora blessed infrastructure to be put in place,
> not for any one person to be responsible for populating it
This requires manpower (to check for junk, to clean up entries, to
discriminate among conclicting entries, ...). Ask the people at
<http://www.linuxprinting.org> if this is a trivial job. And printers are
outside the box, so it is /simple/ compared to all possible strange
interactions among in-box pieces.
I may be ignorant on the finer details, but between the outputs of
lspci, and lsusb, how many dupplicates can their possibly be?
While it may be non trivial to maintain linuxprinting.org it is a very
useful resource for pre-purchase printer considerations.
Google is a great resource, but it only goes so far.
I recently had to setup an older sound interface pci card on a fedora
box I setup at work. And indiciations were bright that it was linux
compatible and fully alsa supported. I did a locate and found the
module already in the fedora kernel tree , i thought great.
2-3 hours later I finally found out that the card needed firmware, not
available in extras or core, and just barely mentioned on the driver's
author's page.
It would have been nice to know that the kernel module is Fedora
compatible, but the firmware (to make the device work) is not.
> The benefit of this being that next time I'm buying
hardware, I can
> scurry over to the db and check what the best options are.
For higher-end stuff the data is usually at hand, for el-cheapo not (and
better stay away from that in any case).
I'm not sure what more one needs than the output of lspci, and lsusb,
and dmesg...of course I could be missing something here.
--
Fedora Core 6 and proud
6:51 a.m.
Arthur Pemberton <pemboa(a)gmail.com> wrote:
On 1/10/07, Horst H. von Brand <vonbrand(a)inf.utfsm.cl> wrote:
[...]
> [...]
>
> > All I'm asking for a Fedora blessed infrastructure to be put in place,
> > not for any one person to be responsible for populating it
>
> This requires manpower (to check for junk, to clean up entries, to
> discriminate among conclicting entries, ...). Ask the people at
> <http://www.linuxprinting.org> if this is a trivial job. And printers are
> outside the box, so it is /simple/ compared to all possible strange
> interactions among in-box pieces.
I may be ignorant on the finer details, but between the outputs of
lspci, and lsusb, how many dupplicates can their possibly be?
I've seen a WiFi card with a (somewhat) supported TI chipset which didn't
work at all, due to differences in the handling of firmware by the rest of
the card (or that was what we ended up suspecting, as firmware loading just
didn't work). lspci/lsusb saying something is no guarantee that the rest of
the card isn't screwed up beyond hope.
While it may be non trivial to maintain linuxprinting.org it is a
very
useful resource for pre-purchase printer considerations.
Yes. Now multiply that job by 10 (WiFi cards, say, have a much shorter
lifespan than printers and there are much more companies making the stuff)
for each type of device out there, and you are in the ballpark of what this
requires.
Google is a great resource, but it only goes so far.
A web page purporting to list all devices supported by Fedora will make
information materialize out of thin air exactly how? If it ain't in Google,
it doesn't exist...
But what do I know... set up the webpage and start collecting data. I'd
love to be proven wrong.
I recently had to setup an older sound interface pci card on a
fedora
box I setup at work. And indiciations were bright that it was linux
compatible and fully alsa supported. I did a locate and found the
module already in the fedora kernel tree , i thought great.
2-3 hours later I finally found out that the card needed firmware, not
available in extras or core, and just barely mentioned on the driver's
author's page.
It would have been nice to know that the kernel module is Fedora
compatible, but the firmware (to make the device work) is not.
If the /author/ doesn't tell you that, how are the Fedora folks to know
about that minor detail?
> > The benefit of this being that next time I'm buying
hardware, I can
> > scurry over to the db and check what the best options are.
>
> For higher-end stuff the data is usually at hand, for el-cheapo not (and
> better stay away from that in any case).
I'm not sure what more one needs than the output of lspci, and lsusb,
and dmesg...of course I could be missing something here.
lspci(8) mostly tells you the base chip in the card, and to get there you
have to install it somewhere sane. Won't work for buying a card by mail
order. And that is not enough, as other pieces/variations of the chip might
(or not) work.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
11:44 a.m.
On Thu, Jan 11, 2007 at 09:51:52 -0300,
"Horst H. von Brand" <vonbrand(a)inf.utfsm.cl> wrote:
Arthur Pemberton <pemboa(a)gmail.com> wrote:
>
> 2-3 hours later I finally found out that the card needed firmware, not
> available in extras or core, and just barely mentioned on the driver's
> author's page.
>
> It would have been nice to know that the kernel module is Fedora
> compatible, but the firmware (to make the device work) is not.
If the /author/ doesn't tell you that, how are the Fedora folks to know
about that minor detail?
OpenBSD might have information on whether or not the firmware has a license
that permits redistribution. If it does, then you can probably get it from
them if it isn't in the Fedora driver. If it doesn't then Fedora shouldn't
have it and you will want to see if the manufacturer distributes it under
acceptible terms from their website.
11:37 a.m.
On Sun, 2007-01-07 at 06:10 -0600, Arthur Pemberton wrote:
2) I haven't heard much of Python 2.5 for Fedora 7. Comments
would be
appreciated.
It's already in rawhide and thus will be in Fedora 7. It could have a
bullet on the feature list, but new foo x.y.z just isn't that
interesting as a "feature", IMHO
Jeremy
1:15 a.m.
New subject: Ruby and Rails packages (was: Fedora 7)
On 2007-01-04, Bill Nottingham said:
- Modify the build system to support this new paradigm
- Merge Core and Extras in source control
- Use the new pungi tool to spin all releases
- A Fedora Desktop spin
- A Fedora Server spin
- A Fedora KDE spin
- Make LiveCDs as a part of the distribution release process
- Ability to customize non-packaging distrubution parameters
- Switch to libata drivers for PATA support
- Speedup of bootup and shutdown
- Make wireless rock-solid
- Add wireless firmware for all the chipsets we can
- CodecBuddy
- Fixing the proliferation of dictionary packages
- Support encrypted filesystems
- Fast user switching in the desktop
- Fix the firewire stack
- Switch to a tickless kernel by default
- Fix unnecessary wakeups across the distribution
- Add KVM virtualization support to our tools
- Investigate (but probably don't switch to) new init technologies
- Add the nouveau drivers for nVidia cards
- Speed up Yum and RPM
- Add support for RandR 1.2
- Switch to syslog-ng
- Make the update system useable by all
It will also be good to finalize the ruby and rails packing guidelines
so that people can start packing things.
--
Leo <sdl.web AT gmail.com> (GPG Key: 9283AA3F)
7:58 p.m.
New subject: Ruby and Rails packages (was: Fedora 7)
On Tue, 2007-01-16 at 07:15 +0000, Leo wrote:
It will also be good to finalize the ruby and rails packing
guidelines
so that people can start packing things.
The ruby guidelines have been around for a while [1]; what we don't have
is guidelines on packaging rubygems. That's a little more difficult
since gems implement their own packaging system, and making sure that
rpm-packaged gems and plain gems interoperate nicely requires some
thought (and work) In addition, gems are not suitable for distributing
binary extensions since they lack any semblance of multilib support.
Having said all that, I have packaged ruby-activerecord and
ruby-activesupport; one day, I swear I'll package the rest of rails, but
I'd love to see somebody beat me to it.
David
[1] http://fedoraproject.org/wiki/Packaging/Ruby
6308
days inactive
6321
days old
352 comments
89 participants
participants (89)
-
Andrew Overholt -
Andrew Parker -
Arthur Pemberton -
Bill Nottingham -
Bojan Smojver -
Brian Pepple -
Bruno Wolff III -
Chitlesh GOORAH -
Chris Adams -
Chris Lumens -
Chuck Anderson -
Dan Williams -
Dave Jones -
David Cantrell -
David Lutterkort -
David Nielsen -
David Zeuthen -
Dax Kelson -
Dax Kelson
-
Deji Akingunola -
Denis Leroy -
Dennis Gilmore -
drago01 -
Emmanuel Seyman -
Eric Feldhusen -
Eric S. Raymond -
Fabio Comolli -
Florin Andrei -
Giandomenico De Tullio -
Gianluca Sforna -
Horst H. von Brand -
Jack Tanner -
Jason L Tibbitts III -
Jef Spaleta -
Jeffrey Ollie -
Jeremy Katz -
Jerry Williams -
Jesse Keating -
Jindrich Novy -
Jos Vos -
Jose Pedro Oliveira -
Josh Boyer -
José Abílio Matos -
Keith Sharp -
Lamont R. Peterson -
Leo -
Lyvim Xaphir -
Mark Rosenstand -
Matej Cepl -
Matthew Miller -
Matthias Clasen -
Mauricio Teixeira (netmask) -
Michael Wiktowy -
Mike McGrath -
Miles Sabin -
MJang -
Naoki -
Neal Becker -
Nicolas Mailhot -
Oisin Feeley -
Ola Thoresen -
Olivier Galibert -
Patrice Dumas -
Paul Howarth -
Paul W. Frields -
Pekka Pietikäinen -
Peter Gordon -
Peter Robinson -
Rahul Sundaram -
Ralf Corsepius -
Rex Dieter -
Richard Hughes -
Robert Scheck -
Roozbeh Pournader -
Rudi Chiarito -
Saikat Guha -
seth vidal -
Stephen John Smoogen -
Thomas Canniot -
Thomas Fitzsimmons -
Thorsten Leemhuis -
Tom Lane -
Tom Tromey -
Tony Nelson -
Toshio Kuratomi -
Vnpenguin -
Warren Togami -
Warren Togami -
Zoltan Boszormenyi