4:11 p.m.
I have a fstab entry like this:
/dev/sde1 /mnt/sdcard autonoexec,noauto,users,ro,sync,shortname=lower 0 0
which I use in a script to take pictures off my camera's SD card and
transfer them to my photo management system. I've been doing it this way for
a long time, and now with modern Linux I recognize that there's better ways
of doing it. But I was surprised when I updated this system to latest
rawhide and rebooted, because it came up with that filesystem mounted.
Is this expected behavior?
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
10:19 a.m.
On Sat, 21.08.10 17:11, Matthew Miller (mattdm(a)mattdm.org) wrote:
I have a fstab entry like this:
/dev/sde1 /mnt/sdcard autonoexec,noauto,users,ro,sync,shortname=lower 0 0
which I use in a script to take pictures off my camera's SD card and
transfer them to my photo management system. I've been doing it this way for
a long time, and now with modern Linux I recognize that there's better ways
of doing it. But I was surprised when I updated this system to latest
rawhide and rebooted, because it came up with that filesystem mounted.
Is this expected behavior?
Yes, I expected it.
In systemd we auto-generate all sorts of implicit requirement and
ordering dependencies between mount points and the devices they are
mounted from. This allows many neat tricks, for example we automatically
order mounts for /foo/bar and /foo properly, so that /foo is mounted
first and /foo/bar is mounted second, even though the devices might have
appeared in the device tree in the reverse order. I also added implicit
dependencies so that a device showing up that is listed in /etc/fstab
causes the device to be mounted. I figured this would be nice behaviour
and we basically get it for free, and actually I still think it is.
So, to turn this around. Do you think this behaviour is problematic? Can
you make a good case for dropping this automatism? If so I'd be willing
to do so.
Lennart
--
Lennart Poettering - Red Hat, Inc.
10:28 a.m.
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de> said:
So, to turn this around. Do you think this behaviour is problematic?
Can
you make a good case for dropping this automatism? If so I'd be willing
to do so.
The fact that "noauto" in /etc/fstab is documented to not automatically
mount filesystems means that they shouldn't be automatically mounted.
--
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:51 a.m.
On Mon, 23.08.10 10:28, Chris Adams (cmadams(a)hiwaay.net) wrote:
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de> said:
> So, to turn this around. Do you think this behaviour is problematic? Can
> you make a good case for dropping this automatism? If so I'd be willing
> to do so.
The fact that "noauto" in /etc/fstab is documented to not automatically
mount filesystems means that they shouldn't be automatically mounted.
Well, we took the liberty to interpret noauto a little bit differently
than you: everything marked "auto" will be mounted at boot, and boot
will not proceed until all devices listed as auto appeared and are fully
mounted (or things timed out). File systems marked as "noauto" won't
delay the boot process if they aren't, but they'll still be mounted when
they are plugged in, regardless whether that is at boot or during
runtime.
i.e. "auto" → wait for this on boot; "noauto" → don't delay boot
for this.
Lennart
--
Lennart Poettering - Red Hat, Inc.
11:03 a.m.
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de> said:
Well, we took the liberty to interpret noauto a little bit
differently
than you: everything marked "auto" will be mounted at boot, and boot
will not proceed until all devices listed as auto appeared and are fully
mounted (or things timed out). File systems marked as "noauto" won't
delay the boot process if they aren't, but they'll still be mounted when
they are plugged in, regardless whether that is at boot or during
runtime.
Please take the liberty to implement "noauto" as documented. See "man
mount":
noauto Can only be mounted explicitly (i.e., the -a option will not
cause the filesystem to be mounted).
--
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.
12:22 p.m.
On 08/23/2010 09:33 PM, Chris Adams wrote:
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de>
said:
> Well, we took the liberty to interpret noauto a little bit differently
> than you: everything marked "auto" will be mounted at boot, and boot
> will not proceed until all devices listed as auto appeared and are fully
> mounted (or things timed out). File systems marked as "noauto" won't
> delay the boot process if they aren't, but they'll still be mounted when
> they are plugged in, regardless whether that is at boot or during
> runtime.
Please take the liberty to implement "noauto" as documented. See "man
mount":
noauto Can only be mounted explicitly (i.e., the -a option will not
cause the filesystem to be mounted).
I agree with this. We cannot take options that mean something for a
very long time and change it to mean something completely different. If
you don't recognize the option at all, it is one thing (although that
needs very good reasons for doing that) but changing semantics is just
plain wrong. If that new behaviour is useful, make it as extra options.
Rahul
11:32 a.m.
On Mon, 23.08.10 12:23, David Michael (fedora.dm0(a)gmail.com) wrote:
On Mon, Aug 23, 2010 at 11:51 AM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
> i.e. "auto" → wait for this on boot; "noauto" → don't delay
boot for this.
I may be wrong, but wasn't there already a "bootwait" and
"nobootwait"
defined for this behavior?
I see no such option documented anywhere?
Lennart
--
Lennart Poettering - Red Hat, Inc.
11:44 a.m.
On Mon, Aug 23, 2010 at 12:32 PM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
On Mon, 23.08.10 12:23, David Michael (fedora.dm0(a)gmail.com) wrote:
> On Mon, Aug 23, 2010 at 11:51 AM, Lennart Poettering
> <mzerqung(a)0pointer.de> wrote:
> > i.e. "auto" → wait for this on boot; "noauto" → don't
delay boot for this.
>
> I may be wrong, but wasn't there already a "bootwait" and
"nobootwait"
> defined for this behavior?
I see no such option documented anywhere?
Google responds to "nobootwait" with many Ubuntu forums etc. where
people are apparently using it, but I didn't see any official-looking
documentation. Perhaps it's a Debian thing; I just remembered seeing
those fstab options somewhere.
11:28 a.m.
Lennart Poettering wrote:
Well, we took the liberty to interpret noauto a little bit
differently
than you: everything marked "auto" will be mounted at boot, and boot
will not proceed until all devices listed as auto appeared and are fully
mounted (or things timed out). File systems marked as "noauto" won't
delay the boot process if they aren't, but they'll still be mounted when
they are plugged in, regardless whether that is at boot or during
runtime.
i.e. "auto" → wait for this on boot; "noauto" → don't delay boot
for this.
This is not a reinterpretation, but rather completely new semantics that
differ from existing documentation on a variety of UNIX and UNIX-like
systems, including Fedora itself:
Fedora: "‘‘noauto’’ (do not mount when "mount -a" is given, e.g., boot
time)"
FreeBSD: "If the option ``noauto'' is specified, the file system will
not be automatically mounted at system startup."
OpenBSD and Mac OS X: "The option ``auto'' can be used in the
``noauto'' form to cause a file system not to be mounted automatically
(with mount -A or mount -a, or at system boot time)."
Please implement noauto as documented and assign these new semantics to
another option.
11:40 a.m.
New subject: systemd and changes
On Mon, Aug 23, 2010 at 05:51:30PM +0200, Lennart Poettering wrote:
Well, we took the liberty to interpret noauto a little bit
differently
than you: everything marked "auto" will be mounted at boot, and boot
will not proceed until all devices listed as auto appeared and are fully
mounted (or things timed out). File systems marked as "noauto" won't
delay the boot process if they aren't, but they'll still be mounted when
they are plugged in, regardless whether that is at boot or during
runtime.
i.e. "auto" → wait for this on boot; "noauto" → don't delay boot
for this.
This seems like a useful behavior, but we can't just make old options have
radically different meaning -- there's really no room for interpretation.
How about having a new option called "noboot", "nowait",
"nobootwait",
"nowaitonboot", "autolater", or somesuch? Although, arguably, if one
needs
that kind of functionality, the existing autofs daemon does it in a more
flexibile way already.
Is it helpful at this point if I file a bug for systemd's noauto behavior?
This is the second such surprise that I've come across -- "shutdown -r +1"
of course being the other. And of course before that, the long thread about
the chkconfig and service commands. I was positively impressed by your
responsiveness and flexibility on the shutdown delay issue, but I have to
say that the pattern here is making me worried. I don't mean it as a flame
or attack on either you or the project, but I wonder if things are moving
too fast for systemd to be a good choice for Fedora 14.
Again, with no intent to troll, can you estimate how many more changes like
this are in store? Like I hope was illustrated in the "the next steps"
thread, change in itself isn't cost-neutral. When you're replacing a core
component of the OS, and you're faced with a point where a human interface
could be changed, the first thought must be "how can we make this
improvement with minimal disruption?".
So, my question is serious. If we go ahead with systemd for F14, will we be
hit with an onslaught of confusion, trouble, and change? That would be good
for testing systemd, but *not awesome* for the distribution or for its
users. Or, on the other hand, is it a matter of a few kinks which we can get
solved before release?
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
12:01 p.m.
New subject: systemd and changes
On Mon, Aug 23, 2010 at 12:40:35PM -0400, Matthew Miller wrote:
So, my question is serious. If we go ahead with systemd for F14, will
we be
hit with an onslaught of confusion, trouble, and change? That would be good
for testing systemd, but *not awesome* for the distribution or for its
users. Or, on the other hand, is it a matter of a few kinks which we can get
solved before release?
Here's another one:
https://bugzilla.redhat.com/show_bug.cgi?id=624249#c6
This will cause trouble with scripts which assume Red Hat's long practice of
using runlevel 3 for text-only multiuser mode. They might be making a poor
assumption, but those scripts are surely out there. Let's not break them.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
6:16 p.m.
New subject: systemd and changes
Matthew Miller wrote:
Here's another one:
https://bugzilla.redhat.com/show_bug.cgi?id=624249#c6
This will cause trouble with scripts which assume Red Hat's long practice
of using runlevel 3 for text-only multiuser mode. They might be making a
poor assumption, but those scripts are surely out there. Let's not break
them.
I don't see that behavior as being broken, since runlevels 2, 3 and 4 are
the same thing (in the default configuration, and when they're not, this
behavior will not appear), so it should not matter which you use. If scripts
assume that only runlevels 3 and 5 exist, those scripts are already broken
(just boot with a 4 in your kernel arguments, using upstart or even the old
SysVInit, and watch it break).
Kevin Kofler
6:29 p.m.
New subject: systemd and changes
On Wed, 25.08.10 01:16, Kevin Kofler (kevin.kofler(a)chello.at) wrote:
I don't see that behavior as being broken, since runlevels 2, 3
and 4 are
the same thing (in the default configuration, and when they're not, this
behavior will not appear), so it should not matter which you use. If scripts
assume that only runlevels 3 and 5 exist, those scripts are already broken
(just boot with a 4 in your kernel arguments, using upstart or even the old
SysVInit, and watch it break).
Note that I have now changed git upstream to preferably return 3 or 5 if
multiple different answers would make sense. This should avoid most
problems with scripts doing "if [ `runlevel` = 3 ] ; then", even if
that's a kinda broken thing to do. Since runlevels 3 and 5 are the ones
anaconda writes this should be the safest bet.
Lennart
--
Lennart Poettering - Red Hat, Inc.
6:32 p.m.
New subject: systemd and changes
On Wed, Aug 25, 2010 at 01:29:20AM +0200, Lennart Poettering wrote:
Note that I have now changed git upstream to preferably return 3 or 5
if
multiple different answers would make sense. This should avoid most
problems with scripts doing "if [ `runlevel` = 3 ] ; then", even if
that's a kinda broken thing to do. Since runlevels 3 and 5 are the ones
anaconda writes this should be the safest bet.
For the record, I agree that those scripts are probably horrible old
kludges. It's just nice when we can not break those. So, again, thanks for
reponsiveness on this, Lennart.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
8:32 a.m.
New subject: systemd and changes
On Tue, 2010-08-24 at 19:32 -0400, Matthew Miller wrote:
On Wed, Aug 25, 2010 at 01:29:20AM +0200, Lennart Poettering wrote:
> Note that I have now changed git upstream to preferably return 3 or 5 if
> multiple different answers would make sense. This should avoid most
> problems with scripts doing "if [ `runlevel` = 3 ] ; then", even if
> that's a kinda broken thing to do. Since runlevels 3 and 5 are the ones
> anaconda writes this should be the safest bet.
For the record, I agree that those scripts are probably horrible old
kludges. It's just nice when we can not break those. So, again, thanks for
reponsiveness on this, Lennart.
Hey Matt, I'd like to thank you for staying constructive and friendly in
these heated debates, that is really great.
12:10 p.m.
New subject: systemd noauto bugzilla entry
On Mon, Aug 23, 2010 at 12:40:35PM -0400, Matthew Miller wrote:
Is it helpful at this point if I file a bug for systemd's noauto
behavior?
https://bugzilla.redhat.com/show_bug.cgi?id=626502
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
1:22 p.m.
New subject: systemd and changes
On Mon, 23.08.10 12:40, Matthew Miller (mattdm(a)mattdm.org) wrote:
This seems like a useful behavior, but we can't just make old
options have
radically different meaning -- there's really no room for interpretation.
How about having a new option called "noboot", "nowait",
"nobootwait",
"nowaitonboot", "autolater", or somesuch? Although, arguably, if one
needs
that kind of functionality, the existing autofs daemon does it in a more
flexibile way already.
Well, it's not really a mount option, it's a systemd option.
Anyway, upstream git now makes it configurable globally whether these
simple implictly created deps are added or not. It defaults to off.
Is it helpful at this point if I file a bug for systemd's noauto
behavior?
Well, given that this is already changed upstream, not really, no. ;-)
This is the second such surprise that I've come across --
"shutdown -r +1"
of course being the other. And of course before that, the long thread about
the chkconfig and service commands. I was positively impressed by your
responsiveness and flexibility on the shutdown delay issue, but I have to
say that the pattern here is making me worried. I don't mean it as a flame
or attack on either you or the project, but I wonder if things are moving
too fast for systemd to be a good choice for Fedora 14.
That's quite a jump you are making there. First you say you are happy
with the speed I processed your last issue with (and let's also note
that this new issue is already fixed, too) and then you say it was too
slow on F14.
Quite frankly I'd draw a completely different conclusion of the current
state of affairs: everything is looking pretty great. The number of bugs
open is kinda small, and nothing major of it. And the two issues you
raised weren't even bugs, but one was more of a feature request and the
other a request of change of behaviour.
And anyway, *2* "incidents" don't really make up a pattern, do they?
If you'd put the bar for some other package as high as you are putting
it for systemd, then well, maybe the Linux kernel isn't ready for F14
yet either? ;-)
A little bit more optimism, please!
Again, with no intent to troll, can you estimate how many more
changes like
this are in store? Like I hope was illustrated in the "the next steps"
thread, change in itself isn't cost-neutral. When you're replacing a core
component of the OS, and you're faced with a point where a human interface
could be changed, the first thought must be "how can we make this
improvement with minimal disruption?".
So, my question is serious. If we go ahead with systemd for F14, will we be
hit with an onslaught of confusion, trouble, and change? That would be good
for testing systemd, but *not awesome* for the distribution or for its
users. Or, on the other hand, is it a matter of a few kinks which we can get
solved before release?
Well, of course, systemd is magic and bug-free. Because I am Gandhi 2.0
I also have the powers to make everybody happy. Yippieh!
Nah, seriously. Every software has bugs. And systemd isn't
sysvinit. Because of that it doesn't always behave like sysvinit. But
that's expected. I could name you a couple of other things where we
depart from sysvinit. (for example, we ignore the Sxx/Kxx priorities of
the /etc/rcX.d symlinks by default if the LSB header includes ordering
information anyway). Many of these differences shouldn't matter really,
and we can often tell people that they are misusing things if they are
relying on the old behaviour (i.e. because they apparently didn't use
chkconfig in the example mentioned).
So, there'll be more stuff coming up, I am sure. I'd bet on it. There
will be bugs. I'll bet on that too. But that's fine. That's OK. That's
expected. Software has bugs. And first releases of software definitely
have bugs. That's why we have all this alpha/beta process for Fedora in
place, so that we can find them early.
That all said if you have a look on the number and quality of open bugs
of systemd for F14 then it appears to be a lot stabler and more polished
than probably most of the stuff in the current base system. It's
definitely not a good metric, but I do believe if that even if the
number increases to a healthy level comparable with other core packages
we'd still be fine.
So, breath deeply, and let's all be jolly!
Lennart
--
Lennart Poettering - Red Hat, Inc.
1:55 p.m.
New subject: systemd and changes
On Mon, Aug 23, 2010 at 08:22:16PM +0200, Lennart Poettering wrote:
> This is the second such surprise that I've come across --
"shutdown -r +1"
> of course being the other. And of course before that, the long thread about
> the chkconfig and service commands. I was positively impressed by your
> responsiveness and flexibility on the shutdown delay issue, but I have to
> say that the pattern here is making me worried. I don't mean it as a flame
> or attack on either you or the project, but I wonder if things are moving
> too fast for systemd to be a good choice for Fedora 14.
That's quite a jump you are making there. First you say you are happy
with the speed I processed your last issue with (and let's also note
that this new issue is already fixed, too) and then you say it was too
slow on F14.
I don't think it's a jump. I'm glad you're responsive to these concerns.
However, I don't want a Fedora release to ship with many more such concerns
unresolved. The place to address these things is in a development tree.
And anyway, *2* "incidents" don't really make up a
pattern, do they?
I actually count four that I've noticed so far:
- chkconfig and service not working as expected
- shutdown delay option destructively ignored
- filesystems marked 'noauto' getting mounted automatically
- runlevel 3 reporting itself as runlevel 4
Now, you have been good about providing a solution for these. But those are
just the things *I've* noticed, and let me assure you that I am quite far
from the _most_ crotchety set-in-his-or-her ways old-school sysadmin. The
pattern I see is that each time, you respond initially with (paraphrased)
"It's not broken -- we've made it better!" before implementing the fix.
So, I'm honestly asking: what are the odds that these few things are the
only improvements that cause a disruptive change to user interaction? I
don't think it's unreasonable to wonder if there are other changes which fit
this category.
If you'd put the bar for some other package as high as you are
putting
it for systemd, then well, maybe the Linux kernel isn't ready for F14
yet either? ;-)
If we were running some other kernel, and the Linux kernel came along and
made a whole bunch of changes to user interaction, yes, I would indeed say
that it's not ready yet.
A little bit more optimism, please!
I don't want to be so optimistic that we, with our eyes on a beautiful
perfect future ahead, stroll right into tarpit without looking.
Well, of course, systemd is magic and bug-free. Because I am Gandhi
2.0
I also have the powers to make everybody happy. Yippieh!
Right, not askin' for that.
Nah, seriously. Every software has bugs. And systemd isn't
sysvinit. Because of that it doesn't always behave like sysvinit. But
that's expected. I could name you a couple of other things where we
depart from sysvinit. (for example, we ignore the Sxx/Kxx priorities of
the /etc/rcX.d symlinks by default if the LSB header includes ordering
information anyway). Many of these differences shouldn't matter really,
and we can often tell people that they are misusing things if they are
relying on the old behaviour (i.e. because they apparently didn't use
chkconfig in the example mentioned).
In a lot of cases, that's probably okay -- but we need to make sure that all
of these things make the release notes. And as we've seen, in many cases
what other people think matters turns out to surprise you. (Users -- so
strange and difficult to predict... both sysadmin work and software
development would be so nicer without 'em....)
So, there'll be more stuff coming up, I am sure. I'd bet on
it. There
will be bugs. I'll bet on that too. But that's fine. That's OK. That's
expected. Software has bugs. And first releases of software definitely
have bugs. That's why we have all this alpha/beta process for Fedora in
place, so that we can find them early.
This is such a substantial change, and the system so young, that I'm really
afraid that one such cycle isn't going to be enough. I don't think it would
be a failure to say that we should leave the system as optional for F14 and
aim to make it default for F15.
That all said if you have a look on the number and quality of open
bugs
of systemd for F14 then it appears to be a lot stabler and more polished
than probably most of the stuff in the current base system. It's
definitely not a good metric, but I do believe if that even if the
number increases to a healthy level comparable with other core packages
we'd still be fine.
So, breath deeply, and let's all be jolly!
I'm concerned there aren't enough eyeballs yet -- and people don't
necessarily no where to look, because the changes can be in unexpected
areas. It took me a few minutes to figure out that systemd was mounting my
noauto filesystem, for example.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
2:33 p.m.
New subject: systemd and changes
On Mon, 23.08.10 14:55, Matthew Miller (mattdm(a)mattdm.org) wrote:
This is such a substantial change, and the system so young, that
I'm really
afraid that one such cycle isn't going to be enough. I don't think it would
be a failure to say that we should leave the system as optional for F14 and
aim to make it default for F15.
Well, maybe we should discuss this when we actually ran into a real
problem instead of just "seeing patterns"?
Seriously, don't discuss these things to death in advance.
> That all said if you have a look on the number and quality of
open bugs
> of systemd for F14 then it appears to be a lot stabler and more polished
> than probably most of the stuff in the current base system. It's
> definitely not a good metric, but I do believe if that even if the
> number increases to a healthy level comparable with other core packages
> we'd still be fine.
> So, breath deeply, and let's all be jolly!
I'm concerned there aren't enough eyeballs yet -- and people don't
necessarily no where to look, because the changes can be in unexpected
areas. It took me a few minutes to figure out that systemd was mounting my
noauto filesystem, for example.
Well, it boils to the age old fact that software which is not used is
buggy. Simply by letting software rot for another 6 months bugs won't go
away. You have to push things into the distributions if they appear to
be ready, and they very much appear so to me in this case, and I managed
to convince FESCO of that.
Fix the bugs when you find them. Revert if things go really wrong. But
in this case they haven't. Absolutely not. Everything's on track.
Fedora is different things to different people. But I think I am not
wrong if I recognize that one mostly accepted consensus is that Fedora
is where the innovation happens and and which shall lead the development
of Linux as a whole. And that's why systemd is at the right place and
at the right time.
Please, end this discussion for now, and restart it if we find a real
issue? That's not too much to ask for now, is it?
Lennart
--
Lennart Poettering - Red Hat, Inc.
3:17 p.m.
New subject: systemd and changes
On Mon, Aug 23, 2010 at 09:33:26PM +0200, Lennart Poettering wrote:
Well, maybe we should discuss this when we actually ran into a real
problem instead of just "seeing patterns"?
Seriously, don't discuss these things to death in advance.
The whole point of having these things in testing is to discuss them in
advance. I'm taking a very moderate position on caution here, and I don't
think it's unreasonable.
Well, it boils to the age old fact that software which is not used
is
buggy. Simply by letting software rot for another 6 months bugs won't go
away. You have to push things into the distributions if they appear to
be ready, and they very much appear so to me in this case, and I managed
to convince FESCO of that.
Was there a conversation other than this FESCO meeting?
<http://meetbot.fedoraproject.org/fedora-meeting/2010-06-15/fesco.2010-06-...
There, I see this discussion:
20:51:41 <mezcalero> so, i would like to keep the options open, but i'd
like to see the testing for the case "systemd as default"
[...]
20:51:59 <mjg59> mezcalero: The feature owner is always free to decide to
stop pushing it part way through the release
20:52:13 <ajax> and i'm happy to say no to anything you like ;)
20:52:33 <pjones> I don't have a problem with you trying to make sure
it's
ready to _try_ to use as default fairly early
20:52:41 <mezcalero> mjg59: well, yes, but i want to make clear that with
this proposal this case is not unlikely
20:52:47 <mjg59> mezcalero: If you're confident that it'll behave itself,
I don't have any problem with aiming for it to replace upstart -
but I'd like to see the initial transition happen early, so we
have good confidence that it works for everyone
20:52:47 <pjones> I think we need to have a longer discussion as to if
that's what we're going to do though, even if you do have it
ready.
And it goes on, but it's clear that the decision made is: We'll go ahead
with the feature as optional, and allow an attempt at making it the default,
but that isn't a done decision. I'm not sure if you actually read this
before or participated directly in the discussion, but if you have, it seems
a bit disingenuous to characterize this as having convinced FESCO that
systemd should be on default.
Oh, I have found a later meeting, from August 3rd. There, the comments
(after a brief discussion o updating the wiki):
20:05:40 <nirik> What do folks think on systemd? still too early to tell
if it will be ready for f14? (I know it's not had that much
testing yet).
20:06:05 <adamw> i think it would be useful to look at alpha feedback on
that
20:06:09 <cebbert> is it still trying to dictate how the kernel gets
packaged?
[... different-topic python packaging comment elided ... ]
20:06:21 <notting> cebbert: have you filed a bug?
[... different-topic python packaging comment elided ... ]
20:06:52 <dmalcolm> nirik: given that as it stands it's less featureful
that ubuntu's version of the same, it's debatable that it's now a
"feature"
20:07:05 <dmalcolm> nirik: hence F15, I think
20:07:11 <mclasen> nirik/adamw: I know lennart was working on a bugfix
release of systemd todasy
20:07:45 <nirik> dmalcolm: yeah, no shame in moving it out a release...
20:07:49 <adamw> yeah, we're going to need one to fix the 100% CPU usage bug
at a minimum.
20:07:58 <nirik> mclasen: great.
20:08:13 <mclasen> I'll try to make sure that it lands before tomorrow
20:08:18 <mclasen> if I can get hold of lennart
20:08:21 <adamw> ok
20:08:24 <adamw> thanks
Which echos what I was saying earlier -- it's not a failure if systemd
doesn't make F14.
Please, end this discussion for now, and restart it if we find a
real
issue? That's not too much to ask for now, is it?
I'm not quoting all of this to argue, but to bring it to your attention if
you haven't seen already. Having a discussion at this point is absolutely
appropriate if you want to get systemd in by default. Or if not at this
point, as feedback from the alpha release starts coming in.
I understand your desire to get your code out there in the real world. But
Fedora really can't afford to have a marketing-disaster release right now.
Because this is a far-reaching change to a core service, any problems people
encounter will be amplified -- and amplified *way more* than my little
complaints. I want to avoid that.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
3:31 p.m.
New subject: systemd and changes
On 08/24/2010 01:47 AM, Matthew Miller wrote:
I understand your desire to get your code out there in the real
world. But
Fedora really can't afford to have a marketing-disaster release right now.
Because this is a far-reaching change to a core service, any problems people
encounter will be amplified -- and amplified *way more* than my little
complaints. I want to avoid that.
Your concern is valid. Shall we wait till we have a alpha release and
perhaps a test day and then we can revisit this discussion? If there
are no serious issues being reported, we can go ahead with the current
choice. We have not obsoleted upstart precisely to enable us to
fallback easily.
Rahul
3:57 p.m.
New subject: systemd and changes
On Mon, 23.08.10 16:17, Matthew Miller (mattdm(a)mattdm.org) wrote:
Oh, I have found a later meeting, from August 3rd. There, the
comments
(after a brief discussion o updating the wiki):
20:05:40 <nirik> What do folks think on systemd? still too early to tell
if it will be ready for f14? (I know it's not had that much
testing yet).
20:06:05 <adamw> i think it would be useful to look at alpha feedback on
that
20:06:09 <cebbert> is it still trying to dictate how the kernel gets
packaged?
[... different-topic python packaging comment elided ... ]
20:06:21 <notting> cebbert: have you filed a bug?
Yes, did this happen? I am not aware of any issue. I exchanged a couple
of mails with Dave a couple of days ago and to my knowledge we settled
everything that was left to discuss?
[... different-topic python packaging comment elided ... ]
20:06:52 <dmalcolm> nirik: given that as it stands it's less featureful
that ubuntu's version of the same, it's debatable that it's now a
"feature"
I am not sure where this comes from, but well, there is not really much
truth in it.
20:07:05 <dmalcolm> nirik: hence F15, I think
20:07:11 <mclasen> nirik/adamw: I know lennart was working on a bugfix
release of systemd todasy
20:07:45 <nirik> dmalcolm: yeah, no shame in moving it out a release...
20:07:49 <adamw> yeah, we're going to need one to fix the 100% CPU usage bug
at a minimum.
This all has been fixed, and strictly speaking this was and still is a a
known issue in X which doesn't properly handle it if it opens a tty at
the same time as a getty. It's a race. We now avoid the race by making
sure we never start the getty and X on the same terminal, but one could
argue that's just taping over the real issue.
This is all old stuff that was fixed very quickly, and I think adamw
will ahgree with me that all issues we found for the f14 alpha release
were really quickly dealt with and fixed.
Which echos what I was saying earlier -- it's not a failure if
systemd
doesn't make F14.
It simply echoes that new software isn't perfect. And that we fixed all
issues quickly.
I'm not quoting all of this to argue, but to bring it to your
attention if
you haven't seen already. Having a discussion at this point is absolutely
appropriate if you want to get systemd in by default. Or if not at this
point, as feedback from the alpha release starts coming in.
Well, you are building a case out of bugs that have been fixed weeks
ago.
I understand your desire to get your code out there in the real
world. But
Fedora really can't afford to have a marketing-disaster release right
now.
Ah, it can't? When can it?
Neither do I see a marketing desaster looming anywhere nor do I see
any relation to "not now".
Because this is a far-reaching change to a core service, any problems
people
encounter will be amplified -- and amplified *way more* than my little
complaints. I want to avoid that.
Well, there's a much more constructive way in doing that instead of
going on with the discussion here: test the alpha. File bugs. You
already have been very successful with that, so please go on.
Anyway, I won't reply to this discussion anymore. I am happy to
reinvestigate this whole issue again if we run into real trouble, but so
far you are "seeing patterns" where no patterns are and from my
perspective everything is working out very well so far.
Thanks,
Lennart
--
Lennart Poettering - Red Hat, Inc.
4:31 p.m.
New subject: systemd and changes
On Mon, 2010-08-23 at 22:57 +0200, Lennart Poettering wrote:
On Mon, 23.08.10 16:17, Matthew Miller (mattdm(a)mattdm.org) wrote:
> Oh, I have found a later meeting, from August 3rd. There, the
comments
> (after a brief discussion o updating the wiki)
[snip]
> [... different-topic python packaging comment elided ... ]
> 20:06:52 <dmalcolm> nirik: given that as it stands it's less featureful
> that ubuntu's version of the same, it's debatable that it's
now a
> "feature"
I am not sure where this comes from, but well, there is not really much
truth in it.
In that part of the conversation quoted above, I was referring to:
https://fedoraproject.org/wiki/Features/DebugPythonStacks
not to systemd (this is the "different-topic python packaging comment"
referred to).
Sorry for any confusion.
> 20:07:05 <dmalcolm> nirik: hence F15, I think
> 20:07:11 <mclasen> nirik/adamw: I know lennart was working on a bugfix
> release of systemd todasy
> 20:07:45 <nirik> dmalcolm: yeah, no shame in moving it out a release...
> 20:07:49 <adamw> yeah, we're going to need one to fix the 100% CPU usage
bug
> at a minimum.
Likewise, in the above fragment, both nirik and I were discussing the
DebugPythonStacks feature, whereas mclasen and adamw were talking about
systemd, I believe.
[snip]
Hope this makes sense
Dave
4:47 p.m.
New subject: systemd and changes
On Mon, 23.08.10 17:31, David Malcolm (dmalcolm(a)redhat.com) wrote:
> > 20:07:05 <dmalcolm> nirik: hence F15, I think
> > 20:07:11 <mclasen> nirik/adamw: I know lennart was working on a bugfix
> > release of systemd todasy
> > 20:07:45 <nirik> dmalcolm: yeah, no shame in moving it out a
release...
> > 20:07:49 <adamw> yeah, we're going to need one to fix the 100% CPU
usage bug
> > at a minimum.
Likewise, in the above fragment, both nirik and I were discussing the
DebugPythonStacks feature, whereas mclasen and adamw were talking about
systemd, I believe.
David, thanks for the clarifications! Much appreciated!
Matthew, I think you need to choose your examples more
carefully. This is funny. ;-)
Lennart
--
Lennart Poettering - Red Hat, Inc.
5:24 p.m.
New subject: systemd and changes
On Mon, 2010-08-23 at 23:47 +0200, Lennart Poettering wrote:
On Mon, 23.08.10 17:31, David Malcolm (dmalcolm(a)redhat.com) wrote:
> > > 20:07:05 <dmalcolm> nirik: hence F15, I think
> > > 20:07:11 <mclasen> nirik/adamw: I know lennart was working on a
bugfix
> > > release of systemd todasy
> > > 20:07:45 <nirik> dmalcolm: yeah, no shame in moving it out a
release...
> > > 20:07:49 <adamw> yeah, we're going to need one to fix the 100%
CPU usage bug
> > > at a minimum.
>
> Likewise, in the above fragment, both nirik and I were discussing the
> DebugPythonStacks feature, whereas mclasen and adamw were talking about
> systemd, I believe.
David, thanks for the clarifications! Much appreciated!
Matthew, I think you need to choose your examples more
carefully. This is funny. ;-)
I really don't want to get drawn into this, but here goes...
From my recollection of Matthew's email (I've already deleted
most of
this thread), it looked like he took care to isolate those
PythonDebugStacks parts of the discussion from the parts discussing
systemd, and that he had highlighted other parts of the discussion that
_did_ pertain to systemd.
But I could be misremembering; in any case, please give Matthew the
benefit of the doubt here.
With my former "QA architect" hat on: please do have a test day for
systemd, and try to cover a broad range of different uses and use cases:
with a change this deep, it's the things you're not expecting that cause
the "interesting" problems, alas. I think a test day should also help
identify what experienced Fedora users expect from their services
framework, and ameliorate some communication difficulties here (in
particular, catering to the sysadmin persona - you do use personae in
your designs, right?). The "mere" act of writing test cases for a piece
of software often turns up interesting issues to do with what the scope
of a project is, and differences in expectation between different
stakeholders.
(This thread is already too long, though)
Hope this is helpful.
Dave
5:44 p.m.
New subject: systemd and changes
On Mon, 23.08.10 18:24, David Malcolm (dmalcolm(a)redhat.com) wrote:
With my former "QA architect" hat on: please do have a test
day for
systemd, and try to cover a broad range of different uses and use cases:
with a change this deep, it's the things you're not expecting that cause
the "interesting" problems, alas. I think a test day should also help
identify what experienced Fedora users expect from their services
framework, and ameliorate some communication difficulties here (in
particular, catering to the sysadmin persona - you do use personae in
your designs, right?). The "mere" act of writing test cases for a piece
of software often turns up interesting issues to do with what the scope
of a project is, and differences in expectation between different
stakeholders.
Yupp, I already talked with Adam about this, and he suggested 16th
september, but I haven't responded to his suggestion so far.
/me does that now.
Lennart
--
Lennart Poettering - Red Hat, Inc.
3:59 p.m.
New subject: systemd and changes
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/23/10 1:17 PM, Matthew Miller wrote:
I understand your desire to get your code out there in the real
world. But
Fedora really can't afford to have a marketing-disaster release right now.
Because this is a far-reaching change to a core service, any problems people
encounter will be amplified -- and amplified *way more* than my little
complaints. I want to avoid that.
Also note that Fedora 15 development is happening now, rawhide is
composing each night, and systemd could be tested there just as easily
as tested with Fedora 14 branched. Unlike the old days if you missed
one release you had to wait months before trying again, we now are able
to give you a development tree for the next release immediately.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxy4U0ACgkQ4v2HLvE71NVrnACfSdDiiYsZDxeqhIF5hL/+X0/K
pBsAn1uxW7AQWvklNwnnZq3Kzo5Hs+Wd
=Kai9
-----END PGP SIGNATURE-----
4:08 p.m.
New subject: systemd and changes
On Mon, 23.08.10 13:59, Jesse Keating (jkeating(a)j2solutions.net) wrote:
On 8/23/10 1:17 PM, Matthew Miller wrote:
> I understand your desire to get your code out there in the real world. But
> Fedora really can't afford to have a marketing-disaster release right now.
> Because this is a far-reaching change to a core service, any problems people
> encounter will be amplified -- and amplified *way more* than my little
> complaints. I want to avoid that.
Also note that Fedora 15 development is happening now, rawhide is
composing each night, and systemd could be tested there just as easily
as tested with Fedora 14 branched. Unlike the old days if you missed
one release you had to wait months before trying again, we now are able
to give you a development tree for the next release immediately.
Well, but why? things in F14 are jolly?
Either stop this discussion or tell me exactly which bug you think is
the one that makes you think that "systemd for f14" doesn't work out?
Lennart
--
Lennart Poettering - Red Hat, Inc.
4:29 p.m.
New subject: systemd and changes
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/23/10 2:08 PM, Lennart Poettering wrote:
Well, but why? things in F14 are jolly?
Either stop this discussion or tell me exactly which bug you think is
the one that makes you think that "systemd for f14" doesn't work out?
I don't have an opinion on that front. I'm just trying to show that
/if/ it was decided that F14 was a no-go for systemd, all is not lost
and development+testing can continue in the F15 tree.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxy6FcACgkQ4v2HLvE71NXUvACcCwfqQ9M44291YepMDHnFjPAl
WSsAoJKwcKbBEO+B9g/lIAqAAbHIwUE4
=7UQn
-----END PGP SIGNATURE-----
7:04 p.m.
New subject: systemd and changes
On Mon, Aug 23, 2010 at 11:08:24PM +0200, Lennart Poettering wrote:
On Mon, 23.08.10 13:59, Jesse Keating (jkeating(a)j2solutions.net)
wrote:
> On 8/23/10 1:17 PM, Matthew Miller wrote:
> > I understand your desire to get your code out there in the real world. But
> > Fedora really can't afford to have a marketing-disaster release right now.
> > Because this is a far-reaching change to a core service, any problems people
> > encounter will be amplified -- and amplified *way more* than my little
> > complaints. I want to avoid that.
>
> Also note that Fedora 15 development is happening now, rawhide is
> composing each night, and systemd could be tested there just as easily
> as tested with Fedora 14 branched. Unlike the old days if you missed
> one release you had to wait months before trying again, we now are able
> to give you a development tree for the next release immediately.
Well, but why? things in F14 are jolly?
Either stop this discussion or tell me exactly which bug you think is
the one that makes you think that "systemd for f14" doesn't work out?
Maybe I should start a new thread since this isn't really a bug, but it is
a blocker -- we need to get some packaging guidelines out for systemd.
I think that the last message on the subject was this one:
http://lists.fedoraproject.org/pipermail/devel/2010-July/139483.html
Could I get a reply as to whether that looks right?
I'm not sure if the systemd binary names have changed since that post.
As noted in the post, I'm not sure if the outlined procedure correctly
implements level 1.
We should probably also have the scriptlets for implementing level 3 for the
things basic to the system that require that.
-Toshio
1:36 p.m.
New subject: systemd and changes
On Mon, 23.08.10 20:04, Toshio Kuratomi (a.badger(a)gmail.com) wrote:
On Mon, Aug 23, 2010 at 11:08:24PM +0200, Lennart Poettering wrote:
> On Mon, 23.08.10 13:59, Jesse Keating (jkeating(a)j2solutions.net) wrote:
>
> > On 8/23/10 1:17 PM, Matthew Miller wrote:
> > > I understand your desire to get your code out there in the real world.
But
> > > Fedora really can't afford to have a marketing-disaster release right
now.
> > > Because this is a far-reaching change to a core service, any problems
people
> > > encounter will be amplified -- and amplified *way more* than my little
> > > complaints. I want to avoid that.
> >
> > Also note that Fedora 15 development is happening now, rawhide is
> > composing each night, and systemd could be tested there just as easily
> > as tested with Fedora 14 branched. Unlike the old days if you missed
> > one release you had to wait months before trying again, we now are able
> > to give you a development tree for the next release immediately.
>
> Well, but why? things in F14 are jolly?
>
> Either stop this discussion or tell me exactly which bug you think is
> the one that makes you think that "systemd for f14" doesn't work out?
>
Maybe I should start a new thread since this isn't really a bug, but it is
a blocker -- we need to get some packaging guidelines out for systemd.
I think that the last message on the subject was this one:
http://lists.fedoraproject.org/pipermail/devel/2010-July/139483.html
Could I get a reply as to whether that looks right?
There's something missing about how to handle upgrades from only-sysv to
both-sysv-and-systemd packages. i.e. you need to check whether sysv is
enabled and enable the systemd services accordingly. This is described
in daemon(7) in more detail.
As noted in the post, I'm not sure if the outlined procedure
correctly
implements level 1.
We should probably also have the scriptlets for implementing level 3 for the
things basic to the system that require that.
Tbh I'd not amend the policy for now, if that's acceptable. The policy
currently says that packages should have SysV scripts and that's a good
thing. Some selected pkgs now contain systemd unit files in addition to
sysv init scripts, but the only policy I'd recommend for them is to say
that they should enable/disable/start/stop these exactly in the same
cases as the sysv scripts previously were. And I'd say that such a
policy is clear anyway.
In the F15 cycle we should then revisit this, and come up with a sane
policy and even make sysv scripts optional. However, note that this all
will probably turn out more complex than it might look: for example,
so far no policy for D-Bus services existed, and all D-Bus services
that are bus activatable are enabled unconditionally and cannot be
disabled without removing the package. Something similar applied to
stuff that got started via Upstart or udev: so far it was not possible
to disable these services in a sane way.
The policy in F15 should cover all these cases, as we shift the focus
away from start-everything-on-bootup to a scheme where things are more
dynamic.
Or in other words: I don't think we should rush out a policy here, let's
continue to work for what we have in F14, and then in F15 come up with a
comprehensive policy on this, which would even incorporate the
experiences we gained with the selected packages which already shipped
both sysv and systemd unit files in F14.
BTW, was there a written down policy on how to package Upstart
jobs/services?
Lennart
--
Lennart Poettering - Red Hat, Inc.
2:29 a.m.
New subject: systemd and changes
On Mon, 23 Aug 2010 16:17:21 -0400, Matthew wrote:
Was there a conversation other than this FESCO meeting?
<http://meetbot.fedoraproject.org/fedora-meeting/2010-06-15/fesco.2010-06-...
There, I see this discussion:
20:51:41 <mezcalero> so, i would like to keep the options open, but i'd
like to see the testing for the case "systemd as default"
[...]
I'm not sure if you actually read this
before or participated directly in the discussion, but [...]
"mezcalero" is Lennart himself. Or more precisely, one of his user names.
[Doesn't make it impossible for somebody else to enter IRC with that
name (and perhaps register that one even if not occupied already), but
well, that's beyond the scope of this reply.]
--
Fedora release 14 (Laughlin) - Linux 2.6.35.2-9.fc14.x86_64
loadavg: 0.38 0.29 0.28
1:05 p.m.
New subject: systemd and changes
On Tue, 24.08.10 09:29, Michael Schwendt (mschwendt(a)gmail.com) wrote:
On Mon, 23 Aug 2010 16:17:21 -0400, Matthew wrote:
> Was there a conversation other than this FESCO meeting?
>
<http://meetbot.fedoraproject.org/fedora-meeting/2010-06-15/fesco.2010-06-...
>
> There, I see this discussion:
>
> 20:51:41 <mezcalero> so, i would like to keep the options open, but i'd
> like to see the testing for the case "systemd as default"
> [...]
> I'm not sure if you actually read this
> before or participated directly in the discussion, but [...]
"mezcalero" is Lennart himself. Or more precisely, one of his user
names.
I only ever use this one. No split personality here, sorry ;-)
Lennart
--
Lennart Poettering - Red Hat, Inc.
6:44 p.m.
New subject: systemd and changes
Matthew Miller wrote:
I understand your desire to get your code out there in the real
world. But
Fedora really can't afford to have a marketing-disaster release right now.
We already had one, Fedora 9 (KDE 4.0.x anyone?). And well, we survived, and
I still believe that what we did was ultimately the right thing, despite all
the whining and naysaying.
Kevin Kofler
6:46 p.m.
New subject: systemd and changes
+1 to kevin
On Wed, Aug 25, 2010 at 11:44 AM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Matthew Miller wrote:
> I understand your desire to get your code out there in the real world. But
> Fedora really can't afford to have a marketing-disaster release right now.
We already had one, Fedora 9 (KDE 4.0.x anyone?). And well, we survived, and
I still believe that what we did was ultimately the right thing, despite all
the whining and naysaying.
Kevin Kofler
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Kind Regards
Jose M Manimala
http://josemanimala.eu.org/blog
GPGkeyID: 1BE49F39
3:32 p.m.
New subject: systemd and changes
Matthew Miller (mattdm(a)mattdm.org) said:
So, I'm honestly asking: what are the odds that these few things
are the
only improvements that cause a disruptive change to user interaction? I
don't think it's unreasonable to wonder if there are other changes which fit
this category.
My concern with this line of thinking is that you're asking us to quantify
the unknown unknown, and define a time period of testing which is
'long enough' for us to catch all the unknown unknowns. This seems
impractical, in as much as it doesn't give us any clear criteria to define
success with.
Bill
3:52 p.m.
New subject: systemd and changes
On Mon, 23 Aug 2010, Bill Nottingham wrote:
Matthew Miller (mattdm(a)mattdm.org) said:
> So, I'm honestly asking: what are the odds that these few things are the
> only improvements that cause a disruptive change to user interaction? I
> don't think it's unreasonable to wonder if there are other changes which
fit
> this category.
My concern with this line of thinking is that you're asking us to quantify
the unknown unknown, and define a time period of testing which is
'long enough' for us to catch all the unknown unknowns. This seems
impractical, in as much as it doesn't give us any clear criteria to define
success with.
It's just risk management. I think we'd be better off acknowledging there
are unknown unknowns and try to mitigate them. One way we could have done
that this time around was making it an optional feature (as Matt was
mentioning in a previous email) for F14 and then decide in F15 if it was
ready. Unfortunately that's not the path we seem to be on. We unwisely
seemed to declare it ready before anyone even saw it then we ignored what
we didn't know as if we knew there were going to be no problems. The sad
thing is that's such an easy fix by making brand new features for core
components like this opt in, even if it's just for a single release.
-Mike
4:05 p.m.
New subject: systemd and changes
On Mon, 23.08.10 15:52, Mike McGrath (mmcgrath(a)redhat.com) wrote:
On Mon, 23 Aug 2010, Bill Nottingham wrote:
> Matthew Miller (mattdm(a)mattdm.org) said:
> > So, I'm honestly asking: what are the odds that these few things are the
> > only improvements that cause a disruptive change to user interaction? I
> > don't think it's unreasonable to wonder if there are other changes
which fit
> > this category.
>
> My concern with this line of thinking is that you're asking us to quantify
> the unknown unknown, and define a time period of testing which is
> 'long enough' for us to catch all the unknown unknowns. This seems
> impractical, in as much as it doesn't give us any clear criteria to define
> success with.
>
It's just risk management. I think we'd be better off acknowledging there
are unknown unknowns and try to mitigate them. One way we could have done
that this time around was making it an optional feature (as Matt was
mentioning in a previous email) for F14 and then decide in F15 if it was
ready. Unfortunately that's not the path we seem to be on. We unwisely
seemed to declare it ready before anyone even saw it then we ignored what
we didn't know as if we knew there were going to be no problems. The sad
thing is that's such an easy fix by making brand new features for core
components like this opt in, even if it's just for a single release.
I am sorry, but your are discussing all this from the perspective as if
something went really horribly wrong with how things worked out. But
frankly, I don't even see what even remotely went wrong. So far, I am
myself surprised how smooth this all went. I was prepared for much
worse, I have expected much worse.
I know I am repeating myself: everything's wonderful.
I am quite frankly amazed about the magic powers of fedora-devel to
discuss to death issues that quite frankly have no base at all.
Stoping making up a case were no case can be made up.
Lennart
--
Lennart Poettering - Red Hat, Inc.
4:17 p.m.
New subject: systemd and changes
On Monday, August 23, 2010 04:05:11 pm Lennart Poettering wrote:
On Mon, 23.08.10 15:52, Mike McGrath (mmcgrath(a)redhat.com) wrote:
> On Mon, 23 Aug 2010, Bill Nottingham wrote:
> > Matthew Miller (mattdm(a)mattdm.org) said:
> > > So, I'm honestly asking: what are the odds that these few things are
> > > the only improvements that cause a disruptive change to user
> > > interaction? I don't think it's unreasonable to wonder if there
are
> > > other changes which fit this category.
> >
> > My concern with this line of thinking is that you're asking us to
> > quantify the unknown unknown, and define a time period of testing
> > which is 'long enough' for us to catch all the unknown unknowns. This
> > seems impractical, in as much as it doesn't give us any clear criteria
> > to define success with.
>
> It's just risk management. I think we'd be better off acknowledging
> there are unknown unknowns and try to mitigate them. One way we could
> have done that this time around was making it an optional feature (as
> Matt was mentioning in a previous email) for F14 and then decide in F15
> if it was ready. Unfortunately that's not the path we seem to be on.
> We unwisely seemed to declare it ready before anyone even saw it then we
> ignored what we didn't know as if we knew there were going to be no
> problems. The sad thing is that's such an easy fix by making brand new
> features for core components like this opt in, even if it's just for a
> single release.
I am sorry, but your are discussing all this from the perspective as if
something went really horribly wrong with how things worked out. But
frankly, I don't even see what even remotely went wrong. So far, I am
myself surprised how smooth this all went. I was prepared for much
worse, I have expected much worse.
I know I am repeating myself: everything's wonderful.
Umm we discussed for many hours on friday the issue im having that is
resulting im my desktop being unable to boot since now the network service
will not start which also causes dbus to not start and my sysetm to never
fully come up.
With no outcome other than to stick with upstart for now its not all
wonderful and peachy. it has been the case forever that if your using ldap
for auth you need to have network start before dbus that has always been the
answer but you broke that from happening.
Dennis
4:29 p.m.
New subject: systemd and changes
On Mon, 23 Aug 2010 16:17:26 -0500
Dennis Gilmore <dennis(a)ausil.us> wrote:
With no outcome other than to stick with upstart for now its not all
wonderful and peachy. it has been the case forever that if your
using ldap for auth you need to have network start before dbus that
I think you mean ^^^^ user enumeration here ?
has always been the answer but you broke that from happening.
Stop using nss_ldap and use sssd instead and the problem will magically
go away by itself.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
4:33 p.m.
New subject: systemd and changes
On Mon, 23.08.10 16:17, Dennis Gilmore (dennis(a)ausil.us) wrote:
> > It's just risk management. I think we'd be better
off acknowledging
> > there are unknown unknowns and try to mitigate them. One way we could
> > have done that this time around was making it an optional feature (as
> > Matt was mentioning in a previous email) for F14 and then decide in F15
> > if it was ready. Unfortunately that's not the path we seem to be on.
> > We unwisely seemed to declare it ready before anyone even saw it then we
> > ignored what we didn't know as if we knew there were going to be no
> > problems. The sad thing is that's such an easy fix by making brand new
> > features for core components like this opt in, even if it's just for a
> > single release.
>
> I am sorry, but your are discussing all this from the perspective as if
> something went really horribly wrong with how things worked out. But
> frankly, I don't even see what even remotely went wrong. So far, I am
> myself surprised how smooth this all went. I was prepared for much
> worse, I have expected much worse.
>
> I know I am repeating myself: everything's wonderful.
Umm we discussed for many hours on friday the issue im having that is
resulting im my desktop being unable to boot since now the network service
will not start which also causes dbus to not start and my sysetm to never
fully come up.
With no outcome other than to stick with upstart for now its not all
wonderful and peachy. it has been the case forever that if your using ldap
for auth you need to have network start before dbus that has always been the
answer but you broke that from happening.
Well, that's not entirely fair I think. Most people taking part in the
discussion I think agreed that it's pam_ldap's fault here or at least
dbus', some even suggested to remove pam_ldap from the distribution
entirely, and adviced you to use sssd instead.
This is mostly a bug that becomes visible through systemd, but has been
existing since about forever, and you can easily trigger problems with
it even in other contexts.
While I personally believe that this problem is not particularly crucial
and as I understood you you even agreed on trying sssd instead, I'd be
willing to sit down and unfuck pam_ldap to the level that makes this
work, should FESCO come to the conclusion that it matters. The problem
is probably easy to fix actually as pam_ldap should just cleanly refuse
service if the network isn't around.
Lennart
--
Lennart Poettering - Red Hat, Inc.
4:38 p.m.
New subject: systemd and changes
On Mon, Aug 23, 2010 at 23:05:11 +0200,
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
I know I am repeating myself: everything's wonderful.
Maybe now, but the landing close to alpha made it harder to do some other
testing needed before the alpha. (Though the fallout from Python and Boost
updates, seemed worse.)
I would have liked to have seen this land about a month earlier than it did.
4:09 p.m.
New subject: systemd and changes
Mike McGrath (mmcgrath(a)redhat.com) said:
> My concern with this line of thinking is that you're asking
us to quantify
> the unknown unknown, and define a time period of testing which is
> 'long enough' for us to catch all the unknown unknowns. This seems
> impractical, in as much as it doesn't give us any clear criteria to define
> success with.
It's just risk management. I think we'd be better off acknowledging there
are unknown unknowns and try to mitigate them.
Sure, but when you say 'we should hold off X period of time' in order to
mitigate unknown unknowns, how do you define 'X'? How do you know when it's
ready? All I'm seeing are appeals to gut feelings. We can all say that 'more
time == more testing', but how do you claim 'good enough'?
ready. Unfortunately that's not the path we seem to be on. We
unwisely
seemed to declare it ready before anyone even saw it then we ignored what
we didn't know as if we knew there were going to be no problems. The sad
thing is that's such an easy fix by making brand new features for core
components like this opt in, even if it's just for a single release.
Having to support multiple boot paths for the system, making everyone
who gets odd bugs filed against kernel, dracut, plymouth, etc. triage them
isn't exactly an 'easy fix' - it *adds* complication to both paths.
Bill
4:22 p.m.
New subject: systemd and changes
On Mon, 23 Aug 2010, Bill Nottingham wrote:
Mike McGrath (mmcgrath(a)redhat.com) said:
> > My concern with this line of thinking is that you're asking us to quantify
> > the unknown unknown, and define a time period of testing which is
> > 'long enough' for us to catch all the unknown unknowns. This seems
> > impractical, in as much as it doesn't give us any clear criteria to define
> > success with.
>
> It's just risk management. I think we'd be better off acknowledging there
> are unknown unknowns and try to mitigate them.
Sure, but when you say 'we should hold off X period of time' in order to
mitigate unknown unknowns, how do you define 'X'? How do you know when it's
ready? All I'm seeing are appeals to gut feelings. We can all say that 'more
time == more testing', but how do you claim 'good enough'?
I'd say one release is good enough for Fedora.
> ready. Unfortunately that's not the path we seem to be on.
We unwisely
> seemed to declare it ready before anyone even saw it then we ignored what
> we didn't know as if we knew there were going to be no problems. The sad
> thing is that's such an easy fix by making brand new features for core
> components like this opt in, even if it's just for a single release.
Having to support multiple boot paths for the system, making everyone
who gets odd bugs filed against kernel, dracut, plymouth, etc. triage them
isn't exactly an 'easy fix' - it *adds* complication to both paths.
I'd rather have multiple boot paths to choose from then only one boot path
that is 2 months old. It should be added to the cost of the change.
(yet another thing we ignored in this process). My experience has so far
been very bad with systemd so when Lennart proclaims that everything's
fine, I'm just filled with more worry.
I'm trying to figure out how to prevent this in the future so we stop
losing users. (Yes, we really are at pre-FC6 numbers wrt user base which
means we have the fewest number of users since we started keeping track of
such things) and I think it's because of poorly planned "features" like
these.
-Mike
4:30 p.m.
New subject: systemd and changes
On Mon, Aug 23, 2010 at 11:22 PM, Mike McGrath <mmcgrath(a)redhat.com> wrote:
On Mon, 23 Aug 2010, Bill Nottingham wrote:
> Mike McGrath (mmcgrath(a)redhat.com) said:
> > > My concern with this line of thinking is that you're asking us to
quantify
> > > the unknown unknown, and define a time period of testing which is
> > > 'long enough' for us to catch all the unknown unknowns. This seems
> > > impractical, in as much as it doesn't give us any clear criteria to
define
> > > success with.
> >
> > It's just risk management. I think we'd be better off acknowledging
there
> > are unknown unknowns and try to mitigate them.
>
> Sure, but when you say 'we should hold off X period of time' in order to
> mitigate unknown unknowns, how do you define 'X'? How do you know when
it's
> ready? All I'm seeing are appeals to gut feelings. We can all say that 'more
> time == more testing', but how do you claim 'good enough'?
>
I'd say one release is good enough for Fedora.
> > ready. Unfortunately that's not the path we seem to be on. We unwisely
> > seemed to declare it ready before anyone even saw it then we ignored what
> > we didn't know as if we knew there were going to be no problems. The sad
> > thing is that's such an easy fix by making brand new features for core
> > components like this opt in, even if it's just for a single release.
>
> Having to support multiple boot paths for the system, making everyone
> who gets odd bugs filed against kernel, dracut, plymouth, etc. triage them
> isn't exactly an 'easy fix' - it *adds* complication to both paths.
>
I'd rather have multiple boot paths to choose from then only one boot path
that is 2 months old.
Being "2 months old" isn't a problem in itself ... bugs on the other
hand might be if they can't be fixed in time (this does not include
already fixed ones).
4:42 p.m.
New subject: systemd and changes
On Mon, Aug 23, 2010 at 23:30:22 +0200,
drago01 <drago01(a)gmail.com> wrote:
Being "2 months old" isn't a problem in itself ... bugs on the other
hand might be if they can't be fixed in time (this does not include
already fixed ones).
It is already too late. The bugs impacted alpha testing and probably in
at least part contributed to the slip.
Features (changes in general) that impact testing of significant fractions
of the system should not be landing close to the alpha freeze. It makes it
difficult for other people to get their work done.
12:01 a.m.
New subject: systemd and changes
2010/8/23 drago01 <drago01(a)gmail.com>:
On Mon, Aug 23, 2010 at 11:22 PM, Mike McGrath
<mmcgrath(a)redhat.com> wrote:
> On Mon, 23 Aug 2010, Bill Nottingham wrote:
>
>> Mike McGrath (mmcgrath(a)redhat.com) said:
>> > > My concern with this line of thinking is that you're asking us to
quantify
>> > > the unknown unknown, and define a time period of testing which is
>> > > 'long enough' for us to catch all the unknown unknowns. This
seems
>> > > impractical, in as much as it doesn't give us any clear criteria to
define
>> > > success with.
>> >
>> > It's just risk management. I think we'd be better off acknowledging
there
>> > are unknown unknowns and try to mitigate them.
>>
>> Sure, but when you say 'we should hold off X period of time' in order to
>> mitigate unknown unknowns, how do you define 'X'? How do you know when
it's
>> ready? All I'm seeing are appeals to gut feelings. We can all say that
'more
>> time == more testing', but how do you claim 'good enough'?
>>
>
> I'd say one release is good enough for Fedora.
>
>> > ready. Unfortunately that's not the path we seem to be on. We
unwisely
>> > seemed to declare it ready before anyone even saw it then we ignored what
>> > we didn't know as if we knew there were going to be no problems. The
sad
>> > thing is that's such an easy fix by making brand new features for core
>> > components like this opt in, even if it's just for a single release.
>>
>> Having to support multiple boot paths for the system, making everyone
>> who gets odd bugs filed against kernel, dracut, plymouth, etc. triage them
>> isn't exactly an 'easy fix' - it *adds* complication to both paths.
>>
>
> I'd rather have multiple boot paths to choose from then only one boot path
> that is 2 months old.
Being "2 months old" isn't a problem in itself ... bugs on the other
hand might be if they can't be fixed in time (this does not include
already fixed ones).
it is, because 2 months for a critical system that is required for
booting doesent provide enough time for testing at all. just note that
after reinstalling systemd on rawhide it now boots again (the
introduced bugs with linking havent been properly fixed by package
updates but only with a reinstall since the workarounds published on
the list didnt work for me at all) , but for some reason
networkmanager didnt start automatically at boot. a problem found in a
few seconds of looking at it. a change like that needs a longer
testing period. i agree that fieldtesting is a really good way of
finding alot bugs quickly and getting them fixed but that is really
what rawhide is there for. Sorry for not beeing that optimistic after
working with software for a rather long time.
kind regards,
Rudolf Kastl
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
4:32 p.m.
New subject: systemd and changes
Not answering Mike directly here, but the thread in general...
IMHO, it's too early to have this discussion.
Alpha has not even been released...
Instead, before:
2010-09-14 Beta Change Deadline
Features 100% Complete
We should look at the state of things and decide if we should revert
(just like any other feature thats not ready).
So, please everyone test and file bugs and note your cases where things
don't work and we can evaluate before the Beta Change deadline.
kevin
(speaking for myself)
5:04 p.m.
New subject: systemd and changes
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/23/10 2:32 PM, Kevin Fenzi wrote:
Not answering Mike directly here, but the thread in general...
IMHO, it's too early to have this discussion.
Alpha has not even been released...
Instead, before:
2010-09-14 Beta Change Deadline
Features 100% Complete
We should look at the state of things and decide if we should revert
(just like any other feature thats not ready).
So, please everyone test and file bugs and note your cases where things
don't work and we can evaluate before the Beta Change deadline.
kevin
(speaking for myself)
As to not keep moving the goal posts for Lennart, I believe that some
group (perhaps FESCo) should come up with a set of "do or die"
functionality for systemd, that can be tested for at the test day. That
way the goals are clearly marked. If it passes, hurray! If it doesn't
pass, then FESCo would be able to give Lennart a timeline to make them
pass, or enact the rollback plan. Obviously this timeline should leave
enough time at the end of it to enact the rollback plan without causing
Beta to slip. Or FESCo could decide that systemd is worth slipping for
and thus enact a slip until systemd can pass the "do or die" test set.
Either way, clearly mark the goals, let Lennart shoot for them.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxy8HgACgkQ4v2HLvE71NX9DwCfbWvTeeOAYcT+odSyhqUO1AtE
VTgAoLUfTgSl7IvZ4Go0tZ+DPprRalZ0
=TePV
-----END PGP SIGNATURE-----
9:48 a.m.
New subject: systemd and changes
On Mon, Aug 23, 2010 at 03:04:43PM -0700, Jesse Keating wrote:
As to not keep moving the goal posts for Lennart, I believe that
some
group (perhaps FESCo) should come up with a set of "do or die"
functionality for systemd, that can be tested for at the test day. That
way the goals are clearly marked. If it passes, hurray! If it doesn't
pass, then FESCo would be able to give Lennart a timeline to make them
pass, or enact the rollback plan. Obviously this timeline should leave
enough time at the end of it to enact the rollback plan without causing
Beta to slip. Or FESCo could decide that systemd is worth slipping for
and thus enact a slip until systemd can pass the "do or die" test set.
Either way, clearly mark the goals, let Lennart shoot for them.
FTR, this sounds perfect to me. I am not opposed to systemd a priori.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
4:35 p.m.
New subject: systemd and changes
On Mon, 23.08.10 16:22, Mike McGrath (mmcgrath(a)redhat.com) wrote:
(yet another thing we ignored in this process). My experience has so
far
been very bad with systemd so when Lennart proclaims that everything's
fine, I'm just filled with more worry.
Bugzilla ids please?
Lennart
--
Lennart Poettering - Red Hat, Inc.
4:39 p.m.
New subject: systemd and changes
On Mon, 23 Aug 2010, Lennart Poettering wrote:
On Mon, 23.08.10 16:22, Mike McGrath (mmcgrath(a)redhat.com) wrote:
> (yet another thing we ignored in this process). My experience has so far
> been very bad with systemd so when Lennart proclaims that everything's
> fine, I'm just filled with more worry.
Bugzilla ids please?
You fixed them all so far, then got onto devel and pretended that fixed
bugs mean no bugs. So yes, to put it as directly as possible: My
experience with systemd has been absolutely horrible.
-Mike
4:58 p.m.
New subject: systemd and changes
On Mon, 23.08.10 16:39, Mike McGrath (mmcgrath(a)redhat.com) wrote:
On Mon, 23 Aug 2010, Lennart Poettering wrote:
> On Mon, 23.08.10 16:22, Mike McGrath (mmcgrath(a)redhat.com) wrote:
>
> > (yet another thing we ignored in this process). My experience has so far
> > been very bad with systemd so when Lennart proclaims that everything's
> > fine, I'm just filled with more worry.
>
> Bugzilla ids please?
>
You fixed them all so far, then got onto devel and pretended that fixed
bugs mean no bugs. So yes, to put it as directly as possible: My
experience with systemd has been absolutely horrible.
"Pretended on devel"?
I am not sure what your problem with me or systemd is, but I'd prefer
you dropped those personal attacks, or at least if you call me a
pretender point me to where I supposedly "pretended" something.
Also, given how "horrible" your experience was: you haven't file a
single bug against systemd. Ever.
What you are doing is fudding, stop that.
Be more constructive. I am very open to suggestions on systemd, and I
have responded to all bugs coming up in this matter very quickly. If
you cannot appreciate that then at least please don't constantly
interfere. Thank you.
Lennart
--
Lennart Poettering - Red Hat, Inc.
5:04 p.m.
New subject: systemd and changes
On Mon, 23 Aug 2010, Lennart Poettering wrote:
On Mon, 23.08.10 16:39, Mike McGrath (mmcgrath(a)redhat.com) wrote:
>
> On Mon, 23 Aug 2010, Lennart Poettering wrote:
>
> > On Mon, 23.08.10 16:22, Mike McGrath (mmcgrath(a)redhat.com) wrote:
> >
> > > (yet another thing we ignored in this process). My experience has so far
> > > been very bad with systemd so when Lennart proclaims that
everything's
> > > fine, I'm just filled with more worry.
> >
> > Bugzilla ids please?
> >
>
> You fixed them all so far, then got onto devel and pretended that fixed
> bugs mean no bugs. So yes, to put it as directly as possible: My
> experience with systemd has been absolutely horrible.
"Pretended on devel"?
I am not sure what your problem with me or systemd is, but I'd prefer
you dropped those personal attacks, or at least if you call me a
pretender point me to where I supposedly "pretended" something.
Also, given how "horrible" your experience was: you haven't file a
single bug against systemd. Ever.
Because the bugs were so obvious that others filed them?
What you are doing is fudding, stop that.
Be more constructive. I am very open to suggestions on systemd, and I
have responded to all bugs coming up in this matter very quickly. If
you cannot appreciate that then at least please don't constantly
interfere. Thank you.
No you're not, you fight change at every turn and have completely
dismissed my concerns and Matt's concerns as "funny". I have nothing more
to say to you on this or on Pulseaudio except to hope that systemd is as
easy to uninstall. Do what you want. No one seems to be able to steer
this Fedora boat so do whatever you want.
-Mike
5:12 p.m.
New subject: systemd and changes
On 08/24/2010 03:34 AM, Mike McGrath wrote:
No you're not, you fight change at every turn and have
completely
dismissed my concerns and Matt's concerns as "funny". I have nothing more
to say to you on this or on Pulseaudio except to hope that systemd is as
easy to uninstall. Do what you want. No one seems to be able to steer
this Fedora boat so do whatever you want.
The bugs Matt pointed out were fixed very quickly and the comment about
being "funny" were in reaction to David Malcolm's clarification that
certain quoted portions of the IRC conversations were not concerns
related to systemd at all. I think it would be useful if you point out
specific milestones to accomplish.
Rahul
5:14 p.m.
New subject: systemd and changes
It seems to me that it is mostly sysadmins that are concerned about
systemd. That is understandable, they are the group of users that will
be most affected by the new paradigm, and will have to learn new
tricks.
Yet sysadmins are just a section of the Fedora users. For example,
people that like me that use Fedora at home will hardly notice a
difference - provided bugs are fixed, which they seem to be. And those
like me are not making their voice heard.
Sysadmins have the option of waiting three months after the release
before upgrading, to give time for the dust to settle, or even
skipping F14 altogether, or using upstart by changing the grub menu.
So I say, let's give Lennart a break - he has been working hard on
this - and be optimist!
5:27 p.m.
New subject: systemd and changes
Piscium píše v Po 23. 08. 2010 v 23:14 +0100:
It seems to me that it is mostly sysadmins that are concerned about
systemd. That is understandable, they are the group of users that will
be most affected by the new paradigm, and will have to learn new
tricks.
Yet sysadmins are just a section of the Fedora users. For example,
people that like me that use Fedora at home will hardly notice a
difference - provided bugs are fixed, which they seem to be. And those
like me are not making their voice heard.
If non-sysadmins will hardly notice the
new init system, shouldn't the
sysadmins, who will notice, be the primary consideration?
Mirek
5:38 p.m.
New subject: systemd and changes
2010/8/23 Miloslav Trmač <mitr(a)volny.cz>:
If non-sysadmins will hardly notice the new init system,
shouldn't the
sysadmins, who will notice, be the primary consideration?
Mirek
Not IMO. Sysadmins are just one group of stakeholders. My intervention
was just to put things in perspective.
However if a sysadmin takes care of a network of 100 PCs running
Fedora, for example at a university, one could possibly say that his
voice should have the same weight as 100 home users. But then again
there are no reliable statistics on Linux use, and that includes
Fedora.
7:08 p.m.
New subject: systemd and changes
Miloslav Trmač wrote:
If non-sysadmins will hardly notice the new init system,
shouldn't the
sysadmins, who will notice, be the primary consideration?
Non-sysadmins will notice that their system boots faster, which is a great
thing. Sysadmins will notice the negative effects.
At least that's Piscium's view. We should not forget that home users have to
admin their systems to some extent and thus some home users might also
notice some of those changes to admin interfaces.
Kevin Kofler
1:14 a.m.
New subject: systemd and changes
On Wed, Aug 25, 2010 at 02:08:02AM +0200, Kevin Kofler wrote:
Miloslav Trmač wrote:
> If non-sysadmins will hardly notice the new init system, shouldn't the
> sysadmins, who will notice, be the primary consideration?
Non-sysadmins will notice that their system boots faster, which is a great
thing. Sysadmins will notice the negative effects.
I consider myself sysadmin. And I'm really excited about systemd.
The amount of control it gives me is astounding. Once you read excellent
manpages, all is understandable and quite cool. There are some quirks
I'm not sure will work OK (like interaction between PrivateTmp= and
pam_namespace configured for /tmp like on fedorapeople) but Lennart is
responsive and fixes bugs quickly.
The only disadvantage is need to learn few new commands, but let's be serious.
Being a sysadmin doesn't mean working with stale knowledge from last
century. One has to learn few tricks from time to time, especially in
fast moving environment like Linux. And to utilise all cool things Linux
offers we need new tools. I'm happy to see those tools showing up and using
quite coherent syntax - “tool” “action” “target”. Systemctl has this syntax,
btrfs has this syntax, iscsitadm has it and I find those quite natural.
(Frankly, even slow moving platforms like Solaris introduce new functionality,
requesting competent sysadmin to update his knowledge. SMF, ZFS, Crossbow,
Comstar. All replace or extend existing functionality and are worth few
moments to accomodate).
Unit files are simple and nicely documented. I shiver every time when
I have to write SMF manifest, whereas configuring systemd is pleasure for me.
Creating .service file for running service in idle scheduling class, chrooted,
with lowest IO priority, outputting to syslog, and using executable which
was not meant to be daemonised in the first place is... braindead simple.
It is first time I want to upgrade my home server to branched, just
to get systemd. Don't generalise that sysadms are against systemd.
--
Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking
xmpp: zdzichubg(a)chrome.pl an IP-routable hand grenade.'' -- Andrew Morton
(LKML)
5:39 p.m.
New subject: systemd and changes
On Mon, 23.08.10 17:04, Mike McGrath (mmcgrath(a)redhat.com) wrote:
> I am not sure what your problem with me or systemd is, but
I'd prefer
> you dropped those personal attacks, or at least if you call me a
> pretender point me to where I supposedly "pretended" something.
>
> Also, given how "horrible" your experience was: you haven't file a
> single bug against systemd. Ever.
>
Because the bugs were so obvious that others filed them?
Hmm, can't find you among any CC's of those bugs either, or am I blind?
> What you are doing is fudding, stop that.
>
> Be more constructive. I am very open to suggestions on systemd, and I
> have responded to all bugs coming up in this matter very quickly. If
> you cannot appreciate that then at least please don't constantly
> interfere. Thank you.
>
No you're not, you fight change at every turn and have completely
dismissed my concerns and Matt's concerns as "funny". I have nothing more
to say to you on this or on Pulseaudio except to hope that systemd is as
easy to uninstall. Do what you want. No one seems to be able to steer
this Fedora boat so do whatever you want.
Note that Matthew did acknowledge that I quickly reacted to his requests
and iirc I implemented all his requests in the shutdown situation in
less than 24h, and in the other cases it wasn't much different.
I figured the problem people had with systemd was that it was too much
change, not too little. But you seem to believe otherwise, yay?
Let me clarify that the "funny" comment just referred to the quotes
Matthew used, which turned out to be unrelated to the point he was
actually trying to make.
Lennart
--
Lennart Poettering - Red Hat, Inc.
5 p.m.
New subject: systemd and changes
On 08/24/2010 03:09 AM, Mike McGrath wrote:
You fixed them all so far, then got onto devel and pretended that
fixed
bugs mean no bugs. So yes, to put it as directly as possible: My
experience with systemd has been absolutely horrible.
The tone of the conversation seems to have degraded again. Since
Lennart did fix all the bugs, there aren't any known major known
problems *at this point* and noone has to pretend anything. Let us
revisit this before the feature freeze. We will have a lot more users
testing the alpha release and if we don't find any major issues, that
would be a good amount of assurance.
Rahul
7:10 p.m.
New subject: systemd and changes
Rahul Sundaram wrote:
Let us revisit this before the feature freeze.
I think you mean the feature completion deadline. What we call the "feature
freeze" has already passed. But we allow started features to get completed
until (shortly before) the Beta.
Kevin Kofler
7:01 p.m.
New subject: systemd and changes
Bill Nottingham wrote:
Having to support multiple boot paths for the system, making
everyone
who gets odd bugs filed against kernel, dracut, plymouth, etc. triage them
isn't exactly an 'easy fix' - it *adds* complication to both paths.
Right. In fact, I think we're supporting way too many deprecated
alternatives for way too long, e.g. when will the old legacy "network"
service which has been deprecated for ages finally be gone?
Of course it makes sense to keep deprecated stuff around when it's needed to
make things work, e.g. HAL is still needed for KDE right now (but that might
already be resolved by F15 since work on new u* Solid backends is going
strong upstream, also thanks to Fedora developers from Red Hat Czech), but I
don't see anything requiring e.g. the old "network" to stay around.
Kevin Kofler
7:32 p.m.
New subject: systemd and changes
On 08/24/2010 08:01 PM, Kevin Kofler wrote:
Bill Nottingham wrote:
> Having to support multiple boot paths for the system, making everyone
> who gets odd bugs filed against kernel, dracut, plymouth, etc. triage them
> isn't exactly an 'easy fix' - it *adds* complication to both paths.
Right. In fact, I think we're supporting way too many deprecated
alternatives for way too long, e.g. when will the old legacy "network"
service which has been deprecated for ages finally be gone?
Of course it makes sense to keep deprecated stuff around when it's needed to
make things work, e.g. HAL is still needed for KDE right now (but that might
already be resolved by F15 since work on new u* Solid backends is going
strong upstream, also thanks to Fedora developers from Red Hat Czech), but I
don't see anything requiring e.g. the old "network" to stay around.
Isn't "network" needed for people who don't run NetworkManager?
For the longest time, NM only worked predictably for logged-in users,
which made "network" service a requirement for servers with static IPs
and such.
Jeff
7:34 p.m.
New subject: systemd and changes
On Tue, 24 Aug 2010 20:32:42 -0400
Jeff Garzik <jgarzik(a)pobox.com> wrote:
On 08/24/2010 08:01 PM, Kevin Kofler wrote:
> Bill Nottingham wrote:
>> Having to support multiple boot paths for the system, making
>> everyone who gets odd bugs filed against kernel, dracut, plymouth,
>> etc. triage them isn't exactly an 'easy fix' - it *adds*
>> complication to both paths.
>
> Right. In fact, I think we're supporting way too many deprecated
> alternatives for way too long, e.g. when will the old legacy
> "network" service which has been deprecated for ages finally be
> gone?
>
> Of course it makes sense to keep deprecated stuff around when it's
> needed to make things work, e.g. HAL is still needed for KDE right
> now (but that might already be resolved by F15 since work on new u*
> Solid backends is going strong upstream, also thanks to Fedora
> developers from Red Hat Czech), but I don't see anything requiring
> e.g. the old "network" to stay around.
Isn't "network" needed for people who don't run NetworkManager?
For the longest time, NM only worked predictably for logged-in users,
which made "network" service a requirement for servers with static
IPs and such.
It's still needed for folks who have a bridging setup.
Hopefully soon NM will handle that case, but AFAIK it does not yet.
kevin
7:44 p.m.
New subject: systemd and changes
Jeff Garzik wrote:
Isn't "network" needed for people who don't run
NetworkManager?
The idea is that everybody should run NM. :-)
For the longest time, NM only worked predictably for logged-in
users,
which made "network" service a requirement for servers with static IPs
and such.
That has been fixed for several Fedora releases now. NM now supports
systemwide settings and brings interfaces with a systemwide configuration up
at boot time (as opposed to login time).
Kevin Kofler
8:39 p.m.
New subject: systemd and changes
On Wed, 2010-08-25 at 02:44 +0200, Kevin Kofler wrote:
Jeff Garzik wrote:
> Isn't "network" needed for people who don't run NetworkManager?
The idea is that everybody should run NM. :-)
When it works reliably in all situations. I get a choice. Usually, I
will have NetworkManager installed on a fresh system (I say usually,
because there was a time when it would be removed immediately), but the
network device may not even be connected even after logging in (you say
this works, whereas I know it doesn't always because I've seen it). And
every system I have (I dunno about you) also uses KVM with various
bridging setups that "just" work the moment you aren't using NM.
That's not to say NM won't work for all cases eventually. It's just
another example of how typical (laptop) Desktop use is not the only
thing people are using Fedora for.
Jon.
10:31 p.m.
New subject: systemd and changes
On Tuesday, August 24, 2010 07:32:42 pm Jeff Garzik wrote:
On 08/24/2010 08:01 PM, Kevin Kofler wrote:
> Bill Nottingham wrote:
>> Having to support multiple boot paths for the system, making everyone
>> who gets odd bugs filed against kernel, dracut, plymouth, etc. triage
>> them isn't exactly an 'easy fix' - it *adds* complication to both
>> paths.
>
> Right. In fact, I think we're supporting way too many deprecated
> alternatives for way too long, e.g. when will the old legacy "network"
> service which has been deprecated for ages finally be gone?
>
> Of course it makes sense to keep deprecated stuff around when it's needed
> to make things work, e.g. HAL is still needed for KDE right now (but
> that might already be resolved by F15 since work on new u* Solid
> backends is going strong upstream, also thanks to Fedora developers from
> Red Hat Czech), but I don't see anything requiring e.g. the old
> "network" to stay around.
Isn't "network" needed for people who don't run NetworkManager?
For the longest time, NM only worked predictably for logged-in users,
which made "network" service a requirement for servers with static IPs
and such.
Jeff
There are still use cases that NetworkManager doesnt handle. RHEL 6 still
defaults to network on servers not sure about workstation installs.
there is likely going to be a need for it for some time yet
Dennis
7:34 p.m.
New subject: systemd and changes
Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at> said:
Right. In fact, I think we're supporting way too many deprecated
alternatives for way too long, e.g. when will the old legacy "network"
service which has been deprecated for ages finally be gone?
Hopefully not before there is something capable of replacing it. Maybe
you don't have bridges, 802.1q VLANs (and even bridged VLANs), etc., but
last I checked, NM didn't handle them.
--
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.
8:55 p.m.
New subject: systemd and changes
On Wed, Aug 25, 2010 at 02:01:55AM +0200, Kevin Kofler wrote:
Right. In fact, I think we're supporting way too many deprecated
alternatives for way too long, e.g. when will the old legacy "network"
service which has been deprecated for ages finally be gone?
When there's a compelling use case for NetworkManager on machines that don't
move around?
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
10:25 p.m.
New subject: systemd and changes
Matthew Miller wrote:
When there's a compelling use case for NetworkManager on machines
that
don't move around?
The "compelling use case" is that it doesn't make sense to maintain 2 pieces
of core infrastructure code doing the same thing, especially when one's
functionality is a subset of the other's. (Now the problem is that it still
isn't, which I hadn't been aware of before this discussion, hopefully the
missing stuff like bridging will get added to NM soon, and hopefully there
won't be another missing piece "everyone" will be complaining about (before,
it was systemwide settings, static IPs and IPv6, those are all implemented
now AFAIK).)
And FWIW, strictly speaking, there's a compelling use case for NM on a
machine that doesn't move around: If the network plug is in another room and
you don't want to extend a 20m cable through 2+ doors, you have to use
wireless networking. If you want to use something secure, you cannot rely on
unencrypted wireless or WEP, you have to use WPA (or WPA2) with AES/CCMP
(warning: TKIP is also insecure!). But the old network service does not
support WPA. You either have to apply an unofficial patch (which was never
applied because no new features are being added to the deprecated service)
or use an rc.local hack or just use NM, which supports WPA just fine. Of
course this isn't the average use case for a non-moving computer, but it's a
use case and it's a machine which doesn't move around. :-)
Kevin Kofler
10:39 p.m.
New subject: systemd and changes
On Wed, 25 Aug 2010, Kevin Kofler wrote:
Matthew Miller wrote:
> When there's a compelling use case for NetworkManager on machines that
> don't move around?
The "compelling use case" is that it doesn't make sense to maintain 2
pieces
of core infrastructure code doing the same thing, especially when one's
functionality is a subset of the other's. (Now the problem is that it still
isn't, which I hadn't been aware of before this discussion, hopefully the
missing stuff like bridging will get added to NM soon, and hopefully there
won't be another missing piece "everyone" will be complaining about
(before,
it was systemwide settings, static IPs and IPv6, those are all implemented
now AFAIK).)
I still prefer network scripts to NetworkManager everywhere except my
laptop. Why? Because I know exactly what bash scripts are going to do
every time. Being able to predict what program X is going to do is
immensely valuable. NetworkManager certainly has it's place, but it's not
on my servers. The simplicity of /etc/init.d/network _is_ a feature and
it's not one NetworkManager can replace.
-Mike
11:08 p.m.
New subject: systemd and changes
On Wed, Aug 25, 2010 at 05:25:17AM +0200, Kevin Kofler wrote:
The "compelling use case" is that it doesn't make sense
to maintain 2 pieces
of core infrastructure code doing the same thing, especially when one's
functionality is a subset of the other's. (Now the problem is that it still
Maybe. The tradeoff is that it's asking me to run another relatively
complicated daemon on all of my systems, running all of the time, simply for
the sake of configuring something statically at boot time. And maintaining
the legacy system is pretty straightforward. This crosses over into the MTA
thread: clearly, a huge advantage for the laptop case, and some reasonable
arguments for desktop use -- but unless Fedora as a whole is ready to bite
the bullet and declare itself officially no good for servers, some
consideration should be made.
If NetworkManager can be made to bring up interfaces and then get out of the
way when there's nothing but static interfaces defined, awesome. Perhaps
this is where the conversation is relevant to the larger thread: systemd
could take care of that. It could even reactivate the service if the
situation changes.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
11:33 p.m.
New subject: systemd and changes
On Wed, Aug 25, 2010 at 12:08:13AM -0400, Matthew Miller wrote:
> The "compelling use case" is that it doesn't make
sense to maintain 2 pieces
> of core infrastructure code doing the same thing, especially when one's
> functionality is a subset of the other's. (Now the problem is that it still
Maybe. The tradeoff is that it's asking me to run another relatively
complicated daemon on all of my systems, running all of the time, simply for
the sake of configuring something statically at boot time. And maintaining
the legacy system is pretty straightforward. This crosses over into the MTA
thread: clearly, a huge advantage for the laptop case, and some reasonable
arguments for desktop use -- but unless Fedora as a whole is ready to bite
the bullet and declare itself officially no good for servers, some
consideration should be made.
PS: I want to add that I'm encouraged by the thought and work that's going
into tools like nmcli. And man pages.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
6:15 a.m.
New subject: systemd and changes
On Wed, Aug 25, 2010 at 05:25:17AM +0200, Kevin Kofler wrote:
Matthew Miller wrote:
> When there's a compelling use case for NetworkManager on machines that
> don't move around?
The "compelling use case" is that it doesn't make sense to maintain 2
pieces
of core infrastructure code doing the same thing, especially when one's
functionality is a subset of the other's. (Now the problem is that it still
isn't, which I hadn't been aware of before this discussion, hopefully the
missing stuff like bridging will get added to NM soon, and hopefully there
won't be another missing piece "everyone" will be complaining about
(before,
it was systemwide settings, static IPs and IPv6, those are all implemented
now AFAIK).)
Does it support setting "ip rule" commands if an interface is up?
http://projects.gnome.org/NetworkManager/developers/settings-spec-08.html
Did not show this. And it seems not to be able to create tun or tap
devices, which requires only a small ifup-tun script with the old
system.
And FWIW, strictly speaking, there's a compelling use case for NM
on a
machine that doesn't move around: If the network plug is in another room and
you don't want to extend a 20m cable through 2+ doors, you have to use
wireless networking. If you want to use something secure, you cannot rely on
unencrypted wireless or WEP, you have to use WPA (or WPA2) with AES/CCMP
(warning: TKIP is also insecure!). But the old network service does not
support WPA. You either have to apply an unofficial patch (which was never
With the old network service it was still possible to manually use
iwconfig and wpa-supplicant and therefore WPA. Or to create a OpenVPN
tunnel, which I would prefer more than using WPA in terms of security.
But with NetworkManager running, the command line tools usually do not
work as expected.
Regards
Till
5:08 a.m.
New subject: systemd and changes
Till Maas, Wed, 25 Aug 2010 13:15:20 +0200:
Does it support setting "ip rule" commands if an interface
is up?
http://projects.gnome.org/NetworkManager/developers/settings-
spec-08.html
I am not sure I know what you mean (I am not that great netadmin), but I
a lot things can be done with scripts in /etc/NetworkManager/dispatcher.d/
Did not show this. And it seems not to be able to create tun or tap
devices, which requires only a small ifup-tun script with the old
system.
With the old network service it was still possible to manually use
iwconfig and wpa-supplicant and therefore WPA. Or to create a OpenVPN
tunnel, which I would prefer more than using WPA in terms of security.
But with NetworkManager running, the command line tools usually do not
work as expected.
NetworkManager-openvpn works great here and yes it does create tun0.
Matěj
--
http://www.ceplovi.cz/matej/, Jabber: mcepl<at>ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
Only two of my personalities are schizophrenic, but one of them
is paranoid and the other one is out to get him.
5:36 a.m.
New subject: systemd and changes
On Thu, Aug 26, 2010 at 10:08:27AM +0000, Matej Cepl wrote:
Till Maas, Wed, 25 Aug 2010 13:15:20 +0200:
> Does it support setting "ip rule" commands if an interface is up?
> http://projects.gnome.org/NetworkManager/developers/settings-
spec-08.html
I am not sure I know what you mean (I am not that great netadmin), but I
a lot things can be done with scripts in /etc/NetworkManager/dispatcher.d/
Where is the documentation about this if it is not the link I posted?
E.g. a lot of the old system is documented at:
/usr/share/doc/initscripts-*/sysconfig.txt
> Did not show this. And it seems not to be able to create tun or
tap
> devices, which requires only a small ifup-tun script with the old
> system.
> With the old network service it was still possible to manually use
> iwconfig and wpa-supplicant and therefore WPA. Or to create a OpenVPN
> tunnel, which I would prefer more than using WPA in terms of security.
> But with NetworkManager running, the command line tools usually do not
> work as expected.
NetworkManager-openvpn works great here and yes it does create tun0.
I am pretty sure, that it is openvpn that creates tun0 only when it is
called. But it is possible to create tun or tap devices before openvpn
is open and they can even have pretty arbitrary names.
Regards
Till
1:29 p.m.
New subject: systemd and changes
On Thu, 2010-08-26 at 10:08 +0000, Matej Cepl wrote:
> With the old network service it was still possible to manually
use
> iwconfig and wpa-supplicant and therefore WPA. Or to create a OpenVPN
> tunnel, which I would prefer more than using WPA in terms of security.
> But with NetworkManager running, the command line tools usually do not
> work as expected.
NetworkManager-openvpn works great here and yes it does create tun0.
Great. It works fine on a laptop, in general. But on a
desktop/server/workstation that is connected for weeks at a time (like
mine), I don't want to have to do clicky buttony stuff just to make my
network work. Nothing has yet proved as simple as the "network" scripts,
though I'm sure we could shove in a few layers of
g-whatever-it's-called-now-conf for good measure.
Jon.
2:17 p.m.
New subject: systemd and changes
On Thu, Aug 26, 2010 at 10:29 AM, Jon Masters <jonathan(a)jonmasters.org> wrote:
Great. It works fine on a laptop, in general. But on a
desktop/server/workstation that is connected for weeks at a time (like
mine), I don't want to have to do clicky buttony stuff just to make my
network work. Nothing has yet proved as simple as the "network" scripts,
though I'm sure we could shove in a few layers of
g-whatever-it's-called-now-conf for good measure.
Just to be clear.. its the clickity nature of the initial system wide
configuration that is the barrier for you? if you had a reasonable
non-clickity way to add a system wide on-boot activated network
controlled networkmanager via cli would that suffice?
-jef
2:29 p.m.
New subject: systemd and changes
On Thursday, August 26, 2010, 3:17:52 PM, Jeff wrote:
On Thu, Aug 26, 2010 at 10:29 AM, Jon Masters
<jonathan(a)jonmasters.org> wrote:
> Great. It works fine on a laptop, in general. But on a
> desktop/server/workstation that is connected for weeks at a time (like
> mine), I don't want to have to do clicky buttony stuff just to make my
> network work. Nothing has yet proved as simple as the "network" scripts,
> though I'm sure we could shove in a few layers of
> g-whatever-it's-called-now-conf for good measure.
Just to be clear.. its the clickity nature of the initial system
wide
configuration that is the barrier for you? if you had a reasonable
non-clickity way to add a system wide on-boot activated network
controlled networkmanager via cli would that suffice?
-jef
Let's not forget that NM is not suitable for someone running a local
DNS server (bind with DNSSEC enabled). It also does not work at all
when used on a laptop as a caching DNS.
There is a F14^H^H^HF15 feature to make NM work with bind and DSNSEC.
I look forward to it - my girlfriend's ISP's DNS servers can take up
to 10 seconds to resolve an address, and occasionally simply do not
resolve legit URLs.
Al
7:40 p.m.
New subject: systemd and changes
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/26/10 12:29 PM, Al Dunsmuir wrote:
On Thursday, August 26, 2010, 3:17:52 PM, Jeff wrote:
> On Thu, Aug 26, 2010 at 10:29 AM, Jon Masters <jonathan(a)jonmasters.org> wrote:
>> Great. It works fine on a laptop, in general. But on a
>> desktop/server/workstation that is connected for weeks at a time (like
>> mine), I don't want to have to do clicky buttony stuff just to make my
>> network work. Nothing has yet proved as simple as the "network"
scripts,
>> though I'm sure we could shove in a few layers of
>> g-whatever-it's-called-now-conf for good measure.
> Just to be clear.. its the clickity nature of the initial system wide
> configuration that is the barrier for you? if you had a reasonable
> non-clickity way to add a system wide on-boot activated network
> controlled networkmanager via cli would that suffice?
> -jef
Let's not forget that NM is not suitable for someone running a local
DNS server (bind with DNSSEC enabled). It also does not work at all
when used on a laptop as a caching DNS.
There is a F14^H^H^HF15 feature to make NM work with bind and DSNSEC.
I look forward to it - my girlfriend's ISP's DNS servers can take up
to 10 seconds to resolve an address, and occasionally simply do not
resolve legit URLs.
Al
That's strange. I use it on my laptop, which has a caching local DNS
server (dnsmasq) and it works just fine. I do have a script in
/etc/NetworkManager/dispatcher.d/ that waits for bringup and vpn bring
up to make adjustments to the running local DNS server (which seems
easier with NM than it would be with the old scripts).
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkx3CZgACgkQ4v2HLvE71NWWNACgmO8uxgIqX3dqUKkwf5ml07/l
MmgAmwYH6L3s06/noL3UBXTyQg/tuFmZ
=8LvP
-----END PGP SIGNATURE-----
4:43 a.m.
New subject: systemd and changes
2010/8/27 Jesse Keating <jkeating(a)j2solutions.net>:
That's strange. I use it on my laptop, which has a caching local
DNS
server (dnsmasq) and it works just fine. I do have a script in
/etc/NetworkManager/dispatcher.d/ that waits for bringup and vpn bring
up to make adjustments to the running local DNS server (which seems
easier with NM than it would be with the old scripts).
How can it be easier than this line in /etc/dhcp/dhclient-eth0-up-hooks:
new_domain_name_servers="127.0.0.1 $new_domain_name_servers"
This doesn't work with NM anymore however, so care to share your NM script?
(Imho NM should offer a configuration option for this, seems a common case.)
Thanks
Thomas
6:02 a.m.
New subject: systemd and changes
On Fri, Aug 27, 2010 at 11:43:41AM +0200, Thomas Moschny wrote:
2010/8/27 Jesse Keating <jkeating(a)j2solutions.net>:
> That's strange. I use it on my laptop, which has a caching local DNS
> server (dnsmasq) and it works just fine. I do have a script in
> /etc/NetworkManager/dispatcher.d/ that waits for bringup and vpn bring
> up to make adjustments to the running local DNS server (which seems
> easier with NM than it would be with the old scripts).
How can it be easier than this line in /etc/dhcp/dhclient-eth0-up-hooks:
new_domain_name_servers="127.0.0.1 $new_domain_name_servers"
This worked until recently on Fedora 12:
$ cat /etc/dhclient-eth1.conf
interface "eth1" {
supersede domain-name-servers 127.0.0.1;
}
Regards
Till
10:53 a.m.
New subject: systemd and changes
On Fri, 2010-08-27 at 13:02 +0200, Till Maas wrote:
On Fri, Aug 27, 2010 at 11:43:41AM +0200, Thomas Moschny wrote:
> 2010/8/27 Jesse Keating <jkeating(a)j2solutions.net>:
> > That's strange. I use it on my laptop, which has a caching local DNS
> > server (dnsmasq) and it works just fine. I do have a script in
> > /etc/NetworkManager/dispatcher.d/ that waits for bringup and vpn bring
> > up to make adjustments to the running local DNS server (which seems
> > easier with NM than it would be with the old scripts).
>
> How can it be easier than this line in /etc/dhcp/dhclient-eth0-up-hooks:
> new_domain_name_servers="127.0.0.1 $new_domain_name_servers"
This worked until recently on Fedora 12:
$ cat /etc/dhclient-eth1.conf
interface "eth1" {
supersede domain-name-servers 127.0.0.1;
}
If that broke, then it's a bug and I'll fix it. NM still
checks /etc/dhclient-<iface>.conf first, and if that does not exist,
falls back to the new preferred location (used by anaconda and others)
of /etc/dhcp/dhclient-<iface>.conf. If not, I need to fix it.
Dan
3:30 p.m.
New subject: systemd and changes
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/27/2010 02:43 AM, Thomas Moschny wrote:
2010/8/27 Jesse Keating <jkeating(a)j2solutions.net>:
> That's strange. I use it on my laptop, which has a caching local DNS
> server (dnsmasq) and it works just fine. I do have a script in
> /etc/NetworkManager/dispatcher.d/ that waits for bringup and vpn bring
> up to make adjustments to the running local DNS server (which seems
> easier with NM than it would be with the old scripts).
How can it be easier than this line in /etc/dhcp/dhclient-eth0-up-hooks:
new_domain_name_servers="127.0.0.1 $new_domain_name_servers"
That only does half the job. That just forces your dns resolution to
use the local host, but that does nothing for updating the local
resolver for any new upstream DNS servers it should become aware of,
such as a vpn coming online.
It's catching the VPN coming up / down, and reacting to that which is
easier with NetworkManager.
This doesn't work with NM anymore however, so care to share your NM script?
export LC_ALL=C
if [ "$2" = "vpn-up" ]; then
<do some stuff here, like touching /etc/resolv.conf, touching dnsmasq
config, restarting dnsmasq>
fi
if [ "$2" = "vpn-down" ]; then
<do some stuff to undo the above>
fi
(Imho NM should offer a configuration option for this, seems a common
case.)
Thanks
Thomas
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkx4IIIACgkQ4v2HLvE71NV5mQCgrD7D8h2mpz3SHxi+Qqv1P8ec
7t0An1c/ZP5inWR4szePDuTs0qx4Nb5b
=wx67
-----END PGP SIGNATURE-----
3:20 p.m.
New subject: systemd and changes
Al Dunsmuir <al.dunsmuir(a)sympatico.ca> writes:
Let's not forget that NM is not suitable for someone running a
local
DNS server (bind with DNSSEC enabled). It also does not work at all
when used on a laptop as a caching DNS.
Doesn't NetworkManager respect PEERDNS=no? As I understand it, it does
read ifcfg-whatever.
If it doesn't, that should be reasonably easy to fix.
/Benny
2:57 p.m.
New subject: systemd and changes
On Thu, 2010-08-26 at 11:17 -0800, Jeff Spaleta wrote:
On Thu, Aug 26, 2010 at 10:29 AM, Jon Masters
<jonathan(a)jonmasters.org> wrote:
> Great. It works fine on a laptop, in general. But on a
> desktop/server/workstation that is connected for weeks at a time (like
> mine), I don't want to have to do clicky buttony stuff just to make my
> network work. Nothing has yet proved as simple as the "network" scripts,
> though I'm sure we could shove in a few layers of
> g-whatever-it's-called-now-conf for good measure.
Just to be clear.. its the clickity nature of the initial system wide
configuration that is the barrier for you? if you had a reasonable
non-clickity way to add a system wide on-boot activated network
controlled networkmanager via cli would that suffice?
Yup, the clickity nature of any configuration is a giant off-putting
neon sign saying "stay away" for me, in general, if there is no CLI
though I think it's good to have GUI configuration for end users. I know
there is an NM CLI but I need it to be as easy as the existing network
scripts before I make that switch.
Jon.
10:49 a.m.
New subject: systemd and changes
On Thu, 2010-08-26 at 15:57 -0400, Jon Masters wrote:
On Thu, 2010-08-26 at 11:17 -0800, Jeff Spaleta wrote:
> On Thu, Aug 26, 2010 at 10:29 AM, Jon Masters <jonathan(a)jonmasters.org>
wrote:
> > Great. It works fine on a laptop, in general. But on a
> > desktop/server/workstation that is connected for weeks at a time (like
> > mine), I don't want to have to do clicky buttony stuff just to make my
> > network work. Nothing has yet proved as simple as the "network"
scripts,
> > though I'm sure we could shove in a few layers of
> > g-whatever-it's-called-now-conf for good measure.
>
> Just to be clear.. its the clickity nature of the initial system wide
> configuration that is the barrier for you? if you had a reasonable
> non-clickity way to add a system wide on-boot activated network
> controlled networkmanager via cli would that suffice?
Yup, the clickity nature of any configuration is a giant off-putting
neon sign saying "stay away" for me, in general, if there is no CLI
though I think it's good to have GUI configuration for end users. I know
there is an NM CLI but I need it to be as easy as the existing network
scripts before I make that switch.
What things need to be easier about the cli bits that the network
scripts get right? No doubt there are some, but would you mind filing
them as enhancement requests or bugs so we have some goals to hit?
In the end, ifup/ifdown should also still work for connections NM
controls, since ifup/ifdown just call NM for those connections in F13+.
ifup just says "activate this interface with this configuration" which
is the same thing NM does too, so that mapping is pretty 1:1.
Dan
2:28 p.m.
New subject: systemd and changes
Dan Williams <dcbw(a)redhat.com> wrote:
What things need to be easier about the cli bits that the network
scripts get right? No doubt there are some, but would you mind filing
them as enhancement requests or bugs so we have some goals to hit?
In the end, ifup/ifdown should also still work for connections NM
controls, since ifup/ifdown just call NM for those connections in F13+.
ifup just says "activate this interface with this configuration" which
is the same thing NM does too, so that mapping is pretty 1:1.
I actually have a bug to file about that. The setting for NM_CONTROLLED
is still set even if NetworkManager isn't installed. It (or Ananconda)
should scrub the configs before installing the settings used during the
install.
--Ben
2:28 p.m.
New subject: systemd and changes
Ben Boeckel (mathstuf(a)gmail.com) said:
I actually have a bug to file about that. The setting for
NM_CONTROLLED
is still set even if NetworkManager isn't installed. It (or Ananconda)
should scrub the configs before installing the settings used during the
install.
IMO, NM_CONTROLLED should *never* be written, and should only be
used by administrators where they feel it's necessary.
Bill
10:54 p.m.
New subject: systemd and changes
Bill Nottingham <notting(a)redhat.com> wrote:
Ben Boeckel (mathstuf(a)gmail.com) said:
> I actually have a bug to file about that. The setting for NM_CONTROLLED
> is still set even if NetworkManager isn't installed. It (or Ananconda)
> should scrub the configs before installing the settings used during the
> install.
IMO, NM_CONTROLLED should *never* be written, and should only be
used by administrators where they feel it's necessary.
Bill
Bug filed[1]
--Ben
[1]https://bugzilla.redhat.com/show_bug.cgi?id=629819
3:12 p.m.
New subject: systemd and changes
On 26/08/2010, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
Just to be clear.. its the clickity nature of the initial system
wide
configuration that is the barrier for you? if you had a reasonable
non-clickity way to add a system wide on-boot activated network
controlled networkmanager via cli would that suffice?
An example which I think highlights what Jon's trying to say:
When I build a new KVM host via kickstart I run a very simple little
script in a %post section to preconfigure a number of VLANs for me
along with a bridge for each VLAN which the KVM guests can then
connect to. With the old school networking scripts I can simply do
this with a for loop and cat (none of the interfaces need IPs) and
there's nothing there for me to forget to do or typo while doing, it's
just done. With NetworkManager I'm not sure there's an easy way to do
this automatically. I'm a SysAdmin I don't want to do the dull
repetitive bits if I can help it, I only want to do the bits that are
unique and GUIs do not lend themselves to automation.
Mark
10:39 a.m.
New subject: systemd and changes
On Thu, Aug 26, 2010 at 09:12:28PM +0100, Mark Chappell wrote:
On 26/08/2010, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
> Just to be clear.. its the clickity nature of the initial system wide
> configuration that is the barrier for you? if you had a reasonable
> non-clickity way to add a system wide on-boot activated network
> controlled networkmanager via cli would that suffice?
An example which I think highlights what Jon's trying to say:
When I build a new KVM host via kickstart I run a very simple little
script in a %post section to preconfigure a number of VLANs for me
along with a bridge for each VLAN which the KVM guests can then
connect to. With the old school networking scripts I can simply do
this with a for loop and cat (none of the interfaces need IPs) and
there's nothing there for me to forget to do or typo while doing, it's
just done. With NetworkManager I'm not sure there's an easy way to do
this automatically. I'm a SysAdmin I don't want to do the dull
repetitive bits if I can help it, I only want to do the bits that are
unique and GUIs do not lend themselves to automation.
NM can use old style /etc/sysconfig/network-scripts/ifcfg-*. Can't
you just write those out from your %post section? Or, if you want all
the NM features like WPA wireless config, you can use the keyfile
plugin to write NM ini-style key-value files. Either way, those are
text files that are easily handled from shell scripts.
10:54 a.m.
New subject: systemd and changes
Once upon a time, Chuck Anderson <cra(a)WPI.EDU> said:
NM can use old style /etc/sysconfig/network-scripts/ifcfg-*.
Can't
you just write those out from your %post section? Or, if you want all
the NM features like WPA wireless config, you can use the keyfile
plugin to write NM ini-style key-value files. Either way, those are
text files that are easily handled from shell scripts.
This is rather under-documented I discovered last night. There is a
document that describes the keyfile plugin config, but it doesn't appear
to be on the NM website, and it isn't included in any Fedora RPM as far
as I found. I opened BZ 627782 about this; the spec file takes steps to
keep the timestamps on docs (for multilib), but then only includes a
single file (the library API) in an RPM.
The ifcfg-rh plugin doesn't appear to have any documentation at all
(from what I understand, it doesn't support all the same things in
network-scripts that ifup/etc. do, and it adds some things of its own
for WPA and the like).
--
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:46 a.m.
New subject: systemd and changes
On Fri, 2010-08-27 at 10:54 -0500, Chris Adams wrote:
Once upon a time, Chuck Anderson <cra(a)WPI.EDU> said:
> NM can use old style /etc/sysconfig/network-scripts/ifcfg-*. Can't
> you just write those out from your %post section? Or, if you want all
> the NM features like WPA wireless config, you can use the keyfile
> plugin to write NM ini-style key-value files. Either way, those are
> text files that are easily handled from shell scripts.
This is rather under-documented I discovered last night. There is a
document that describes the keyfile plugin config, but it doesn't appear
to be on the NM website, and it isn't included in any Fedora RPM as far
as I found. I opened BZ 627782 about this; the spec file takes steps to
keep the timestamps on docs (for multilib), but then only includes a
single file (the library API) in an RPM.
The ifcfg-rh plugin doesn't appear to have any documentation at all
(from what I understand, it doesn't support all the same things in
network-scripts that ifup/etc. do, and it adds some things of its own
for WPA and the like).
The ifcfg-rh plugin attempts to interpret ifcfg files just like
ifup/ifdown do. These limitations and extensions should be documented
better. But in the end, you want better documentation for the ifcfg
file format as defined by Red Hat/Fedora (SUSE's is slightly different).
Most of that has been documented since the beginning of time in places
like:
ifup-ipv6
ifup-wireless
man ifup
/usr/share/doc/initscripts-*/sysconfig.txt
But of course some of that is out of date, and NM implements WPA and
802.1x support that the system initscripts don't. Better documentation
all around?
Dan
12:50 p.m.
New subject: systemd and changes
On 27/08/2010, Chuck Anderson <cra(a)wpi.edu> wrote:
NM can use old style /etc/sysconfig/network-scripts/ifcfg-*.
Can't
you just write those out from your %post section?
Those would be the old school files I was referring to, I hadn't found
the NH-rh plugin, but as long as the RH network init script exists why
would I want to use NM to start them rather than the RH script once
started I don't want any of the other NM functions.
Mark
12:56 p.m.
New subject: systemd and changes
On 27/08/2010, Mark Chappell <tremble(a)tremble.org.uk> wrote:
On 27/08/2010, Chuck Anderson <cra(a)wpi.edu> wrote:
> NM can use old style /etc/sysconfig/network-scripts/ifcfg-*. Can't
> you just write those out from your %post section?
Those would be the old school files I was referring to, I hadn't found
the NH-rh plugin, but as long as the RH network init script exists why
would I want to use NM to start them rather than the RH script once
started I don't want any of the other NM functions.
I should point out that if NM gained a CLI so that I could do
something like that then I wouldn't mind the old RH scripts going
away, all I want is *a* method that I can automate easily, NM
currently only has a bit of a hack to do this.
Mark
1:16 p.m.
New subject: systemd and changes
On Fri, Aug 27, 2010 at 06:56:33PM +0100, Mark Chappell wrote:
I should point out that if NM gained a CLI so that I could do
something like that then I wouldn't mind the old RH scripts going
away, all I want is *a* method that I can automate easily, NM
currently only has a bit of a hack to do this.
There is cnetworkmanager, but I believe it is only there to select a
preconfigured connection.
Regards
Till
1:22 p.m.
New subject: systemd and changes
On 27/08/2010, Till Maas <opensource(a)till.name> wrote:
On Fri, Aug 27, 2010 at 06:56:33PM +0100, Mark Chappell wrote:
> I should point out that if NM gained a CLI so that I could do
> something like that then I wouldn't mind the old RH scripts going
> away, all I want is *a* method that I can automate easily, NM
> currently only has a bit of a hack to do this.
There is cnetworkmanager, but I believe it is only there to select a
preconfigured connection.
Indeed, which would be useless for my use case. I may of course be
the only one doing such things, but I suspect that at the very least
Jon may be too...
Mark
1:23 p.m.
New subject: systemd and changes
On 08/27/2010 02:22 PM, Mark Chappell wrote:
On 27/08/2010, Till Maas <opensource(a)till.name> wrote:
> On Fri, Aug 27, 2010 at 06:56:33PM +0100, Mark Chappell wrote:
>
>> I should point out that if NM gained a CLI so that I could do
>> something like that then I wouldn't mind the old RH scripts going
>> away, all I want is *a* method that I can automate easily, NM
>> currently only has a bit of a hack to do this.
>
> There is cnetworkmanager, but I believe it is only there to select a
> preconfigured connection.
Indeed, which would be useless for my use case. I may of course be
the only one doing such things, but I suspect that at the very least
Jon may be too...
I assume nmcli doesn't meet the requirements?
~spot
1:30 p.m.
New subject: systemd and changes
On 27/08/2010, Tom "spot" Callaway <tcallawa(a)redhat.com> wrote:
On 08/27/2010 02:22 PM, Mark Chappell wrote:
> Indeed, which would be useless for my use case. I may of course be
> the only one doing such things, but I suspect that at the very least
> Jon may be too...
I assume nmcli doesn't meet the requirements?
Not so far as I could decipher from the man page, not with bridges and
interfaces with no IPs anyway, of course this may fall under the itch
to scratch list somewhere...
Mark
1:44 p.m.
New subject: systemd and changes
On Fri, Aug 27, 2010 at 07:30:11PM +0100, Mark Chappell wrote:
On 27/08/2010, Tom "spot" Callaway
<tcallawa(a)redhat.com> wrote:
> On 08/27/2010 02:22 PM, Mark Chappell wrote:
>> Indeed, which would be useless for my use case. I may of course be
>> the only one doing such things, but I suspect that at the very least
>> Jon may be too...
>
> I assume nmcli doesn't meet the requirements?
Not so far as I could decipher from the man page, not with bridges and
interfaces with no IPs anyway, of course this may fall under the itch
to scratch list somewhere...
NM doesn't (yet?) support:
- bridges: https://bugzilla.redhat.com/show_bug.cgi?id=558982
- vlans: https://bugzilla.redhat.com/show_bug.cgi?id=492377
Nb. there is following feature:
http://fedoraproject.org/wiki/Features/Shared_Network_Interface
which is about cooperation between NM and Fedora virtualisation stuff
and includes bridging support.
--
Tomasz Torcz Morality must always be based on practicality.
xmpp: zdzichubg(a)chrome.pl -- Baron Vladimir Harkonnen
1:58 p.m.
New subject: systemd and changes
On 27/08/2010, Tomasz Torcz <tomek(a)pipebreaker.pl> wrote:
NM doesn't (yet?) support:
- bridges: https://bugzilla.redhat.com/show_bug.cgi?id=558982
- vlans: https://bugzilla.redhat.com/show_bug.cgi?id=492377
That would explain why I couldn't figure out how to do it :)
Nb. there is following feature:
http://fedoraproject.org/wiki/Features/Shared_Network_Interface
which is about cooperation between NM and Fedora virtualisation stuff
and includes bridging support.
But again SFAICT requires manual intervention when creating a new
server. Like I said, the less I have to do to bring up a new server
the better.
Mark
10:40 a.m.
New subject: systemd and changes
On Fri, 2010-08-27 at 19:58 +0100, Mark Chappell wrote:
On 27/08/2010, Tomasz Torcz <tomek(a)pipebreaker.pl> wrote:
> NM doesn't (yet?) support:
> - bridges: https://bugzilla.redhat.com/show_bug.cgi?id=558982
> - vlans: https://bugzilla.redhat.com/show_bug.cgi?id=492377
That would explain why I couldn't figure out how to do it :)
When NM does support these, it will support these using the normal ifcfg
file key/value formats which are documented in the 'initscripts' package
as they always have been. There's nothing special about ifcfg files
that NetworkManager really changes; we've gone to great effort to
interpret ifcfg files almost exactly like ifup/ifdown interpret them.
So, if you want to use a CLI to create system-wide network connections,
you use 'vi' or 'nano' or 'emacs' and write an ifcfg file like
you
always did. Nothing has changed here.
Then you ifup them. Or you use nmcli to activate them. The point is
that when creating or activating/deactivating connections that NM
supports your workflow should not really change.
Dan
> Nb. there is following feature:
> http://fedoraproject.org/wiki/Features/Shared_Network_Interface
> which is about cooperation between NM and Fedora virtualisation stuff
> and includes bridging support.
But again SFAICT requires manual intervention when creating a new
server. Like I said, the less I have to do to bring up a new server
the better.
Mark
1:08 p.m.
New subject: systemd and changes
On Thu, Sep 02, 2010 at 10:40:21AM -0500, Dan Williams wrote:
as they always have been. There's nothing special about ifcfg
files
that NetworkManager really changes; we've gone to great effort to
interpret ifcfg files almost exactly like ifup/ifdown interpret them.
One million thank yous for that, by the way.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
3:10 p.m.
New subject: systemd and changes
Once upon a time, Tom spot Callaway <tcallawa(a)redhat.com> said:
I assume nmcli doesn't meet the requirements?
nmcli manages connections (up/down), but AFAIK doesn't support
configuring them or creating new connections. I didn't find a CLI tool
for creating/configuring NM connections other than the universal "vi"
(but then the config files are not well documented).
--
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.
6:01 a.m.
New subject: systemd and changes
On 27.08.2010 19:56, Mark Chappell wrote:
On 27/08/2010, Mark Chappell<tremble(a)tremble.org.uk> wrote:
> On 27/08/2010, Chuck Anderson<cra(a)wpi.edu> wrote:
>> NM can use old style /etc/sysconfig/network-scripts/ifcfg-*. Can't
>> you just write those out from your %post section?
>
> Those would be the old school files I was referring to, I hadn't found
> the NH-rh plugin, but as long as the RH network init script exists why
> would I want to use NM to start them rather than the RH script once
> started I don't want any of the other NM functions.
I should point out that if NM gained a CLI so that I could do
something like that then I wouldn't mind the old RH scripts going
away, all I want is *a* method that I can automate easily, NM
currently only has a bit of a hack to do this.
And another problem, at least here and in my eyes :).
==============================================
[root@hostname ~]# yum install NetworkManager
<blah>
Dependencies Resolved
Installing:
NetworkManager
Installing for dependencies:
ConsoleKit
ConsoleKit-libs
ModemManager
NetworkManager-glib
avahi-autoipd
dnsmasq
eggdbus
libgudev1
libpcap
mobile-broadband-provider-info
polkit
ppp wpa_supplicant
Transaction Summary
Install 14 Package(s)
Total download size: 2.7 M
Installed size: 9.3 M
Is this ok [y/N]: No thanks
==============================================
I don't understand yet, why I need a avahi-daemon working by default. Oh
yes: avahi <- cups <- samba, but why working.
Glandvador
noon
New subject: systemd and changes
On Mon, 2010-08-23 at 15:52 -0500, Mike McGrath wrote:
It's just risk management. I think we'd be better off
acknowledging there
are unknown unknowns and try to mitigate them. One way we could have done
that this time around was making it an optional feature (as Matt was
mentioning in a previous email) for F14 and then decide in F15 if it was
ready. Unfortunately that's not the path we seem to be on. We unwisely
seemed to declare it ready before anyone even saw it then we ignored what
we didn't know as if we knew there were going to be no problems. The sad
thing is that's such an easy fix by making brand new features for core
components like this opt in, even if it's just for a single release.
Well, ironically enough, Lennart's last big revolution illustrates the
problem with that. PulseAudio - previously PolypAudio, remember - was
'opt-in' for several releases; it was packaged in Fedora and many other
major distributions, you could enable it just by installing it. It was
used by approximately no-one. People just don't opt in to big bits of
infrastructural change unless they have some very specific reason to do
so; booting the system more or less works for most people, so why would
they 'opt in' to a new init daemon?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12:02 p.m.
New subject: systemd and changes
Adam Williamson wrote:
On Mon, 2010-08-23 at 15:52 -0500, Mike McGrath wrote:
> It's just risk management. I think we'd be better off acknowledging there
> are unknown unknowns and try to mitigate them. One way we could have done
> that this time around was making it an optional feature (as Matt was
> mentioning in a previous email) for F14 and then decide in F15 if it was
> ready. Unfortunately that's not the path we seem to be on. We unwisely
> seemed to declare it ready before anyone even saw it then we ignored what
> we didn't know as if we knew there were going to be no problems. The sad
> thing is that's such an easy fix by making brand new features for core
> components like this opt in, even if it's just for a single release.
Well, ironically enough, Lennart's last big revolution illustrates the
problem with that. PulseAudio - previously PolypAudio, remember - was
'opt-in' for several releases; it was packaged in Fedora and many other
major distributions, you could enable it just by installing it. It was
used by approximately no-one. People just don't opt in to big bits of
infrastructural change unless they have some very specific reason to do
so; booting the system more or less works for most people, so why would
they 'opt in' to a new init daemon?
If it's worth the revolution, wouldn't people choose to opt in?
If nobody ever opts in, perhaps it's not worth the revolution?
Just a thought ;)
-Eric
12:10 p.m.
New subject: systemd and changes
On Tue, 24 Aug 2010, Eric Sandeen wrote:
Adam Williamson wrote:
> On Mon, 2010-08-23 at 15:52 -0500, Mike McGrath wrote:
>
>> It's just risk management. I think we'd be better off acknowledging
there
>> are unknown unknowns and try to mitigate them. One way we could have done
>> that this time around was making it an optional feature (as Matt was
>> mentioning in a previous email) for F14 and then decide in F15 if it was
>> ready. Unfortunately that's not the path we seem to be on. We unwisely
>> seemed to declare it ready before anyone even saw it then we ignored what
>> we didn't know as if we knew there were going to be no problems. The sad
>> thing is that's such an easy fix by making brand new features for core
>> components like this opt in, even if it's just for a single release.
>
> Well, ironically enough, Lennart's last big revolution illustrates the
> problem with that. PulseAudio - previously PolypAudio, remember - was
> 'opt-in' for several releases; it was packaged in Fedora and many other
> major distributions, you could enable it just by installing it. It was
> used by approximately no-one. People just don't opt in to big bits of
> infrastructural change unless they have some very specific reason to do
> so; booting the system more or less works for most people, so why would
> they 'opt in' to a new init daemon?
If it's worth the revolution, wouldn't people choose to opt in?
If nobody ever opts in, perhaps it's not worth the revolution?
Just a thought ;)
People like you and me would opt-in. (well I would on some hosts) because
we know what we're doing. Expert eyes get a look at it before it's forced
onto our users, who are already leaving in leaps and bounds.
-Mike
12:18 p.m.
New subject: systemd and changes
Mike McGrath wrote:
On Tue, 24 Aug 2010, Eric Sandeen wrote:
> Adam Williamson wrote:
>> On Mon, 2010-08-23 at 15:52 -0500, Mike McGrath wrote:
>>
>>> It's just risk management. I think we'd be better off acknowledging
there
>>> are unknown unknowns and try to mitigate them. One way we could have done
>>> that this time around was making it an optional feature (as Matt was
>>> mentioning in a previous email) for F14 and then decide in F15 if it was
>>> ready. Unfortunately that's not the path we seem to be on. We unwisely
>>> seemed to declare it ready before anyone even saw it then we ignored what
>>> we didn't know as if we knew there were going to be no problems. The
sad
>>> thing is that's such an easy fix by making brand new features for core
>>> components like this opt in, even if it's just for a single release.
>> Well, ironically enough, Lennart's last big revolution illustrates the
>> problem with that. PulseAudio - previously PolypAudio, remember - was
>> 'opt-in' for several releases; it was packaged in Fedora and many other
>> major distributions, you could enable it just by installing it. It was
>> used by approximately no-one. People just don't opt in to big bits of
>> infrastructural change unless they have some very specific reason to do
>> so; booting the system more or less works for most people, so why would
>> they 'opt in' to a new init daemon?
> If it's worth the revolution, wouldn't people choose to opt in?
>
> If nobody ever opts in, perhaps it's not worth the revolution?
>
> Just a thought ;)
>
People like you and me would opt-in. (well I would on some hosts) because
we know what we're doing. Expert eyes get a look at it before it's forced
onto our users, who are already leaving in leaps and bounds.
I would opt in -if- I saw some benefit to it. I probably wouldn't opt in
if it looked like change for the sake of change/shininess/newness.
-Eric
-Mike
12:19 p.m.
New subject: systemd and changes
On Tue, 2010-08-24 at 12:10 -0500, Mike McGrath wrote:
People like you and me would opt-in. (well I would on some hosts)
because
we know what we're doing. Expert eyes get a look at it before it's forced
onto our users, who are already leaving in leaps and bounds.
Again, Pulse/PolypAudio seems to suggest that this is not the case. Why
didn't expert eyes who knew what they were doing migrate to that before
it become default? Or, alternatively, if the expert eyes which knew what
they were doing did migrate, why didn't they catch the bugs that others
encountered when it became default?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12:56 p.m.
New subject: systemd and changes
On Tue, 24 Aug 2010, Adam Williamson wrote:
On Tue, 2010-08-24 at 12:10 -0500, Mike McGrath wrote:
> People like you and me would opt-in. (well I would on some hosts) because
> we know what we're doing. Expert eyes get a look at it before it's forced
> onto our users, who are already leaving in leaps and bounds.
Again, Pulse/PolypAudio seems to suggest that this is not the case. Why
didn't expert eyes who knew what they were doing migrate to that before
it become default? Or, alternatively, if the expert eyes which knew what
they were doing did migrate, why didn't they catch the bugs that others
encountered when it became default?
If us experts aren't even willing to opt-in in modest enough numbers to
test it, why on earth would we force it on people at all?
-Mike
1:17 p.m.
New subject: systemd and changes
On Tue, 24.08.10 12:56, Mike McGrath (mmcgrath(a)redhat.com) wrote:
On Tue, 24 Aug 2010, Adam Williamson wrote:
> On Tue, 2010-08-24 at 12:10 -0500, Mike McGrath wrote:
>
> > People like you and me would opt-in. (well I would on some hosts) because
> > we know what we're doing. Expert eyes get a look at it before it's
forced
> > onto our users, who are already leaving in leaps and bounds.
>
> Again, Pulse/PolypAudio seems to suggest that this is not the case. Why
> didn't expert eyes who knew what they were doing migrate to that before
> it become default? Or, alternatively, if the expert eyes which knew what
> they were doing did migrate, why didn't they catch the bugs that others
> encountered when it became default?
>
If us experts aren't even willing to opt-in in modest enough numbers to
test it, why on earth would we force it on people at all?
Well, here's are two simple facts for you:
1) if things are not used they tend to have bugs
2) if things have bugs they are not used
Acknowledging this: if you want to innovate you have no other option
than pushing things to the people, and then fix what breaks.
And if you never are willing to pass something to the users before it is
100% stable and tested, then it will never be 100% stable and tested,
and you simply stop to innovate. But that wouldn't be Fedora anymore
then.
And I think so far things went really well with systemd, even though
this discussion might create the impression it didn't.
Lennart
--
Lennart Poettering - Red Hat, Inc.
2:40 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 24, 2010 at 08:17:19PM +0200, Lennart Poettering wrote:
Acknowledging this: if you want to innovate you have no other option
than pushing things to the people, and then fix what breaks.
We do not have this luxury. If we "push" something broken to the people, the
people will _completely understandably_ throw up their hands and say "huh,
guess that sucked" and try another distribution. Or stay on their other
distribution -- let Fedora be the playground for developers, and serious
distributions for real users can pick out the parts that worked afterward.
I know we've had plenty of dramatic trolling on this list from people
demanding this or that change from the distribution or else they'll leave
for good. I'm not talking about those noisemakers. I'm talking about _an
actual user base_.
This *is* happening, and we need to tread carefully, because once you loose
respect and reputation, it is very, very hard to get back.
Being innovative is an important part of what Fedora is. But Fedora can't be
*just* Rawhide.
And I think so far things went really well with systemd, even though
this discussion might create the impression it didn't.
As long as you stay involved in the discussion, which, again, I appreciate,
we have a chance of things going well. But from the point of view of someone
actively testing systemd, it's looking pretty rocky. You can ignore that if
you want, but *Fedora* can't.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
2:59 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, 2010-08-24 at 15:40 -0400, Matthew Miller wrote:
This *is* happening, and we need to tread carefully, because once you
loose
respect and reputation, it is very, very hard to get back.
I really think you're extrapolating too far from some very limited data
here. You have some statistics which indicate that Fedora usage is
declining. You are extrapolating from this to the conclusion that this
is happening because Fedora changes too rapidly. I don't think your data
support your conclusion; I haven't seen you cite any data in support of
your assumption as to the *reason* Fedora usage is declining.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:05 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 24, 2010 at 12:59:57PM -0700, Adam Williamson wrote:
> This *is* happening, and we need to tread carefully, because
once you loose
> respect and reputation, it is very, very hard to get back.
I really think you're extrapolating too far from some very limited data
here. You have some statistics which indicate that Fedora usage is
declining. You are extrapolating from this to the conclusion that this
is happening because Fedora changes too rapidly. I don't think your data
support your conclusion; I haven't seen you cite any data in support of
your assumption as to the *reason* Fedora usage is declining.
I'm not extrapolating that. Fedora usage is declining -- both shown in
statistics and anecdotally. (I don't know a single student using Fedora
anymore, and I hear from a lot of students using Linux.) I don't know *what*
to blame that on -- I think it's partly just the well-deserved success of
the competition.
I am saying that *because* we are in that situation, we have to be careful.
We *do* need to change rapidly, because otherwise we'll become totally
irrelivant. But we don't have the luxury of "pushing" things on the user
community and hoping they stay around while we fix it up.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
7:29 p.m.
New subject: fedora mission (was Re: systemd and changes)
Matthew Miller wrote:
I don't know a single student using Fedora anymore,
I'm a student using Fedora. :-p But not at Harvard. ;-)
I don't know *what* to blame that on
I blame it on people slowly destroying what Fedora is all about, with things
like that "stable updates vision". And also on people blatantly not caring
about sizable parts of our community, e.g. by hiding the KDE download links
behind several clicks from the front page (while making the GNOME download 1
click).
Kevin Kofler
2:54 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Wed, Aug 25, 2010 at 1:29 AM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Matthew Miller wrote:
> I don't know a single student using Fedora anymore,
I'm a student using Fedora. :-p But not at Harvard. ;-)
> I don't know *what* to blame that on
I blame it on people slowly destroying what Fedora is all about, with things
like that "stable updates vision". And also on people blatantly not caring
about sizable parts of our community, e.g. by hiding the KDE download links
behind several clicks from the front page (while making the GNOME download 1
click).
Any analysis of trends of this kind have to be done carefully
otherwise it is easy to draw invalid conclusions. Some people run
multiple machines but update their systems from local repos so raw yum
checkin data may not necessarily be representative. In addition some
people do not update for specific reasons - some servers are regarded
as relatively safe behind firewalls and there may be reasons that are
not directly Fedora ones for not updating. For example one machine
that I manage is needed to run MS office via crossover office and in
F12 onwards there are selinux issues that mean you can't do that
unless you downgrade selinux protection. That particular machine
needs to share files with other Windows users in the office and edit
office files, so OpenOffice is not an option in that case (Complex OO
calc files have been demonstrated to be very incompatible with MS
Office, for example) and so any upgrade from f11 will have to wait for
that machine.
However some normal users who are not that familiar with admin may be
reluctant to spend the time and effort running new installs and
spending the time to learn the "tricks" needed to get things working
on the new system. The only people I personally know who use Fedora
are sufficiently admin capable to take on upgrades every cycle, *or*
who have knowledgeable geeks like me to fix their system for them, and
remain a *pure* user. How that plays out across the large numbers of
users across the world is hard to guess with accuracy.
Either way, we do need progress, and I am all in favour of driving
exciting new features - after all think back to the early Fedora days
and compare those old versions with f13 - there is no comparison, and
we *do* have a superb and efficient and very usable operating system -
as we move to f14 and beyond it is absolutely right to move forward
onto new ideas and developments with enthusiasm. Of course there will
be rocky roads to drive across and there are always unforeseen
problems to resolve - but that is what being a developer is all about
- so long as the bugs and issues get resolved in a satisfactory way
then we are doing the right thing.
Fedora leads the way in some of the linux areas - and sure there are
plenty of people who use Ubuntu and won't switch to Fedora - but in
some areas Fedora is ahead - but I bet that unless things deteriorated
markedly then there will still be a supportive and vibrant Fedora user
community. Just by the way I am an academic and I do know some
students in my department who run Fedora - in fact the majority of
linux machines in my department run either Fedora or Centos but not
Ubuntu!
--
mike c
1:21 p.m.
New subject: fedora mission (was Re: systemd and changes)
Matthew Miller wrote:
> I don't know a single student using Fedora anymore,
> I don't know *what* to blame that on
I blame it on people slowly destroying what Fedora is all about, with things
like that "stable updates vision".
And some of us students switched to Fedora *because of* the stable
updates vision.
In my experience, the lack of Fedora users at my university is mostly
due to other distros having better marketing and the fact that new
people will use whatever they can get help with (ie. whatever distro
their friends are using). It has little to nothing to do with "people
slowly destroying what Fedora is all about."
--
-Eli
5:06 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 24, 2010 at 12:59:57PM -0700, Adam Williamson wrote:
On Tue, 2010-08-24 at 15:40 -0400, Matthew Miller wrote:
> This *is* happening, and we need to tread carefully, because once you loose
> respect and reputation, it is very, very hard to get back.
I really think you're extrapolating too far from some very limited data
here. You have some statistics which indicate that Fedora usage is
declining. You are extrapolating from this to the conclusion that this
is happening because Fedora changes too rapidly. I don't think your data
support your conclusion; I haven't seen you cite any data in support of
your assumption as to the *reason* Fedora usage is declining.
I don't think anyone can generalize that the usage of Fedora is
declining. What we can prove, and certainly is troublesome, is that
yum check-ins of successive releases have been dropping by a couple
percent each release (although downloads are actually up), compared on
a per-week basis. It's no less likely that this decrease is due to
people just staying on a stable release, even past EOL. I've heard
anecdotal evidence to support that, which is no more or less valuable
than any other anecdotal evidence being presented, I suppose (IOW,
probably not worth a thing). If someone can present a hard analysis
that points to only one possible scenario, fantastic -- we can start
looking at causes.
None of the foregoing paragraph is meant to write off concern about
watching out for our users. We can innovate, and we can do it with
proper care for a wide group of people, including people like Matt who
are experienced sysadmins not opposed to change "a priori" (lifting
your words, Matt).
But we can't innovate at all without trying new things at some point.
That point ought to be based on something solid like the acceptance
criteria Bill's already writing up. Then FESCo can have more
confidence in making a decision about it. I'd rather concentrate on
that constructive effort than epidemiologically questionable
generalizations.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
Where open source multiplies: http://opensource.com
6:31 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 24, 2010 at 06:06:45PM -0400, Paul W. Frields wrote:
But we can't innovate at all without trying new things at some
point.
That point ought to be based on something solid like the acceptance
criteria Bill's already writing up. Then FESCo can have more
confidence in making a decision about it. I'd rather concentrate on
that constructive effort than epidemiologically questionable
generalizations.
Fair enough. I'll back off of those. It's a discussion for a different list,
anyway.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
7:19 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 24, 2010 at 2:06 PM, Paul W. Frields <stickster(a)gmail.com> wrote:
I don't think anyone can generalize that the usage of Fedora is
declining. What we can prove, and certainly is troublesome, is that
yum check-ins of successive releases have been dropping by a couple
percent each release (although downloads are actually up), compared on
a per-week basis. It's no less likely that this decrease is due to
people just staying on a stable release, even past EOL. I've heard
anecdotal evidence to support that, which is no more or less valuable
than any other anecdotal evidence being presented, I suppose (IOW,
probably not worth a thing). If someone can present a hard analysis
that points to only one possible scenario, fantastic -- we can start
looking at causes.
One additional metric which I'd like to see is the raw number of yum
check-ins per week regardless of ip-addresses as an historic trend.
As a stand alone metric its prone to both over and under counting like
the other metrics but in a different way. It would be interesting to
see if the raw yum check-in counts as an historic trend followed the
download trending or the unique-ip trending.
-jef
8:41 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, 24 Aug 2010, Jeff Spaleta wrote:
On Tue, Aug 24, 2010 at 2:06 PM, Paul W. Frields
<stickster(a)gmail.com> wrote:
> I don't think anyone can generalize that the usage of Fedora is
> declining. What we can prove, and certainly is troublesome, is that
> yum check-ins of successive releases have been dropping by a couple
> percent each release (although downloads are actually up), compared on
> a per-week basis. It's no less likely that this decrease is due to
> people just staying on a stable release, even past EOL. I've heard
> anecdotal evidence to support that, which is no more or less valuable
> than any other anecdotal evidence being presented, I suppose (IOW,
> probably not worth a thing). If someone can present a hard analysis
> that points to only one possible scenario, fantastic -- we can start
> looking at causes.
One additional metric which I'd like to see is the raw number of yum
check-ins per week regardless of ip-addresses as an historic trend.
As a stand alone metric its prone to both over and under counting like
the other metrics but in a different way. It would be interesting to
see if the raw yum check-in counts as an historic trend followed the
download trending or the unique-ip trending.
Ask and ye' shall receive.
http://mmcgrath.fedorapeople.org/yum_hits.html
I'm not quite sure what to make of it all yet except that this trend does
conflict with the "current release" numbers we have on the statistics page
(indicating people are using Fedora even after EOL) and that security
incidents requiring a rebuild of everything is bad for business, at least
temporarily :)
-Mike
8:43 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Wed, 2010-08-25 at 20:41 -0500, Mike McGrath wrote:
On Tue, 24 Aug 2010, Jeff Spaleta wrote:
> On Tue, Aug 24, 2010 at 2:06 PM, Paul W. Frields <stickster(a)gmail.com> wrote:
> > I don't think anyone can generalize that the usage of Fedora is
> > declining. What we can prove, and certainly is troublesome, is that
> > yum check-ins of successive releases have been dropping by a couple
> > percent each release (although downloads are actually up), compared on
> > a per-week basis. It's no less likely that this decrease is due to
> > people just staying on a stable release, even past EOL. I've heard
> > anecdotal evidence to support that, which is no more or less valuable
> > than any other anecdotal evidence being presented, I suppose (IOW,
> > probably not worth a thing). If someone can present a hard analysis
> > that points to only one possible scenario, fantastic -- we can start
> > looking at causes.
>
> One additional metric which I'd like to see is the raw number of yum
> check-ins per week regardless of ip-addresses as an historic trend.
> As a stand alone metric its prone to both over and under counting like
> the other metrics but in a different way. It would be interesting to
> see if the raw yum check-in counts as an historic trend followed the
> download trending or the unique-ip trending.
>
Ask and ye' shall receive.
http://mmcgrath.fedorapeople.org/yum_hits.html
I'm not quite sure what to make of it all yet except that this trend does
conflict with the "current release" numbers we have on the statistics page
(indicating people are using Fedora even after EOL) and that security
incidents requiring a rebuild of everything is bad for business, at least
temporarily :)
HAHAHAH August 2008.
sigh.
-sv
9:58 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Wed, Aug 25, 2010 at 19:41, Mike McGrath <mmcgrath(a)redhat.com> wrote:
On Tue, 24 Aug 2010, Jeff Spaleta wrote:
> On Tue, Aug 24, 2010 at 2:06 PM, Paul W. Frields <stickster(a)gmail.com> wrote:
> > I don't think anyone can generalize that the usage of Fedora is
> > declining. What we can prove, and certainly is troublesome, is that
> > yum check-ins of successive releases have been dropping by a couple
> > percent each release (although downloads are actually up), compared on
> > a per-week basis. It's no less likely that this decrease is due to
> > people just staying on a stable release, even past EOL. I've heard
> > anecdotal evidence to support that, which is no more or less valuable
> > than any other anecdotal evidence being presented, I suppose (IOW,
> > probably not worth a thing). If someone can present a hard analysis
> > that points to only one possible scenario, fantastic -- we can start
> > looking at causes.
>
> One additional metric which I'd like to see is the raw number of yum
> check-ins per week regardless of ip-addresses as an historic trend.
> As a stand alone metric its prone to both over and under counting like
> the other metrics but in a different way. It would be interesting to
> see if the raw yum check-in counts as an historic trend followed the
> download trending or the unique-ip trending.
>
Ask and ye' shall receive.
http://mmcgrath.fedorapeople.org/yum_hits.html
I'm not quite sure what to make of it all yet except that this trend does
conflict with the "current release" numbers we have on the statistics page
(indicating people are using Fedora even after EOL) and that security
incidents requiring a rebuild of everything is bad for business, at least
temporarily :)
My graphic is not up to date but similar...
http://smooge.fedorapeople.org/images/growth-over-time.png
I need to update the numbers to after may and get the data 'cleaner'
and my lines darker because mmcgrath's looks better than mine.
--
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines
6:58 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Wed, Aug 25, 2010 at 08:41:45PM -0500, Mike McGrath wrote:
On Tue, 24 Aug 2010, Jeff Spaleta wrote:
> On Tue, Aug 24, 2010 at 2:06 PM, Paul W. Frields <stickster(a)gmail.com> wrote:
> > I don't think anyone can generalize that the usage of Fedora is
> > declining. What we can prove, and certainly is troublesome, is that
> > yum check-ins of successive releases have been dropping by a couple
> > percent each release (although downloads are actually up), compared on
> > a per-week basis. It's no less likely that this decrease is due to
> > people just staying on a stable release, even past EOL. I've heard
> > anecdotal evidence to support that, which is no more or less valuable
> > than any other anecdotal evidence being presented, I suppose (IOW,
> > probably not worth a thing). If someone can present a hard analysis
> > that points to only one possible scenario, fantastic -- we can start
> > looking at causes.
>
> One additional metric which I'd like to see is the raw number of yum
> check-ins per week regardless of ip-addresses as an historic trend.
> As a stand alone metric its prone to both over and under counting like
> the other metrics but in a different way. It would be interesting to
> see if the raw yum check-in counts as an historic trend followed the
> download trending or the unique-ip trending.
>
Ask and ye' shall receive.
http://mmcgrath.fedorapeople.org/yum_hits.html
I'm not quite sure what to make of it all yet except that this trend does
conflict with the "current release" numbers we have on the statistics page
(indicating people are using Fedora even after EOL) and that security
incidents requiring a rebuild of everything is bad for business, at least
temporarily :)
This past week for instance, over 20,000 unique new IPs appeared for
Fedora 11:
https://fedoraproject.org/w/index.php?title=Statistics&diff=194190&am...
My hunch is that a couple thousand a week are probably due to cable
modems or laptops moving to addresses we simply haven't seen before.
That's about how many new IPs appear for Fedora 7 or Rawhide each
week. But there's just no way to tell cause other than hunches. The
folks who hang out in IRC #fedora as well as users@ list susbscribers
can confirm people show up pretty frequently with newly-installed EOL
Fedora.
My scripts are always available here for reference.
http://pfrields.fedorapeople.org/scripts/fedora-log1-statistics-scripts.t...
They're based on the command templates that Max originally worked out
with Mike, and linked from the [[Statistics]] wiki page:
https://fedoraproject.org/wiki/Statistics/Commands
If you guys find discrepancies or differences there, let me know; I'm
always looking to make these as accurate as possible.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
Where open source multiplies: http://opensource.com
12:51 p.m.
New subject: fedora mission (was Re: systemd and changes)
Paul W. Frields wrote:
My hunch is that a couple thousand a week are probably due to cable
modems or laptops moving to addresses we simply haven't seen before.
That's about how many new IPs appear for Fedora 7 or Rawhide each
week. But there's just no way to tell cause other than hunches. The
folks who hang out in IRC #fedora as well as users@ list susbscribers
can confirm people show up pretty frequently with newly-installed EOL
Fedora.
We probably need to attack this trend more aggressively, like putting
expiration dates into the installer after which it'll just refuse to
install, stuffing fedora-release-n+1 into the Fedora n updates repository at
Fedora n's EOL date etc.
It is completely unresponsible to install obsolete releases which don't get
security updates anymore, and some people just won't listen.
Kevin Kofler
1:03 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Thu, 2010-08-26 at 19:51 +0200, Kevin Kofler wrote:
We probably need to attack this trend more aggressively, like putting
expiration dates into the installer after which it'll just refuse to
install
Honestly, that's just a great way to turn more people off.
There are plenty of valid reasons to run old software, security updates
or no - testing for compatibility being one obvious one (either with the
O/S itself, or versions of software the O/S shipped with - when did
Fedora last ship Firefox 2, for example?)
Putting up a message saying "this is no longer supported" - fine.
Stopping people / making it impossible? That's not "Freedom".
Cheers,
Alex.
--
This message was scanned by Better Hosted and is believed to be clean.
http://www.betterhosted.com
7:32 p.m.
New subject: fedora mission (was Re: systemd and changes)
On 26/08/10 12:03 PM, Alex Hudson wrote:
On Thu, 2010-08-26 at 19:51 +0200, Kevin Kofler wrote:
> We probably need to attack this trend more aggressively, like putting
> expiration dates into the installer after which it'll just refuse to
> install
Putting up a message saying "this is no longer supported" - fine.
Agreed.
Stopping people / making it impossible? That's not
"Freedom".
It's... DRM!
thufor
2:21 p.m.
New subject: fedora mission (was Re: systemd and changes)
Kevin Kofler wrote:
We probably need to attack this trend more aggressively, like putting
expiration dates into the installer after which it'll just refuse to
install, stuffing fedora-release-n+1 into the Fedora n updates repository at
Fedora n's EOL date etc.
Not only is this disingenuous, but it also contradicts Fedora's
"Freedom" policy. Adding a big fat warning message to the installer,
however, is much less of a problem and gets the message across just as
effectively. Just make sure that the "expiration date" is far enough
out in the future that we can be certain that it will occur after the
release's EOL date since we don't know when that will be at the time of
image creation.
11:53 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Thursday 26 of August 2010 21:21:53 Garrett Holmstrom wrote:
Kevin Kofler wrote:
> We probably need to attack this trend more aggressively, like putting
> expiration dates into the installer after which it'll just refuse to
> install, stuffing fedora-release-n+1 into the Fedora n updates repository
> at Fedora n's EOL date etc.
Not only is this disingenuous, but it also contradicts Fedora's
"Freedom" policy. Adding a big fat warning message to the installer,
however, is much less of a problem and gets the message across just as
effectively. Just make sure that the "expiration date" is far enough
out in the future that we can be certain that it will occur after the
release's EOL date since we don't know when that will be at the time of
image creation.
I don't think it should be far enough. It should be some time before EOL
happens. What's the point installing and configuring new system that will EOL
tomorrow / after one week? But still... +1 to warning message in the installer
12:03 a.m.
New subject: fedora mission (was Re: systemd and changes)
On 8/26/2010 11:53 PM, Michal Hlavinka wrote:
On Thursday 26 of August 2010 21:21:53 Garrett Holmstrom wrote:
> Kevin Kofler wrote:
>> We probably need to attack this trend more aggressively, like putting
>> expiration dates into the installer after which it'll just refuse to
>> install, stuffing fedora-release-n+1 into the Fedora n updates repository
>> at Fedora n's EOL date etc.
>
> Not only is this disingenuous, but it also contradicts Fedora's
> "Freedom" policy. Adding a big fat warning message to the installer,
> however, is much less of a problem and gets the message across just as
> effectively. Just make sure that the "expiration date" is far enough
> out in the future that we can be certain that it will occur after the
> release's EOL date since we don't know when that will be at the time of
> image creation.
I don't think it should be far enough. It should be some time before EOL
happens. What's the point installing and configuring new system that will EOL
tomorrow / after one week? But still... +1 to warning message in the installer
At the time the install images are composed the release's EOL date has
not yet been decided, so we would be stuck with guessing a date and
hoping it will be somewhat close.
Fedora releases are either "Supported" or "Unsupported." Unless the
community wants to define some third, "Sort-of-supported" state then
there should be no functional changes in the installer's and
repositories' behaviors until after the release goes "Unsupported."
--
Garrett Holmstrom
12:26 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Friday 27 of August 2010 07:03:06 Garrett Holmstrom wrote:
On 8/26/2010 11:53 PM, Michal Hlavinka wrote:
> On Thursday 26 of August 2010 21:21:53 Garrett Holmstrom wrote:
>> Kevin Kofler wrote:
>>> We probably need to attack this trend more aggressively, like putting
>>> expiration dates into the installer after which it'll just refuse to
>>> install, stuffing fedora-release-n+1 into the Fedora n updates
>>> repository at Fedora n's EOL date etc.
>>
>> Not only is this disingenuous, but it also contradicts Fedora's
>> "Freedom" policy. Adding a big fat warning message to the installer,
>> however, is much less of a problem and gets the message across just as
>> effectively. Just make sure that the "expiration date" is far enough
>> out in the future that we can be certain that it will occur after the
>> release's EOL date since we don't know when that will be at the time of
>> image creation.
>
> I don't think it should be far enough. It should be some time before EOL
> happens. What's the point installing and configuring new system that will
> EOL tomorrow / after one week? But still... +1 to warning message in the
> installer
At the time the install images are composed the release's EOL date has
not yet been decided, so we would be stuck with guessing a date and
hoping it will be somewhat close.
Fedora releases are either "Supported" or "Unsupported." Unless the
community wants to define some third, "Sort-of-supported" state then
there should be no functional changes in the installer's and
repositories' behaviors until after the release goes "Unsupported."
Yes, but the message does not have to be "Warning: Fedora N is no longer
supported", it can be something like "Warning: Fedora relase is usualy
supported 13 months, you are probably going to install unsupported version or
version that is going to be unsupported after a few days. You can check this
on fedoraproject.org.... Check get.fedoraproject.org for more recent version."
I think the wording is not the main problem
7:31 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Fri, Aug 27, 2010 at 12:03:06AM -0500, Garrett Holmstrom wrote:
At the time the install images are composed the release's EOL
date has
not yet been decided, so we would be stuck with guessing a date and
hoping it will be somewhat close.
Give it a year, and it's still better than the current state.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
3:03 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Thu, 26 Aug 2010 19:51:09 +0200
Kevin Kofler <kevin.kofler(a)chello.at> wrote:
It is completely unresponsible to install obsolete releases which
don't get security updates anymore, and some people just won't listen.
Some people also have no choice due to hardware requirements and have
non-networked uses that makes them less susceptible from security
issues.
Why should we make crippleware ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
3:37 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Thu, 2010-08-26 at 19:51 +0200, Kevin Kofler wrote:
Paul W. Frields wrote:
> My hunch is that a couple thousand a week are probably due to cable
> modems or laptops moving to addresses we simply haven't seen before.
> That's about how many new IPs appear for Fedora 7 or Rawhide each
> week. But there's just no way to tell cause other than hunches. The
> folks who hang out in IRC #fedora as well as users@ list susbscribers
> can confirm people show up pretty frequently with newly-installed EOL
> Fedora.
We probably need to attack this trend more aggressively, like putting
expiration dates into the installer after which it'll just refuse to
install, stuffing fedora-release-n+1 into the Fedora n updates repository at
Fedora n's EOL date etc.
Ah yes, attack the symptom and not the disease. Yay. Let me let you in
on a secret. Most people (and by which I mean, those not on this list)
generally don't like re-installing or upgrading their computer every 6
months. People install older releases because it's what they have (in
which case, there's a valid reason to push for the latest) BUT also
because they don't want to be using an extension of rawhide. They want
to wait a little time for things to settle down, for there to be fewer
updates to waste their time on, etc. It's the rate of churn, lack of
durability in the length of the cycle, etc. that are the problems.
But sure, we can blame the users, and scratch our heads when the figures
indicate what might be happening, why people are jumping ship, etc. and
not have a user survey to tell us what the users want (a fantastic
idea). These would all help maintain the status quo just fine.
Jon.
4:54 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Fri, 2010-08-27 at 16:37 -0400, Jon Masters wrote:
Ah yes, attack the symptom and not the disease. Yay. Let me let you in
on a secret. Most people (and by which I mean, those not on this list)
generally don't like re-installing or upgrading their computer every 6
months. People install older releases because it's what they have (in
which case, there's a valid reason to push for the latest) BUT also
because they don't want to be using an extension of rawhide. They want
to wait a little time for things to settle down, for there to be fewer
updates to waste their time on, etc. It's the rate of churn, lack of
durability in the length of the cycle, etc. that are the problems.
But sure, we can blame the users, and scratch our heads when the figures
indicate what might be happening, why people are jumping ship, etc. and
not have a user survey to tell us what the users want (a fantastic
idea). These would all help maintain the status quo just fine.
Your attack is misguided, Jon. It is very much our responsibility to
inform users that the software they install or use is no longer actively
supported.
5:08 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Fri, 2010-08-27 at 17:54 -0400, Matthias Clasen wrote:
On Fri, 2010-08-27 at 16:37 -0400, Jon Masters wrote:
>
> Ah yes, attack the symptom and not the disease. Yay. Let me let you in
> on a secret. Most people (and by which I mean, those not on this list)
> generally don't like re-installing or upgrading their computer every 6
> months. People install older releases because it's what they have (in
> which case, there's a valid reason to push for the latest) BUT also
> because they don't want to be using an extension of rawhide. They want
> to wait a little time for things to settle down, for there to be fewer
> updates to waste their time on, etc. It's the rate of churn, lack of
> durability in the length of the cycle, etc. that are the problems.
>
> But sure, we can blame the users, and scratch our heads when the figures
> indicate what might be happening, why people are jumping ship, etc. and
> not have a user survey to tell us what the users want (a fantastic
> idea). These would all help maintain the status quo just fine.
Your attack is misguided, Jon. It is very much our responsibility to
inform users that the software they install or use is no longer actively
supported.
I'm not saying that. I'm saying that the real problem here might be
people are running older releases because they are looking for a more
stable environment or just don't want to upgrade every 6 months. This
isn't a RHEL/other-derivative vs. Fedora thing. Because "Enterprise"
distributions give you many years and lots more guarantees. Way beyond
what I personally feel is needed here. But again, since we have never
taken the initiative to ask people why they leave Fedora or why they
stick with old releases, we won't know the answer to this.
Again, I feel it is necessary to have a survey of Fedora users.
Preferably annually. And listen to the feedback. If they say "yep, we
just love the churn, the number of updates" and so forth, then fine. If
they say "actually we'd like less than 800 updates after installing",
then also fine. I'm sorry to beat a dead horse, I just feel it is very
important that we finally, clearly articulate who our users are and what
they want by treating more like customers and gathering their input.
Jon.
5:19 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Fri, Aug 27, 2010 at 2:08 PM, Jon Masters <jonathan(a)jonmasters.org> wrote:
Again, I feel it is necessary to have a survey of Fedora users.
Preferably annually. And listen to the feedback. If they say "yep, we
just love the churn, the number of updates" and so forth, then fine. If
they say "actually we'd like less than 800 updates after installing",
then also fine. I'm sorry to beat a dead horse, I just feel it is very
important that we finally, clearly articulate who our users are and what
they want by treating more like customers and gathering their input.
How would you prevent such a survey opportunity from being dominated
by a vocal minority that wasn't actually representative? It's a
difficult question.
We can't articulate who are users are. We can articulate who are
target users are. And then we can try to survey that target and see if
we are meeting their needs. Whether or not there is significant usage
outside that target group is an interesting question..but not
necessary the question of most importance.
-jef
5:47 p.m.
New subject: fedora mission (was Re: systemd and changes)
On 08/27/10 15:19, Jeff Spaleta wrote:
On Fri, Aug 27, 2010 at 2:08 PM, Jon
Masters<jonathan(a)jonmasters.org> wrote:
> Again, I feel it is necessary to have a survey of Fedora users.
> Preferably annually. And listen to the feedback. If they say "yep, we
> just love the churn, the number of updates" and so forth, then fine. If
> they say "actually we'd like less than 800 updates after installing",
> then also fine. I'm sorry to beat a dead horse, I just feel it is very
> important that we finally, clearly articulate who our users are and what
> they want by treating more like customers and gathering their input.
How would you prevent such a survey opportunity from being dominated
by a vocal minority that wasn't actually representative? It's a
difficult question.
We can't articulate who are users are. We can articulate who are
target users are. And then we can try to survey that target and see if
we are meeting their needs. Whether or not there is significant usage
outside that target group is an interesting question..but not
necessary the question of most importance.
-jef
Actually I think Fedora *should* articulate who the users are, basically
design and express who and what Fedora is designed for. If you poll
"users" - people who download Fedora - and cater to their stated desires
for the sake of market share, then market forces will start to drive the
shape of the distro. Populist market forces would tend to force everything
to a gray mushy mass of similar distros.
(see http://en.wikipedia.org/wiki/Hotelling%27s_law).
I think it would be much better for Fedora to decide what it *should* be,
specifically what the Fedora userspace should be, and excel at that.
Don't follow the "market" or worry about being the most popular distro
(unless that's really a goal ..?) Decide the niche, and be strong in
that niche.
Cheers,
-Bob Arendt
5:49 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Fri, 2010-08-27 at 15:47 -0700, Bob Arendt wrote:
I think it would be much better for Fedora to decide what it *should*
be,
specifically what the Fedora userspace should be, and excel at that.
Don't follow the "market" or worry about being the most popular distro
(unless that's really a goal ..?) Decide the niche, and be strong in
that niche.
That is also an acceptable outcome. What is not acceptable is the
current status quo. We either ask our users what they want and do that,
or very explicitly state "This is Fedora, this is what is does, this is
who are userbase is, and this is what we offer".
I am open to either outcome, and I am not immovable, but I am tired of
seeing discussions wherein there seems to lack a clear focus.
Jon.
5:58 p.m.
New subject: fedora mission (was Re: systemd and changes)
"Jon Masters" <jonathan(a)jonmasters.org> wrote:
On Fri, 2010-08-27 at 15:47 -0700, Bob Arendt wrote:
> I think it would be much better for Fedora to decide what it *should* be,
> specifically what the Fedora userspace should be, and excel at that.
> Don't follow the "market" or worry about being the most popular distro
> (unless that's really a goal ..?) Decide the niche, and be strong in
> that niche.
That is also an acceptable outcome. What is not acceptable is the
current status quo. We either ask our users what they want and do that,
or very explicitly state "This is Fedora, this is what is does, this is
who are userbase is, and this is what we offer".
Pretty sure the board is trying to do exactly that, then ask fesco to implement it.
I am open to either outcome, and I am not immovable, but I am tired of
seeing discussions wherein there seems to lack a clear focus.
Jon.
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Sent from my Android phone. Please excuse my brevity.
4:03 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Fri, 2010-08-27 at 18:49 -0400, Jon Masters wrote:
On Fri, 2010-08-27 at 15:47 -0700, Bob Arendt wrote:
> I think it would be much better for Fedora to decide what it *should* be,
> specifically what the Fedora userspace should be, and excel at that.
> Don't follow the "market" or worry about being the most popular
distro
> (unless that's really a goal ..?) Decide the niche, and be strong in
> that niche.
That is also an acceptable outcome. What is not acceptable is the
current status quo. We either ask our users what they want and do that,
or very explicitly state "This is Fedora, this is what is does, this is
who are userbase is, and this is what we offer".
I actually think your survey request should happen either way. Even if
Fedora says up-front "Our goals are X, Y, and Z, and every decision we
take is aimed at reaching those goals" (whether it's "be on the bleeding
edge", or whatever), the feedback from users is crucial in determining
whether or not those goals are being met.
Cheers
Alex
--
This message was scanned by Better Hosted and is believed to be clean.
http://www.betterhosted.com
6:09 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Fri, Aug 27, 2010 at 2:47 PM, Bob Arendt <rda(a)rincon.com> wrote:
Actually I think Fedora *should* articulate who the users are,
basically
design and express who and what Fedora is designed for.
<snip>
I think it would be much better for Fedora to decide what it *should*
be,
specifically what the Fedora userspace should be, and excel at that.
You have contradicted yourself a little bit here. And maybe its a
language barrier so I'll be explicit.
Who the users are now and who our users should be are not necessarily
the same group. Polling our current user-base doesn't necessarily help
us define who are users should be. And similarly polling our current
user-base doesn't necessarily help us identify what we need to do
better to better find and serve the users who should be using Fedora.
Nor does it necessarily help us focus on the needs on any particular
group that currently exists. We have some users who want A. We have
some users who want B. That's what a survey will tell us, it won't
help us judge the value of A relative to the value of B as a focus.
-jef
6:52 p.m.
New subject: fedora mission (was Re: systemd and changes)
On 08/27/10 16:09, Jeff Spaleta wrote:
On Fri, Aug 27, 2010 at 2:47 PM, Bob Arendt<rda(a)rincon.com>
wrote:
> Actually I think Fedora *should* articulate who the users are, basically
> design and express who and what Fedora is designed for.
<snip>
> I think it would be much better for Fedora to decide what it *should* be,
> specifically what the Fedora userspace should be, and excel at that.
You have contradicted yourself a little bit here. And maybe its a
language barrier so I'll be explicit.
Who the users are now and who our users should be are not necessarily
the same group. Polling our current user-base doesn't necessarily help
us define who are users should be. And similarly polling our current
user-base doesn't necessarily help us identify what we need to do
better to better find and serve the users who should be using Fedora.
Nor does it necessarily help us focus on the needs on any particular
group that currently exists. We have some users who want A. We have
some users who want B. That's what a survey will tell us, it won't
help us judge the value of A relative to the value of B as a focus.
-jef
My first statement was poorly phrased. Fedora should state it's principles,
properties, use-cases, plant it's flag, and call for users that are
interested in these characteristics to rally around it. Fedora seems to do
this from time to time; My point is that it should continue to do this.
The real people who should decide that direction are the contributors - it's
where the project's strength and energy comes from. Developers, testers, etc.
Poll your contributors - polling the userbase adds noise. Fedora should
stick with it's Meritocratic roots.
.. of course, not being a significant contributor, I've disenfranchised
myself. But I'm still a strong Fedora follower and enjoy the distribution.
Cheers,
-Bob Arendt
9:32 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Fri, Aug 27, 2010 at 7:52 PM, Bob Arendt <rda(a)rincon.com> wrote:
On 08/27/10 16:09, Jeff Spaleta wrote:
> On Fri, Aug 27, 2010 at 2:47 PM, Bob Arendt<rda(a)rincon.com> wrote:
>> Actually I think Fedora *should* articulate who the users are, basically
>> design and express who and what Fedora is designed for.
> <snip>
>> I think it would be much better for Fedora to decide what it *should* be,
>> specifically what the Fedora userspace should be, and excel at that.
>
> You have contradicted yourself a little bit here. And maybe its a
> language barrier so I'll be explicit.
>
> Who the users are now and who our users should be are not necessarily
> the same group. Polling our current user-base doesn't necessarily help
> us define who are users should be. And similarly polling our current
> user-base doesn't necessarily help us identify what we need to do
> better to better find and serve the users who should be using Fedora.
> Nor does it necessarily help us focus on the needs on any particular
> group that currently exists. We have some users who want A. We have
> some users who want B. That's what a survey will tell us, it won't
> help us judge the value of A relative to the value of B as a focus.
>
> -jef
My first statement was poorly phrased. Fedora should state it's principles,
properties, use-cases, plant it's flag, and call for users that are
interested in these characteristics to rally around it. Fedora seems to do
this from time to time; My point is that it should continue to do this.
The real people who should decide that direction are the contributors - it's
where the project's strength and energy comes from. Developers, testers, etc.
Poll your contributors - polling the userbase adds noise. Fedora should
stick with it's Meritocratic roots.
Isn't this what you're asking for? Seems like this same discussion
happened last year and this was the result.
https://fedoraproject.org/wiki/User_base
Polling your users, via a posting on one of the lists isn't going to
work. Most of the people that I work with that are using Fedora don't
even bother to follow the mailing lists. The best bet is to put
polls on the start page of the browser and that only works if they've
not changed their homepage. Market research firms get paid lots of
money to try to do this. Their results for measuring the community in
general is pretty weak.
For my part I think the User Base is a reasonable expectation for new
users and that might be as good as it gets. Of course, I don't have
too many issues with wha'ts happening. Even though there are a lot of
updates, I expect to be on the edge and I'm okay with that.
12:50 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Fri, 2010-08-27 at 15:47 -0700, Bob Arendt wrote:
On 08/27/10 15:19, Jeff Spaleta wrote:
> On Fri, Aug 27, 2010 at 2:08 PM, Jon Masters<jonathan(a)jonmasters.org> wrote:
>> Again, I feel it is necessary to have a survey of Fedora users.
>> Preferably annually. And listen to the feedback. If they say "yep, we
>> just love the churn, the number of updates" and so forth, then fine. If
>> they say "actually we'd like less than 800 updates after
installing",
>> then also fine. I'm sorry to beat a dead horse, I just feel it is very
>> important that we finally, clearly articulate who our users are and what
>> they want by treating more like customers and gathering their input.
>
> How would you prevent such a survey opportunity from being dominated
> by a vocal minority that wasn't actually representative? It's a
> difficult question.
>
> We can't articulate who are users are. We can articulate who are
> target users are. And then we can try to survey that target and see if
> we are meeting their needs. Whether or not there is significant usage
> outside that target group is an interesting question..but not
> necessary the question of most importance.
>
> -jef
Actually I think Fedora *should* articulate who the users are, basically
design and express who and what Fedora is designed for. If you poll
If you read Jef's mail carefully, you'd notice that's exactly what he's
saying. Pay attention to the distinction between 'users' and 'target
users'.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12:16 p.m.
New subject: fedora mission (was Re: systemd and changes)
On 08/27/2010 10:47 PM, Bob Arendt wrote:
Actually I think Fedora*should* articulate who the users are,
basically
design and express who and what Fedora is designed for. If you poll
"users" - people who download Fedora - and cater to their stated desires
for the sake of market share, then market forces will start to drive the
shape of the distro. Populist market forces would tend to force everything
to a gray mushy mass of similar distros.
(seehttp://en.wikipedia.org/wiki/Hotelling%27s_law).
I think it would be much better for Fedora to decide what it*should* be,
specifically what the Fedora userspace should be, and excel at that.
Don't follow the "market" or worry about being the most popular distro
(unless that's really a goal ..?) Decide the niche, and be strong in
that niche.
I see no difference in the market directly affecting the shape of the
distro or a corporate entity which is driven by the market which then
shapes the distro to it's need to feed that market.
We have a clear cut example what can happen ( The Oracle and OpenSolaris
case ) so first and foremost we need to make sure that a single
corporate entity does not have control over the project which means that
no corporate entity may have majority of it's employ in boards, steering
committees, SIG etc. to prevent that corporate entity seizing control
over the projects, steering it's directions to it's will and for us as a
community not being too depended on that corporate entity should that
corporate be bought or otherwise be controlled by individuals that do
not share the same vision as the community.
It's not far from reality that Red Hat will get bought by a company like
Oracle so what's preventing us to get the same treatment as OpenSolaris
got?
What happens to all the work the community has done, the fruits of our
labour?
The first and foremost mission that the project should be doing at this
point is to make dam sure we are ready for it encase Red Hat will not be
there tomorrow or it's there but not in the same form that we all love.
To make sure that all the countless hours and for some years of
contribution which have grown and make up what Fedora is today will not
be for vain encase that happens and the community continues to thrive
and stay strong.
The first mistake we did was trying to label end user since it's not up
to the project in whole to decide which end user type it's target.
It's should be up to individual community SIG's to decide what user base
they are targeting and the form they will present that to the end user
in live cd or a predefined installation option be it with the latest and
greatest bits of their product or a not which may or may not be
influenced from feed backs from the micro community they have
established around the product they ship.
The Fedora project in whole should give equal access to those bits and
devote equal amount of marketing resources to promote them.
Simply allow the casual user that walks in the Fedora garden to pick
what ever fruit he chooses that grew from the labour of the community to
taste and enjoy.
Unfortunately that is not how things are being done in the Fedora garden
today instead we force one vision ( Desktop ) and with one DE ( Gnome )
which greatly overshadows all the good work that's being done in other
corners in the lcommunity like in server applications and KDE XFCE and
LXDE and willingly or unwilling hinder the growth in the micro community
around those Desktop Environment, hiding them like some rotten apples
from infested tree in a shed in the back yard.
It's going to be interesting to see if we ever reach the point when a
end users would like to search for a certain application for a certain
task he needs to perform and the only application he's offered will be
the Gnome ones.
How many new developers do you honestly think we attract to the
community when the playing field is this and the only game that your
allowed to play is Gnome Desktop.
JBG
12:31 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Sat, Aug 28, 2010 at 17:16:12 +0000,
"\"Jóhann B. Guðmundsson\"" <johannbg(a)gmail.com> wrote:
It's not far from reality that Red Hat will get bought by a
company
like Oracle so what's preventing us to get the same treatment as
OpenSolaris got?
What happens to all the work the community has done, the fruits of
our labour?
The code being distributed and needed for the build system are available.
Removing the trademarked pieces are easy.
So the project would need to change it's name, get new hardware and network
service and hope enough community members continued to work on it and that
there weren't ogranization issues caused by Redhat employees in leadership
positions being lost.
The first mistake we did was trying to label end user since it's
not
up to the project in whole to decide which end user type it's
target.
I disagree. I think the project is the entity that needs to determine this.
It's should be up to individual community SIG's to decide
what user
base they are targeting and the form they will present that to the
end user in live cd or a predefined installation option be it with
the latest and greatest bits of their product or a not which may or
may not be influenced from feed backs from the micro community they
have established around the product they ship.
SIGs will be given a lot of lattitude and the target user will be used
for resolving conflicts between SIGs.
The Fedora project in whole should give equal access to those bits
and devote equal amount of marketing resources to promote them.
I disagree. Resources are limited. We need to prioritize marketing
where it will best benefit the project.
12:43 p.m.
New subject: fedora mission (was Re: systemd and changes)
On 08/28/2010 05:31 PM, Bruno Wolff III wrote:
On Sat, Aug 28, 2010 at 17:16:12 +0000,
"\"Jóhann B. Guðmundsson\""<johannbg(a)gmail.com> wrote:
> It's not far from reality that Red Hat will get bought by a company
> like Oracle so what's preventing us to get the same treatment as
> OpenSolaris got?
>
> What happens to all the work the community has done, the fruits of
> our labour?
The code being distributed and needed for the build system are available.
Removing the trademarked pieces are easy.
So the project would need to change it's name, get new hardware and network
service and hope enough community members continued to work on it and that
there weren't ogranization issues caused by Redhat employees in leadership
positions being lost.
For every leadership position that a corporate employee has there needs
to be a equal community member that shares that same role with him.
> The first mistake we did was trying to label end user since it's not
> up to the project in whole to decide which end user type it's
> target.
I disagree. I think the project is the entity that needs to determine this.
Unfortunate this has the side effect off taking side of one part of the
community over the other ( and the problem that comes with that ) and
usually people that are asked in cases like these are not the once
directly affected by the outcome of that decision.
> It's should be up to individual community SIG's to decide
what user
> base they are targeting and the form they will present that to the
> end user in live cd or a predefined installation option be it with
> the latest and greatest bits of their product or a not which may or
> may not be influenced from feed backs from the micro community they
> have established around the product they ship.
SIGs will be given a lot of lattitude and the target user will be used
for resolving conflicts between SIGs.
Not following you here as I see it there would be no conflicts if the
SIGs them selves decided who their target audience is.
> The Fedora project in whole should give equal access to those
bits
> and devote equal amount of marketing resources to promote them.
I disagree. Resources are limited. We need to prioritize marketing
where it will best benefit the project.
1)
What would be the criteria to determine how to spend those resources.
2)
Should we not then be spending all those resources strictly on core
components on marketing the community in whole where all would benefit
not a sub community within the community in whole..
1:05 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Sat, Aug 28, 2010 at 17:43:35 +0000,
"\"Jóhann B. Guðmundsson\"" <johannbg(a)gmail.com> wrote:
Unfortunate this has the side effect off taking side of one part of the
community over the other ( and the problem that comes with that ) and
usually people that are asked in cases like these are not the once
directly affected by the outcome of that decision.
If two parts of the project have conflicting desires, than one is not
going to get what they want.
Not following you here as I see it there would be no conflicts if the
SIGs them selves decided who their target audience is.
SIGs don't work in independent silos. They share code and resources with
the rest of the project. As such they can have conflicts with other SIGs.
1)
What would be the criteria to determine how to spend those resources.
I don't know. Marketing isn't my field. There is a marketing team and maybe
someone from that group could weigh in on this.
2)
Should we not then be spending all those resources strictly on core
components on marketing the community in whole where all would benefit
not a sub community within the community in whole..
That is still going to favor some SIGs over others.
1:42 p.m.
New subject: fedora mission (was Re: systemd and changes)
"Jóhann B. Guðmundsson" <johannbg(a)gmail.com> wrote:
On 08/28/2010 05:31 PM, Bruno Wolff III wrote:
> On Sat, Aug 28, 2010 at 17:16:12 +0000,
> "\"Jóhann B. Guðmundsson\""<johannbg(a)gmail.com> wrote:
>> It's not far from reality that Red Hat will get bought by a company
>> like Oracle so what's preventing us to get the same treatment as
>> OpenSolaris got?
>>
>> What happens to all the work the community has done, the fruits of
>> our labour?
> The code being distributed and needed for the build system are available.
> Removing the trademarked pieces are easy.
>
> So the project would need to change it's name, get new hardware and network
> service and hope enough community members continued to work on it and that
> there weren't ogranization issues caused by Redhat employees in leadership
> positions being lost.
For every leadership position that a corporate employee has there needs
to be a equal community member that shares that same role with him.
This is utter bullshit. It assumes that anybody who works in the corporate world and
happens to have an interest in Fedora is somehow going to be a puppet for the Smokey
backroom corporate overlords and their evil designs upon Fedora. It's ludicrous. What
about people who work for a university, or work for themselves? Are they somehow immune to
making decisions that benefit themselves or their paycheck writer?
This continued distinction of "corporate worker" vs "community" is
pointless and poisonous.
>
>> The first mistake we did was trying to label end user since it's not
>> up to the project in whole to decide which end user type it's
>> target.
> I disagree. I think the project is the entity that needs to determine this.
Unfortunate this has the side effect off taking side of one part of the
community over the other ( and the problem that comes with that ) and
usually people that are asked in cases like these are not the once
directly affected by the outcome of that decision.
So long as there are SIGs with their own target group and outcome there are going to be
conflicts in direction and vision.
>> It's should be up to individual community SIG's to
decide what user
>> base they are targeting and the form they will present that to the
>> end user in live cd or a predefined installation option be it with
>> the latest and greatest bits of their product or a not which may or
>> may not be influenced from feed backs from the micro community they
>> have established around the product they ship.
> SIGs will be given a lot of lattitude and the target user will be used
> for resolving conflicts between SIGs.
>
Not following you here as I see it there would be no conflicts if the
SIGs them selves decided who their target audience is.
What the mobile sig and what the server sig want are going to be different things. That
conflict will show itself in package configs, comps groupings, update policy, etc...
>> The Fedora project in whole should give equal access to those
bits
>> and devote equal amount of marketing resources to promote them.
> I disagree. Resources are limited. We need to prioritize marketing
> where it will best benefit the project.
1)
What would be the criteria to determine how to spend those resources.
2)
Should we not then be spending all those resources strictly on core
components on marketing the community in whole where all would benefit
not a sub community within the community in whole..
The board has decided and defined a target audience, and an offering that benefits that
audience. This is where project level marketing and other resources are going to be
focused. SIGs can target and market to other people, so long as their changes do not
conflict too greatly with the needs of the project default target and offering.
--
Sent from my Android phone. Please excuse my brevity.
2:09 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Sat, Aug 28, 2010 at 11:42:15 -0700,
Jesse Keating <jkeating(a)j2solutions.net> wrote:
This is utter bullshit. It assumes that anybody who works in the corporate world and
happens to have an interest in Fedora is somehow going to be a puppet for the Smokey
backroom corporate overlords and their evil designs upon Fedora. It's ludicrous. What
about people who work for a university, or work for themselves? Are they somehow immune to
making decisions that benefit themselves or their paycheck writer?
For my part I was assuming that the hypothetical buyer might order their
employees not to work on Fedora any more if they wanted to keep their jobs.
I further assumed that not all of the employees would be in a position to
immediately resign and would not be able to participate in the new Fedora
for a noticeable period of time.
The particular issue with Redhat employees is that there are a lot of them
contributing to Fedora and doing a lot of work for Fedora. If my employer
banned employees from working on Fedora, I think I would be the only
contributor (not counting people who just file bug reports or
lurk on the mailing lists) taken out.
I think takeover of Redhat by some company hostile to Fedora is possible,
but pretty unlikely.
2:42 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Sat, Aug 28, 2010 at 11:42:15AM -0700, Jesse Keating wrote:
What the mobile sig and what the server sig want are going to be
different
things. That conflict will show itself in package configs, comps
groupings, update policy, etc...
Actually, not necessarily. Those two groups both have a pretty strong
interest in minimalism.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
2:56 p.m.
New subject: fedora mission (was Re: systemd and changes)
On 08/28/2010 06:42 PM, Jesse Keating wrote:
This is utter bullshit. It assumes that anybody who works in the
corporate world and happens to have an interest in Fedora is somehow going to be a puppet
for the Smokey backroom corporate overlords and their evil designs upon Fedora. It's
ludicrous. What about people who work for a university, or work for themselves? Are they
somehow immune to making decisions that benefit themselves or their paycheck writer?
This continued distinction of "corporate worker" vs "community" is
pointless and poisonous.
Jesse excuse me since I dont think this is utter bullshit and pointless
and poisonous.
I just want remind you that I both live and come from a country that
recently was flushed down the drain thanks to a hand full of smokey back
room corporate overlords. You might not believe in their existance but I
certanly do since I'm paying for their mistake as will my descendants.
There is a difference for individual that get paid to work with a
project and those that don't but do so of their own free will and that
individual might well be working for the same company as the one that
get paid to do so.
The distinction remains the same thou, one is the doing something to
benefit his employer in some way or form, he may like what he's doing
but in the end that's still what he's doing while the other one is not.
I have absolutely no idea how many of Red Hat employs are doing because
they get paid to do so and how many of them are contributing to Fedora
on their own accordance and honestly you cant expect me to know that.
Perhaps you can share some light on that?
I have no idea where Fedora stands within Red Hat and if there is some
kind of backup plan that Red Hat has in place encase it gets bought by
some corporate which looks at Fedora and deems it not profitable enough
and decides to write it of.
But the threat is real so regardless of what the corporate entity is we
need to remain strong enough to stand on our own two fleets if we ever
find ourself in that situation.
Let's just hope it never comes down to that.
JBG
3:28 p.m.
New subject: fedora mission (was Re: systemd and changes)
"Jóhann B. Guðmundsson" <johannbg(a)gmail.com> wrote:
On 08/28/2010 06:42 PM, Jesse Keating wrote:
> This is utter bullshit. It assumes that anybody who works in the corporate world and
happens to have an interest in Fedora is somehow going to be a puppet for the Smokey
backroom corporate overlords and their evil designs upon Fedora. It's ludicrous. What
about people who work for a university, or work for themselves? Are they somehow immune to
making decisions that benefit themselves or their paycheck writer?
>
> This continued distinction of "corporate worker" vs "community"
is pointless and poisonous.
Jesse excuse me since I dont think this is utter bullshit and pointless
and poisonous.
I just want remind you that I both live and come from a country that
recently was flushed down the drain thanks to a hand full of smokey back
room corporate overlords. You might not believe in their existance but I
certanly do since I'm paying for their mistake as will my descendants.
There is a difference for individual that get paid to work with a
project and those that don't but do so of their own free will and that
individual might well be working for the same company as the one that
get paid to do so.
The distinction remains the same thou, one is the doing something to
benefit his employer in some way or form, he may like what he's doing
but in the end that's still what he's doing while the other one is not.
I have absolutely no idea how many of Red Hat employs are doing because
they get paid to do so and how many of them are contributing to Fedora
on their own accordance and honestly you cant expect me to know that.
Perhaps you can share some light on that?
I have no idea where Fedora stands within Red Hat and if there is some
kind of backup plan that Red Hat has in place encase it gets bought by
some corporate which looks at Fedora and deems it not profitable enough
and decides to write it of.
But the threat is real so regardless of what the corporate entity is we
need to remain strong enough to stand on our own two fleets if we ever
find ourself in that situation.
Let's just hope it never comes down to that.
What are you afraid of? Fedora is not a country, you don't have to move to get away.
All the code is free. Most the code isn't even ours, it belongs to the upstreams. If
somebody were to buy RHT, the worse they could do is prevent previous RHT employees from
working on it as their day job, turn off the servers and sit on the trademarks. All the
code and people can go to a new project name. It would just take a few servers and an
uplink to the mirror system, which is not owned by RHT or Fedora. There really isn't
any intellectual property around Fedora that isn't open and transparent. Man power
may die off, but some arbitrary rule about how many people who might be employed by RHT
can serve in decision bodies wouldn't change that at all.
So I ask you again, what are you so afraid of that you think you can fix?
--
Sent from my Android phone. Please excuse my brevity.
4:06 p.m.
New subject: fedora mission (was Re: systemd and changes)
On 08/28/2010 08:28 PM, Jesse Keating wrote:
What are you afraid of?
I think my concerns have been very clear.
Fedora is not a country, you don't have to move to get away.
All the code is free. Most the code isn't even ours, it belongs to the upstreams. If
somebody were to buy RHT, the worse they could do is prevent previous RHT employees from
working on it as their day job, turn off the servers and sit on the trademarks. All the
code and people can go to a new project name. It would just take a few servers and an
uplink to the mirror system, which is not owned by RHT or Fedora. There really isn't
any intellectual property around Fedora that isn't open and transparent. Man power
may die off, but some arbitrary rule about how many people who might be employed by RHT
can serve in decision bodies wouldn't change that at all.
So I ask you again, what are you so afraid of that you think you can fix?
I'm afraid of what might happen if an individual like you, an key player
within the community suddenly disappears from the face of the planet.
So let me ask you this who's your backup ( given that you at least have
one within Red Hat ) and can a community member step in you're shoes to
full fill your role in your absence?
JBG
4:40 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Sat, 28 Aug 2010, "Jóhann B. Guðmundsson" wrote:
On 08/28/2010 08:28 PM, Jesse Keating wrote:
> What are you afraid of?
I think my concerns have been very clear.
> Fedora is not a country, you don't have to move to get away. All the code is
free. Most the code isn't even ours, it belongs to the upstreams. If somebody were to
buy RHT, the worse they could do is prevent previous RHT employees from working on it as
their day job, turn off the servers and sit on the trademarks. All the code and people can
go to a new project name. It would just take a few servers and an uplink to the mirror
system, which is not owned by RHT or Fedora. There really isn't any intellectual
property around Fedora that isn't open and transparent. Man power may die off, but
some arbitrary rule about how many people who might be employed by RHT can serve in
decision bodies wouldn't change that at all.
>
> So I ask you again, what are you so afraid of that you think you can fix?
I'm afraid of what might happen if an individual like you, an key player
within the community suddenly disappears from the face of the planet.
So let me ask you this who's your backup ( given that you at least have
one within Red Hat ) and can a community member step in you're shoes to
full fill your role in your absence?
Dennis is his backup (RH employee) and if need be I know jwb (not redhat
employee) is more than capable of handling these problems. Believe it or
not, we do consider these things and cross train. If you have the
several hours per week available to contribute for a few years you too
could be a backup.
I know it's not a comfortable thing to deal with, I know I'm not super
happy about it but Fedora exists almost entirely because RH wills it to.
If RH decided Fedora should go away, it would. You could fork, have a
mess of a time getting infrastructure, and get that fork going but that
wouldn't be Fedora, it'd be something else.
We tried to turn Fedora into an independent legal entity with multiple
stakeholders and there was almost 0 support in terms of funding for it
(Google: Fedora Foundation). Bottom line, when Red Hat tried to give
Fedora to the community, the community wasn't there to take it. All you
can do is trust RH to do the right thing, know we'll make mistakes from
time to time and know that those of us that were volunteers that have now
been lucky enough to be hired on to do it full time (myself included) are
looking out for Fedora's best interest, not a paycheck.
-Mike
9:14 p.m.
New subject: fedora mission (was Re: systemd and changes)
Mike McGrath wrote:
All you can do is trust RH to do the right thing, know we'll
make
mistakes from time to time
And bear in mind how long Red Hat has been doing this and how often
they've chosen to stay on the side of free software versus trying to
close things off for short-term financial gain...
and know that those of us that were volunteers that have now been
lucky enough to be hired on to do it full time (myself included) are
looking out for Fedora's best interest, not a paycheck.
Every time I see you, Jesse, Dennis, Bill or the numerous other
@redhat.com infrastructire folks working on things over the weekend
(or well past any normal 9-5 hours), I'm reminded that this isn't
"just a job" to you guys. And I'm quite thankful for all the time you
guys put in, over and above what Red Hat pays you to put in. Thank
you!
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Between two evils, I always pick the one I never tried before.
-- Mae West
12:10 a.m.
New subject: fedora mission (was Re: systemd and changes)
On 08/28/2010 09:40 PM, Mike McGrath wrote:
Dennis is his backup (RH employee) and if need be I know jwb (not
redhat
employee) is more than capable of handling these problems. Believe it or
not, we do consider these things and cross train. If you have the
several hours per week available to contribute for a few years you too
could be a backup
Interesting respond...
How many years do you believe I have contributed and how many hours do
you think I have spent in that contribution?
JBG
12:29 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Sun, 29 Aug 2010, "Jóhann B. Guðmundsson" wrote:
On 08/28/2010 09:40 PM, Mike McGrath wrote:
> Dennis is his backup (RH employee) and if need be I know jwb (not redhat
> employee) is more than capable of handling these problems. Believe it or
> not, we do consider these things and cross train. If you have the
> several hours per week available to contribute for a few years you too
> could be a backup
Interesting respond...
How many years do you believe I have contributed and how many hours do
you think I have spent in that contribution?
Beats me, but not to releng, the team who's ability you were calling into
question. I do hope you read the rest of my email, the two paragraphs not
quoted were the interesting parts of that response.
-Mike
12:46 a.m.
New subject: fedora mission (was Re: systemd and changes)
On 08/28/2010 09:40 PM, Mike McGrath wrote:
I know it's not a comfortable thing to deal with, I know I'm
not super
happy about it but Fedora exists almost entirely because RH wills it to.
If RH decided Fedora should go away, it would. You could fork, have a
mess of a time getting infrastructure, and get that fork going but that
wouldn't be Fedora, it'd be something else.
Well my main concern is exactly what you have stated "If RH decide
Fedora should go away it would" in other words "You exist only because
we allow you to exist"
The former is a pretty strong statement the latter is my own
interpretation of what you just stated.
We tried to turn Fedora into an independent legal entity with
multiple
stakeholders and there was almost 0 support in terms of funding for it
(Google: Fedora Foundation). Bottom line, when Red Hat tried to give
Fedora to the community, the community wasn't there to take it. All you
can do is trust RH to do the right thing, know we'll make mistakes from
time to time and know that those of us that were volunteers that have now
been lucky enough to be hired on to do it full time (myself included) are
looking out for Fedora's best interest, not a paycheck.
Times change and people
with it and I'm willing to put money were my
mouth is. So let's separate the infrastructure to a neutral ground,
let's find a good place to host the community on. I don't have much to
spare but I'm willing to give it all I got it's not like I have not I've
invested far to much of my time and other things in the project so far..
JBG
1:55 a.m.
New subject: fedora mission (was Re: systemd and changes)
On 08/29/2010 11:16 AM, "Jóhann B. Guðmundsson" wrote:
Well my main concern is exactly what you have stated "If RH
decide
Fedora should go away it would" in other words "You exist only because
we allow you to exist"
The former is a pretty strong statement the latter is my own
interpretation of what you just stated.
The trademark has to be owned by some entity and not individuals. If
you don't want Red Hat to own it, you should be pushing for a non-profit
foundation. Note however all of the code including what powers the
infrastructure is free and open source software.
Rahul
3:35 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Sun, Aug 29, 2010 at 05:46:31 +0000,
"\"Jóhann B. Guðmundsson\"" <johannbg(a)gmail.com> wrote:
Times change and people with it and I'm willing to put money were
my
mouth is. So let's separate the infrastructure to a neutral ground,
let's find a good place to host the community on. I don't have much to
spare but I'm willing to give it all I got it's not like I have not I've
invested far to much of my time and other things in the project so far..
There is no reason to expect they have changed that much since the last
time this was looked at. You still wouldn't be able to have a nonprofit
organization (for tax purposes) to handle infrastructure and accept the
current level of contributions from Red Hat. People are less likely to
donate if their donations aren't tax deductible.
Going down that road now seems very dangerous and likely to kill the
project.
4:38 a.m.
New subject: fedora mission (was Re: systemd and changes)
Over the last few days there seems to be a bit of existential angst
about Fedora. So here are my random thoughts.
About Fedora disappearing if Red Hat is bought by some evil
corporation, for example Microsoft. :-) I am not worried. As it has
been pointed out, all the Fedora packages as well as infrastructure
are open source so they would not be lost. Undoubtedly people that
have contributed to Fedora over the years, and have thereby developed
affection for the distro as well as online relationships with other
people in Fedora, would feel a sense of loss. That is normal. But that
would not be the end of the world as we know it. Either a new distro
would arise out of the ashes, or people could start contributing to an
existing distro, and there are hundreds of them out there.
About Fedora losing users, or not growing. I don't think we can go by
anecdotal evidence. We need reliable statistics, but I don't think
they exist now, and I doubt they will exist in the next five years, if
ever. For example, I have Fedora, Windows, Ubuntu, Scientific Linux,
etc, on my multi-boot PC. So how would I show up in statistics? Other
people might run two OSes simultaneously with virtualization, so the
same statistical problem occurs. And there could be a server tucked
away in the corner of a server room running FTP. Does such a server
count as a user?
So IMO instead of having a numerical target for users (which as I
pointed out we cannot measure) Fedora should focus on its current
stakeholders: Red Hat obviously, because it is the main single
contributor and pays the bills, and the rest of the community, such as
the people that manage, package, test and participate in the mailing
lists and forums.
I have been using Linux for only a year, and Fedora since last
December, so my experience is quite limited. I think Fedora is fine
the way it is, there is however a couple of things that do not thrill
me. First the name of the distro: Fedora. It completely turns me off,
and that is one of the reasons why Fedora was not the first distro I
tried. Part of the reason is the sound of the world, which evokes an
unpleasant association in my mother language. Then the logo does not
appeal to me either.
If you look at Ubuntu, they came up with a logo that reflects the name
of the distro. For a while they had pictures of people in circles
holding hands and so on. This is good marketing. Fedora is a hat. As
far as I know Fedora is not allowed to use a hat in its logo to
prevent the Fedora brand to get mixed up with Red Hat's. Fair enough.
But this means that marketing becomes more complicated due to lack of
brand consistency.
The problem could be solved by changing the name of the distro, but
this would incur large costs, not only to Red Hat but also to its
contributors that for example pay for websites that have Fedora in the
name, so it is not practical. The solution was an abstract logo (the
stylized f) which is not as powerful. I am not a graphical designer,
still I would venture that it would be possible to come up with a
nicer looking abstract logo.
Then there are colours. Look at Ubuntu 10.04. I think they came up
with bold original colours that mix well together. This is not an easy
feat. On the other hand Fedora colours completely turn me off. This
does not bother me personally, because I can customize the Gnome
desktop and have a nice image for Grub background, so I only see
Fedora colours in Plymouth, and that is because I have not had the
time to see if I can customize those.
You might say that colours are not important, substance is what
matters. And that is true to some extent. However a nice appearance
helps to attract new users to a distro. I think Ubuntu is more in tune
with the zeitgeist and that may be why it appears to have more users.
Someone remarked that Fedora is not popular among university students.
This is a group that it would be good to try to attract. Now I am not
an university student, but my guess is many of them, at least in the
west, like Lady Gaga. She is not a great singer, she is popular mainly
for bold visuals. This to prove my point that looks sell. A
disclaimer: I am not keen on pop, I like classical music!
In a nutshell: IMO Fedora is fine, except that it should come up with
a better logo, typeface and colours, something with an edge!
3:15 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Sun, 29 Aug 2010 10:38:29 +0100
Piscium <groknok(a)gmail.com> wrote:
...snip...
In a nutshell: IMO Fedora is fine, except that it should come up
with
a better logo, typeface and colours, something with an edge!
Please do join in the design team and help them out:
http://fedoraproject.org/wiki/Join_the_Design_Team
IMHO, I like the logo, typeface and colors, but more constructive
feedback to them is welcome I am sure.
kevin
1:38 a.m.
New subject: fedora mission (was Re: systemd and changes)
On 29 August 2010 21:15, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Sun, 29 Aug 2010 10:38:29 +0100
Piscium <groknok(a)gmail.com> wrote:
Please do join in the design team and help them out:
http://fedoraproject.org/wiki/Join_the_Design_Team
While I appreciate the arts, I am not good at creating art, so I am
afraid I would be of no use to the design team.
1:42 a.m.
New subject: fedora mission (was Re: systemd and changes)
On 08/30/2010 12:08 PM, Piscium wrote:
While I appreciate the arts, I am not good at creating art, so I am
afraid I would be of no use to the design team.
Providing constructive and directed feedback would certainly count as a
useful contribution. Design team mailing list often has discussions
about proposals before picking a theme or whatever.
Rahul
10:59 a.m.
New subject: fedora mission (was Re: systemd and changes)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/28/2010 10:46 PM, "Jóhann B. Guðmundsson" wrote:
Well my main concern is exactly what you have stated "If RH
decide
Fedora should go away it would" in other words "You exist only because
we allow you to exist"
The former is a pretty strong statement the latter is my own
interpretation of what you just stated.
Fedora the name, and Fedora some of the current hardware resources, and
Fedora some of the current warm bodies would go away, but not the code,
many of the other people, the documentation, the mirrors, etc... I
don't see any amount of trying to shadow corporate employees with
"community" (what does that even mean?) making any amount of difference
on this point.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkx71WkACgkQ4v2HLvE71NXBegCeMQ+E08vvuEvZa1/qeqKqQYvC
Gt4AoJYC2FUJ3+oKNha71eqgOgDbebMF
=2XL0
-----END PGP SIGNATURE-----
8:52 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Sat, 2010-08-28 at 16:40 -0500, Mike McGrath wrote:
> So let me ask you this who's your backup ( given that you at
least have
> one within Red Hat ) and can a community member step in you're shoes to
> full fill your role in your absence?
>
Dennis is his backup (RH employee) and if need be I know jwb (not redhat
employee) is more than capable of handling these problems. Believe it or
Worth noting Jesse was actually off work for most of the Alpha release
period: almost all the Alpha test and RC composes were done by Dennis.
Obviously it worked well if you don't know this until we tell you ;)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
5:08 p.m.
New subject: fedora mission (was Re: systemd and changes)
"Jóhann B. Guðmundsson" <johannbg(a)gmail.com> wrote:
On 08/28/2010 08:28 PM, Jesse Keating wrote:
> What are you afraid of?
I think my concerns have been very clear.
> Fedora is not a country, you don't have to move to get away. All the code is
free. Most the code isn't even ours, it belongs to the upstreams. If somebody were to
buy RHT, the worse they could do is prevent previous RHT employees from working on it as
their day job, turn off the servers and sit on the trademarks. All the code and people can
go to a new project name. It would just take a few servers and an uplink to the mirror
system, which is not owned by RHT or Fedora. There really isn't any intellectual
property around Fedora that isn't open and transparent. Man power may die off, but
some arbitrary rule about how many people who might be employed by RHT can serve in
decision bodies wouldn't change that at all.
>
> So I ask you again, what are you so afraid of that you think you can fix?
I'm afraid of what might happen if an individual like you, an key player
within the community suddenly disappears from the face of the planet.
So let me ask you this who's your backup ( given that you at least have
one within Red Hat ) and can a community member step in you're shoes to
full fill your role in your absence?
Multiple people filled in for me recently when I took leave for the birth of my second
son. One project I and others have been working on is documenting the things we do so that
others can fill in easily. Not good for job security but good for project longevity.
However. At this time I don't sit on any decision making group, so I'm really not
sure what a rule that dictates that a "community" person balance my RHT
presence. The rel-eng group is free form, anybody who wants to show up and work can.
There are no numbered seats or president or anything like that. Just tasks and tickets and
people that process them. Should RHT go away and I go away the process documentation
remains and anybody can pick it up and run with it. Or they can duplicate it in a
differently named project should the Fedora name be no longer usable.
--
Sent from my Android phone. Please excuse my brevity.
4:37 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Sat, Aug 28, 2010 at 01:28:26PM -0700, Jesse Keating wrote:
What are you afraid of? Fedora is not a country, you don't have
to
move to get away. All the code is free. Most the code isn't even ours,
it belongs to the upstreams. If somebody were to buy RHT, the worse
they could do is prevent previous RHT employees from working on it as
their day job, turn off the servers and sit on the trademarks. All the
code and people can go to a new project name. It would just take a
few servers and an uplink to the mirror system, which is not owned by
RHT or Fedora. There really isn't any intellectual property around
Fedora that isn't open and transparent. Man power may die off, but
some arbitrary rule about how many people who might be employed by RHT
can serve in decision bodies wouldn't change that at all.
So I ask you again, what are you so afraid of that you think you can fix?
Afaik, the only thing that would be lost is the ability to relicense
unlicensed contributions, e.g. the power that the CLA gives to RedHat.
With the FPCA, the board could relicense everything. But RedHat appoints
the board chair, who has veto power. If this is right, then this could
be changed by making the chair seat another normal seat, that is voted
for by the community and make the board elect it's chair by itself.
Also the trademarks and other rights might be moved to an non-profit
association.
--
Sent from my Android phone. Please excuse my brevity.
And you managed to proper quote! \o/ Now the next step is not to create
very long lines. ;-)
Regards
Till
10:56 a.m.
New subject: fedora mission (was Re: systemd and changes)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/28/2010 02:37 PM, Till Maas wrote:
And you managed to proper quote! \o/ Now the next step is not to
create
very long lines. ;-)
Ugh, I had no idea it was generating that junk. *sigh*
I just filed http://code.google.com/p/k9mail/issues/detail?id=2240
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkx71K0ACgkQ4v2HLvE71NVLWACfWbB1EJwwmKJvRil3O3L30bgw
NXAAn344eFS3g/L1Bkgog4xGOiv/Tg85
=chRN
-----END PGP SIGNATURE-----
8:53 a.m.
New subject: fedora mission (was Re: systemd and changes)
On 08/28/2010 05:37 PM, Till Maas wrote:
With the FPCA, the board could relicense everything. But RedHat
appoints
the board chair, who has veto power. If this is right, then this could
be changed by making the chair seat another normal seat, that is voted
for by the community and make the board elect it's chair by itself.
Till, you know that's not true.
With the FPCA, any "unlicensed" contributions that Fedora receives are
relicensed to a Fedora approved license. The only Fedora approved
licenses are Free licenses. If a contributor doesn't want Fedora
determining which Free license to use on their contribution, they can
put their choice of Free license on it, and Fedora then only has the
option of either using it under that explicitly chosen license or not at
all.
So, no, the board could not relicense everything.
~spot
4:55 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Wed, Sep 01, 2010 at 09:53:15AM -0400, Tom spot Callaway wrote:
On 08/28/2010 05:37 PM, Till Maas wrote:
> With the FPCA, the board could relicense everything. But RedHat appoints
> the board chair, who has veto power. If this is right, then this could
> be changed by making the chair seat another normal seat, that is voted
> for by the community and make the board elect it's chair by itself.
Till, you know that's not true.
With the FPCA, any "unlicensed" contributions that Fedora receives are
relicensed to a Fedora approved license. The only Fedora approved
licenses are Free licenses. If a contributor doesn't want Fedora
determining which Free license to use on their contribution, they can
put their choice of Free license on it, and Fedora then only has the
option of either using it under that explicitly chosen license or not at
all.
So, no, the board could not relicense everything.
Sorry, I was too imprecise. I meant that the "unlicensed" contributions
can only be relicensed to another default license by the board. And if
Red Hat is lost to some evil company, as far as I understand, the Fedora
project might not have this power anymore, because of the power of Red
Hat on the board. This might not have any significance in the future,
e.g. it might not be needed to change the default license, but in case
it is, this might be a problem. But in the past the similiar condition
in the CLA was used to change the license of the contents in the wiki
from something else to a creative commons license. So at least this
power was needed in the past. Sorry again, I did not mean to imply that
the FPCA can be used to overwrite the license of contributions under a
specific license and I really like the new FPCA.
Regards
Till
5:11 p.m.
New subject: fedora mission (was Re: systemd and changes)
On 09/01/2010 05:55 PM, Till Maas wrote:
Sorry, I was too imprecise. I meant that the "unlicensed"
contributions
can only be relicensed to another default license by the board. And if
Red Hat is lost to some evil company, as far as I understand, the Fedora
project might not have this power anymore, because of the power of Red
Hat on the board. This might not have any significance in the future,
e.g. it might not be needed to change the default license, but in case
it is, this might be a problem. But in the past the similiar condition
in the CLA was used to change the license of the contents in the wiki
from something else to a creative commons license. So at least this
power was needed in the past. Sorry again, I did not mean to imply that
the FPCA can be used to overwrite the license of contributions under a
specific license and I really like the new FPCA.
Well, I think that if "Red Hat is lost to some evil company", there are
bigger problems than said evil company replacing the FPL with an evil
puppet, then forcing the board to approve a new (and evil) default
license for unlicensed contribution, then applying the new (and evil)
default license to all unlicensed contributions. ;)
However, to play this out, copies of those unlicensed files would not be
copyright of either Red Hat or the Evil Company, the authors of those
works would still retain copyright, and could simply make the files
available under a non-evil license, so even if the evil company tried to
work the system, those authors could simply circumvent them.
Note: This is one of the many reasons why copyright assignment CLAs are
a BAD BAD idea.
In a more complicated case, like the Fedora wiki, a copy under the old
(non-evil) terms could be forked off and continued, since the license
doesn't stop being applicable to that version.
~spot
2:42 p.m.
New subject: fedora mission (was Re: systemd and changes)
2010/8/28 "Jóhann B. Guðmundsson" <johannbg(a)gmail.com>:
On 08/27/2010 10:47 PM, Bob Arendt wrote:
Actually I think Fedora *should* articulate who the users are, basically
design and express who and what Fedora is designed for. If you poll
"users" - people who download Fedora - and cater to their stated desires
for the sake of market share, then market forces will start to drive the
shape of the distro. Populist market forces would tend to force everything
to a gray mushy mass of similar distros.
(see http://en.wikipedia.org/wiki/Hotelling%27s_law).
I think it would be much better for Fedora to decide what it *should* be,
specifically what the Fedora userspace should be, and excel at that.
Don't follow the "market" or worry about being the most popular distro
(unless that's really a goal ..?) Decide the niche, and be strong in
that niche.
Well first of all you are going to need to reset your view of what
Fedora is. For the most part Fedora is a community built around the
Fedora Operating System which is 90+% sponsored and paid for by Red
Hat Inc. All Fedora trademarks are owned by Red Hat Inc, and many
costly services are provided free to the community by Red Hat.
Those legal facts are not going to change in the short term, nor will
lots of emails or long rants help move it any faster. I also am not
going to advocate "shutting up and taking it" as someone thought I was
before. I advocate constructive engagement and if that doesn't work
finding some place where you are happier even if it means making
something new to do that.
--
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines
3:14 p.m.
New subject: fedora mission
Hi,
For the most part Fedora is a community built around the Fedora
Operating System which is 90+% sponsored and paid for by Red Hat
Inc.
How are you defining which things are sponsored and paid for? If it's
"whatever things Red Hat chooses to pay for", then the answer to how
much RH pays for is 100% by definition. If it's "all of the things
Red Hat requires from external contributors in order to make Fedora",
the answer to how much RH pays for is surely more like 10%, assuming
RH's level of contribution to the kernel and GNOME and so on holds
across different projects.
But I suppose this doesn't get at my real annoyance with your mail,
which is that you answered "how are we going to decide who Fedora's
users are and what they need?" with something awfully close to "Red
Hat funds everything and so Fedora doesn't need to care about that",
with a side dose of "and go away if you don't like it".
- Chris.
--
Chris Ball <cjb(a)laptop.org>
One Laptop Per Child
3:39 p.m.
New subject: fedora mission
On Sat, Aug 28, 2010 at 16:14:42 -0400,
Chris Ball <cjb(a)laptop.org> wrote:
How are you defining which things are sponsored and paid for? If it's
"whatever things Red Hat chooses to pay for", then the answer to how
much RH pays for is 100% by definition. If it's "all of the things
Red Hat requires from external contributors in order to make Fedora",
the answer to how much RH pays for is surely more like 10%, assuming
RH's level of contribution to the kernel and GNOME and so on holds
across different projects.
Probably he is referring to infrastructure. Servers and network capacity.
There is also funding to support events like FADs and FUDCONs.
If you count people time, then its probably not that high.
8:22 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Sat, 28 Aug 2010 17:16:12 +0000, you wrote:
We have a clear cut example what can happen ( The Oracle and
OpenSolaris
case ) so first and foremost we need to make sure that a single
corporate entity does not have control over the project which means that
no corporate entity may have majority of it's employ in boards, steering
committees, SIG etc. to prevent that corporate entity seizing control
over the projects, steering it's directions to it's will and for us as a
community not being too depended on that corporate entity should that
corporate be bought or otherwise be controlled by individuals that do
not share the same vision as the community.
It's not far from reality that Red Hat will get bought by a company like
Oracle so what's preventing us to get the same treatment as OpenSolaris
got?
1) Given the significant amount of work that Red Hat does in the Linux
ecosystem - kernel, gcc, glibc, xorg, gnome, etc - every Linux
distribution out there whether it be Fedora or Debian or any other is
dependent on Red Hat. There is no simple way of getting around this
reality unless someone has a lot of money to spend hiring developers.
2) The Solaris/OpenSolaris case under Oracle demonstrates the
importance of licence choice and the difficulty of taking a large,
proprietary project open source. This does not apply to Linux. Unlike
the Solaris CDDL the GPL, combined with the variety of contributors,
means it is pretty much impossible to take Linux closed source without
violating the licence. In the case of OpenSolaris they never grew a
community of contributors, the licence allows them to do binary only
distribution, and they never fully opened up Solaris hencing making a
true fork of OpenSolaris difficult because the source is missing from
some key parts.
The first and foremost mission that the project should be doing at
this
point is to make dam sure we are ready for it encase Red Hat will not be
there tomorrow or it's there but not in the same form that we all love.
While some planning will help, if Red Hat goes then Fedora will be the
least of the problems the community faces. As such it is not worth
worrying about.
The first mistake we did was trying to label end user since it's
not up
to the project in whole to decide which end user type it's target.
It's should be up to individual community SIG's to decide what user base
they are targeting and the form they will present that to the end user
in live cd or a predefined installation option be it with the latest and
greatest bits of their product or a not which may or may not be
influenced from feed backs from the micro community they have
established around the product they ship.
Sorry, but won't work. As much as your or I may wish otherwise people
in general won't differentiate between Fedora Gnome/Fedora KDE/Fedora
cutting edge/Fedora stable/ etc. It will all get shortened to Fedora,
and thus impact on the project's reputation as a whole. While the
SIGs are useful to customize Fedora around a particular purpose, all
the SIGs must pull in the same general direction.
The Fedora project in whole should give equal access to those bits and
devote equal amount of marketing resources to promote them.
Fedora, like most (all?) other opensource projects suffers from a lack
of manpower and resources. As long as this is the case there will be
projects that suffer.
9:50 p.m.
New subject: fedora mission (was Re: systemd and changes)
As an aside it is important to remember that solaris was moribund -
almost kaput- because most of the world had turned to linux in its stead
and its customer base shrinking - some die hards or those that didn't
want or weren't able to switch to linux for whatever reason.
Linux today is live and vibrant ... that may change of course ... but
comparing fedora (or any linux) with solaris is not apt.
gene/
7 a.m.
New subject: fedora mission (was Re: systemd and changes)
Hi.
On Sat, 28 Aug 2010 22:50:46 -0400, Genes MailLists wrote
As an aside it is important to remember that solaris was moribund -
almost kaput- because most of the world had turned to linux in its
stead and its customer base shrinking - some die hards or those that
didn't want or weren't able to switch to linux for whatever reason.
Because, like it or not, Solaris still does some things that have no
counterpart in the linux world (feature set wise or functionality wise).
9:32 a.m.
New subject: fedora mission (was Re: systemd and changes)
On 08/29/2010 08:00 AM, Ralf Ertzinger wrote:
Hi.
On Sat, 28 Aug 2010 22:50:46 -0400, Genes MailLists wrote
> As an aside it is important to remember that solaris was moribund -
> almost kaput- because most of the world had turned to linux in its
> stead and its customer base shrinking - some die hards or those that
> didn't want or weren't able to switch to linux for whatever reason.
Because, like it or not, Solaris still does some things that have no
counterpart in the linux world (feature set wise or functionality wise).
ZFS is a good example - btrfs is not there yet. Is there anything else ?
11:20 p.m.
New subject: fedora mission (was Re: systemd and changes)
"Jóhann B. Guðmundsson" wrote:
The first mistake we did was trying to label end user since it's
not up
to the project in whole to decide which end user type it's target.
It's should be up to individual community SIG's to decide what user base
they are targeting and the form they will present that to the end user
in live cd or a predefined installation option be it with the latest and
greatest bits of their product or a not which may or may not be
influenced from feed backs from the micro community they have
established around the product they ship.
+1. I couldn't agree more. We really need to give more decision power to
SIGs and accept that different Fedora spins will have different target user
bases. There's no one size that fits it all.
The Fedora project in whole should give equal access to those bits
and
devote equal amount of marketing resources to promote them.
Simply allow the casual user that walks in the Fedora garden to pick
what ever fruit he chooses that grew from the labour of the community to
taste and enjoy.
Unfortunately that is not how things are being done in the Fedora garden
today instead we force one vision ( Desktop ) and with one DE ( Gnome )
which greatly overshadows all the good work that's being done in other
corners in the lcommunity like in server applications and KDE XFCE and
LXDE and willingly or unwilling hinder the growth in the micro community
around those Desktop Environment, hiding them like some rotten apples
from infested tree in a shed in the back yard.
Strong +1 there too. I've been complaining about this kind of second-class
treatment for everything not GNOME for a while.
It's going to be interesting to see if we ever reach the point
when a
end users would like to search for a certain application for a certain
task he needs to perform and the only application he's offered will be
the Gnome ones.
Yuck! That's indeed a very scary perspective! Yet I could see it happening.
:-(
Kevin Kofler
2:43 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Sun, 29 Aug 2010 06:20:01 +0200, you wrote:
"Jóhann B. Guðmundsson" wrote:
> The first mistake we did was trying to label end user since it's not up
> to the project in whole to decide which end user type it's target.
>
> It's should be up to individual community SIG's to decide what user base
> they are targeting and the form they will present that to the end user
> in live cd or a predefined installation option be it with the latest and
> greatest bits of their product or a not which may or may not be
> influenced from feed backs from the micro community they have
> established around the product they ship.
+1. I couldn't agree more. We really need to give more decision power to
SIGs and accept that different Fedora spins will have different target user
bases. There's no one size that fits it all.
There still needs to be a consistent set of policies that all of
Fedora follows, otherwise the actions of one SIG can hurt the other
SIGs. This is the "cost" of using the Fedora name, where the name has
a value in the mind of the public and that value must be consistent
across all products that carry that name.
If a SIG finds those rules/decisions too restrictive then the benefit
of open source is that they can take the project elsewhere, give it a
new name, and run things the way they want.
> The Fedora project in whole should give equal access to those
bits and
> devote equal amount of marketing resources to promote them.
>
> Simply allow the casual user that walks in the Fedora garden to pick
> what ever fruit he chooses that grew from the labour of the community to
> taste and enjoy.
>
> Unfortunately that is not how things are being done in the Fedora garden
> today instead we force one vision ( Desktop ) and with one DE ( Gnome )
> which greatly overshadows all the good work that's being done in other
> corners in the lcommunity like in server applications and KDE XFCE and
> LXDE and willingly or unwilling hinder the growth in the micro community
> around those Desktop Environment, hiding them like some rotten apples
> from infested tree in a shed in the back yard.
Strong +1 there too. I've been complaining about this kind of second-class
treatment for everything not GNOME for a while.
Many of us claim to want a wide selection of choices when we go
looking for something to buy, but retailers have done studies that
show that choice ends up confusing the customer and they walk away
choosing nothing. This is why retailers tend to limit the choices to
2 or 3 options. They sell more this way.
If Fedora created a home page that offered up every available option
the new people would simply go to another distribution whose website
isn't as confusing, or stick with Windows.
Does this mean some projects don't get the exposure they deserve? Yes,
but unfortunately there is no way around it without hurting Fedora as
a whole.
3:29 a.m.
New subject: fedora mission (was Re: systemd and changes)
Le vendredi 27 août 2010 à 15:47 -0700, Bob Arendt a écrit :
Actually I think Fedora *should* articulate who the users are,
basically
design and express who and what Fedora is designed for. If you poll
"users" - people who download Fedora - and cater to their stated desires
for the sake of market share, then market forces will start to drive the
shape of the distro. Populist market forces would tend to force everything
to a gray mushy mass of similar distros.
(see http://en.wikipedia.org/wiki/Hotelling%27s_law).
I think it would be much better for Fedora to decide what it *should* be,
specifically what the Fedora userspace should be, and excel at that.
As has been shown many times in the past, when you have engineers that
decide "who" their ideal target users are, and ignore the
"unrepresentative" users that provide actual feedback now, you get a
system where they decide their ideal users agree 100% with their design,
and do not care about all the boring/annoying/difficult bugs actual
users are complaining about but the engineer really does not want to fix
(and a majority of his fantasy users agrees with him, surprise!).
This is just human nature.
In closed software companies you have the same effect except marketing
people are calling the shots and deciding what the fantasy users want.
And they also use a reality distortion field, though not the same one
the engineers would like to.
This is how a perfectly fine system like Solaris degenerated in a pile
of obsolete cruft: the people deciding what fantasy users wanted spent
years ignoring field request to update ksh/vi/etc till the amount of
cruft exceeded what could be cleaned up in a reasonable amount of time.
So don't ignore our users, they may not be ideal users, but they're the
only form of reality check we have now. And without a reality check, and
looking where you walk, it's very easy to jump out of cliff while
dreaming of castles in the sky.
User requests should not be used to decide what the long term goals are,
but that does not mean it is sane to pursue the long term goals without
making sure current users are satisfied. And some of those users have
good long-term suggestions too.
--
Nicolas Mailhot
5:23 p.m.
New subject: fedora mission (was Re: systemd and changes)
"Jon Masters" <jonathan(a)jonmasters.org> wrote:
On Fri, 2010-08-27 at 17:54 -0400, Matthias Clasen wrote:
> On Fri, 2010-08-27 at 16:37 -0400, Jon Masters wrote:
>
> >
> > Ah yes, attack the symptom and not the disease. Yay. Let me let you in
> > on a secret. Most people (and by which I mean, those not on this list)
> > generally don't like re-installing or upgrading their computer every 6
> > months. People install older releases because it's what they have (in
> > which case, there's a valid reason to push for the latest) BUT also
> > because they don't want to be using an extension of rawhide. They want
> > to wait a little time for things to settle down, for there to be fewer
> > updates to waste their time on, etc. It's the rate of churn, lack of
> > durability in the length of the cycle, etc. that are the problems.
> >
> > But sure, we can blame the users, and scratch our heads when the figures
> > indicate what might be happening, why people are jumping ship, etc. and
> > not have a user survey to tell us what the users want (a fantastic
> > idea). These would all help maintain the status quo just fine.
>
> Your attack is misguided, Jon. It is very much our responsibility to
> inform users that the software they install or use is no longer actively
> supported.
I'm not saying that. I'm saying that the real problem here might be
people are running older releases because they are looking for a more
stable environment or just don't want to upgrade every 6 months. This
isn't a RHEL/other-derivative vs. Fedora thing. Because "Enterprise"
distributions give you many years and lots more guarantees. Way beyond
what I personally feel is needed here. But again, since we have never
taken the initiative to ask people why they leave Fedora or why they
stick with old releases, we won't know the answer to this.
Again, I feel it is necessary to have a survey of Fedora users.
Preferably annually. And listen to the feedback. If they say "yep, we
just love the churn, the number of updates" and so forth, then fine. If
they say "actually we'd like less than 800 updates after installing",
then also fine. I'm sorry to beat a dead horse, I just feel it is very
important that we finally, clearly articulate who our users are and what
they want by treating more like customers and gathering their input.
The cynic in me would expect that the people who want something different than the fire
hose we have now are silently leaving, and those that are left are going to say they like
the deluge of updates.
Or I could just quote Henry Ford, or any other people who talk about design by committee.
--
Sent from my Android phone. Please excuse my brevity.
5:39 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Fri, 2010-08-27 at 15:23 -0700, Jesse Keating wrote:
>Again, I feel it is necessary to have a survey of Fedora users.
>Preferably annually. And listen to the feedback. If they say "yep, we
>just love the churn, the number of updates" and so forth, then fine. If
>they say "actually we'd like less than 800 updates after installing",
>then also fine. I'm sorry to beat a dead horse, I just feel it is very
>important that we finally, clearly articulate who our users are and what
>they want by treating more like customers and gathering their input.
So I'm filing another FESCo ticket as I type this. They can decide to
reject my proposal again, in which case I will bring it up with the
Fedora Board by way of appeal. I will take "no" for an answer once it's
been escalated all the way, because then at least I will have tried.
The cynic in me would expect that the people who want something
different than the fire hose we have now are silently leaving,
and those that are left are going to say they like the deluge of
updates.
On some level, if they say that, I suppose I get to eat my hat and deal
with the deluge. At least we'll know. Maybe we'll be surprised :)
Or I could just quote Henry Ford, or any other people who talk
about design by committee.
But I feel it is "design by committee" now, just the Open Source
version. A small group of people (f-d-l and similar) arbitrarily decide
what the userbase "wants" without asking them, and based on what they
would like to see in the distribution themselves. There are elections,
but only those with a very strong involvement are motivated to stand.
And it's hard to vote if you're not very informed on the issues, whereas
almost everyone and his/her dog has an opinion in a poll. Yes, that can
be bad too (people manipulating the survey, etc), but there are ways to
write polls and conduct them in a more scientific way that is /less/
(but not perfect) vulnerable to that. And it's better than /no/ data.
Look upon this as a democratic action, an opinion poll, a survey. The
kinds of things governments, corporations, non-profits, and other groups
do to find out how they're doing and what could improve. If over 50% say
they like the rate of updates and are willing to accept breakage, then
fine, we can quote that number and I will have to eat my words. It
doesn't mean the end to the discussion, but it provides data. If the
results are very skewed in favor of churn, I will then also owe Kevin a
beer or two for being in the minority opinion, and maybe eat a hat.
Jon.
5:52 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Fri, 2010-08-27 at 18:39 -0400, Jon Masters wrote:
On Fri, 2010-08-27 at 15:23 -0700, Jesse Keating wrote:
> >Again, I feel it is necessary to have a survey of Fedora users.
> >Preferably annually. And listen to the feedback. If they say "yep, we
> >just love the churn, the number of updates" and so forth, then fine. If
> >they say "actually we'd like less than 800 updates after
installing",
> >then also fine. I'm sorry to beat a dead horse, I just feel it is very
> >important that we finally, clearly articulate who our users are and what
> >they want by treating more like customers and gathering their input.
So I'm filing another FESCo ticket as I type this. They can decide to
reject my proposal again, in which case I will bring it up with the
Fedora Board by way of appeal. I will take "no" for an answer once it's
been escalated all the way, because then at least I will have tried.
https://fedorahosted.org/fesco/ticket/453
Jon.
6 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Fri, 27 Aug 2010 18:52:30 -0400
Jon Masters <jonathan(a)jonmasters.org> wrote:
On Fri, 2010-08-27 at 18:39 -0400, Jon Masters wrote:
> On Fri, 2010-08-27 at 15:23 -0700, Jesse Keating wrote:
>
> > >Again, I feel it is necessary to have a survey of Fedora users.
> > >Preferably annually. And listen to the feedback. If they say
> > >"yep, we just love the churn, the number of updates" and so
> > >forth, then fine. If they say "actually we'd like less than 800
> > >updates after installing", then also fine. I'm sorry to beat a
> > >dead horse, I just feel it is very important that we finally,
> > >clearly articulate who our users are and what they want by
> > >treating more like customers and gathering their input.
>
> So I'm filing another FESCo ticket as I type this. They can decide
> to reject my proposal again, in which case I will bring it up with
> the Fedora Board by way of appeal. I will take "no" for an answer
> once it's been escalated all the way, because then at least I will
> have tried.
https://fedorahosted.org/fesco/ticket/453
Perhaps you could provide feedback on your last ticket before filing
another one?
https://fedorahosted.org/fesco/ticket/350
There were some negative votes there, but it was not closed.
I asked you to talk to our marketing SIG and see what they knew about
survey's and what info they already were gathering.
kevin
6:03 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Fri, 2010-08-27 at 17:00 -0600, Kevin Fenzi wrote:
On Fri, 27 Aug 2010 18:52:30 -0400
Jon Masters <jonathan(a)jonmasters.org> wrote:
> > So I'm filing another FESCo ticket as I type this. They
can decide
> > to reject my proposal again, in which case I will bring it up with
> > the Fedora Board by way of appeal. I will take "no" for an answer
> > once it's been escalated all the way, because then at least I will
> > have tried.
>
> https://fedorahosted.org/fesco/ticket/453
Perhaps you could provide feedback on your last ticket before filing
another one?
https://fedorahosted.org/fesco/ticket/350
There were some negative votes there, but it was not closed.
I asked you to talk to our marketing SIG and see what they knew about
survey's and what info they already were gathering.
Sure. I read the comments on the last one along the lines of "we're not
going to do this", and also in context of what I saw on IRC. But ok. I
will talk to the marketing folks. Meanwhile, can you actually discuss
the point of my ticket, which is whether you're even amenable to having
such a survey in the first place? If you want to merge both tickets into
one single ticket, fine. But let's get an answer on the idea.
Jon.
6 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Fri, 27 Aug 2010, Jon Masters wrote:
On Fri, 2010-08-27 at 15:23 -0700, Jesse Keating wrote:
> >Again, I feel it is necessary to have a survey of Fedora users.
> >Preferably annually. And listen to the feedback. If they say "yep, we
> >just love the churn, the number of updates" and so forth, then fine. If
> >they say "actually we'd like less than 800 updates after
installing",
> >then also fine. I'm sorry to beat a dead horse, I just feel it is very
> >important that we finally, clearly articulate who our users are and what
> >they want by treating more like customers and gathering their input.
So I'm filing another FESCo ticket as I type this. They can decide to
reject my proposal again, in which case I will bring it up with the
Fedora Board by way of appeal. I will take "no" for an answer once it's
been escalated all the way, because then at least I will have tried.
> The cynic in me would expect that the people who want something
> different than the fire hose we have now are silently leaving,
> and those that are left are going to say they like the deluge of
> updates.
On some level, if they say that, I suppose I get to eat my hat and deal
with the deluge. At least we'll know. Maybe we'll be surprised :)
> Or I could just quote Henry Ford, or any other people who talk
> about design by committee.
But I feel it is "design by committee" now, just the Open Source
version. A small group of people (f-d-l and similar) arbitrarily decide
what the userbase "wants" without asking them, and based on what they
would like to see in the distribution themselves.
I said something similar at the board meeting today. I think "designed"
isn't the right word. I don't think we have any designs we're following
at all. It's just engineered. Fedora literally just comes to being
without any thought or design of a coherent whole. All focus is on the
pieces. We're just seeing trees, not the forest.
-Mike
5:59 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Fri, 2010-08-27 at 18:00 -0500, Mike McGrath wrote:
On Fri, 27 Aug 2010, Jon Masters wrote:
> But I feel it is "design by committee" now, just the
Open Source
> version. A small group of people (f-d-l and similar) arbitrarily decide
> what the userbase "wants" without asking them, and based on what they
> would like to see in the distribution themselves.
I said something similar at the board meeting today. I think "designed"
isn't the right word. I don't think we have any designs we're following
at all. It's just engineered. Fedora literally just comes to being
without any thought or design of a coherent whole. All focus is on the
pieces. We're just seeing trees, not the forest.
Exactly. It's like Bugzilla - all individual components and no cohesion.
We need to have more of a notion of cross-component interaction. When
proposals are introduced that are cool - like systemd is - then they can
be reviewed and integrated in the context of the overall distribution,
rather than an itch someone had to scratch. And if that means things
sometimes take longer to get in (but are better integrated), so be it.
I'd personally like to see some teams created that deal with
cross-functional parts of the distribution and are more use-case focused
than focused on specific silos. There is no "Desktop", because there is
integration between that and the bowels of the system. There is no
"kernel" because it integrates with udev, systemd, and other pieces.
Jon.
11:25 p.m.
New subject: fedora mission (was Re: systemd and changes)
Jesse Keating wrote:
The cynic in me would expect that the people who want something
different
than the fire hose we have now are silently leaving, and those that are
left are going to say they like the deluge of updates.
You say that as if it were a negative thing. It's actually very positive, it
means we have found our niche and set some very specific expectations in our
user base! We should stick to that and not suddenly turn around half-turn.
Or I could just quote Henry Ford, or any other people who talk about
design by committee.
As others have pointed out, "design by committee" is actually what the
Board, and you as the author of the "vision" the Board voted for, are doing.
Kevin Kofler
2:43 a.m.
New subject: fedora mission (was Re: systemd and changes)
2010/8/29 Kevin Kofler <kevin.kofler(a)chello.at>:
Jesse Keating wrote:
> The cynic in me would expect that the people who want something different
> than the fire hose we have now are silently leaving, and those that are
> left are going to say they like the deluge of updates.
You say that as if it were a negative thing. It's actually very positive, it
means we have found our niche and set some very specific expectations in our
user base! We should stick to that and not suddenly turn around half-turn.
Absolutely. For example, often criticized "having many updates" is
IMHO a good thing, since it's really nice to see new git or new gnash
without upgrading to pre-release version.
Regards,
--
Vedran Miletić
2:53 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Sun, 29 Aug 2010 09:43:16 +0200, you wrote:
2010/8/29 Kevin Kofler <kevin.kofler(a)chello.at>:
> Jesse Keating wrote:
>> The cynic in me would expect that the people who want something different
>> than the fire hose we have now are silently leaving, and those that are
>> left are going to say they like the deluge of updates.
>
> You say that as if it were a negative thing. It's actually very positive, it
> means we have found our niche and set some very specific expectations in our
> user base! We should stick to that and not suddenly turn around half-turn.
>
Absolutely. For example, often criticized "having many updates" is
IMHO a good thing, since it's really nice to see new git or new gnash
without upgrading to pre-release version.
And how would you feel it the upgrade to git, or some other software,
caused you to lose days of time at work/home because something changed
that breaks your workflow?
If packagers are allowed to update packages when they want, what is
the difference between a released version and rawhide?
Users need the ability to assume that when they install a released
version of Fedora to use on their server/workstation/laptop that they
will be able to do their work, whether personal or at an office,
without the fear that applying an update will break their system.
If you reall need a newer version of git, gnash, or any other software
and your really can't wait the less than 6 months to the next release
then you have the option of risking breakage by installing it yourself
(either through compiling or trying a rawhide package). But don't
assume that everyone else wishes to take those same risks.
11:03 a.m.
New subject: fedora mission (was Re: systemd and changes)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/28/2010 09:25 PM, Kevin Kofler wrote:
Jesse Keating wrote:
> The cynic in me would expect that the people who want something different
> than the fire hose we have now are silently leaving, and those that are
> left are going to say they like the deluge of updates.
You say that as if it were a negative thing.
To me it is. It's you and people like you that want to shove a ton of
updates down the throats of our stable release users (including changes
that alter behavior and sonames etc...) that have ruined the Fedora I
helped to build. I want my Fedora back, I don't want what you're creating.
It's actually very positive, it
means we have found our niche and set some very specific expectations
in our
user base! We should stick to that and not suddenly turn around half-turn.
We've found our niche, but chasing away our previous niche (and having
less users show up in our tracking mechanism for it) It's getting to
the point where me, as a long time Fedora developer and sometimes
leader, is not enjoying using Fedora any more. Every update run can
break things, and often does. Every update takes for ever because there
are so many updates. Too many to review each one and see what it does,
and how to maybe test it and provide feedback. Updates runs just get
pushed off longer and longer so that I have a block of time to A) apply
the damn things, and B) spend a few hours recovering from any sort of
fallout in my workflow. If I don't enjoy using the product I'm
creating, that doesn't bode well.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkx71lsACgkQ4v2HLvE71NUnGQCfT5YAjnmAwonEmY55mM5sl73Q
rl0AoLTO/Ze9fzkLBGnohyltNtjUupmz
=Aec5
-----END PGP SIGNATURE-----
11:07 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, Aug 30, 2010 at 12:03 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/28/2010 09:25 PM, Kevin Kofler wrote:
> Jesse Keating wrote:
>> The cynic in me would expect that the people who want something different
>> than the fire hose we have now are silently leaving, and those that are
>> left are going to say they like the deluge of updates.
>
> You say that as if it were a negative thing.
To me it is. It's you and people like you that want to shove a ton of
updates down the throats of our stable release users (including changes
that alter behavior and sonames etc...) that have ruined the Fedora I
helped to build. I want my Fedora back, I don't want what you're creating.
I have been using Fedora forever, and I have the exact opposite
sentiment. I find that updates and too slow in coming. I feel that
there are other distros for stable, slow releases.
--
Fedora 13
(www.pembo13.com)
12:45 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, Aug 30, 2010 at 6:03 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/28/2010 09:25 PM, Kevin Kofler wrote:
> Jesse Keating wrote:
>> The cynic in me would expect that the people who want something different
>> than the fire hose we have now are silently leaving, and those that are
>> left are going to say they like the deluge of updates.
>
> You say that as if it were a negative thing.
To me it is. It's you and people like you that want to shove a ton of
updates down the throats of our stable release users (including changes
that alter behavior and sonames etc...) that have ruined the Fedora I
helped to build. I want my Fedora back, I don't want what you're creating.
Interesting here is that one can say "Leave the project if you don't
like what we do" (already done in the direction of Kevin Kofler) but
the offer doesn't count for everybody.
Not saying you should leave, for sure not. I think you're valuable for
the project. The same counts by the way as well for Kevin and everyone
else not sharing your opinion.
> It's actually very positive, it
> means we have found our niche and set some very specific expectations in our
> user base! We should stick to that and not suddenly turn around half-turn.
We've found our niche, but chasing away our previous niche (and having
less users show up in our tracking mechanism for it)
What previous niche?
It's getting to
the point where me, as a long time Fedora developer and sometimes
leader, is not enjoying using Fedora any more. Every update run can
break things, and often does.
Why not give QA the time to settle and find out how the new things work out?
Every update takes for ever because there
are so many updates. Too many to review each one and see what it does,
and how to maybe test it and provide feedback. Updates runs just get
pushed off longer and longer so that I have a block of time to A) apply
the damn things, and B) spend a few hours recovering from any sort of
fallout in my workflow.
What DE is in use on your box?
If I don't enjoy using the product I'm
creating, that doesn't bode well.
Well, it's not just you, creating it. BTW, the same feeling counts for
everyone else.
--
LG Thomas
Dubium sapientiae initium
12:48 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, Aug 30, 2010 at 1:45 PM, Thomas Janssen
<thomasj(a)fedoraproject.org> wrote:
On Mon, Aug 30, 2010 at 6:03 PM, Jesse Keating
<jkeating(a)redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 08/28/2010 09:25 PM, Kevin Kofler wrote:
>> Jesse Keating wrote:
>>> The cynic in me would expect that the people who want something different
>>> than the fire hose we have now are silently leaving, and those that are
>>> left are going to say they like the deluge of updates.
>>
>> You say that as if it were a negative thing.
>
> To me it is. It's you and people like you that want to shove a ton of
> updates down the throats of our stable release users (including changes
> that alter behavior and sonames etc...) that have ruined the Fedora I
> helped to build. I want my Fedora back, I don't want what you're creating.
Interesting here is that one can say "Leave the project if you don't
like what we do" (already done in the direction of Kevin Kofler) but
the offer doesn't count for everybody.
Not saying you should leave, for sure not. I think you're valuable for
the project. The same counts by the way as well for Kevin and everyone
else not sharing your opinion.
>> It's actually very positive, it
>> means we have found our niche and set some very specific expectations in our
>> user base! We should stick to that and not suddenly turn around half-turn.
>
> We've found our niche, but chasing away our previous niche (and having
> less users show up in our tracking mechanism for it)
What previous niche?
Being a fast paced, bleeding edge distro -- what I always expected.
-
Fedora 13
(www.pembo13.com)
2:36 p.m.
New subject: fedora mission (was Re: systemd and changes)
"Thomas Janssen" <thomasj(a)fedoraproject.org> wrote:
On Mon, Aug 30, 2010 at 6:03 PM, Jesse Keating
<jkeating(a)redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 08/28/2010 09:25 PM, Kevin Kofler wrote:
>> Jesse Keating wrote:
>>> The cynic in me would expect that the people who want something different
>>> than the fire hose we have now are silently leaving, and those that are
>>> left are going to say they like the deluge of updates.
>>
>> You say that as if it were a negative thing.
>
> To me it is. It's you and people like you that want to shove a ton of
> updates down the throats of our stable release users (including changes
> that alter behavior and sonames etc...) that have ruined the Fedora I
> helped to build. I want my Fedora back, I don't want what you're creating.
Interesting here is that one can say "Leave the project if you don't
like what we do" (already done in the direction of Kevin Kofler) but
the offer doesn't count for everybody.
Not saying you should leave, for sure not. I think you're valuable for
the project. The same counts by the way as well for Kevin and everyone
else not sharing your opinion.
>> It's actually very positive, it
>> means we have found our niche and set some very specific expectations in our
>> user base! We should stick to that and not suddenly turn around half-turn.
>
> We've found our niche, but chasing away our previous niche (and having
> less users show up in our tracking mechanism for it)
What previous niche?
We had a distro that was pretty general purpose, worked for servers and desktops and even
laptops. We had a predictable schedule.
We had new technology thanks to rawhide. We had timely bugfixes that didn't sacrifice
stability,
as in things didn't change out from under you on a stable release. We had an ecosystem
of third parties
that would build up stacks of newer things should a user be adventurous. We had a fresh
release quite
often that could be relied upon for at least a year. We had a culture of not just
throwing crap over the wall at our users, which included ourselves. We had accountability
when things did go awry and a honest
effort to disrupt the users of our stable releases as little as possible. We also
we're a very free distro avoiding nonfree stuff, and we worked well with
upstreams. We we're easy to configure, easy to update, easy to install whether a
single system or 400 systems in a lab. We we're easy to administrate in the same
scenarios.
This was fairly unique and what drew a lot of people to the project.
> It's getting to
> the point where me, as a long time Fedora developer and sometimes
> leader, is not enjoying using Fedora any more. Every update run can
> break things, and often does.
Why not give QA the time to settle and find out how the new things work out?
Because the likes of Kevin throw fits whenever we try to insert any QA time or seem to try
and improve the quality of our updates in any way other than "throw more of them at
people."
> Every update takes for ever because there
> are so many updates. Too many to review each one and see what it does,
> and how to maybe test it and provide feedback. Updates runs just get
> pushed off longer and longer so that I have a block of time to A) apply
> the damn things, and B) spend a few hours recovering from any sort of
> fallout in my workflow.
What DE is in use on your box?
I use Gnome with some KDE apps.
> If I don't enjoy using the product I'm
> creating, that doesn't bode well.
Well, it's not just you, creating it. BTW, the same feeling counts for
everyone else.
--
Sent from my Android phone. Please excuse my brevity.
3:04 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, Aug 30, 2010 at 12:36:42PM -0700, Jesse Keating wrote:
We had a distro that was pretty general purpose, worked for servers
and
desktops and even laptops. We had a predictable schedule. We had new
technology thanks to rawhide. We had timely bugfixes that didn't sacrifice
stability, as in things didn't change out from under you on a stable
release. We had an ecosystem of third parties that would build up stacks
of newer things should a user be adventurous. We had a fresh release quite
often that could be relied upon for at least a year. We had a culture of
not just throwing crap over the wall at our users, which included
ourselves. We had accountability when things did go awry and a honest
effort to disrupt the users of our stable releases as little as possible.
We also we're a very free distro avoiding nonfree stuff, and we worked
well with upstreams. We we're easy to configure, easy to update, easy to
install whether a single system or 400 systems in a lab. We we're easy to
administrate in the same scenarios.
This sounds like an excellent definition for what Fedora should be.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
3:35 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, 30 Aug 2010 16:04:40 -0400
Matthew Miller <mattdm(a)mattdm.org> wrote:
On Mon, Aug 30, 2010 at 12:36:42PM -0700, Jesse Keating wrote:
> We had a distro that was pretty general purpose, worked for servers
> and desktops and even laptops. We had a predictable schedule. We
> had new technology thanks to rawhide. We had timely bugfixes that
> didn't sacrifice stability, as in things didn't change out from
> under you on a stable release. We had an ecosystem of third parties
> that would build up stacks of newer things should a user be
> adventurous. We had a fresh release quite often that could be
> relied upon for at least a year. We had a culture of not just
> throwing crap over the wall at our users, which included ourselves.
> We had accountability when things did go awry and a honest effort
> to disrupt the users of our stable releases as little as possible.
> We also we're a very free distro avoiding nonfree stuff, and we
> worked well with upstreams. We we're easy to configure, easy to
> update, easy to install whether a single system or 400 systems in a
> lab. We we're easy to administrate in the same scenarios.
This sounds like an excellent definition for what Fedora should be.
<aol>Me too</aol>
I would love to see us work back toward the above where we are no
longer doing so.
kevin
3:06 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, Aug 30, 2010 at 12:36:42PM -0700, Jesse Keating wrote:
> Why not give QA the time to settle and find out how the new
things
> work out?
Because the likes of Kevin throw fits whenever we try to insert any
QA
time or seem to try and improve the quality of our updates in any way
other than "throw more of them at people."
So you're saying we cannot test the new qa and update-process
'achievements' for a while because Kevin doesn't like them?
--
sven === jabber/xmpp: sven(a)lankes.net
11:42 p.m.
New subject: fedora mission (was Re: systemd and changes)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/30/10 1:06 PM, Sven Lankes wrote:
On Mon, Aug 30, 2010 at 12:36:42PM -0700, Jesse Keating wrote:
>> Why not give QA the time to settle and find out how the new things
>> work out?
> Because the likes of Kevin throw fits whenever we try to insert any QA
> time or seem to try and improve the quality of our updates in any way
> other than "throw more of them at people."
So you're saying we cannot test the new qa and update-process
'achievements' for a while because Kevin doesn't like them?
I'm saying that these changes were made in the face of extreme
resistance on Kevin's (and other's) parts. So whatever the outcome it's
already going counter to the Fedora that he would like to see, or
continue seeing.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkx8iDkACgkQ4v2HLvE71NVavACgsp6IrANe5Z7MQ2T8kT475AGC
YMgAn31XiShtXwfes2yBxASO2dEff9cE
=HiR1
-----END PGP SIGNATURE-----
3:40 a.m.
New subject: fedora mission (was Re: systemd and changes)
On 08/31/2010 05:42 AM, Jesse Keating wrote:
On 8/30/10 1:06 PM, Sven Lankes wrote:
> On Mon, Aug 30, 2010 at 12:36:42PM -0700, Jesse Keating wrote:
>>> Why not give QA the time to settle and find out how the new things
>>> work out?
>> Because the likes of Kevin throw fits whenever we try to insert any QA
>> time or seem to try and improve the quality of our updates in any way
>> other than "throw more of them at people."
> So you're saying we cannot test the new qa and update-process
> 'achievements' for a while because Kevin doesn't like them?
I'm saying that these changes were made in the face of extreme
resistance on Kevin's (and other's) parts. So whatever the outcome it's
already going counter to the Fedora that he would like to see, or
continue seeing.
Sure. But from what I recall, the "extreme resistance" amounted to little
more than posting a lot of emails, many of which were slapped down pretty
quickly.
Andrew.
5:55 a.m.
New subject: fedora mission (was Re: systemd and changes)
Andrew Haley píše v Út 31. 08. 2010 v 09:40 +0100:
On 08/31/2010 05:42 AM, Jesse Keating wrote:
> I'm saying that these changes were made in the face of extreme
> resistance on Kevin's (and other's) parts. So whatever the outcome
it's
> already going counter to the Fedora that he would like to see, or
> continue seeing.
Sure. But from what I recall, the "extreme resistance" amounted to little
more than posting a lot of emails, many of which were slapped down pretty
quickly.
What kind of resistance would you consider extreme? Napalm?
Mirek
7:20 a.m.
New subject: fedora mission (was Re: systemd and changes)
On 08/31/2010 11:55 AM, Miloslav Trmač wrote:
Andrew Haley píše v Út 31. 08. 2010 v 09:40 +0100:
> On 08/31/2010 05:42 AM, Jesse Keating wrote:
>> I'm saying that these changes were made in the face of extreme
>> resistance on Kevin's (and other's) parts. So whatever the outcome
it's
>> already going counter to the Fedora that he would like to see, or
>> continue seeing.
>
> Sure. But from what I recall, the "extreme resistance" amounted to little
> more than posting a lot of emails, many of which were slapped down pretty
> quickly.
What kind of resistance would you consider extreme? Napalm?
Something along those lines. :-)
Andrew.
3:13 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, 2010-08-30 at 12:36 -0700, Jesse Keating wrote:
We had a distro that was pretty general purpose, worked for servers
and desktops and even laptops. We had a predictable schedule.
It's called Laissez-faire meets reality. Right now we have a lot of
"free market" philosophy in Fedora that basically says if everything is
left alone then good things will magically happen, sum is greater than
the parts, yada yada yada. Insert some reference to Cathedral and Bazaar
and the implication that only Microsoft and - oh no - corporations would
have a heavy hand in overall cohesion, and you've got the mindset about
how it is now, at least from how I see it. That is a great college
mindset that works great for individual silos and experimentation.
The problem is, there are a lot of things that are decidedly unsexy in
anything, in particular having a product like Fedora be complete, free
of regressions, and overall provide a consistent experience. All of
those things won't just happen without a heavy mandate "this is how it
is, this is what we do, and no you can't do that". We need to say "no"
much more often, and view everything in the context of the project,
rather than just a test vehicle for some pet project that was fun.
Jon.
4:11 p.m.
New subject: fedora mission (was Re: systemd and changes)
Jon Masters píše v Po 30. 08. 2010 v 16:13 -0400:
On Mon, 2010-08-30 at 12:36 -0700, Jesse Keating wrote:
> We had a distro that was pretty general purpose, worked for servers
> and desktops and even laptops. We had a predictable schedule.
It's called Laissez-faire meets reality. Right now we have a lot of
"free market" philosophy in Fedora that basically says if everything is
left alone then good things will magically happen, sum is greater than
the parts, yada yada yada.
Too many labels, too little predictive value...
Let's talk specifically about incentives instead. If interested Linux
developers meet to create a distribution because they want to, you'll
inevitably get an updates firehose:
A typical developer wants the dependencies of the software they are
working on to be _very_ up to date - probably not the upstream
development version, but the upstream maintenance version with _all_
current bug fixes. Waiting 6 months for a bug fix does not make sense -
at that point the developer would be tempted to build the new version
locally.
So, web developers want latest httpd/PHP/Rails/MySQL; GNOME developers
want latest gtk/libgnome*; and so on.
Similarly, everyone who cares about the tools they use daily (which
developers tend to), wants the best versions of these tools, as soon as
it is practical. So, newest version of emacs/vim/kdevelop/...
[Some people develop low-level software against glibc, and haven't
changed their development environment for years; for them the flow of
updates really is not that interesting, and it seems superfluous.]
Saying "use rawhide" is not helpful, because rawhide is very often
broken. A "stable" release that breaks a specific component for a few
days is acceptable - if this is not a component one uses for
development, it doesn't matter; if this is such a component, one knows
about it well enough to be able to revert an update or to contribute a
fix.
When a large number of Fedora contributions are not paid to do so, they
naturally write a distribution _for themselves_. Why would they not?
That means that updates will be frequent; few maintainers would push
updates they consider too risky, but some risk is acceptable. The
"updates firehose" for components one does not much care about is a
minor risk, compared to the "commit firehose" for a mid-size program on
which one collaborates with two or more other people.
The result is a distribution on which it is reasonably easy to develop
current software, and a distribution on which one might not update
critical system updates on the night before giving a presentation on a
conference (FWIW, I can't recall a really bad updates experience). That
doesn't seem to be a bad tradeoff - for a developer.
Now, if we Fedora should be a distribution that developers enjoy using,
there will be an updates firehose - and most developers won't mind too
much. If Fedora should be a distribution that developers can install on
their grandparents' computers, developers won't enjoy working on the
distribution so much - both because this requires bureaucracy, and
because the result is not as interesting a distribution - and either the
quality and size of the distribution will suffer, or there will have to
be another motivation for many people to participate.
So, does Fedora want to be a place where interested Linux developers
meet to create a distribution they enjoy, or a project where people who
are for some reason compelled to create a distribution for others
collaborate on it?
What Fedora advertised is "..., Features, First" - that's a developer's
distro; Fedora was never "M million happy users, growing X% annually".
Mirek
4:17 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, 2010-08-30 at 23:11 +0200, Miloslav Trmač wrote:
Now, if we Fedora should be a distribution that developers enjoy
using,
there will be an updates firehose - and most developers won't mind too
much. If Fedora should be a distribution that developers can install on
their grandparents' computers, developers won't enjoy working on the
distribution so much - both because this requires bureaucracy, and
because the result is not as interesting a distribution - and either the
quality and size of the distribution will suffer, or there will have to
be another motivation for many people to participate.
Why does it have to be one or the other? There are ways to do both with
vitualization, separate stream of packages, multiple versions of the
same thing. Who knows what else. The point is, nobody is saying you
can't take a stable base and add in more recent bits for your area of
interest if six months really is too long for you to wait.
Jon.
4:29 p.m.
New subject: fedora mission (was Re: systemd and changes)
Jon Masters wrote:
Why does it have to be one or the other? There are ways to do both
with
vitualization, separate stream of packages, multiple versions of the
same thing. Who knows what else. The point is, nobody is saying you
can't take a stable base and add in more recent bits for your area of
interest if six months really is too long for you to wait.
Jon, you seem hard set on your ways. You, rudely, snipped a well
articulated e-mail down to what you want to pick a fight about. Why are
we even continuing this discussion?
Fedora will be made by the people that make it. I happily contribute as
a QA person and now as a package maintainer. You should be happy that
more and more people are getting on board for open source development
instead of telling everyone to wait their turn. Yes, there is a
compromise between Kevin Kofler and Jon Masters. It's called Fedora. Let
Fedora 14 ride and watch the new policies unfurl (as many others have
already stated).
4:43 p.m.
New subject: fedora mission (was Re: systemd and changes)
Jon Masters píše v Po 30. 08. 2010 v 17:17 -0400:
On Mon, 2010-08-30 at 23:11 +0200, Miloslav Trmač wrote:
> Now, if we Fedora should be a distribution that developers enjoy using,
> there will be an updates firehose - and most developers won't mind too
> much. If Fedora should be a distribution that developers can install on
> their grandparents' computers, developers won't enjoy working on the
> distribution so much - both because this requires bureaucracy, and
> because the result is not as interesting a distribution - and either the
> quality and size of the distribution will suffer, or there will have to
> be another motivation for many people to participate.
Why does it have to be one or the other? There are ways to do both with
vitualization, separate stream of packages, multiple versions of the
same thing. Who knows what else. The point is, nobody is saying you
can't take a stable base and add in more recent bits for your area of
interest if six months really is too long for you to wait.
Because all these
options require additional work from _each additional
user_. Or do we form 2048 specialized Fedora repos, one for each set of
interesting packages? That just doesn't work.
Mirek
5:29 p.m.
New subject: fedora mission (was Re: systemd and changes)
On 08/30/2010 03:11 PM, Miloslav Trmač wrote:
Jon Masters píše v Po 30. 08. 2010 v 16:13 -0400:
> On Mon, 2010-08-30 at 12:36 -0700, Jesse Keating wrote:
>
>> We had a distro that was pretty general purpose, worked for servers
>> and desktops and even laptops. We had a predictable schedule.
>
> It's called Laissez-faire meets reality. Right now we have a lot of
> "free market" philosophy in Fedora that basically says if everything is
> left alone then good things will magically happen, sum is greater than
> the parts, yada yada yada.
Too many labels, too little predictive value...
Let's talk specifically about incentives instead. If interested Linux
developers meet to create a distribution because they want to, you'll
inevitably get an updates firehose:
A typical developer wants the dependencies of the software they are
working on to be _very_ up to date - probably not the upstream
development version, but the upstream maintenance version with _all_
current bug fixes. Waiting 6 months for a bug fix does not make sense -
at that point the developer would be tempted to build the new version
locally.
So, web developers want latest httpd/PHP/Rails/MySQL; GNOME developers
want latest gtk/libgnome*; and so on.
Similarly, everyone who cares about the tools they use daily (which
developers tend to), wants the best versions of these tools, as soon as
it is practical. So, newest version of emacs/vim/kdevelop/...
[Some people develop low-level software against glibc, and haven't
changed their development environment for years; for them the flow of
updates really is not that interesting, and it seems superfluous.]
Saying "use rawhide" is not helpful, because rawhide is very often
broken. A "stable" release that breaks a specific component for a few
days is acceptable - if this is not a component one uses for
development, it doesn't matter; if this is such a component, one knows
about it well enough to be able to revert an update or to contribute a
fix.
When a large number of Fedora contributions are not paid to do so, they
naturally write a distribution _for themselves_. Why would they not?
That means that updates will be frequent; few maintainers would push
updates they consider too risky, but some risk is acceptable. The
"updates firehose" for components one does not much care about is a
minor risk, compared to the "commit firehose" for a mid-size program on
which one collaborates with two or more other people.
The result is a distribution on which it is reasonably easy to develop
current software, and a distribution on which one might not update
critical system updates on the night before giving a presentation on a
conference (FWIW, I can't recall a really bad updates experience). That
doesn't seem to be a bad tradeoff - for a developer.
Now, if we Fedora should be a distribution that developers enjoy using,
there will be an updates firehose - and most developers won't mind too
much. If Fedora should be a distribution that developers can install on
their grandparents' computers, developers won't enjoy working on the
distribution so much - both because this requires bureaucracy, and
because the result is not as interesting a distribution - and either the
quality and size of the distribution will suffer, or there will have to
be another motivation for many people to participate.
So, does Fedora want to be a place where interested Linux developers
meet to create a distribution they enjoy, or a project where people who
are for some reason compelled to create a distribution for others
collaborate on it?
What Fedora advertised is "..., Features, First" - that's a
developer's
distro; Fedora was never "M million happy users, growing X% annually".
Mirek
I have to say, while I don't agree with this as a direction, this was one of
the most thoughtful explanations of the desire for the latest of everything.
That said, I think developers as more advanced users really need to be able to
make use of something like rawhide to scratch the itch of working on the
latest. The people who I support using Fedora are not primarily developers.
At this point I'm using Fedora for three main reasons - inertia, I use Centos
and Fedora is very similar, and I very much enjoy being part of a community
and being able to give back to the community. Perhaps I can get that
elsewhere though.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
5:56 p.m.
New subject: rawhide rocks! [was Re: fedora mission (was Re: systemd and changes)]
On Mon, Aug 30, 2010 at 11:11:06PM +0200, Miloslav Trmač wrote:
A typical developer wants the dependencies of the software they are
working on to be _very_ up to date - probably not the upstream
development version, but the upstream maintenance version with _all_
current bug fixes. Waiting 6 months for a bug fix does not make sense -
at that point the developer would be tempted to build the new version
locally.
[...]
Saying "use rawhide" is not helpful, because rawhide is
very often
broken.
I've been running rawhide as my primary desktop OS at work for a couple of
years now. During that time, it's only broken so as to cause me as much as a
couple of hours work twice. That seems like a small price to pay for being
on the extreme leading edge as you describe.
And now with the "no frozen rawhide" feature, I expect it to be even more
stable.
A "stable" release that breaks a specific component for a
few
days is acceptable - if this is not a component one uses for
development, it doesn't matter; if this is such a component, one knows
about it well enough to be able to revert an update or to contribute a
fix.
There you go! That's what we have in Rawhide.
Maybe the problem here is that we need to market Rawhide better to Fedora
developers.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
6:05 p.m.
New subject: rawhide rocks! [was Re: fedora mission (was Re: systemd and changes)]
Matthew Miller píše v Po 30. 08. 2010 v 18:56 -0400:
On Mon, Aug 30, 2010 at 11:11:06PM +0200, Miloslav Trmač wrote:
> A typical developer wants the dependencies of the software they are
> working on to be _very_ up to date - probably not the upstream
> development version, but the upstream maintenance version with _all_
> current bug fixes. Waiting 6 months for a bug fix does not make sense -
> at that point the developer would be tempted to build the new version
> locally.
[...]
> Saying "use rawhide" is not helpful, because rawhide is very often
> broken.
I've been running rawhide as my primary desktop OS at work for a couple of
years now. During that time, it's only broken so as to cause me as much as a
couple of hours work twice. That seems like a small price to pay for being
on the extreme leading edge as you describe.
Curious. My experience from using the
latest Fedora (often updating on
the date of GA release) is very similar.
I sometimes wonder what the other users of Fedora are doing that the
"updates firehose" is such a problem...
> A "stable" release that breaks a specific component
for a few
> days is acceptable - if this is not a component one uses for
> development, it doesn't matter; if this is such a component, one knows
> about it well enough to be able to revert an update or to contribute a
> fix.
There you go! That's what we have in Rawhide.
No, for rawhide to really be
useful, it must be possible to put
unfinished system-wide changes in there: it would be pretty much
impossible to integrate systemd into the distribution on a "branch", and
to add it into rawhide only after everything works 100%. rawhide is
here to allow integration of "80% working but not finished" code, and
polishing it. As such, it is unavoidably dangerous, even if it may
often work out fine.
What I was talking about originally is not "80% working but not
finished", but "as far as we know 100% working, but not tested by a
RHEL-equivalent QA process including two beta releases over 6 months".
Mirek
6:50 p.m.
New subject: rawhide rocks! [was Re: fedora mission (was Re: systemd and changes)]
On Tue, Aug 31, 2010 at 01:05:34AM +0200, Miloslav Trmač wrote:
No, for rawhide to really be useful, it must be possible to put
unfinished system-wide changes in there: it would be pretty much
impossible to integrate systemd into the distribution on a "branch", and
to add it into rawhide only after everything works 100%. rawhide is
here to allow integration of "80% working but not finished" code, and
polishing it. As such, it is unavoidably dangerous, even if it may
often work out fine.
Wellllll, actually, see some earlier posts here on this. As it's currently
working, things aren't pushed to Rawhide after they've been through F14
testing.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
11:32 p.m.
New subject: rawhide rocks! [was Re: fedora mission (was Re: systemd and changes)]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/30/10 4:50 PM, Matthew Miller wrote:
On Tue, Aug 31, 2010 at 01:05:34AM +0200, Miloslav Trmač wrote:
> No, for rawhide to really be useful, it must be possible to put
> unfinished system-wide changes in there: it would be pretty much
> impossible to integrate systemd into the distribution on a "branch", and
> to add it into rawhide only after everything works 100%. rawhide is
> here to allow integration of "80% working but not finished" code, and
> polishing it. As such, it is unavoidably dangerous, even if it may
> often work out fine.
Wellllll, actually, see some earlier posts here on this. As it's currently
working, things aren't pushed to Rawhide after they've been through F14
testing.
That's only for some packages where the packager does not do a separate
F15 build and instead relies upon koji inheritance. It isn't
necessarily systemic.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkx8hfEACgkQ4v2HLvE71NVLgACeMCM5QPnE+YLJfRHRO3c6nz9E
ICkAnjsTbWMhLvX5w1DTmClVEXlb+8mW
=TM4A
-----END PGP SIGNATURE-----
6:30 p.m.
New subject: rawhide rocks! [was Re: fedora mission (was Re: systemd and changes)]
On Mon, Aug 30, 2010 at 15:56, Matthew Miller <mattdm(a)mattdm.org> wrote:
On Mon, Aug 30, 2010 at 11:11:06PM +0200, Miloslav Trmač wrote:
> A typical developer wants the dependencies of the software they are
> working on to be _very_ up to date - probably not the upstream
> development version, but the upstream maintenance version with _all_
> current bug fixes. Waiting 6 months for a bug fix does not make sense -
> at that point the developer would be tempted to build the new version
> locally.
[...]
> Saying "use rawhide" is not helpful, because rawhide is very often
> broken.
I've been running rawhide as my primary desktop OS at work for a couple of
years now. During that time, it's only broken so as to cause me as much as
a
couple of hours work twice. That seems like a small price to pay for being
on the extreme leading edge as you describe.
And now with the "no frozen rawhide" feature, I expect it to be even more
stable.
I've moved from being a rawhide junkie to a koji junkie. I've been in that
mode for the last five or six years. My experience has been that rawhide is
most unstable just around alpha time.
There are typically lots of regressions in rawhide. I can expect that
(suspend/resume, printing, usb key mounting, X, compix, control panels, et
al) are broken on a regular basis.
Maybe we should start a self-help group for those of us with this
affliction. I'm more surprised that the package owners haven't found a
better way to make use of us yet.
I choose to live with the regressions. Most users of Fedora are probably
interested in a far more stable system.
darrell
6:52 p.m.
New subject: rawhide rocks! [was Re: fedora mission (was Re: systemd and changes)]
On Mon, Aug 30, 2010 at 04:30:44PM -0700, darrell pfeifer wrote:
I've moved from being a rawhide junkie to a koji junkie. I've
been in that
mode for the last five or six years. My experience has been that rawhide is
most unstable just around alpha time.
That is no longer the case. See: http://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
7:30 p.m.
New subject: rawhide rocks! [was Re: fedora mission (was Re: systemd and changes)]
On Mon, 2010-08-30 at 19:52 -0400, Matthew Miller wrote:
On Mon, Aug 30, 2010 at 04:30:44PM -0700, darrell pfeifer wrote:
> I've moved from being a rawhide junkie to a koji junkie. I've been in that
> mode for the last five or six years. My experience has been that rawhide is
> most unstable just around alpha time.
That is no longer the case. See: http://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal
Actually, you want No_Frozen_Rawhide_Implementation. I made a link just
now from No_Frozen_Rawhide since there's no way I would have thought to
add "Proposal" or "Implementation" on the end when looking it up and
I
knew it was there to start with.
Jon.
5:58 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, Aug 30, 2010 at 11:11:06PM +0200, Miloslav Trmač wrote:
What Fedora advertised is "..., Features, First" -
that's a developer's
distro; Fedora was never "M million happy users, growing X% annually".
For what it's worth: the current statement on the Fedora "target audience"
includes: "familiar with computers, but is not necessarily a hacker or
developer".
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
7:41 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, 2010-08-30 at 18:58 -0400, Matthew Miller wrote:
On Mon, Aug 30, 2010 at 11:11:06PM +0200, Miloslav Trmač wrote:
> What Fedora advertised is "..., Features, First" - that's a
developer's
> distro; Fedora was never "M million happy users, growing X% annually".
For what it's worth: the current statement on the Fedora "target audience"
includes: "familiar with computers, but is not necessarily a hacker or
developer".
And also (on "computer friendly"):
"Our community is made up of people, by and large, who are very tech
savvy. The longer people have been involved in the Fedora community,
typically the more expertise they accrue on Linux and specifically
Fedora. However, our user base does not necessarily share this level of
expertise. We do not assume Fedora users are skilled developers or
hackers, although certainly some are."
See also the following things we apparently don't expect users to be
able to do (linked from the User_base page on the wiki):
"Mitigates unexpected changes in existing software"
"Know where to find software for testing"
"Understand how to select or install testing software"
And furthermore, from "general productivity user":
"When the user does not choose that path, though, we should take care
not to inflict those effects on the user. Accustomization is part of the
user's comfort with the system, no matter what the skill level.
Unexpected changes disrupt the user's accustomed environment and might
cause doubt in the stability of the system and the Fedora Project's
ability to manage it."
Great stuff. And there's more in there too. So the current User_base in
addition to being not very well linked and referenced could hardly be
described as reflecting all of the views in this particular thread. When
the target audience is (re)defined soon, hopefully this documentation
can be updated to reflect reality also.
Jon.
12:45 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, 2010-08-30 at 20:41 -0400, Jon Masters wrote:
Great stuff. And there's more in there too. So the current
User_base in
addition to being not very well linked and referenced could hardly be
described as reflecting all of the views in this particular thread.
Should it really reflect all the views in this thread?
Isn't that literally design-by-committee?
~m
3:28 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, 2010-08-31 at 13:45 -0400, Máirín Duffy wrote:
On Mon, 2010-08-30 at 20:41 -0400, Jon Masters wrote:
> Great stuff. And there's more in there too. So the current User_base in
> addition to being not very well linked and referenced could hardly be
> described as reflecting all of the views in this particular thread.
Should it really reflect all the views in this thread?
Not necessarily. What I'm saying is that it says one thing and the
reality *is* very different. I see quite a few posts basically saying
that that document doesn't matter to them at all, etc.
Jon.
9:09 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, 30 Aug 2010 23:11:06 +0200, you wrote:
A typical developer wants the dependencies of the software they are
working on to be _very_ up to date - probably not the upstream
development version, but the upstream maintenance version with _all_
current bug fixes. Waiting 6 months for a bug fix does not make sense -
at that point the developer would be tempted to build the new version
locally.
While I admit I haven't followed things very closely, I don't believe
anyone is saying don't issue bugfixes. What is being said is don't
upgrade versions just because something newer and shinier comes along
in the middle of a release.
So in other words, dependency 1.6 to 1.6.1 is okay as it is likely a
bug fix, but 1.6 to 1.8 is not okay because it is a new release.
So, web developers want latest httpd/PHP/Rails/MySQL; GNOME
developers
want latest gtk/libgnome*; and so on.
I wouldn't be so sure about that.
If I was developing a web application I would want my version of
httpd/PHP/Rails/MySQL to remain stable - the last thing I want is a
bug to appear in the application I am writing and have to wonder if it
is a problem with my code or did the update in my framework change
something on me.
Similarly, if I develop a desktop app then I want gtk and the Gnome
libraries (or Qt and the KDE libraries) to remain stable under me so I
don't have to wonder where the errors are coming from.
If on the other hand I am actually developing Gnome, then yes I want
the latest gtk etc., but that is why a project like Gnome has jhbuild
to make it easy for the developers to keep to the bleeding edge of the
Gnome stack without disturbing everyone else.
Similarly, everyone who cares about the tools they use daily (which
developers tend to), wants the best versions of these tools, as soon as
it is practical. So, newest version of emacs/vim/kdevelop/...
Again, as a developer I would disagree. Unless the latest
emacs/vim/debugger etc. offer a new feature that is going to save me
time I want things to remain consistent. Upgrading brings the risk of
a new bug that interupts my ability to work. This is something that
should only be done at a new release, so there are no unexpected
surprises to me as I try to balance keeping my system secure with bug
fixes and actually getting the work I want to do done.
Saying "use rawhide" is not helpful, because rawhide is very
often
broken. A "stable" release that breaks a specific component for a few
days is acceptable - if this is not a component one uses for
development, it doesn't matter; if this is such a component, one knows
about it well enough to be able to revert an update or to contribute a
fix.
Ironically you have actually just described rawhide. Despite the
reputation rawhide very rarely breaks for more than a day or 2 at a
time, the usual issue is more that upgrades won't happen because of
dependency issues that can take a while to sort out. But those don't
make the system unusable.
When a large number of Fedora contributions are not paid to do so,
they
naturally write a distribution _for themselves_. Why would they not?
That means that updates will be frequent; few maintainers would push
updates they consider too risky, but some risk is acceptable. The
"updates firehose" for components one does not much care about is a
minor risk, compared to the "commit firehose" for a mid-size program on
which one collaborates with two or more other people.
The problem is there is too much to a system that you do care about,
whether it be your desktop environment, an email program, X, the
kernel, etc. that end up getting pulled out from underneath you as you
try to do your work that isn't related to them.
The result is a distribution on which it is reasonably easy to
develop
current software, and a distribution on which one might not update
critical system updates on the night before giving a presentation on a
conference (FWIW, I can't recall a really bad updates experience). That
doesn't seem to be a bad tradeoff - for a developer.
So lets see, you are going to give a presentation or attend a
conference, where you will likely be using an unsecured network with
many threats that likely don't exist in your home or office
environment, and you are saying that because we have a distrubition
where anything can change and possibly break things you think it is
okay that you have to forgo critical system updates that might prevent
your system from being hacked? How can that be viewed as an
acceptable tradeoff?
What Fedora advertised is "..., Features, First" -
that's a developer's
distro; Fedora was never "M million happy users, growing X% annually".
Actually, Fedora was. Fedora initially followed on from Red Hat Linux
and was stable between releases, but this has gradually changed with
time.
10:56 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, Aug 30, 2010 at 10:09 PM, Gerald Henriksen <ghenriks(a)gmail.com> wrote:
On Mon, 30 Aug 2010 23:11:06 +0200, you wrote:
>A typical developer wants the dependencies of the software they are
>working on to be _very_ up to date - probably not the upstream
>development version, but the upstream maintenance version with _all_
>current bug fixes. Waiting 6 months for a bug fix does not make sense -
>at that point the developer would be tempted to build the new version
>locally.
While I admit I haven't followed things very closely, I don't believe
anyone is saying don't issue bugfixes. What is being said is don't
upgrade versions just because something newer and shinier comes along
in the middle of a release.
So in other words, dependency 1.6 to 1.6.1 is okay as it is likely a
bug fix, but 1.6 to 1.8 is not okay because it is a new release.
6 months for new features in a fast paced distro?
--
Fedora 13
(www.pembo13.com)
11:10 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, 2010-08-30 at 23:56 -0400, Arthur Pemberton wrote:
On Mon, Aug 30, 2010 at 10:09 PM, Gerald Henriksen
<ghenriks(a)gmail.com> wrote:
> On Mon, 30 Aug 2010 23:11:06 +0200, you wrote:
>
>>A typical developer wants the dependencies of the software they are
>>working on to be _very_ up to date - probably not the upstream
>>development version, but the upstream maintenance version with _all_
>>current bug fixes. Waiting 6 months for a bug fix does not make sense -
>>at that point the developer would be tempted to build the new version
>>locally.
>
> While I admit I haven't followed things very closely, I don't believe
> anyone is saying don't issue bugfixes. What is being said is don't
> upgrade versions just because something newer and shinier comes along
> in the middle of a release.
>
> So in other words, dependency 1.6 to 1.6.1 is okay as it is likely a
> bug fix, but 1.6 to 1.8 is not okay because it is a new release.
6 months for new features in a fast paced distro?
You know, compared to almost any other Operating System out there, 6
months is warp speed. I'd rather have fewer features in my stable
install that worked just right, then get shiny new things and deal with
some brokenness in return at a defined point in the future.
Jon.
11:45 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 12:10 AM, Jon Masters <jonathan(a)jonmasters.org> wrote:
On Mon, 2010-08-30 at 23:56 -0400, Arthur Pemberton wrote:
> On Mon, Aug 30, 2010 at 10:09 PM, Gerald Henriksen <ghenriks(a)gmail.com> wrote:
> > On Mon, 30 Aug 2010 23:11:06 +0200, you wrote:
> >
> >>A typical developer wants the dependencies of the software they are
> >>working on to be _very_ up to date - probably not the upstream
> >>development version, but the upstream maintenance version with _all_
> >>current bug fixes. Waiting 6 months for a bug fix does not make sense -
> >>at that point the developer would be tempted to build the new version
> >>locally.
> >
> > While I admit I haven't followed things very closely, I don't believe
> > anyone is saying don't issue bugfixes. What is being said is don't
> > upgrade versions just because something newer and shinier comes along
> > in the middle of a release.
> >
> > So in other words, dependency 1.6 to 1.6.1 is okay as it is likely a
> > bug fix, but 1.6 to 1.8 is not okay because it is a new release.
> 6 months for new features in a fast paced distro?
You know, compared to almost any other Operating System out there, 6
months is warp speed. I'd rather have fewer features in my stable
install that worked just right, then get shiny new things and deal with
some brokenness in return at a defined point in the future.
So far the only brokeness I have had in all of F13 is with `seabios-bin`.
--
Fedora 13
(www.pembo13.com)
12:06 a.m.
New subject: fedora mission (was Re: systemd and changes)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/30/10 9:45 PM, Arthur Pemberton wrote:
So far the only brokeness I have had in all of F13 is with
`seabios-bin`.
People judge brokeness in different ways. For some it's out right
functioning stopping, such as the repeated problems with bind vs dnssec.
For other's it's a change in behavior from one update to another. For
others still it's a change in soname making a locally developed/compiled
application suddenly stop working and needing porting effort. Others
still it's a change that makes documentation produced at the release no
longer apply to the operating system after 3 months of updates.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkx8jdQACgkQ4v2HLvE71NVM5QCgvEGLVB5uDCe+QgdOqO3sNLbt
EVAAoMXo5eijmjPIiMPIZ0k1DkzeHPAJ
=lIVO
-----END PGP SIGNATURE-----
8:19 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 00:45:49 -0400,
Arthur Pemberton <pemboa(a)gmail.com> wrote:
So far the only brokeness I have had in all of F13 is with `seabios-bin`.
Wasn't there recently a packagekit problem where it stopped doing updates,
making it kind of hard to get a fix unless you knew about yum? That's
a pretty significant oops.
8:29 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, 31 Aug 2010, Bruno Wolff III wrote:
On Tue, Aug 31, 2010 at 00:45:49 -0400,
Arthur Pemberton <pemboa(a)gmail.com> wrote:
>
> So far the only brokeness I have had in all of F13 is with `seabios-bin`.
Wasn't there recently a packagekit problem where it stopped doing updates,
making it kind of hard to get a fix unless you knew about yum? That's
a pretty significant oops.
Yes we have links on some of our sites like -
http://start.fedoraproject.org/ for example. The sad thing is this is the
second time this has happened in the last few releases.
-Mike
12:43 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, 2010-08-31 at 00:10 -0400, Jon Masters wrote:
> 6 months for new features in a fast paced distro?
You know, compared to almost any other Operating System out there, 6
months is warp speed. I'd rather have fewer features in my stable
install that worked just right, then get shiny new things and deal with
some brokenness in return at a defined point in the future.
Other operating systems don't work like Linux distributions; the
applications aren't bundled with the core OS. We go to reasonable
lengths to tell people that installing apps from upstream is Bad and
Wrong. On Windows I don't get all my apps through Windows Update and
wait for Microsoft to sign off on updates. We can't compare our release
processes to theirs, when the products we're creating are substantially
different.
As someone pointed out earlier in the thread, in my experience, most
people are fundamentally inconsistent here: generally we have some
components we want updated a lot and some we don't care about (so
probably don't want updated because we'd only notice if the update
'broke something') or actively don't want updated. However, the actual
members of each of those sets vary wildly from person to person. If most
components are delivered through separate mechanisms, as with say
Windows and OS X and more generally with any operating system whose
distributor doesn't follow the model of recommending users should get
all software through official repositories, then problems don't really
occur: you (the user) can choose how to treat each component.
In the traditional Linux distribution, this isn't the case; all
components are maintained in the same repository, and if you don't use
it, you're 'off the reservation'. That kind of limits the choices of the
distributor.
1) Don't shoot everything through the same hose: separate. Fedora used
to do this, with Core and Extras. Now we don't. I can't really comment
on why, I wasn't around. There are clearly advantages and disadvantages
to doing this.
2) Provide multiple hose variations - however you set it up, give users
some kind of way to pick fast updates for some components and slow
updates for others. (All the proposals about multiple package versions
in repositories, or multiple repositories, come under this heading.)
3) Provide one hose, and pick a policy covering how fast the updates
come out of it, and say 'that's what you get, if you like it take it, if
you don't, we don't support you'.
All of these approaches have drawbacks and advantages. Currently we're
on #3, with the twist that the policy is chosen in a fairly haphazard
way. So far we've discussed sticking with #3 but making the policy more
organized and possibly different, and we've also discussed #2, though it
doesn't seem to be going anywhere. #1 doesn't seem to be much in the
running.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
11:25 p.m.
New subject: fedora mission (was Re: systemd and changes)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/30/10 8:56 PM, Arthur Pemberton wrote:
On Mon, Aug 30, 2010 at 10:09 PM, Gerald Henriksen
<ghenriks(a)gmail.com> wrote:
> On Mon, 30 Aug 2010 23:11:06 +0200, you wrote:
>
>> A typical developer wants the dependencies of the software they are
>> working on to be _very_ up to date - probably not the upstream
>> development version, but the upstream maintenance version with _all_
>> current bug fixes. Waiting 6 months for a bug fix does not make sense -
>> at that point the developer would be tempted to build the new version
>> locally.
>
> While I admit I haven't followed things very closely, I don't believe
> anyone is saying don't issue bugfixes. What is being said is don't
> upgrade versions just because something newer and shinier comes along
> in the middle of a release.
>
> So in other words, dependency 1.6 to 1.6.1 is okay as it is likely a
> bug fix, but 1.6 to 1.8 is not okay because it is a new release.
6 months for new features in a fast paced distro?
New features hit rawhide all the time, with no waiting period.
The fact that we can get a reasonably stable release out every 6 months
including all these new features is pretty fast paced and amazing. I
just want to keep that hard work relevant 1, 2, and 13 months after we
make that release.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkx8hCcACgkQ4v2HLvE71NXxXgCgs3nzizN8sgDxxXFLdN/On9D4
TOEAnimkbGlDK/Vd2e5QJJ9VkS6E84/a
=7B90
-----END PGP SIGNATURE-----
11:48 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 12:25 AM, Jesse Keating
<jkeating(a)j2solutions.net> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/30/10 8:56 PM, Arthur Pemberton wrote:
> On Mon, Aug 30, 2010 at 10:09 PM, Gerald Henriksen <ghenriks(a)gmail.com> wrote:
>> On Mon, 30 Aug 2010 23:11:06 +0200, you wrote:
>>
>>> A typical developer wants the dependencies of the software they are
>>> working on to be _very_ up to date - probably not the upstream
>>> development version, but the upstream maintenance version with _all_
>>> current bug fixes. Waiting 6 months for a bug fix does not make sense -
>>> at that point the developer would be tempted to build the new version
>>> locally.
>>
>> While I admit I haven't followed things very closely, I don't believe
>> anyone is saying don't issue bugfixes. What is being said is don't
>> upgrade versions just because something newer and shinier comes along
>> in the middle of a release.
>>
>> So in other words, dependency 1.6 to 1.6.1 is okay as it is likely a
>> bug fix, but 1.6 to 1.8 is not okay because it is a new release.
>
>
> 6 months for new features in a fast paced distro?
>
New features hit rawhide all the time, with no waiting period.
So developers are going to put new features into rawhide knowing that
they will never make it to updates?
The fact that we can get a reasonably stable release out every 6
months
including all these new features is pretty fast paced and amazing.
I seem to remember new features coming faster before.
--
Fedora 13
(www.pembo13.com)
12:08 a.m.
New subject: fedora mission (was Re: systemd and changes)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/30/10 9:48 PM, Arthur Pemberton wrote:
> New features hit rawhide all the time, with no waiting period.
So developers are going to put new features into rawhide knowing that
they will never make it to updates?
Developers put new features in rawhide knowing that they will be in the
next release of Fedora, which would be at the /most/ 6 months from the
time they drop the feature. During that time they have a nightly tree
of software built and consumed by testers and users giving feedback
about that feature, allowing the developer to work on it and make it
even better by the time the next branch event happens and we spin off a
release.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkx8jjwACgkQ4v2HLvE71NUwhgCdGTjGuntH+gQx9TmlaR6RlQHT
jYMAoJqasuCU0eHxIwEp5Xh33egQalGz
=NS5r
-----END PGP SIGNATURE-----
7:33 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, 2010-08-30 at 22:08 -0700, Jesse Keating wrote:
Developers put new features in rawhide knowing that they will be in
the
next release of Fedora, which would be at the /most/ 6 months from the
time they drop the feature.
It's more like 9 months. A feature has to wait until the next branching
of a Fedora version from rawhide, and then for that Fedora version to be
released. For example, a feature that landed in rawhide on 2010-02-19,
just after F13 was branched, would end up in F14 on 2010-11-02.
Your point is still taken.
--
Matt
10:07 a.m.
New subject: fedora mission (was Re: systemd and changes)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/31/10 5:33 AM, Matt McCutchen wrote:
On Mon, 2010-08-30 at 22:08 -0700, Jesse Keating wrote:
> Developers put new features in rawhide knowing that they will be in the
> next release of Fedora, which would be at the /most/ 6 months from the
> time they drop the feature.
It's more like 9 months. A feature has to wait until the next branching
of a Fedora version from rawhide, and then for that Fedora version to be
released. For example, a feature that landed in rawhide on 2010-02-19,
just after F13 was branched, would end up in F14 on 2010-11-02.
Your point is still taken.
It'd be in the Alpha for F14 much earlier. And all along the way, from
rawhide -> branched -> alpha -> beta -> final it'll have users using it
and providing feedback, and a progressively less scary target for eager
users to jump to if they want that new feature earlier.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkx9GsUACgkQ4v2HLvE71NWdeACgn6fdpqnOxhe9VTfJEMk8+kjr
XhkAoKefWbmoR7KEewiySDGRmZiXqCxX
=+rfo
-----END PGP SIGNATURE-----
7:22 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 12:48:02AM -0400, Arthur Pemberton wrote:
> New features hit rawhide all the time, with no waiting period.
So developers are going to put new features into rawhide knowing that
they will never make it to updates?
That seems like an excellent model, yes. When the next Fedora release tree
is branched in less than six months, the new features automatically become
widely available.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
10:56 a.m.
New subject: fedora mission (was Re: systemd and changes)
On 08/30/2010 10:48 PM, Arthur Pemberton wrote:
So developers are going to put new features into rawhide knowing that
they will never make it to updates?
I do it all the time because I know it will be out ~ 6 months, which is pretty
quick.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
8:57 a.m.
New subject: fedora mission (was Re: systemd and changes)
...
So in other words, dependency 1.6 to 1.6.1 is okay as it is likely a
bug fix, but 1.6 to 1.8 is not okay because it is a new release.
there's no reason why 1.8 won't be ok after 2-3 weeks in updates-testing
>So, web developers want latest httpd/PHP/Rails/MySQL; GNOME
developers
>want latest gtk/libgnome*; and so on.
I wouldn't be so sure about that.
If I was developing a web application I would want my version of
httpd/PHP/Rails/MySQL to remain stable - the last thing I want is a
bug to appear in the application I am writing and have to wonder if it
is a problem with my code or did the update in my framework change
something on me.
If you develop some app you want to catch bugs in your app as fast as possible
because you don't want release something that is broken just because there is
newer library out there.
Also my own experience: I wanted webmail client with some set of features the
only client (except too big hordce imp) was latest roundcube. I had to package
it myselfs because it was not even in latest fedora and then update all
dendencies because it was not working with ancient php centos5 provides. I
know Fedora is much "faster" than CentOS, but still... there's no reason why
we should not update packages to newer *stable* release
>Similarly, everyone who cares about the tools they use daily
(which
>developers tend to), wants the best versions of these tools, as soon as
>it is practical. So, newest version of emacs/vim/kdevelop/...
Again, as a developer I would disagree.
Again, as a developer I would agree with Miloslav
>The result is a distribution on which it is reasonably easy to
develop
>current software, and a distribution on which one might not update
>critical system updates on the night before giving a presentation on a
>conference (FWIW, I can't recall a really bad updates experience). That
>doesn't seem to be a bad tradeoff - for a developer.
So lets see, you are going to give a presentation or attend a
conference, where you will likely be using an unsecured network with
many threats that likely don't exist in your home or office
environment, and you are saying that because we have a distrubition
where anything can change and possibly break things you think it is
okay that you have to forgo critical system updates that might prevent
your system from being hacked? How can that be viewed as an
acceptable tradeoff?
That package won't be ancient old, so the risk is small to almost zero. You'd
understand the tradeoff better after first not working presentation you've tried
to do. I won't update nothing day or two before presentation even from current
fedora/centos/...
9:14 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 03:57:47PM +0200, Michal Hlavinka wrote:
> So in other words, dependency 1.6 to 1.6.1 is okay as it is
likely a
> bug fix, but 1.6 to 1.8 is not okay because it is a new release.
there's no reason why 1.8 won't be ok after 2-3 weeks in updates-testing
I hope you are kidding.
Of course, these imaginary numbers aren't very helpful -- some programs make
only minor changes between whole-version-number releases, whereas others
revolutionize the whole project beteen 0.88 and 0.89.
The policy can't be based on version numbers -- it has to be on potential
risk.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
10:31 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Tuesday, August 31, 2010 16:14:39 Matthew Miller wrote:
On Tue, Aug 31, 2010 at 03:57:47PM +0200, Michal Hlavinka wrote:
> > So in other words, dependency 1.6 to 1.6.1 is okay as it is likely a
> > bug fix, but 1.6 to 1.8 is not okay because it is a new release.
>
> there's no reason why 1.8 won't be ok after 2-3 weeks in updates-testing
I hope you are kidding.
nope, I'm 100 % serious
Of course, these imaginary numbers aren't very helpful -- some
programs
make only minor changes between whole-version-number releases, whereas
others revolutionize the whole project beteen 0.88 and 0.89.
The policy can't be based on version numbers -- it has to be on potential
risk.
Note: I agree there should be no updates breaking something - for example when
configuration files from old version does not work with new version. That's out
of the question.
Fedora is not the only distro using (and testing) some program/library. Also
there is very low potential risk to have some problem in F n-1 if the package
works fine in F n. I really don't see any problem with:
new version in rawhide and Fn updates-testing
(after two weeks)
updates for Fn, updates-testing for F n-1
(after two weeks)
updates for F n-1, updates-testing for F n-2
Fedora = “Freedom, Friends, Features, *First*”
10:36 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 05:31:43PM +0200, Michal Hlavinka wrote:
> > > So in other words, dependency 1.6 to 1.6.1 is okay as
it is likely a
> > > bug fix, but 1.6 to 1.8 is not okay because it is a new release.
> > there's no reason why 1.8 won't be ok after 2-3 weeks in
updates-testing
> I hope you are kidding.
nope, I'm 100 % serious
Unfortunately, then: this does not currently match reality.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
11:08 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Tuesday, August 31, 2010 17:36:39 Matthew Miller wrote:
On Tue, Aug 31, 2010 at 05:31:43PM +0200, Michal Hlavinka wrote:
> > > > So in other words, dependency 1.6 to 1.6.1 is okay as it is likely
> > > > a bug fix, but 1.6 to 1.8 is not okay because it is a new release.
> > >
> > > there's no reason why 1.8 won't be ok after 2-3 weeks in
> > > updates-testing
> >
> > I hope you are kidding.
>
> nope, I'm 100 % serious
Unfortunately, then: this does not currently match reality.
that's not any usefull information for discussion. If you can only offend
instead of bringing some new information/arguments, please do not spam this
thread, there is a lot of posts already. thanks
11:28 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 06:08:09PM +0200, Michal Hlavinka wrote:
> > > > there's no reason why 1.8 won't be ok
after 2-3 weeks in
> > > > updates-testing
> > > I hope you are kidding.
> > nope, I'm 100 % serious
> Unfortunately, then: this does not currently match reality.
that's not any usefull information for discussion. If you can only offend
instead of bringing some new information/arguments, please do not spam this
thread, there is a lot of posts already. thanks
I don't mean to offend. And I also don't think there's any new information.
The basic fact of current reality is that the testing repositories do not
get enough exposure or formal testing to demonstrate that an update is okay.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
10:39 a.m.
New subject: fedora mission (was Re: systemd and changes)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/31/10 6:57 AM, Michal Hlavinka wrote:
there's no reason why 1.8 won't be ok after 2-3 weeks in
updates-testing
An update that changes behavior for the end user would never be
acceptable as an update to a stable release. Only severe exceptions
should be made to this rule, where the time/effort to backport the
important fixes from a new upstream release are cost prohibitive and too
complicated to do on our own.
rawhide is not to F-n as debian unstable is to debian testing.
F-n is not to F-(n-1) as debian testing is to debian stable.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkx9IhwACgkQ4v2HLvE71NXnpgCfcso2mCew20a1ERPE31+jJg4z
MtcAnRGCoa1Lrv5loMdOCSqC+4KTchW4
=q/v4
-----END PGP SIGNATURE-----
11:18 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Tuesday, August 31, 2010 17:39:11 Jesse Keating wrote:
On 8/31/10 6:57 AM, Michal Hlavinka wrote:
> there's no reason why 1.8 won't be ok after 2-3 weeks in updates-testing
An update that changes behavior for the end user would never be
acceptable as an update to a stable release. Only severe exceptions
should be made to this rule, where the time/effort to backport the
important fixes from a new upstream release are cost prohibitive and too
complicated to do on our own.
I don't thing there is so much updates that change behaviour, see firefox,
thunderbird, kopete, .... usually there are only new features with old
functionality intact. What I wrote was not a rule, there is always a lot of
space for maintainer's decission.
rawhide is not to F-n as debian unstable is to debian testing.
F-n is not to F-(n-1) as debian testing is to debian stable.
no, but I think rawhide is to F-n as debian unstable is to debian stable. What
I wrote as an example was expecting all versions in F-x are stable not that
one version is more stable than another one. That delay was only for being
"really sure" package is stable, because there are not too much users testing
updates-testing packages if it's not new firefox/kernel/... but after a two
weaks in F-n any package is tested quite well
11:57 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, 2010-08-31 at 18:18 +0200, Michal Hlavinka wrote:
On Tuesday, August 31, 2010 17:39:11 Jesse Keating wrote:
> On 8/31/10 6:57 AM, Michal Hlavinka wrote:
> > there's no reason why 1.8 won't be ok after 2-3 weeks in
updates-testing
>
> An update that changes behavior for the end user would never be
> acceptable as an update to a stable release. Only severe exceptions
> should be made to this rule, where the time/effort to backport the
> important fixes from a new upstream release are cost prohibitive and too
> complicated to do on our own.
I don't thing there is so much updates that change behaviour, see firefox,
thunderbird, kopete, .... usually there are only new features with old
functionality intact. What I wrote was not a rule, there is always a lot of
space for maintainer's decission.
Things like Firefox, and Thunderbird have large external teams
maintaining them who appear to have goals around ensuring a consistent
user experience, with testing, and so forth, over and above just getting
new features. They even do self-updating on some platforms, etc. I would
say they are fantastic examples of packages where you can get away with
a lower commitment in favor of updating them more frequently because the
upstream is known to have the user experience interest as a top priority
over adding new features. But that isn't a given for every single piece
of software by any means, especially when it comes to upstream testing.
I was saying elsewhere that I think what could work for something like
the Server SIG would be a very strong commitment to the crit-path bits,
regular cross-team meetings to discuss proposals and pain points, and a
very co-ordinated planning effort to change the guts of the system.
There is some effort to do that kind of thing already with a different
treatment of crit-path updates, but I think it should go further. Then,
I suppose it would be ok to agree to have a lesser commitment for some
other packages like Firefox, especially where Mozilla (and the packager)
is known to be doing a very good job providing consistent experience.
Jon.
12:10 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 8:57 AM, Jon Masters <jonathan(a)jonmasters.org> wrote:
Things like Firefox, and Thunderbird have large external teams
maintaining them who appear to have goals around ensuring a consistent
user experience, with testing, and so forth, over and above just getting
new features. They even do self-updating on some platforms, etc. I would
say they are fantastic examples of packages where you can get away with
a lower commitment in favor of updating them more frequently because the
upstream is known to have the user experience interest as a top priority
over adding new features. But that isn't a given for every single piece
of software by any means, especially when it comes to upstream testing.
Uhm wait... wasn't a mid release update to thunderbird one of the
historic examples of a large behavior change that precipitated a
strong negative reaction? I think you are careening well away from
fact based argument here.
-jef
10:59 a.m.
New subject: fedora mission (was Re: systemd and changes)
On 08/31/2010 10:40 PM, Jeff Spaleta wrote:
On Tue, Aug 31, 2010 at 8:57 AM, Jon Masters
<jonathan(a)jonmasters.org> wrote:
> Things like Firefox, and Thunderbird have large external teams
> maintaining them who appear to have goals around ensuring a consistent
> user experience, with testing, and so forth, over and above just getting
> new features. They even do self-updating on some platforms, etc. I would
> say they are fantastic examples of packages where you can get away with
> a lower commitment in favor of updating them more frequently because the
> upstream is known to have the user experience interest as a top priority
> over adding new features. But that isn't a given for every single piece
> of software by any means, especially when it comes to upstream testing.
Uhm wait... wasn't a mid release update to thunderbird one of the
historic examples of a large behavior change that precipitated a
strong negative reaction? I think you are careening well away from
fact based argument here.
We shipped a Beta or a RC and then toggled on indexing in a post-release
update. Upstream is not responsible for that. Package maintainer is.
Rahul
11:40 a.m.
New subject: fedora mission (was Re: systemd and changes)
2010/8/31 Jesse Keating <jkeating(a)j2solutions.net>:
An update that changes behavior for the end user would never be
acceptable as an update to a stable release. Only severe exceptions
should be made to this rule, where the time/effort to backport the
important fixes from a new upstream release are cost prohibitive and too
complicated to do on our own.
An update that does not change behavior for the end user is ... not meaningful.
Any update changes something, otherwise it would not have been issued.
And sometimes it is not at all clear if that change is welcome or not.
A bug fix might be in most cases, but could also mean some work to the
"end user" as well, like removing a workaround.
We should accept that people have different expectations, and draw
different lines in the trade of getting new bug fixes and new features
vs. coping with breakage and changed behavior. People might even have
different expectations from package to package. If we decide to draw
that line at a fixed point, distribution-wide, we'll lose people,
inevitably. So lets try to come up with ideas how to satisfy both (or
even more than two) needs. Making categories (critical packages vs.
non-critical packages) is a good step in the right direction, as well
as more than one repository. If there are issues the build system or
the packaging tools cannot handle, good, that is a technical problem
and can be solved. We're not here for politics, are we?
- Thomas
5:13 p.m.
New subject: fedora mission (was Re: systemd and changes)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/31/10 9:40 AM, Thomas Moschny wrote:
2010/8/31 Jesse Keating <jkeating(a)j2solutions.net>:
> An update that changes behavior for the end user would never be
> acceptable as an update to a stable release. Only severe exceptions
> should be made to this rule, where the time/effort to backport the
> important fixes from a new upstream release are cost prohibitive and too
> complicated to do on our own.
An update that does not change behavior for the end user is ... not meaningful.
Ok, fair point. "change behavior" is too vague here. I'm trying to
draw a difference between fixing a bug (which would change the behavior)
and changing things as an "enhancement" or a re-write, or whatever you
want to call it. That is if a user is used to interacting with an
application in one way that is not somehow taking advantage of a flaw,
an update that comes along and changes the way a user has to interact
with that software, that is what I wish to avoid. Surprise is not good,
one doesn't expect to have to re-discover applications and work flows
after applying vendor provided updates for a stable release.
Any update changes something, otherwise it would not have been issued.
And sometimes it is not at all clear if that change is welcome or not.
A bug fix might be in most cases, but could also mean some work to the
"end user" as well, like removing a workaround.
We should accept that people have different expectations, and draw
different lines in the trade of getting new bug fixes and new features
vs. coping with breakage and changed behavior. People might even have
different expectations from package to package. If we decide to draw
that line at a fixed point, distribution-wide, we'll lose people,
inevitably. So lets try to come up with ideas how to satisfy both (or
even more than two) needs. Making categories (critical packages vs.
non-critical packages) is a good step in the right direction, as well
as more than one repository. If there are issues the build system or
the packaging tools cannot handle, good, that is a technical problem
and can be solved. We're not here for politics, are we?
- Thomas
I'm not proposing a iron clad rule. I'm proposing a default way of
treating our updates and users. Exceptions to the default can be made,
and in some cases must be made. I'm arguing though to default on the
side of keeping a release consistent and stable throughout the life of
the release.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkx9fp4ACgkQ4v2HLvE71NU0YwCguxeBjFNq4+qMk7JsMhwvSGGp
MSYAn2RhPBPneRTB4wHztHq3TfbxwK3B
=eE3d
-----END PGP SIGNATURE-----
11:40 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 7:39 AM, Jesse Keating <jkeating(a)j2solutions.net> wrote:
An update that changes behavior for the end user would never be
acceptable as an update to a stable release. Only severe exceptions
should be made to this rule, where the time/effort to backport the
important fixes from a new upstream release are cost prohibitive and too
complicated to do on our own.
Uhm... there are end-user applications under active development that
see monthly-ish updates that can include UI changes and bug fixes
together. In fact UI changes could be considered bugfixes. Are you
sure there is a bright line concerning changes to end-user observable
behavior? I'm not. Bugfixes can deliberately and purposefully change
behavior that some users are used to.
I'm a package maintainer for one such application. I have yet to hear
from a single user...ever..that tracking releases from upstream has
been unwanted for this specific application regardless of the UI
tweaks that happen between upstream releases. In fact I have bug
reports to the contrary asking me to push newer versions because I
originally held back updates across a significant upstream version
boundary.
Am I going to be disallowed from tracking upstream's release schedule
for this particular application by providing monthlyish updates and
moving them through updates-testing into updates-released?
-jef
11:51 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 08:40:29 -0800,
Jeff Spaleta <jspaleta(a)gmail.com> wrote:
I'm a package maintainer for one such application. I have yet to hear
from a single user...ever..that tracking releases from upstream has
been unwanted for this specific application regardless of the UI
tweaks that happen between upstream releases. In fact I have bug
reports to the contrary asking me to push newer versions because I
originally held back updates across a significant upstream version
boundary.
Packages that need to sync to external servers or peers such as multiplayer
games have similar issues. You need to be up to date to for the package
to be useful in some cases.
I would like to see some per package exceptions to this policy that don't
need to be revisited for every update.
12:25 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 11:51:27AM -0500, Bruno Wolff III wrote:
I would like to see some per package exceptions to this policy that
don't
need to be revisited for every update.
I think it's reasonable to put packages into different tiers. Or "lanes",
if
we don't want to think in terms of which is on top of the other.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
12:34 p.m.
New subject: fedora mission (was Re: systemd and changes)
* Bruno Wolff III [31/08/2010 19:25] :
Packages that need to sync to external servers or peers such as multiplayer
games have similar issues. You need to be up to date to for the package
to be useful in some cases.
Same goes for programs that scrape web pages (I'm thinking of gcstar but
I'm sure there are others). If the page layout changes, the page scraper
needs to be updated and that usually involves updating the package.
Emmanuel
12:50 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 9:34 AM, Emmanuel Seyman
<emmanuel.seyman(a)club-internet.fr> wrote:
Same goes for programs that scrape web pages (I'm thinking of
gcstar but
I'm sure there are others). If the page layout changes, the page scraper
needs to be updated and that usually involves updating the package.
Yep.. gourmet does this to some extent as well for scrape recipes from
specific sites as well as provide a generic web scraper for you to
build your own recipe grabber.
-jef
1:31 p.m.
New subject: fedora mission (was Re: systemd and changes)
Jeff Spaleta (jspaleta(a)gmail.com) said:
On Tue, Aug 31, 2010 at 9:34 AM, Emmanuel Seyman
<emmanuel.seyman(a)club-internet.fr> wrote:
> Same goes for programs that scrape web pages (I'm thinking of gcstar but
> I'm sure there are others). If the page layout changes, the page scraper
> needs to be updated and that usually involves updating the package.
Yep.. gourmet does this to some extent as well for scrape recipes from
specific sites as well as provide a generic web scraper for you to
build your own recipe grabber.
That's gross. (I realize you're blocked on the sites you rely on, but
geez, can't you find sites with real APIs?)
Bill
1:55 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 10:31 AM, Bill Nottingham <notting(a)redhat.com> wrote:
That's gross. (I realize you're blocked on the sites you rely
on, but
geez, can't you find sites with real APIs?)
It is what it is. Though I do like being given credit for doing
development work that I'm not actually responsible for. Makes me feel
important.
if you have specific recipe cites that have a documented API that
you'd like to see added file an RFE with as much information as you
can and I'll see if I can't help implement an API client plugin for
that site inside the gourmet plugin system to gift to the upstream
developers.
-jef
2:03 p.m.
New subject: fedora mission (was Re: systemd and changes)
Some people like everything up-to-date, while others are more
conservative. Fine. Isn't there a middle ground?
Currently there are these repos: updates and updates_testing.
Maybe two more repos could be added: updates_fixes and updates_enhancements.
After a package stays for a while in updates_testing, and is
considered good, the package maintainer would decide where to move it.
If it is security-related it would go to updates, if not he would look
at the changes since the previous version. If the changes are minor,
just bug fixes, the package would go to updates_fixes, if besides bug
fixes it has enhancements, it would be moved to updates_enhancements.
People with yum would enable the repos they need according to their
requirements. People using PackageKit or yumex would have two tick
boxes in option settings to enable (or not) fixes and enhancements.
The downside is that if upstream the security fixes are available only
at the latest source, it would take some work to port just the
security fixes on top of the latest stable version. It would be easier
just to get the full upstream version (including enhancements and bug
fixes) and package it and move into updates.
It would then be the choice of the package maintainer to decide on
what to do based on time available and how comfortable he feels
patching source code: either port just security fixes (which implies
doing two packages, one with just security fixes and another with
enhancements) or a single package with everything.
---
P. S. As an alternative to the above, to simplify things a bit, a
single new repo could be created, with both enhancements and fixes.
2:56 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, 2010-08-31 at 20:03 +0100, Piscium wrote:
Some people like everything up-to-date, while others are more
conservative. Fine. Isn't there a middle ground?
Currently there are these repos: updates and updates_testing.
Maybe two more repos could be added: updates_fixes and updates_enhancements.
We've had multiple proposals along these lines (as I mentioned in
passing on my general post about the three main ways to deal with
software delivery in a repository-based OS). The principal objection to
them is that it results in more work for already overworked developers.
I don't think any of the proposals has been seriously considered at
FESCo or Board level yet, though IMBW.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:26 p.m.
New subject: fedora mission (was Re: systemd and changes)
Jeff Spaleta (jspaleta(a)gmail.com) said:
On Tue, Aug 31, 2010 at 10:31 AM, Bill Nottingham
<notting(a)redhat.com> wrote:
> That's gross. (I realize you're blocked on the sites you rely on, but
> geez, can't you find sites with real APIs?)
It is what it is. Though I do like being given credit for doing
development work that I'm not actually responsible for. Makes me feel
important.
It is not meant to be a complaint at you or a request for you to do more
work. It's a complaint at the state of the world. (Why not find the
biggest windmill of all to tilt at?)
Bill
3:16 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 11:26 AM, Bill Nottingham <notting(a)redhat.com> wrote:
It is not meant to be a complaint at you or a request for you to do
more
work. It's a complaint at the state of the world. (Why not find the
biggest windmill of all to tilt at?)
I didn't mean for you to think it was a complaint. If I actually had
developed anything significant in gourmet I'd be beaming with pride
with the notoriety.
Seriously though, there is a plugin system, it is possible to avoid
webscraping. If there are recipe sites out there with documented APIs
we can get those sites their own site-specific plugin with a weebit of
effort without completely re-engineering how gourmet works.
Even then..if the API changes we are in the same boat with regard to
updates mid-release.
-jef
2:08 p.m.
New subject: fedora mission (was Re: systemd and changes)
* Bill Nottingham [31/08/2010 21:01] :
That's gross.
Yup, no question about it.
(I realize you're blocked on the sites you rely on,
but
geez, can't you find sites with real APIs?)
For some of them, it is possible (DVDfr.com has a stable XML API and the
webmaster has contributed to GCstar). Sadly, it's the exception rather
than the rule.
Emmanuel
3:47 p.m.
New subject: fedora mission (was Re: systemd and changes)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/31/10 9:40 AM, Jeff Spaleta wrote:
On Tue, Aug 31, 2010 at 7:39 AM, Jesse Keating
<jkeating(a)j2solutions.net> wrote:
> An update that changes behavior for the end user would never be
> acceptable as an update to a stable release. Only severe exceptions
> should be made to this rule, where the time/effort to backport the
> important fixes from a new upstream release are cost prohibitive and too
> complicated to do on our own.
Uhm... there are end-user applications under active development that
see monthly-ish updates that can include UI changes and bug fixes
together. In fact UI changes could be considered bugfixes. Are you
sure there is a bright line concerning changes to end-user observable
behavior? I'm not. Bugfixes can deliberately and purposefully change
behavior that some users are used to.
I'm a package maintainer for one such application. I have yet to hear
from a single user...ever..that tracking releases from upstream has
been unwanted for this specific application regardless of the UI
tweaks that happen between upstream releases. In fact I have bug
reports to the contrary asking me to push newer versions because I
originally held back updates across a significant upstream version
boundary.
Am I going to be disallowed from tracking upstream's release schedule
for this particular application by providing monthlyish updates and
moving them through updates-testing into updates-released?
I appreciate that there are going to be exceptions to the rule. There
are going to be packages or suites of packages where the users far and
away prefer always the latest whenever possible. In the cases where
these packages are "leaf node" with little interaction across the rest
of the distro I think that's fine to have a stated exception (and
expectation) to the policy. But they should be the exceptions and not
the rules.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkx9akMACgkQ4v2HLvE71NW9IgCfU13FFR/bkUuZO25gBz4NSqrC
PJsAnR6HwtshFaBMTrdOsidayuEcX2V7
=YK8m
-----END PGP SIGNATURE-----
3:33 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, Aug 30, 2010 at 3:36 PM, Jesse Keating <jkeating(a)j2solutions.net> wrote:
"Thomas Janssen" <thomasj(a)fedoraproject.org> wrote:
>On Mon, Aug 30, 2010 at 6:03 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 08/28/2010 09:25 PM, Kevin Kofler wrote:
>>> Jesse Keating wrote:
>>>> The cynic in me would expect that the people who want something
different
>>>> than the fire hose we have now are silently leaving, and those that are
>>>> left are going to say they like the deluge of updates.
>>>
>>> You say that as if it were a negative thing.
>>
>> To me it is. It's you and people like you that want to shove a ton of
>> updates down the throats of our stable release users (including changes
>> that alter behavior and sonames etc...) that have ruined the Fedora I
>> helped to build. I want my Fedora back, I don't want what you're
creating.
>
>Interesting here is that one can say "Leave the project if you don't
>like what we do" (already done in the direction of Kevin Kofler) but
>the offer doesn't count for everybody.
>Not saying you should leave, for sure not. I think you're valuable for
>the project. The same counts by the way as well for Kevin and everyone
>else not sharing your opinion.
>
>>> It's actually very positive, it
>>> means we have found our niche and set some very specific expectations in our
>>> user base! We should stick to that and not suddenly turn around half-turn.
>>
>> We've found our niche, but chasing away our previous niche (and having
>> less users show up in our tracking mechanism for it)
>
>What previous niche?
We had a distro that was pretty general purpose, worked for servers and desktops and even
laptops. We had a predictable schedule.
We had new technology thanks to rawhide. We had timely bugfixes that didn't sacrifice
stability,
as in things didn't change out from under you on a stable release. We had an
ecosystem of third parties
that would build up stacks of newer things should a user be adventurous. We had a fresh
release quite
often that could be relied upon for at least a year. We had a culture of not just
throwing crap over the wall at our users, which included ourselves. We had accountability
when things did go awry and a honest
effort to disrupt the users of our stable releases as little as possible. We also
we're a very free distro avoiding nonfree stuff, and we worked well with
upstreams. We we're easy to configure, easy to update, easy to install whether a
single system or 400 systems in a lab. We we're easy to administrate in the same
scenarios.
This was fairly unique and what drew a lot of people to the project.
Is this still unique?
--
Fedora 13
(www.pembo13.com)
11:36 p.m.
New subject: fedora mission (was Re: systemd and changes)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/30/10 1:33 PM, Arthur Pemberton wrote:
Is this still unique?
I believe it is, particularly with our attention to freedom and upstream
relationships, and our connection to arguably /the/ premiere enterprise
Linux offering.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkx8hssACgkQ4v2HLvE71NVE4ACdEY9OpsgBCSJ41y/+ifsYg/xA
AssAn2cq5iQ5FB/20WdiW9xw8g0c+JvK
=txgZ
-----END PGP SIGNATURE-----
11:50 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 12:36 AM, Jesse Keating
<jkeating(a)j2solutions.net> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/30/10 1:33 PM, Arthur Pemberton wrote:
> Is this still unique?
I believe it is, particularly with our attention to freedom and upstream
relationships, and our connection to arguably /the/ premiere enterprise
Linux offering.
The attention to freedom is not unique. The attention to upstream is
invisible to users.
--
Fedora 13
(www.pembo13.com)
12:11 a.m.
New subject: fedora mission (was Re: systemd and changes)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/30/10 9:50 PM, Arthur Pemberton wrote:
On Tue, Aug 31, 2010 at 12:36 AM, Jesse Keating
<jkeating(a)j2solutions.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 8/30/10 1:33 PM, Arthur Pemberton wrote:
>> Is this still unique?
>
> I believe it is, particularly with our attention to freedom and upstream
> relationships, and our connection to arguably /the/ premiere enterprise
> Linux offering.
The attention to freedom is not unique. The attention to upstream is
invisible to users.
We want to not just be compelling to users, but we want to be compelling
to developers as well.
Our attention to freedom /when combined/ with all our other aspects does
make a unique picture. Not ever bit is going to be interesting to a
casual user, or a upstream developer. But each can find something
useful in what we do.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkx8juoACgkQ4v2HLvE71NUr7gCeJGq5iRsme4ZeuBQkE/NC6SiN
hu0AniJ8cE6vV3LAuu0oRfFagHYPQRTU
=xib/
-----END PGP SIGNATURE-----
12:56 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 1:11 AM, Jesse Keating <jkeating(a)j2solutions.net> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/30/10 9:50 PM, Arthur Pemberton wrote:
> On Tue, Aug 31, 2010 at 12:36 AM, Jesse Keating
> <jkeating(a)j2solutions.net> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 8/30/10 1:33 PM, Arthur Pemberton wrote:
>>> Is this still unique?
>>
>> I believe it is, particularly with our attention to freedom and upstream
>> relationships, and our connection to arguably /the/ premiere enterprise
>> Linux offering.
>
>
> The attention to freedom is not unique. The attention to upstream is
> invisible to users.
>
>
We want to not just be compelling to users, but we want to be compelling
to developers as well.
Our attention to freedom /when combined/ with all our other aspects does
make a unique picture. Not ever bit is going to be interesting to a
casual user, or a upstream developer. But each can find something
useful in what we do.
So here's what I understand to be what you are suggesting as a
"mission": a strongly free Linux distro, with only bug fix updates
between releases, with an attention to tracking upstream.
Strongly free and tracking upstream is something developers would
appreciate, however bug fix only updates are often contrary to what
developers want and outlier users like myself.
Bug-fix updates benefit general users but general users often don't
like to bare with the additional complexity gained by being so
adherent to FOSS philosophy.
I am suggesting that the mission you would like is contradictory: not
that it cannot happen, but in that it represents an intersection of
people that is very small.
--
Fedora 13
(www.pembo13.com)
8:05 a.m.
New subject: fedora mission (was Re: systemd and changes)
On 08/31/2010 11:26 AM, Arthur Pemberton wrote:
Strongly free and tracking upstream is something developers would
appreciate, however bug fix only updates are often contrary to what
developers want and outlier users like myself.
It depends on whether Fedora is a platform for development. If it is,
developers usually do not want many changes.
Rahul
11:26 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 07:05, Rahul Sundaram <metherid(a)gmail.com> wrote:
On 08/31/2010 11:26 AM, Arthur Pemberton wrote:
> Strongly free and tracking upstream is something developers would
> appreciate, however bug fix only updates are often contrary to what
> developers want and outlier users like myself.
It depends on whether Fedora is a platform for development. If it is,
developers usually do not want many changes.
It depends on the type of developer and what they are doing. Trying to
lump all the developers into one bottle is one of the problems of this
so-called conversation.
--
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines
11:38 a.m.
New subject: fedora mission (was Re: systemd and changes)
On 08/31/2010 12:26 PM, Stephen John Smoogen wrote:
On Tue, Aug 31, 2010 at 07:05, Rahul Sundaram
<metherid(a)gmail.com> wrote:
> It depends on whether Fedora is a platform for development. If it is,
> developers usually do not want many changes.
>
It depends on the type of developer and what they are doing. Trying to
lump all the developers into one bottle is one of the problems of this
so-called conversation.
I concur - I know some who are happy with things staying as they were
in 1980.
I know more who prefer reasonably current toolkits - many get
frustrated when obligated to work on older installs (the 'stable' but
somewhat ancient ones in particular) which may have packages a few
years older than current.
And its not just kernels, libraries and compilers but applications
too. (e.g TeXlive without biblatex, openoffice without docx etc etc).
gene/
10:58 a.m.
New subject: fedora mission (was Re: systemd and changes)
On 08/30/2010 10:50 PM, Arthur Pemberton wrote:
The attention to freedom is not unique. The attention to upstream is
invisible to users.
But it is why I want to *develop* for Fedora.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
11:32 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, 2010-08-31 at 09:58 -0600, Orion Poplawski wrote:
On 08/30/2010 10:50 PM, Arthur Pemberton wrote:
> The attention to freedom is not unique. The attention to upstream is
> invisible to users.
But it is why I want to *develop* for Fedora.
You cut out the rest of Arthur's email, where he says exactly the same
thing. This isn't a point scoring exercise, please read entire emails
before you spot a piece you think you disagree with and try to win by
contradicting it.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12:26 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 12:32 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Tue, 2010-08-31 at 09:58 -0600, Orion Poplawski wrote:
> On 08/30/2010 10:50 PM, Arthur Pemberton wrote:
> > The attention to freedom is not unique. The attention to upstream is
> > invisible to users.
>
> But it is why I want to *develop* for Fedora.
You cut out the rest of Arthur's email, where he says exactly the same
thing. This isn't a point scoring exercise, please read entire emails
before you spot a piece you think you disagree with and try to win by
contradicting it.
Thank you for mentioning this, I was simply not going to respond to
Mr. Poplawski.
Maybe I was too long winded, or failed to communicate my point: a
stable (bug fix only updates, slow feature release), strongly FOSS,
strongly upstream seems to be what some (I am not going to make
assumptions about numbers) want. I see two problems with this:
1) the nature of such a distro would make it attractive to a smaller
percentage of the Linux community
2) the only aspect of that that would be unique is the commitment to
upstream -- something which will be appreciated by few
I'm not saying that any aspect of such a mission would be bad, just
that it would be very niche.
--
Fedora 13
(www.pembo13.com)
2:56 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 01:26:27PM -0400, Arthur Pemberton wrote:
Maybe I was too long winded, or failed to communicate my point: a
stable (bug fix only updates, slow feature release), strongly FOSS,
strongly upstream seems to be what some (I am not going to make
assumptions about numbers) want. I see two problems with this:
Where, keep in mind, "slow" is defined as twice a year, right?
1) the nature of such a distro would make it attractive to a smaller
percentage of the Linux community
Do you have a basis for this claim? I think it's the opposite.
2) the only aspect of that that would be unique is the commitment to
upstream -- something which will be appreciated by few
I don't think that's fair at all. Fedora is unique in a lot of ways, and a
waterfall of updates isn't essential to that uniqueness.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
3:03 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 3:56 PM, Matthew Miller <mattdm(a)mattdm.org> wrote:
On Tue, Aug 31, 2010 at 01:26:27PM -0400, Arthur Pemberton wrote:
> Maybe I was too long winded, or failed to communicate my point: a
> stable (bug fix only updates, slow feature release), strongly FOSS,
> strongly upstream seems to be what some (I am not going to make
> assumptions about numbers) want. I see two problems with this:
Where, keep in mind, "slow" is defined as twice a year, right?
Yes.
> 1) the nature of such a distro would make it attractive to a
smaller
> percentage of the Linux community
Do you have a basis for this claim? I think it's the opposite.
The basis is logic. Users who want stable, slow environments do so
primarily because the want simpler to setup and maintain systems.
Those users also don't want to install other unsupported repositories
for full drivers, codecs, font engines, media, players ect which they
then have to install unassisted.
> 2) the only aspect of that that would be unique is the commitment
to
> upstream -- something which will be appreciated by few
I don't think that's fair at all. Fedora is unique in a lot of ways, and a
waterfall of updates isn't essential to that uniqueness.
List those ways please, aside from the relationship with Red Hat/CentOS.
--
Fedora 13
(www.pembo13.com)
9:51 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 04:03:17PM -0400, Arthur Pemberton wrote:
> Where, keep in mind, "slow" is defined as twice a
year, right?
Yes.
I think this is a remarkable definition of slow. Especially if we can
provide options for people who want a faster path to do so.
> I don't think that's fair at all. Fedora is unique in a
lot of ways, and a
> waterfall of updates isn't essential to that uniqueness.
List those ways please, aside from the relationship with Red Hat/CentOS.
Why brush that aside? Historically, there's been a lot of fear in Fedora of
being perceived as merely a beta or technology preview for RHEL. By now,
though, we've proven that that's not the case, that what we've said all
along is true — Fedora is a great distro in its own right! But it'd be silly
of us to overcompensate by distancing ourselves completely. Fedora is part
of an entire ecosystem, and part of that ecosystem includes an open source
company which has a great enterprise distribution based on the work we do
here, and which employees a great number of engineers, hackers, developers,
and designers all contributing significantly to free software. Why *start*
by cutting that out?
(All right... all right... but apart from better sanitation and medicine and
education and irrigation and public health and roads and a freshwater system
and baths and public order... what have the Romans done for us?)
I also think that it's not true that just because Ubuntu aims to be a
general purpose distribution, we can't as well. It's unlike the
coke-vs-pepsi analogy you suggest, because it's all free software and
parallel development actually benefits everyone. Two groups can approach the
same target differently.
But that's not all there is to it.
Fedora has a great release engineering team and process. There's a serious
emphasis on shipping solid, professional releases. Ubuntu has a process too,
but they end up with things like a zero-day last-minute respin of 10.04.
That would not have happened in the same way with Fedora.
There may be work to do on QA of packages that get put out as updates, but
the overall QA process in Fedora is great. The packaging guidelines and
initial review process are well-considered and polished by real-world use.
We've got great package-development infrastructure and tools, and great
people working on those.
Fedora is built on important technology. For example: kickstart. It's better
than Debian's scripted installs, and Ubuntu's implementation of kickstart
is.... lacking. This is cool stuff, and it enables other cool stuff like
Fedora spins. Another example: from one point of view, RPM vs. dpkg is
negligible, but there are technical features which make it nicer for some
purposes (like a derived distribution). My point isn't to argue about the
relative virtues of different technology, but that key points of the
distribution-glue are unique.
And Fedora *is* fast -- see above.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
11:13 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Wed, Sep 1, 2010 at 10:51 AM, Matthew Miller <mattdm(a)mattdm.org> wrote:
On Tue, Aug 31, 2010 at 04:03:17PM -0400, Arthur Pemberton wrote:
> > Where, keep in mind, "slow" is defined as twice a year, right?
> Yes.
I think this is a remarkable definition of slow. Especially if we can
provide options for people who want a faster path to do so.
> > I don't think that's fair at all. Fedora is unique in a lot of ways, and
a
> > waterfall of updates isn't essential to that uniqueness.
> List those ways please, aside from the relationship with Red Hat/CentOS.
Why brush that aside?
Because it is very obvious, and it also subjective as a pro or con.
Historically, there's been a lot of fear in Fedora of
being perceived as merely a beta or technology preview for RHEL. By now,
though, we've proven that that's not the case, that what we've said all
along is true — Fedora is a great distro in its own right! But it'd be silly
of us to overcompensate by distancing ourselves completely. Fedora is part
of an entire ecosystem, and part of that ecosystem includes an open source
company which has a great enterprise distribution based on the work we do
here, and which employees a great number of engineers, hackers, developers,
and designers all contributing significantly to free software. Why *start*
by cutting that out?
(All right... all right... but apart from better sanitation and medicine and
education and irrigation and public health and roads and a freshwater system
and baths and public order... what have the Romans done for us?)
I also think that it's not true that just because Ubuntu aims to be a
general purpose distribution, we can't as well. It's unlike the
coke-vs-pepsi analogy you suggest, because it's all free software and
parallel development actually benefits everyone. Two groups can approach the
same target differently.
But that's not all there is to it.
Fedora has a great release engineering team and process. There's a serious
emphasis on shipping solid, professional releases. Ubuntu has a process too,
but they end up with things like a zero-day last-minute respin of 10.04.
That would not have happened in the same way with Fedora.
There may be work to do on QA of packages that get put out as updates, but
the overall QA process in Fedora is great. The packaging guidelines and
initial review process are well-considered and polished by real-world use.
We've got great package-development infrastructure and tools, and great
people working on those.
Fedora is built on important technology. For example: kickstart. It's better
than Debian's scripted installs, and Ubuntu's implementation of kickstart
is.... lacking. This is cool stuff, and it enables other cool stuff like
Fedora spins. Another example: from one point of view, RPM vs. dpkg is
negligible, but there are technical features which make it nicer for some
purposes (like a derived distribution). My point isn't to argue about the
relative virtues of different technology, but that key points of the
distribution-glue are unique.
And Fedora *is* fast -- see above.
I would like to point out how nuanced and somewhat subjective the
differences you stated are, even if I may agree with most of them.
--
Fedora 13
(www.pembo13.com)
11:36 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Wed, Sep 01, 2010 at 12:13:04PM -0400, Arthur Pemberton wrote:
>> > I don't think that's fair at all. Fedora is
unique in a lot of ways,
>> > and a waterfall of updates isn't essential to that uniqueness.
>> List those ways please, aside from the relationship with Red Hat/CentOS.
> Why brush that aside?
Because it is very obvious, and it also subjective as a pro or con.
But being obvious doesn't disqualify it -- it makes it, well, more obvious.
And the question isn't about pro or cons, it's about uniqueness.
I would like to point out how nuanced and somewhat subjective the
differences you stated are, even if I may agree with most of them.
Not counting that big one, maybe. :) But part of my point is: we don't need
to be dramatic about distinguishing ourselves from Ubuntu just for the sake
of doing that. I think there's room for both even with significant overlap
in mission.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
3:07 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, 2010-08-31 at 15:56 -0400, Matthew Miller wrote:
On Tue, Aug 31, 2010 at 01:26:27PM -0400, Arthur Pemberton wrote:
> Maybe I was too long winded, or failed to communicate my point: a
> stable (bug fix only updates, slow feature release), strongly FOSS,
> strongly upstream seems to be what some (I am not going to make
> assumptions about numbers) want. I see two problems with this:
Where, keep in mind, "slow" is defined as twice a year, right?
> 1) the nature of such a distro would make it attractive to a smaller
> percentage of the Linux community
Do you have a basis for this claim? I think it's the opposite.
> 2) the only aspect of that that would be unique is the commitment to
> upstream -- something which will be appreciated by few
I don't think that's fair at all. Fedora is unique in a lot of ways, and a
waterfall of updates isn't essential to that uniqueness.
Arthur's idea was better expressed in his original mail. His point was
that a Fedora aiming at the niche described (by Jesse) would differ from
Ubuntu solely in its more rigorous interpretation of 'freedom' and its
attention to upstream, which experience seems to show are not things the
majority of people who go for the Ubuntu niche care much about. I think
this is a pretty reasonable thesis - note how popular non-free software
is with Ubuntu users, how many people use Mint (which is essentially
Ubuntu with even more non-free stuff added), and how few people use/used
the more-strictly-free Ubuntu variations that have existed.
As he put it, "I am suggesting that the mission you would like is
contradictory: not that it cannot happen, but in that it represents an
intersection of people that is very small." The niche described is a
kind of mix of attributes that appeal to entirely different types of
users/contributors.
Do go back and read his original email, Date: Tue, 31 Aug 2010 01:56:26
-0400 (30/08/10 10:56:26 PM).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4:43 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 4:07 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Tue, 2010-08-31 at 15:56 -0400, Matthew Miller wrote:
> On Tue, Aug 31, 2010 at 01:26:27PM -0400, Arthur Pemberton wrote:
> > Maybe I was too long winded, or failed to communicate my point: a
> > stable (bug fix only updates, slow feature release), strongly FOSS,
> > strongly upstream seems to be what some (I am not going to make
> > assumptions about numbers) want. I see two problems with this:
>
> Where, keep in mind, "slow" is defined as twice a year, right?
>
> > 1) the nature of such a distro would make it attractive to a smaller
> > percentage of the Linux community
>
> Do you have a basis for this claim? I think it's the opposite.
>
> > 2) the only aspect of that that would be unique is the commitment to
> > upstream -- something which will be appreciated by few
>
> I don't think that's fair at all. Fedora is unique in a lot of ways, and a
> waterfall of updates isn't essential to that uniqueness.
Arthur's idea was better expressed in his original mail. His point was
that a Fedora aiming at the niche described (by Jesse) would differ from
Ubuntu solely in its more rigorous interpretation of 'freedom' and its
attention to upstream, which experience seems to show are not things the
majority of people who go for the Ubuntu niche care much about. I think
this is a pretty reasonable thesis - note how popular non-free software
is with Ubuntu users, how many people use Mint (which is essentially
Ubuntu with even more non-free stuff added), and how few people use/used
the more-strictly-free Ubuntu variations that have existed.
As he put it, "I am suggesting that the mission you would like is
contradictory: not that it cannot happen, but in that it represents an
intersection of people that is very small." The niche described is a
kind of mix of attributes that appeal to entirely different types of
users/contributors.
Exactly, the key idea is "The niche described is a kind of mix of
attributes that appeal to entirely different types of
users/contributors".
It is an admirable goal to push for, even it it may nto reflect my own
desires. However, I believe that it may be analogous to selling vegan
dishes at a butcher shop.
--
Fedora 13
(www.pembo13.com)
10:03 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, Aug 31, 2010 at 05:43:26PM -0400, Arthur Pemberton wrote:
Exactly, the key idea is "The niche described is a kind of mix
of
attributes that appeal to entirely different types of
users/contributors".
It's not a crazy point. :) But I disagree that the niche is as niche-like as
you're making it out to be. The inconveniences caused by adherence to free
software principles aren't that overwhelming, and I'm not sure developers
are really that resistant to stability.
It is an admirable goal to push for, even it it may nto reflect my
own
desires. However, I believe that it may be analogous to selling vegan
dishes at a butcher shop.
Nice. :) But I don't think it quite holds. I get the "pure free software =
vegan" analogy, but in what way is a stable (but still forward-thinking and
innovative!) system like a butcher shop?
As I said in my other message, I don't think Fedora reduces to *just* the
intersection you're describing. The contradictory aims may put pressure on
each other, but I think the answer is in finding a proper balance, and
finding ways to reduce or deflect that pressure so that the project as a
whole isn't thrown off.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
7:09 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, Aug 30, 2010 at 9:36 PM, Jesse Keating <jkeating(a)j2solutions.net> wrote:
"Thomas Janssen" <thomasj(a)fedoraproject.org> wrote:
>What previous niche?
We had a distro that was pretty general purpose, worked for servers and desktops and even
laptops. We had a predictable schedule.
We had new technology thanks to rawhide. We had timely bugfixes that didn't sacrifice
stability,
as in things didn't change out from under you on a stable release. We had an
ecosystem of third parties
that would build up stacks of newer things should a user be adventurous. We had a fresh
release quite
often that could be relied upon for at least a year. We had a culture of not just
throwing crap over the wall at our users, which included ourselves. We had accountability
when things did go awry and a honest
effort to disrupt the users of our stable releases as little as possible. We also
we're a very free distro avoiding nonfree stuff, and we worked well with
upstreams. We we're easy to configure, easy to update, easy to install whether a
single system or 400 systems in a lab. We we're easy to administrate in the same
scenarios.
This was fairly unique and what drew a lot of people to the project.
I'm not sure i would call that a niche, but it sounds very good. Count me in.
>> It's getting to
>> the point where me, as a long time Fedora developer and sometimes
>> leader, is not enjoying using Fedora any more. Every update run can
>> break things, and often does.
>
>Why not give QA the time to settle and find out how the new things work out?
Because the likes of Kevin throw fits whenever we try to insert any QA time or seem to
try and improve the quality of our updates in any way other than "throw more of them
at people."
Hm, ignore Kevin or the likes here. The new Bodhi and proventesters
are a good step in the right direction. As proventester and
24/7-updates-testing enabled guy, i can say, it starts to work. Thanks
to everybody involved.
>> Every update takes for ever because there
>> are so many updates. Too many to review each one and see what it does,
>> and how to maybe test it and provide feedback. Updates runs just get
>> pushed off longer and longer so that I have a block of time to A) apply
>> the damn things, and B) spend a few hours recovering from any sort of
>> fallout in my workflow.
>
>What DE is in use on your box?
I use Gnome with some KDE apps.
The Gnome Desktop should be safe (not a Gnome user so i can only guess
here, sorry) and the KDE Desktop gets more and more "stable". Means
the *big* UI changes are over. Small improvements will most likely
always happen, together with bugfixes, as that's the KDE philosophy.
People like me likes that, but i can understand the others who don't
want even small changes.
I personally would like to see a F n-1 that gets just the badly needed
bugfixes (security and crash). But have the latest release get mixed
updates, bugfixes and smaller UI improvements. That way, the ones with
slow i-net or just don't want to see much updates could be happy with
n-1. And all the others as well with the latest release.
Rawhide and personal repos, would still fulfil the role for people
living on the real bleeding side of the edge and for hot-new-stuff to
develop in.
--
Best regards
Thomas
1:22 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, Aug 30, 2010 at 10:03, Jesse Keating <jkeating(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/28/2010 09:25 PM, Kevin Kofler wrote:
> Jesse Keating wrote:
>> The cynic in me would expect that the people who want something different
>> than the fire hose we have now are silently leaving, and those that are
>> left are going to say they like the deluge of updates.
>
> You say that as if it were a negative thing.
To me it is. It's you and people like you that want to shove a ton of
updates down the throats of our stable release users (including changes
that alter behavior and sonames etc...) that have ruined the Fedora I
helped to build. I want my Fedora back, I don't want what you're creating.
The problem to quote a tv philosopher is:
The avalanche has already started, it is too late for the pebbles to vote.
The changes towards a distribution that attracts people who live in
the moment happened a while back, and has been building momentum for
quite some time. Trying to erect barriers now is not going to help but
make it so nothing exists afterwords. The things that can be done are:
A) get out of the way, B) go with the flow, or C) figure out what you
can build on top of it. [I am looking at option C]
We've found our niche, but chasing away our previous niche (and
having
less users show up in our tracking mechanism for it) It's getting to
the point where me, as a long time Fedora developer and sometimes
leader, is not enjoying using Fedora any more. Every update run can
What was our previous niche? That is what people seemed so hard to
ever quantify beyond knowing "what it isn't". The people I know who
are running Ubuntu now instead of RHL or Fedora are doing it because
that distribution 'fills in the blanks' for them that RHL/Fedora never
seemed to answer. It has a vision, it has a single voice where they
feel it is needed. Fedora has never been that. (heck even RHL was
never that as you couldn't get any of the RH developers to agree on
much :)).
--
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines
1:30 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, 2010-08-30 at 12:22 -0600, Stephen John Smoogen wrote:
The avalanche has already started, it is too late for the pebbles to
vote.
The changes towards a distribution that attracts people who live in
the moment happened a while back, and has been building momentum for
quite some time. Trying to erect barriers now is not going to help but
make it so nothing exists afterwords. The things that can be done are:
A) get out of the way, B) go with the flow, or C) figure out what you
can build on top of it. [I am looking at option C]
> We've found our niche, but chasing away our previous niche (and having
> less users show up in our tracking mechanism for it) It's getting to
> the point where me, as a long time Fedora developer and sometimes
> leader, is not enjoying using Fedora any more. Every update run can
What was our previous niche? That is what people seemed so hard to
ever quantify beyond knowing "what it isn't". The people I know who
are running Ubuntu now instead of RHL or Fedora are doing it because
that distribution 'fills in the blanks' for them that RHL/Fedora never
seemed to answer. It has a vision, it has a single voice where they
feel it is needed. Fedora has never been that. (heck even RHL was
never that as you couldn't get any of the RH developers to agree on
much :)).
I think the RHL niche was:
1. reasonably current
2. updated to a new release every 6months
3. supported for security/errata for 3yrs
4. free
-sv
2:49 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, Aug 30, 2010 at 12:30, seth vidal <skvidal(a)fedoraproject.org> wrote:
On Mon, 2010-08-30 at 12:22 -0600, Stephen John Smoogen wrote:
> The avalanche has already started, it is too late for the pebbles to vote.
>
> The changes towards a distribution that attracts people who live in
> the moment happened a while back, and has been building momentum for
> quite some time. Trying to erect barriers now is not going to help but
> make it so nothing exists afterwords. The things that can be done are:
> A) get out of the way, B) go with the flow, or C) figure out what you
> can build on top of it. [I am looking at option C]
>
> > We've found our niche, but chasing away our previous niche (and having
> > less users show up in our tracking mechanism for it) It's getting to
> > the point where me, as a long time Fedora developer and sometimes
> > leader, is not enjoying using Fedora any more. Every update run can
>
> What was our previous niche? That is what people seemed so hard to
> ever quantify beyond knowing "what it isn't". The people I know who
> are running Ubuntu now instead of RHL or Fedora are doing it because
> that distribution 'fills in the blanks' for them that RHL/Fedora never
> seemed to answer. It has a vision, it has a single voice where they
> feel it is needed. Fedora has never been that. (heck even RHL was
> never that as you couldn't get any of the RH developers to agree on
> much :)).
>
I think the RHL niche was:
1. reasonably current
actually from our tickets that was "always just behind." :).
2. updated to a new release every 6months
3. supported for security/errata for 3yrs
That long? It never seemed that long. From my recollection it was
until the next .2 release came out. So 4.2 was EOL'd shortly after
5.2, 5.2 shortly after 6.2, and 6.2 shortly after 7.2. [yes there was
a 7.3 but it wasn't supposed to be there :). ] This would give us
about 18 months per .2 release.
4. free
5. About 1/5th the size of Fedora. Not that being smaller is a bad
thing but it was always a bunch of work to figure out what new stuff
to pull in.
--
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines
4:08 a.m.
New subject: fedora mission (was Re: systemd and changes)
On 08/30/2010 07:22 PM, Stephen John Smoogen wrote:
On Mon, Aug 30, 2010 at 10:03, Jesse Keating
<jkeating(a)redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 08/28/2010 09:25 PM, Kevin Kofler wrote:
>> Jesse Keating wrote:
>>> The cynic in me would expect that the people who want something different
>>> than the fire hose we have now are silently leaving, and those that are
>>> left are going to say they like the deluge of updates.
>>
>> You say that as if it were a negative thing.
>
> To me it is. It's you and people like you that want to shove a ton of
> updates down the throats of our stable release users (including changes
> that alter behavior and sonames etc...) that have ruined the Fedora I
> helped to build. I want my Fedora back, I don't want what you're creating.
The problem to quote a tv philosopher is:
The avalanche has already started, it is too late for the pebbles to vote.
The changes towards a distribution that attracts people who live in
the moment happened a while back, and has been building momentum for
quite some time. Trying to erect barriers now is not going to help but
make it so nothing exists afterwords. The things that can be done are:
A) get out of the way, B) go with the flow, or C) figure out what you
can build on top of it. [I am looking at option C]
The pressure to stabilize is a much needed-correction to the pressure
to innovate.
Consider what happens without any such back-pressure. Those who can
no longer stand the churn leave, with only the hard-core bleeding-
edgers remaining. The churn gets faster. Then, even some of those
who were the previous generation of bleeding-edgers can't cope, and
they leave. Left behind, are the *serious* hard core. Etc... This
is a classic case of unrestrained positive feedback, just like thermal
runaway.
In my view, this is exactly the situation we're in at the moment, but
some people are trying to apply a correction to prevent the distro
burning out. It is not too late.
Andrew.
2:09 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, 2010-08-30 at 09:03 -0700, Jesse Keating wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/28/2010 09:25 PM, Kevin Kofler wrote:
> Jesse Keating wrote:
>> The cynic in me would expect that the people who want something different
>> than the fire hose we have now are silently leaving, and those that are
>> left are going to say they like the deluge of updates.
>
> You say that as if it were a negative thing.
To me it is. It's you and people like you that want to shove a ton of
updates down the throats of our stable release users (including changes
that alter behavior and sonames etc...) that have ruined the Fedora I
helped to build. I want my Fedora back, I don't want what you're creating.
Jesse is absolutely right on this point.
Fedora is being ruined by this kind of behavior. You can have progress,
cutting edge, etc. without having to be unstable and unpredictable in
the process. It's called "rawhide" for a reason. It was always intended
to be the place to dump things, but not in "stable" releases. Instead,
we have people so opposed to a little sanity and so scared of 6 months
wait - like anything really matters in that small a timeframe in the
*real* world - that they want to cram things down the throats of the
users. That works fine if you're in college and have a lot of free time,
but some people like their computers to also work on a reasonably
predictable basis, which is not the ride that is Fedora today.
We've found our niche, but chasing away our previous niche (and
having
less users show up in our tracking mechanism for it) It's getting to
the point where me, as a long time Fedora developer and sometimes
leader, is not enjoying using Fedora any more. Every update run can
break things, and often does.
As I've said, on systems not directly connected I just don't bother
doing updates ever. I suspect before too long some effort will get
formed to do a more stable version of Fedora (no, this isn't any
reference to Enterprise stuff - that's entirely different) and at that
point I give it not a whole lot of time before people gravitate toward
that, or there is some fragmentation, or something a lot worse.
Every update takes for ever because there
are so many updates. Too many to review each one and see what it does,
and how to maybe test it and provide feedback. Updates runs just get
pushed off longer and longer so that I have a block of time to A) apply
the damn things, and B) spend a few hours recovering from any sort of
fallout in my workflow. If I don't enjoy using the product I'm
creating, that doesn't bode well.
Again, I think everything you've said is well said, totally appropriate,
and I'm grateful that you spoke up and said it. Because you are
certainly far from being alone.
Jon.
2:44 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, 30 Aug 2010 15:09:06 -0400
Jon Masters <jonathan(a)jonmasters.org> wrote:
> Every update takes for ever because there
> are so many updates. Too many to review each one and see what it
> does, and how to maybe test it and provide feedback. Updates runs
> just get pushed off longer and longer so that I have a block of
> time to A) apply the damn things, and B) spend a few hours
> recovering from any sort of fallout in my workflow. If I don't
> enjoy using the product I'm creating, that doesn't bode well.
Again, I think everything you've said is well said, totally
appropriate, and I'm grateful that you spoke up and said it. Because
you are certainly far from being alone.
I have to say the same, even as a developer, I can't have to stop every
day to reboot or fix my machine while I am working on my own project.
That's why I sometimes culpably delay to update my machine, until some
scary security vulnerability appears (and then I have to do the *HUGE*
update that follows).
I am just glad I have a very fast connection at home right now, but if
I had even a normal DSL like I used in my previous life (1/2 Mbit/s
dload) I would have to seriously consider using a different distro for
machines that are not throw-away.
I *love* the cutting edge of Fedora when a *new* release comes out. But
the amount of churn in *stable* releases, (ie gratuitous updates that
do not really fix bugs just add new stuff (and often new bugs)) is a bit
unsettling for people that actually use their computer to do "work", as
opposed to just try out new stuff every 2 days.
Why people that love raw bleeding cutting edge can't simply use
rawhide ? (Or pick the packages they like to test from there ?)
Simo.
--
Simo Sorce * Red Hat, Inc * New York
2:56 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, Aug 30, 2010 at 03:09:06PM -0400, Jon Masters wrote:
Fedora is being ruined by this kind of behavior. You can have
progress,
cutting edge, etc. without having to be unstable and unpredictable in
the process.
A lot has been done in the last couple of months in that direction.
Proventesters and no more updates directly to stable are there now,
repos.fpo is gaining traction and AutoQA is hopefully coming real
soon now too.
Compared to the F7 - F13 timeframe these are already quite intrusive
changes.
How about giving it a release to see how those changes work out before
pushing for even more radical changes?
Also - and this is a question that I have asked myself and others a
couple of times - if you could implement Fedora the way you want: What
unique selling points are left for Fedora? "Fedora is Ubuntu with rpm"
sounds about as bad as "Fedora is broken most of the time" (not that I
feel it is).
As I've said, on systems not directly connected I just don't
bother
doing updates ever. I suspect before too long some effort will get
formed to do a more stable version of Fedora
Don't we already have that in F n-1?
--
sven === jabber/xmpp: sven(a)lankes.net
3:03 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, 2010-08-30 at 21:56 +0200, Sven Lankes wrote:
> As I've said, on systems not directly connected I just
don't bother
> doing updates ever. I suspect before too long some effort will get
> formed to do a more stable version of Fedora
Don't we already have that in F n-1?
Even that isn't left alone. And it's only supported for 6 months,
assuming one does choose to apply updates. The thing is, I want to keep
up with what's happening, both for personal interest, and for other
reasons, but as it is, the churn is plain nuts. Sure, I can "give it a
release", but I have been "giving it a release" for some time now.
Jon.
3:12 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, Aug 30, 2010 at 21:56:17 +0200,
Sven Lankes <sven(a)lank.es> wrote:
Also - and this is a question that I have asked myself and others a
couple of times - if you could implement Fedora the way you want: What
unique selling points are left for Fedora? "Fedora is Ubuntu with rpm"
sounds about as bad as "Fedora is broken most of the time" (not that I
feel it is).
Freedom
Lots of packages
Easy to contribute to
Up to date at release
New technologies (e.g. selinux, systemd, pulseaudio)
Just works (except for patented media codecs while waiting for sane patent laws)
4:01 p.m.
New subject: fedora mission (was Re: systemd and changes)
Once upon a time, Sven Lankes <sven(a)lank.es> said:
Also - and this is a question that I have asked myself and others a
couple of times - if you could implement Fedora the way you want: What
unique selling points are left for Fedora? "Fedora is Ubuntu with rpm"
sounds about as bad as "Fedora is broken most of the time" (not that I
feel it is).
I guess I've never been concerned about "unique selling points". Why
should it be "Fedora is Ubuntu with RPM", instead of "Ubuntu is Fedora
with DEB"? IIRC Fedora came first (and certainly RHL came before
Ubuntu, although Debian was little before RHL).
I like Fedora because it is free and Free. The development is handled
by a community, not just a single company. Also, RHEL is developed out
of Fedora, and I use RHEL on my servers at work, so Fedora is a bit like
a window into the future of RHEL.
I first moved from Slackware to RHL (3.0.3 in 1996!) after having built
a system of my own from the ground up (compiling everything from source
manually, keeping notes along the way). I appreciated how RPM worked
immediately after that experience. When I found bugs and emailed them
to Red Hat, somebody fixed them. Once RH BZ was set up, I opened a
bunch of early bugs (5 of the first 60, several including patches), and
generally got a good response. I worked with the RHL Betas for a few
years, until this crazy experiment of a community distribution called
Fedora came along.
I like the release schedule of Fedora, but I don't like the idea of each
release continuing to be a rolling update target. I don't really
understand why about six months (or less if you didn't install on
release day) is such a horrible wait to make big changes to the system.
If the up-to-six month wait is the problem, I'd rather see more releases
(e.g. "Fedora 14.1: Now with GNOME3!") with more targeted/focused
changes. That's probably not practical with the available manpower
however.
Why do we need to be concerned about being similar to or different from
Ubuntu?
--
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.
4:04 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, 2010-08-30 at 16:01 -0500, Chris Adams wrote:
I like the release schedule of Fedora, but I don't like the idea
of each
release continuing to be a rolling update target. I don't really
understand why about six months (or less if you didn't install on
release day) is such a horrible wait to make big changes to the system.
Agreed.
Why do we need to be concerned about being similar to or different from
Ubuntu?
Agreed.
-sv
4:18 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, Aug 30, 2010 at 04:01:25PM -0500, Chris Adams wrote:
I guess I've never been concerned about "unique selling
points". Why
should it be "Fedora is Ubuntu with RPM", instead of "Ubuntu is Fedora
with DEB"? IIRC Fedora came first (and certainly RHL came before
Ubuntu, although Debian was little before RHL).
That doesn't matter much. Ubuntu is where the users are.
Why do we need to be concerned about being similar to or different
from
Ubuntu?
For me that question is interesting because selling Fedora is what I do
at FLOSS-events as a Fedora ambassador and 'what is the difference to
ubuntu' is the number one question.
This should certainly not affect the direction we're taking with Fedora
as it's marketing and marketing needs to market whatever is there - but
I still find the question interesting.
--
sven === jabber/xmpp: sven(a)lankes.net
4:33 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, Aug 30, 2010 at 5:01 PM, Chris Adams <cmadams(a)hiwaay.net> wrote:
Once upon a time, Sven Lankes <sven(a)lank.es> said:
> Also - and this is a question that I have asked myself and others a
> couple of times - if you could implement Fedora the way you want: What
> unique selling points are left for Fedora? "Fedora is Ubuntu with rpm"
> sounds about as bad as "Fedora is broken most of the time" (not that I
> feel it is).
I guess I've never been concerned about "unique selling points". Why
should it be "Fedora is Ubuntu with RPM", instead of "Ubuntu is Fedora
with DEB"? IIRC Fedora came first (and certainly RHL came before
Ubuntu, although Debian was little before RHL).
Because people seem to identify Ubuntu with what is being described.
Why do we need to be concerned about being similar to or different
from
Ubuntu?
Well for one, if there is nothing different mission wise between
Fedora and Ubuntu, but Ubuntu gets more attention from desktop users,
then people might as well just all use Ubuntu.
I'm not sure that there is room for a "Coke vs. Pepsi" in Linux
distros. A "fruit juice vs. soda" seems more useful.
--
Fedora 13
(www.pembo13.com)
9:45 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, Aug 30, 2010 at 17:33:33 -0400,
Arthur Pemberton <pemboa(a)gmail.com> wrote:
Well for one, if there is nothing different mission wise between
Fedora and Ubuntu, but Ubuntu gets more attention from desktop users,
then people might as well just all use Ubuntu.
Despite being derived from Debian, the Ubuntu project doesn't seem to consider
freedom as important as the Fedora project does.
12:23 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, 2010-08-30 at 15:09 -0400, Jon Masters wrote:
Instead,
we have people so opposed to a little sanity and so scared of 6 months
wait - like anything really matters in that small a timeframe in the
*real* world
Wow, and everyone gets categorical again. You can disagree with people,
but this is a bit different. Yes, amazingly, things do matter on a six
month timeframe in the 'real world' (whatever that is). Example - I got
a laptop. The graphics on it don't work, except for vesa, which is very
slow (can't play video, and yes, that matters to me) and doesn't run at
native resolution (yes, that matters to me). If Ben doesn't land a fix
for this in Fedora 13's kernel I have to either wait six months to be
able to use my laptop, upgrade it to F14 (which kind of obviates the
point of having a stable release), or run the proprietary driver. None
of these feel like great options.
Just saying, yes, sometimes, it really is reasonable to not want to wait
six months for something to get fixed, and please try to at least
vaguely consider the possibility that your theoretical principles may
not always apply perfectly. Maybe we don't want Fedora to be Rawhide,
but maybe we also don't want it to be a distro where nothing ever gets
updated either...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12:33 a.m.
New subject: fedora mission (was Re: systemd and changes)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/30/10 10:23 PM, Adam Williamson wrote:
Wow, and everyone gets categorical again. You can disagree with
people,
but this is a bit different. Yes, amazingly, things do matter on a six
month timeframe in the 'real world' (whatever that is). Example - I got
a laptop. The graphics on it don't work, except for vesa, which is very
slow (can't play video, and yes, that matters to me) and doesn't run at
native resolution (yes, that matters to me). If Ben doesn't land a fix
for this in Fedora 13's kernel I have to either wait six months to be
able to use my laptop, upgrade it to F14 (which kind of obviates the
point of having a stable release), or run the proprietary driver. None
of these feel like great options.
Just saying, yes, sometimes, it really is reasonable to not want to wait
six months for something to get fixed, and please try to at least
vaguely consider the possibility that your theoretical principles may
not always apply perfectly. Maybe we don't want Fedora to be Rawhide,
but maybe we also don't want it to be a distro where nothing ever gets
updated either...
Where do you see somebody proposing that no updates be issued? Where do
you see somebody proposing a setup where fixing a graphics card can't be
done in the stable release kernel? You've built up a nice strawman that
you've lovingly kicked down.
I don't think anybody wants to prevent fixing a graphics chip issue in a
kernel update. What we wouldn't like to see is dragging in a brand new
xorg major release and kernel major release and dri major release in
order to make that happen. Do you see a difference there?
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkx8lCQACgkQ4v2HLvE71NWjoACeOjpdbr4UjtYM6i903macm69B
LAQAoMYGhtKpFAf+wGXlw9YylFATidh6
=YOwp
-----END PGP SIGNATURE-----
12:47 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, 2010-08-30 at 22:33 -0700, Jesse Keating wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/30/10 10:23 PM, Adam Williamson wrote:
> Wow, and everyone gets categorical again. You can disagree with people,
> but this is a bit different. Yes, amazingly, things do matter on a six
> month timeframe in the 'real world' (whatever that is). Example - I got
> a laptop. The graphics on it don't work, except for vesa, which is very
> slow (can't play video, and yes, that matters to me) and doesn't run at
> native resolution (yes, that matters to me). If Ben doesn't land a fix
> for this in Fedora 13's kernel I have to either wait six months to be
> able to use my laptop, upgrade it to F14 (which kind of obviates the
> point of having a stable release), or run the proprietary driver. None
> of these feel like great options.
>
> Just saying, yes, sometimes, it really is reasonable to not want to wait
> six months for something to get fixed, and please try to at least
> vaguely consider the possibility that your theoretical principles may
> not always apply perfectly. Maybe we don't want Fedora to be Rawhide,
> but maybe we also don't want it to be a distro where nothing ever gets
> updated either...
Where do you see somebody proposing that no updates be issued? Where do
you see somebody proposing a setup where fixing a graphics card can't be
done in the stable release kernel? You've built up a nice strawman that
you've lovingly kicked down.
It's implicit in what Jon said; I was pointing out that he was, possibly
inadvertently, suggesting a principle that was far too strict. I'm not
saying anyone seriously proposed not issuing updates, but the arguments
being used in support of slowing down updates are starting to sound
extremely categorical and in the 'you're just wrong and no-one wants
that' line. That's what I don't like.
Jon's quote, exactly as I quoted it in my email (you removed it):
"Instead, we have people so opposed to a little sanity and so scared of
6 months wait - like anything really matters in that small a timeframe
in the *real* world"
My point is, yes, a 6 months wait *does* matter in the real world,
please don't use that argument, or qualify it properly.
I don't think anybody wants to prevent fixing a graphics chip
issue in a
kernel update. What we wouldn't like to see is dragging in a brand new
xorg major release and kernel major release and dri major release in
order to make that happen. Do you see a difference there?
Of course, now you're the one building straw men. You know I see a
difference there, get off the rhetorical horse. I also know that there's
a continuum, not nice clean distinctions like that every time. What if
the patch is quite an invasive one and we don't want to backport it?
Distros with conservative update policies can and do reject updates that
fix bugs, and only fix bugs, because the changes are too big; Ubuntu and
RHEL have both done this in multiple cases.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
7:54 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Mon, 2010-08-30 at 22:47 -0700, Adam Williamson wrote:
On Mon, 2010-08-30 at 22:33 -0700, Jesse Keating wrote:
> Where do you see somebody proposing that no updates be issued?
Where do
> you see somebody proposing a setup where fixing a graphics card can't be
> done in the stable release kernel? You've built up a nice strawman that
> you've lovingly kicked down.
It's implicit in what Jon said; I was pointing out that he was, possibly
inadvertently, suggesting a principle that was far too strict.
IMO if hardware enablement can be done at no risk, then ok. But as Jesse
said, rebasing some major component to achieve that would not be ok. I
don't really want to pick on Xorg since it usually works well. But, in
the theoretical sense my own opinion is that it's better to have a few
people wait six months for stable support for some new hardware or have
to install some additional - separate - packages for that, if there's a
risk to the existing users. Existing user experience should come first
because they are already running Fedora F-X, not contemplating it.
As Jesse also said, how we define breakage varies a lot, too. For
example, the latest version of evolution out of the box on F13 treats
"Mark Messages as Read" differently from F12. It now wants you to
confirm every time you do this, not just on folders that have
sub-folders, or when touching the top-level Inbox. Had that behavior
changed before the upgrade, I would have regarded it as a form of
"breakage" because it affects how one reads mail vs. the day before.
Sure, it's not package breakage, but it is a change in behavior. You
could say that's not breakage, but it would seem to fall afoul of the
existing policy described in the User_base documents on the wiki.
Jon.
10:30 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Tue, 2010-08-31 at 08:54 -0400, Jon Masters wrote:
On Mon, 2010-08-30 at 22:47 -0700, Adam Williamson wrote:
> On Mon, 2010-08-30 at 22:33 -0700, Jesse Keating wrote:
> > Where do you see somebody proposing that no updates be issued? Where do
> > you see somebody proposing a setup where fixing a graphics card can't be
> > done in the stable release kernel? You've built up a nice strawman that
> > you've lovingly kicked down.
>
> It's implicit in what Jon said; I was pointing out that he was, possibly
> inadvertently, suggesting a principle that was far too strict.
IMO if hardware enablement can be done at no risk, then ok. But as Jesse
I wasn't really talking about the topic of the argument, it was more of
a meta-post on how the argument is being conducted. There's already
clearly (at least) two schools of thought and compromising between them
would be very difficult. If either or both schools start supporting
their arguments with categorical statements like "as if waiting six
months really mattered in the real world", it's only going to make it
harder. In a discussion like this it's only possible to come to a
vaguely workable compromise without everyone hating each other if you at
least acknowledge that the other point of view has some validity too,
even if it's not the one you share.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12:30 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Fri, 2010-08-27 at 18:08 -0400, Jon Masters wrote:
Again, I feel it is necessary to have a survey of Fedora users.
That's users you've already got. It might make the users you already
have happier, sure, and that's a fine thing to do. Iif you want to grow,
though, you may be limiting yourself by only considering responses from
people you've already "won," if that makes sense. E.g., sure, I can make
a better grilled steak that I already serve, and that'll make the
customers I have happier, but if I want to expand my customer base I
might want to consider at least a couple of veggie-friendly dishes for
the menu.
If you define a desired target, then you know who to survey that you
haven't even gotten as a user yet and understand better how to win them
over and expand your userbase...
But I don't think we even have agreement amongst contributors that we
want to expand the userbase (which is troubling to me.)
~m
6:04 p.m.
New subject: fedora mission (was Re: systemd and changes)
On Fri, 27 Aug 2010 17:54:37 -0400
Matthias Clasen <mclasen(a)redhat.com> wrote:
Your attack is misguided, Jon. It is very much our responsibility to
inform users that the software they install or use is no longer actively
supported.
Inform, sure. But Kevin proposed an installer that would "just refuse
to install". Jon had every right to be outraged, IMHO.
-- Pete
2:57 a.m.
New subject: fedora mission (was Re: systemd and changes)
aggressively
I do not agree this strategy is wise or even the correct way. Certain
Fedora versions dropped hardware support. We can't dictate people wht
they can or can not do. I still know people who run old redhat
releases (5.x) as there was m68k support.
Gerard Braad
--
Gerard Braad — 吉拉德
Project-lead Fedora-MIPS
http://fedoraproject.org/wiki/User:gbraad
1:41 p.m.
New subject: fedora mission (was Re: systemd and changes)
Gerard Braad (gbraad(a)fedoraproject.org) said:
> aggressively
I do not agree this strategy is wise or even the correct way. Certain
Fedora versions dropped hardware support. We can't dictate people wht
they can or can not do. I still know people who run old redhat
releases (5.x) as there was m68k support.
<archaeology hat on>
Red Hat Linux as released on the FTP site/boxed sets never directly supported
m68k. There was a different product called 'Linux Rough Cuts', which were
community
ports to various architectures - the example I know of included PPC, m68k,
MIPS, and UltraSparc (before UltraPenguin was merged in.)
<archaeology hat off>
Bill
12:05 a.m.
New subject: fedora mission (was Re: systemd and changes)
On Sun, 2010-08-29 at 15:57 +0800, Gerard Braad wrote:
> aggressively
I do not agree this strategy is wise or even the correct way. Certain
Fedora versions dropped hardware support. We can't dictate people wht
they can or can not do.
Yes, we can. In fact that's more or less what a distribution *does*. The
function of a distribution is essentially to take away certain decisions
from users in the interests of simplifying their experience. If you want
ultimate choice, you build your system from scratch. Distributions take
away the pain involved in that by doing lots of the work for you, which
inevitably involves making choices about how those things are done,
which inevitably means removing the ability for the users to choose how
those things are done, which is indeed 'dictat[ing] what they can or can
not do'. That's our entire function.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
7:23 p.m.
New subject: fedora mission (was Re: systemd and changes)
Matthew Miller wrote:
We do not have this luxury. If we "push" something broken
to the people,
the people will _completely understandably_ throw up their hands and say
"huh, guess that sucked" and try another distribution. Or stay on their
other distribution -- let Fedora be the playground for developers, and
serious distributions for real users can pick out the parts that worked
afterward.
So what? Isn't that part of what Fedora is about? There must be SOMEBODY
taking the risks or things will never move. One of the main goals of Fedora
is to be that somebody, even if it means other distros which parasite our
stabilization efforts will be able to provide a more reliable user
experience in some cases (but at the cost of shipping old software which is
often missing features the users need or having issues already resolved in
the latest upstream code, because those distributions, by relying on fast-
moving distros such as Fedora to test the stuff, have to wait for us to test
them out for them first). And to be blunt, why do you think Red Hat has
started and keeps funding Fedora? Is it not because it is a "playground for
developers" from which RHEL "can pick out the parts that worked
afterward"?
Of course there's a limit to what we can do while keeping our distribution
usable and desirable for people. But we have to take risks, or we will not
be able to ship the latest and greatest features our users choose us for!
And the whole GNU/Linux ecosystem would not work without distributions
taking those risks.
At the end, I think things always played out well, even Fedora 9 turned out
not to be the major disaster people were calling it out to be (and KDE 4,
starting at 4.0.3 and gradually upgraded to improved versions up to 4.2.4 in
updates, was not the only risky major change in it! There was also Upstart
(which for some reason didn't cause as much scandal as systemd now is, maybe
because all its improvements over SysVInit weren't actually used), a new
GCC, a new X.Org X11 drawing complaints from proprietary driver users etc.).
Kevin Kofler
9:32 p.m.
New subject: systemd and changes
2010/8/24 Lennart Poettering <mzerqung(a)0pointer.de>:
On Tue, 24.08.10 12:56, Mike McGrath (mmcgrath(a)redhat.com) wrote:
>
> On Tue, 24 Aug 2010, Adam Williamson wrote:
>
> > On Tue, 2010-08-24 at 12:10 -0500, Mike McGrath wrote:
> >
> > > People like you and me would opt-in. (well I would on some hosts) because
> > > we know what we're doing. Expert eyes get a look at it before it's
forced
> > > onto our users, who are already leaving in leaps and bounds.
> >
> > Again, Pulse/PolypAudio seems to suggest that this is not the case. Why
> > didn't expert eyes who knew what they were doing migrate to that before
> > it become default? Or, alternatively, if the expert eyes which knew what
> > they were doing did migrate, why didn't they catch the bugs that others
> > encountered when it became default?
> >
>
> If us experts aren't even willing to opt-in in modest enough numbers to
> test it, why on earth would we force it on people at all?
Well, here's are two simple facts for you:
1) if things are not used they tend to have bugs
2) if things have bugs they are not used
i am pretty sure that matches with most peoples opinion. infact thats
why i am personally a rawhide user where i expect to have the newest
things first (though it would be nice of the maintainer did do some
basic tests himself to ensure atleast a working system for him
personally before he pushed it into rawhide as default) to be able to
really test it before i have to support people in #fedora with
actually less technical expertize.
change management is usually not about things that go wrong but about
things that can go wrong. aka proper testing and planning before
having "live/production" systems.
it really wouldnt have hurt to test out the "complete system" means
also all the raised potential issues on the checklist you do not feel
responsible for as systemd maintainer. while everything might look
shiny from one single point of view, there are definitely more povs.
and while you personally dont care about some technologies we have
like e.g. iscsi and alot others that were named... they might be
critical to others. what i miss a bit personally is simply seeing
potential implications for the users that are not capable of switching
back to something else because they lack the expertize. or do not
understand some wierd workarounds published somewhere to get stuff
working because there wont be many how tos when the new system will go
live. maybe trying to think from the perspective of a potential user
when it is about a release would be a good approach. i am really
curious what all turns out to be broken in the end... and no matter
which systems fault it is. if it is coming up because of a too quick
change i will definitely blame the process and the lack of
testing/time to get things straight. That said, thanks for your effort
in trying to improve a system.
Acknowledging this: if you want to innovate you have no other option
than pushing things to the people, and then fix what breaks.
but pushing them to end users vs experienced people first and give
them enough time to report their problems is the key difference.
And if you never are willing to pass something to the users before it is
100% stable and tested, then it will never be 100% stable and tested,
and you simply stop to innovate. But that wouldn't be Fedora anymore
then.
software is never 100% done or bugfree. but it appears to me you have
a rather narrow view of only focussing your single system. but that
system has to properly interact with other systems... no matter which
side is to blame.
And I think so far things went really well with systemd, even though
this discussion might create the impression it didn't.
no it doesent at all. it does create the impression that some people
would rather have a better change management for such critical
components than what it currently appears to be. like stated above...
change management is not about what happens or about gut feeling or
confidence... it is about risk management.
in reality every non technical user wont care if it is systemd or
component xyz which is to blame. if it doesent work it doesent work...
but especially if it worked before they wont see any improvement just
a regression. if a simple text editor fails it is one thing. if a
kernel fails you can still boot an old one (after you figure out how
to display the grub menu...) but if an init system fails it doesent
boot and the conclusion would in most cases probably be that you just
install something else if you dont have enough skills to actually get
it to work somehow or analyze the problem.
Rudolf - also working for Red Hat, Inc.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
1:46 p.m.
New subject: systemd and changes
On Tue, Aug 24, 2010 at 12:56:43PM -0500, Mike McGrath wrote:
On Tue, 24 Aug 2010, Adam Williamson wrote:
> Again, Pulse/PolypAudio seems to suggest that this is not the
case. Why
> didn't expert eyes who knew what they were doing migrate to that before
> it become default? Or, alternatively, if the expert eyes which knew what
> they were doing did migrate, why didn't they catch the bugs that others
> encountered when it became default?
>
If us experts aren't even willing to opt-in in modest enough numbers to
test it, why on earth would we force it on people at all?
If something is targeted at non-expert users, then it is understandable
that experts do not want to test it. Or it might not even possible,
because the workflow is completely different, e.g. in F12 pulseaudio
still interfers with jack afaik, which probably mostly hits intermediate
users that just want audio to work easily with all all applications by
default.
Regards
Till
12:59 p.m.
New subject: systemd and changes
On Tue, 24 Aug 2010 10:19:38 -0700
Adam Williamson <awilliam(a)redhat.com> wrote:
On Tue, 2010-08-24 at 12:10 -0500, Mike McGrath wrote:
> People like you and me would opt-in. (well I would on some hosts)
> because we know what we're doing. Expert eyes get a look at it
> before it's forced onto our users, who are already leaving in leaps
> and bounds.
Again, Pulse/PolypAudio seems to suggest that this is not the case.
Why didn't expert eyes who knew what they were doing migrate to that
before it become default? Or, alternatively, if the expert eyes which
knew what they were doing did migrate, why didn't they catch the bugs
that others encountered when it became default?
Sorry Adam,
I have to say that I tried pulseaudio hard all the way from when it was
optionl until it became mandatory. It took *many* releases before it
became *usable* and that generally on on the "right" hardware.
In most cases issues were related to poor testing on disparate HW, but
my main grudge is that when issues where reported in most cases the
answer was something to the tune: "the alsa driver suck it is no a
pulseaudio issue".
Answers like that are BS if you ask me, as applications that didn't
work with pulseaudio generally worked just fine with pure alsa and the
supposedly broken driver. So the expert did what they could, ie,
uninstall pulseaudio and try again 6 months later on the next Fedora
update.
I still occasionally find issues with pulseaudio, but after a few years
it looks it is stable enough (at least on the HW I have) although not
completely bug free.
As for systemd, I hope that, given it does not directly relate/depends
on strange HW, we can have a much easier life.
Although I have to voice the same worries as others about the attitude
of trying to make things "better" for some very personal point of view
of better, like the decision of changing completely the meaning of
noauto. I hope these were isolated episodes and we nailed them all, but
change for change sake seem a big temptation within the systemd
development team and this is somethign that legitimately causes worry
IMO.
That said, on the VM I tried F14 upgrading straight from F12 all seem
fine so far, although the output of systemctl is something I still need
to get used to (I wonder what "maintenance" means referred to the
status of a service) ...
Simo.
--
Simo Sorce * Red Hat, Inc * New York
3:13 p.m.
New subject: systemd and changes
On Tue, 24.08.10 13:59, Simo Sorce (ssorce(a)redhat.com) wrote:
On Tue, 24 Aug 2010 10:19:38 -0700
Adam Williamson <awilliam(a)redhat.com> wrote:
> On Tue, 2010-08-24 at 12:10 -0500, Mike McGrath wrote:
>
> > People like you and me would opt-in. (well I would on some hosts)
> > because we know what we're doing. Expert eyes get a look at it
> > before it's forced onto our users, who are already leaving in leaps
> > and bounds.
>
> Again, Pulse/PolypAudio seems to suggest that this is not the case.
> Why didn't expert eyes who knew what they were doing migrate to that
> before it become default? Or, alternatively, if the expert eyes which
> knew what they were doing did migrate, why didn't they catch the bugs
> that others encountered when it became default?
Sorry Adam,
I have to say that I tried pulseaudio hard all the way from when it was
optionl until it became mandatory. It took *many* releases before it
became *usable* and that generally on on the "right" hardware.
In most cases issues were related to poor testing on disparate HW, but
my main grudge is that when issues where reported in most cases the
answer was something to the tune: "the alsa driver suck it is no a
pulseaudio issue".
Answers like that are BS if you ask me, as applications that didn't
work with pulseaudio generally worked just fine with pure alsa and the
supposedly broken driver. So the expert did what they could, ie,
uninstall pulseaudio and try again 6 months later on the next Fedora
update.
Well, a wise man once said:
"Audio hackers unfortunately don't grow on trees. In my counting,
there are 3 people paid in the whole industry who work on general
purpose audio infrastructure of Linux. Two of them are basically busy
with keeping the HDA driver up-to-date, if I am correctly
informed. The third one is me."
http://lwn.net/Articles/398551/
This is all I have to say about criticism on how we handled this:
http://lwn.net/Articles/398552/
That said, on the VM I tried F14 upgrading straight from F12 all
seem
fine so far, although the output of systemctl is something I still need
to get used to (I wonder what "maintenance" means referred to the
status of a service) ...
That means something isn't right with the service. For more details see:
http://0pointer.de/blog/projects/systemd-for-admins-1.html
The term was stolen from Solaris SMF btw.
Lennart
--
Lennart Poettering - Red Hat, Inc.
4:35 p.m.
New subject: systemd and changes
On Tue, Aug 24, 2010 at 10:13:26PM +0200, Lennart Poettering wrote:
> That said, on the VM I tried F14 upgrading straight from F12 all
seem
> fine so far, although the output of systemctl is something I still need
> to get used to (I wonder what "maintenance" means referred to the
> status of a service) ...
That means something isn't right with the service. For more details see:
http://0pointer.de/blog/projects/systemd-for-admins-1.html
The term was stolen from Solaris SMF btw.
How about "broken"? Shorter, more straightforward, and avoids the
implication that the service was intentionally taken down for maintenance
(my first reaction both here and on Solaris).
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
4:52 p.m.
New subject: systemd and changes
On Tue, 24.08.10 17:35, Matthew Miller (mattdm(a)mattdm.org) wrote:
On Tue, Aug 24, 2010 at 10:13:26PM +0200, Lennart Poettering wrote:
> > That said, on the VM I tried F14 upgrading straight from F12 all seem
> > fine so far, although the output of systemctl is something I still need
> > to get used to (I wonder what "maintenance" means referred to the
> > status of a service) ...
> That means something isn't right with the service. For more details see:
> http://0pointer.de/blog/projects/systemd-for-admins-1.html
> The term was stolen from Solaris SMF btw.
How about "broken"? Shorter, more straightforward, and avoids the
implication that the service was intentionally taken down for maintenance
(my first reaction both here and on Solaris).
Well, I cannot make everybody happy.
Some folks complain if we make up new words, if equivalent words are
already established.
Other folks complain if we reuse existing words, because they like
others better.
Lennart
--
Lennart Poettering - Red Hat, Inc.
6:06 p.m.
New subject: systemd and changes
On Tue, Aug 24, 2010 at 11:52:55PM +0200, Lennart Poettering wrote:
> How about "broken"? Shorter, more straightforward, and
avoids the
> implication that the service was intentionally taken down for maintenance
> (my first reaction both here and on Solaris).
Well, I cannot make everybody happy.
Some folks complain if we make up new words, if equivalent words are
already established.
Other folks complain if we reuse existing words, because they like
others better.
There's a clear difference in the cases -- it's better if you use existing
terminology from what you're replacing, but if you're borrowing from other
related systems, some thought should be put into it. Solaris probably picked
that term because it sounds fancy and vendor-y. That doesn't make it
automatically the best choice.
I don't think this is an important change, in the sense that I've noted
others as important. But, like changing "isolate" to "switch-to", it
improves the user experience. With terms like "isolate" and
"maintenance",
systemd comes with quirky new terminology to learn. With "broken" when a
service is broken, it's self-explanatory. "Needs maintenance" would also
work, but it's too long.
So: I am not suggesting these things to harass you, or even because I want
you to make me happy. (In fact, I'm *already* happy.) I'm suggesting them
because I think they're improvements that will make systemd more pleasant to
use, which will in turn increase acceptance.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
11:02 p.m.
New subject: systemd and changes
On Tue, Aug 24, 2010 at 07:06:06PM -0400, Matthew Miller wrote:
I don't think this is an important change, in the sense that
I've noted
others as important. But, like changing "isolate" to "switch-to", it
improves the user experience. With terms like "isolate" and
"maintenance",
systemd comes with quirky new terminology to learn. With "broken" when a
service is broken, it's self-explanatory. "Needs maintenance" would also
work, but it's too long.
I *knew* I remembered something about SMF from your "rethinking pid 1" blog
post. There, you say:
However, in many ways it is overly complex and, let's say, a bit academic
with its excessive use of XML and new terminology for known things. It is
also closely bound to Solaris specific features such as the contract
system.
Yeahhh. So, that's what I'm sayin': let's avoid bringing in its
"academic"
complexity and terminology, in cases where we can just be straightforward.
:)
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
1:09 p.m.
New subject: systemd and changes
On Tue, 24.08.10 10:19, Adam Williamson (awilliam(a)redhat.com) wrote:
On Tue, 2010-08-24 at 12:10 -0500, Mike McGrath wrote:
> People like you and me would opt-in. (well I would on some hosts) because
> we know what we're doing. Expert eyes get a look at it before it's forced
> onto our users, who are already leaving in leaps and bounds.
Again, Pulse/PolypAudio seems to suggest that this is not the case. Why
didn't expert eyes who knew what they were doing migrate to that before
it become default? Or, alternatively, if the expert eyes which knew what
they were doing did migrate, why didn't they catch the bugs that others
encountered when it became default?
Note that PA is an audio stack for consumers. It's not for audio
technicians. Hence they won't try it. It's as simple as that.
Lennart
--
Lennart Poettering - Red Hat, Inc.
12:29 p.m.
New subject: systemd and changes
On Tue, 2010-08-24 at 12:10 -0500, Mike McGrath wrote:
People like you and me would opt-in. (well I would on some hosts)
because
we know what we're doing. Expert eyes get a look at it before it's forced
onto our users, who are already leaving in leaps and bounds.
Thanks Mike (and Eric), for saying what many of us are also thinking.
Jon.
2:42 p.m.
New subject: systemd and changes
On Tue, Aug 24, 2010 at 12:10:45PM -0500, Mike McGrath wrote:
People like you and me would opt-in. (well I would on some hosts)
because
we know what we're doing. Expert eyes get a look at it before it's forced
onto our users, who are already leaving in leaps and bounds.
Yes. It's worth mentioning that the only reason I got involved with testing
systemd is because I read the initial post and thought it seemed interesting
and cool. In other words, I *have* opted in.
And you're getting testing, and I'm finding bugs.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
12:18 p.m.
New subject: systemd and changes
On Tue, 2010-08-24 at 12:02 -0500, Eric Sandeen wrote:
> Well, ironically enough, Lennart's last big revolution
illustrates the
> problem with that. PulseAudio - previously PolypAudio, remember - was
> 'opt-in' for several releases; it was packaged in Fedora and many other
> major distributions, you could enable it just by installing it. It was
> used by approximately no-one. People just don't opt in to big bits of
> infrastructural change unless they have some very specific reason to do
> so; booting the system more or less works for most people, so why would
> they 'opt in' to a new init daemon?
If it's worth the revolution, wouldn't people choose to opt in?
If nobody ever opts in, perhaps it's not worth the revolution?
No, not really, for a couple of reasons. One, consider the sets of
people involved. systemd opens up interesting possibilities for
operating system creators (that's us) and possibly sysadmins. Neither of
those groups is very large, and certainly both pale in comparison to the
total number of people who will ultimately be *affected*, if only
passively, by the change (which includes both the above groups, plus all
other users).
Even for operating system creators and sysadmins, there's factors to
inhibit switching as long as it's just an optional alternative. We can't
build anything into Fedora that relies on systemd unless it's the
default, obviously. And sysadmins are generally fairly conservative
beasts (that's the point some of them are whaling on here on this list)
who prefer to change as little as possible about a working system.
I'd say it's generally true that, if you get people using Foobar 1.0,
then branch out and offer Foobar 1.x and Foobar 2.x where 1.x is just
maintenance for 1.0 and 2.x has all the shiny new features but some
adjustment shock, people will look at 2.x briefly, think 'ow, it's
different!' and just carry on using 1.x. If you take away 1.x and only
offer 2.x they will migrate to it, whine for a week about what's
different, then quickly forget about it and start realizing the changes
offer them something neat and useful.
Not saying it's a foregone conclusion that that's how it'll go with
systemd, but I think it's worth considering.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:14 p.m.
New subject: systemd and changes
On Tue, Aug 24, 2010 at 10:00:01AM -0700, Adam Williamson wrote:
Well, ironically enough, Lennart's last big revolution
illustrates the
problem with that. PulseAudio - previously PolypAudio, remember - was
'opt-in' for several releases; it was packaged in Fedora and many other
major distributions, you could enable it just by installing it. It was
used by approximately no-one. People just don't opt in to big bits of
Afaik there are only limited benefits using PulseAudio compared to the
previous situation. I just checked the German Wikipedia and the only
rarely practically used enhancement by me is to easily switch between by
two soundcards. But it also meant that a long time PulseAudio defaulted
to the wrong soundcard every now and then.
infrastructural change unless they have some very specific reason to
do
so; booting the system more or less works for most people, so why would
they 'opt in' to a new init daemon?
But systemd seems to provide a lot of new features, e.g. a much nice
syntax for the unit files compared to the ugly and non race condition
free sysv init scripts and the bootup should be faster.
Regards
Till
1:20 p.m.
New subject: systemd and changes
On Tue, 24.08.10 20:14, Till Maas (opensource(a)till.name) wrote:
On Tue, Aug 24, 2010 at 10:00:01AM -0700, Adam Williamson wrote:
> Well, ironically enough, Lennart's last big revolution illustrates the
> problem with that. PulseAudio - previously PolypAudio, remember - was
> 'opt-in' for several releases; it was packaged in Fedora and many other
> major distributions, you could enable it just by installing it. It was
> used by approximately no-one. People just don't opt in to big bits of
Afaik there are only limited benefits using PulseAudio compared to the
previous situation. I just checked the German Wikipedia and the only
rarely practically used enhancement by me is to easily switch between by
two soundcards. But it also meant that a long time PulseAudio defaulted
to the wrong soundcard every now and then.
> infrastructural change unless they have some very specific reason to do
> so; booting the system more or less works for most people, so why would
> they 'opt in' to a new init daemon?
But systemd seems to provide a lot of new features, e.g. a much nice
syntax for the unit files compared to the ugly and non race condition
free sysv init scripts and the bootup should be faster.
Well, for different people different things appear more important. From
that you should not imply that one thing is useless and the other
isn't.
Lennart
--
Lennart Poettering - Red Hat, Inc.
1:58 p.m.
New subject: systemd and changes
On Tue, Aug 24, 2010 at 08:20:16PM +0200, Lennart Poettering wrote:
Well, for different people different things appear more important.
From
that you should not imply that one thing is useless and the other
isn't.
I did not want to imply that PulseAudio is useless. I doubt that you
would have implemented it, if you did not have any use for it. Probably
a lot of people who bought their soundcard without considering to buy
one capable of hardware mixing will also benefit from it. But usually
these people work not that actively in a FOSS community.
Regards
Till
2:02 p.m.
New subject: systemd and changes
Till Maas (opensource(a)till.name) said:
I did not want to imply that PulseAudio is useless. I doubt that you
would have implemented it, if you did not have any use for it. Probably
a lot of people who bought their soundcard without considering to buy
one capable of hardware mixing will also benefit from it. But usually
these people work not that actively in a FOSS community.
I suspect the vast majority of people in F/OSS (including Fedora) don't
buy sound cards, period, any more.
Bill
2:20 p.m.
New subject: systemd and changes
On Tue, Aug 24, 2010 at 03:02:27PM -0400, Bill Nottingham wrote:
Till Maas (opensource(a)till.name) said:
> I did not want to imply that PulseAudio is useless. I doubt that you
> would have implemented it, if you did not have any use for it. Probably
> a lot of people who bought their soundcard without considering to buy
> one capable of hardware mixing will also benefit from it. But usually
> these people work not that actively in a FOSS community.
I suspect the vast majority of people in F/OSS (including Fedora) don't
buy sound cards, period, any more.
Hm, is this, because they already bought a working one in the past? Or
why is this? I did not buy a new sound card since 1998 or so, as well.
But this is only because all new mainboards I bought still supported
PCI, so I can still use it.
Regards
Till
2:26 p.m.
New subject: systemd and changes
On Tue, Aug 24, 2010 at 9:20 PM, Till Maas <opensource(a)till.name> wrote:
On Tue, Aug 24, 2010 at 03:02:27PM -0400, Bill Nottingham wrote:
> Till Maas (opensource(a)till.name) said:
> > I did not want to imply that PulseAudio is useless. I doubt that you
> > would have implemented it, if you did not have any use for it. Probably
> > a lot of people who bought their soundcard without considering to buy
> > one capable of hardware mixing will also benefit from it. But usually
> > these people work not that actively in a FOSS community.
>
> I suspect the vast majority of people in F/OSS (including Fedora) don't
> buy sound cards, period, any more.
Hm, is this, because they already bought a working one in the past? Or
why is this?
Because whatever is on the motherboard is good enough for most users.
2:58 p.m.
New subject: systemd and changes
On Tuesday, August 24, 2010 02:20:05 pm Till Maas wrote:
On Tue, Aug 24, 2010 at 03:02:27PM -0400, Bill Nottingham wrote:
> Till Maas (opensource(a)till.name) said:
> > I did not want to imply that PulseAudio is useless. I doubt that you
> > would have implemented it, if you did not have any use for it. Probably
> > a lot of people who bought their soundcard without considering to buy
> > one capable of hardware mixing will also benefit from it. But usually
> > these people work not that actively in a FOSS community.
>
> I suspect the vast majority of people in F/OSS (including Fedora) don't
> buy sound cards, period, any more.
Hm, is this, because they already bought a working one in the past? Or
why is this? I did not buy a new sound card since 1998 or so, as well.
But this is only because all new mainboards I bought still supported
PCI, so I can still use it.
Regards
Till
Ive not brought one in years, I jsut use whatever is onboard. I have no need
to but something highend for my needs.
Dennis
3:15 p.m.
New subject: systemd and changes
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/24/10 12:20 PM, Till Maas wrote:
On Tue, Aug 24, 2010 at 03:02:27PM -0400, Bill Nottingham wrote:
> Till Maas (opensource(a)till.name) said:
>> I did not want to imply that PulseAudio is useless. I doubt that you
>> would have implemented it, if you did not have any use for it. Probably
>> a lot of people who bought their soundcard without considering to buy
>> one capable of hardware mixing will also benefit from it. But usually
>> these people work not that actively in a FOSS community.
>
> I suspect the vast majority of people in F/OSS (including Fedora) don't
> buy sound cards, period, any more.
Hm, is this, because they already bought a working one in the past? Or
why is this? I did not buy a new sound card since 1998 or so, as well.
But this is only because all new mainboards I bought still supported
PCI, so I can still use it.
Regards
Till
Because generally whats on the mainboard (or in the laptop) works. If
it didn't work, the first reaction isn't "Oh I need to go buy a better
one" it's "why the heck can't linux work with this, is linux still a
piece of crap?". Replacing the soundcard in a laptop is even more tricky.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkx0KHcACgkQ4v2HLvE71NVwqwCgk4Tw3KMlN1ExVYZRYKxgVgQk
JJAAn0w3qnj2d6quHt9wVk4z+HbHoWzL
=VYTH
-----END PGP SIGNATURE-----
4:13 p.m.
New subject: systemd and changes
On Tue, Aug 24, 2010 at 01:15:54PM -0700, Jesse Keating wrote:
Because generally whats on the mainboard (or in the laptop) works.
If
it didn't work, the first reaction isn't "Oh I need to go buy a better
one" it's "why the heck can't linux work with this, is linux still a
piece of crap?". Replacing the soundcard in a laptop is even more tricky.
People thinking that "linux is still a piece of crap" are usually not
that active in the FOSS development. And the first lesson I learned when
I started using linux was to buy hardware after checking that it is
compatible with linux. And this is usually followed by everyone I know
personally who is using linux. Do you really buy new hardware without
checking its compatibility with linux first?
And do you use your soundcard in a way that you benefit from the
Pulseaudio features?
Regards
Till
4:33 p.m.
New subject: systemd and changes
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/24/10 2:13 PM, Till Maas wrote:
On Tue, Aug 24, 2010 at 01:15:54PM -0700, Jesse Keating wrote:
> Because generally whats on the mainboard (or in the laptop) works. If
> it didn't work, the first reaction isn't "Oh I need to go buy a better
> one" it's "why the heck can't linux work with this, is linux still
a
> piece of crap?". Replacing the soundcard in a laptop is even more tricky.
People thinking that "linux is still a piece of crap" are usually not
that active in the FOSS development. And the first lesson I learned when
I started using linux was to buy hardware after checking that it is
compatible with linux. And this is usually followed by everyone I know
personally who is using linux. Do you really buy new hardware without
checking its compatibility with linux first?
Video and wifi I check into. Other than that I expect everything else
to just work.
And do you use your soundcard in a way that you benefit from the
Pulseaudio features?
I can't really answer that because I don't really know what the features
are over what we had previously. I like for my applications to be able
to use my soundcard all at the same time, which I had issues with before
pulse, but that was on previous hardware as well.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkx0OqIACgkQ4v2HLvE71NWFCQCgwlZ7lgpHkHVU5rggkLokATw8
dAoAoIFC/IE4BFudJCqh+HWtNBN6RnQc
=uWJl
-----END PGP SIGNATURE-----
8:15 a.m.
New subject: systemd and changes
On Tue, Aug 24, 2010 at 02:33:25PM -0700, Jesse Keating wrote:
On 8/24/10 2:13 PM, Till Maas wrote:
> On Tue, Aug 24, 2010 at 01:15:54PM -0700, Jesse Keating wrote:
>
>> Because generally whats on the mainboard (or in the laptop) works. If
>> it didn't work, the first reaction isn't "Oh I need to go buy a
better
>> one" it's "why the heck can't linux work with this, is linux
still a
>> piece of crap?". Replacing the soundcard in a laptop is even more tricky.
>
> People thinking that "linux is still a piece of crap" are usually not
> that active in the FOSS development. And the first lesson I learned when
> I started using linux was to buy hardware after checking that it is
> compatible with linux. And this is usually followed by everyone I know
> personally who is using linux. Do you really buy new hardware without
> checking its compatibility with linux first?
Video and wifi I check into. Other than that I expect everything else
to just work.
Then I guess you are lucky or do not use certain type of hardware. I
would check every bit of hardware, e.g. the onboard NIC (I know in the
past there have been issues with atheros or nvidia(?) devices not
directly working), the webcam (if I wanted one), USB3 (afaik there are
already boards providing it). Even for hard disks it is somehow
necessary, because of 4k sector hard disks, which were not properly
supported when the hit the market. Then for notebooks there are special
keys, that might not work, a fingerprint sensor, integrated modem and
umts device. And then there are even normal keyboards with special keys
that might not work. And there are also peripherals like printers or
scanners. I even came across a USB-serial adapter that does not work
with linux. I am not sure, but I believe that using different CPU speeds
did not work directly in linux, too. And probably PAE, too. So any
component may not directly work in linux and this is something that one
has to expect using linux as long as hardware vendors do not provide
drivers for linux before they push the device on the market. And
soundcards tend to be a less stable component, since there are lots of
different chipsets.
> And do you use your soundcard in a way that you benefit from
the
> Pulseaudio features?
>
I can't really answer that because I don't really know what the features
are over what we had previously. I like for my applications to be able
to use my soundcard all at the same time, which I had issues with before
pulse, but that was on previous hardware as well.
This is the one feature that was available by buying a good soundcard.
And this does not mean a high-end one, but not a random one.
Regards
Till
6:55 p.m.
New subject: systemd and changes
Mike McGrath wrote:
The sad thing is that's such an easy fix by making brand new
features for
core components like this opt in, even if it's just for a single release.
FYI, while this looks like an option in this particular case, it's not
always possible, or doing it might require a lot more work and result in
something less integrated. (For example, we definitely did evaluate the
option of shipping both KDE 3 and 4 in parallel in F9, we discarded it due
to many practical issues, such as FHS compliance forcing file conflicts,
significantly higher maintenance work due to many packages getting doubled,
having to choose which KDE to integrate with in some packages (including
kdelibs3 itself, which we are patching in some places to integrate better
into a KDE 4 environment), needing a separate ~/.kde4 to safely support
coexistence of old and new versions of the same applications (and as a
result, existing KDE 3 user settings not getting migrated automatically)
etc.) There are some features which are easy to make optional and others
which are very hard to make optional. It all depends on the individual
feature.
Kevin kofler
9:37 a.m.
New subject: systemd and changes
On Mon, Aug 23, 2010 at 04:32:03PM -0400, Bill Nottingham wrote:
> So, I'm honestly asking: what are the odds that these few
things are the
> only improvements that cause a disruptive change to user interaction? I
> don't think it's unreasonable to wonder if there are other changes which
> fit this category.
My concern with this line of thinking is that you're asking us to quantify
the unknown unknown, and define a time period of testing which is
'long enough' for us to catch all the unknown unknowns. This seems
impractical, in as much as it doesn't give us any clear criteria to define
success with.
I guess what I'm getting at is that we need careful end-user release note
documentation at the alpha testing stage showing what's known by the
developers to have a new interface or semantics. Some of that is in the FAQ
(How do I change a runlevel? Turns out, by "isolating" a target which
defines that runlevel.) but some of it is not -- things like "noauto now
means auto" should have been in there. And a FAQ format is not exactly
what's needed.
Writing this isn't necessarily Lennart's job. But someone needs to do it,
and if it's there sooner rather than later, it'll be a better document and
issues with design and intent can be addressed.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
1:06 p.m.
New subject: systemd and changes
On Tue, 24.08.10 10:37, Matthew Miller (mattdm(a)mattdm.org) wrote:
On Mon, Aug 23, 2010 at 04:32:03PM -0400, Bill Nottingham wrote:
> > So, I'm honestly asking: what are the odds that these few things are the
> > only improvements that cause a disruptive change to user interaction? I
> > don't think it's unreasonable to wonder if there are other changes
which
> > fit this category.
> My concern with this line of thinking is that you're asking us to quantify
> the unknown unknown, and define a time period of testing which is
> 'long enough' for us to catch all the unknown unknowns. This seems
> impractical, in as much as it doesn't give us any clear criteria to define
> success with.
I guess what I'm getting at is that we need careful end-user release note
documentation at the alpha testing stage showing what's known by the
developers to have a new interface or semantics. Some of that is in the FAQ
(How do I change a runlevel? Turns out, by "isolating" a target which
defines that runlevel.) but some of it is not -- things like "noauto now
means auto" should have been in there. And a FAQ format is not exactly
what's needed.
Note that the telinit command is supported, too, by systemd. (as is
"init" as an alias for this).
Lennart
--
Lennart Poettering - Red Hat, Inc.
10:30 a.m.
On Mon, Aug 23, 2010 at 05:19:59PM +0200, Lennart Poettering wrote:
So, to turn this around. Do you think this behaviour is problematic?
Can
you make a good case for dropping this automatism? If so I'd be willing
to do so.
I guess sshfs fuse entries might be problematic, because they can require user
input for the password. Also I guess it will interfer with the "user" option,
because how should systemd be able to know which user should be allowed to
umount the filesystem again? And in general I think that the "noauto" option
should not just be ignored, e.g. in case a filesystem is umounted for safety
reasons to not easily modify it accidently.
Regards
Till
10:38 a.m.
Lennart Poettering (mzerqung(a)0pointer.de) said:
So, to turn this around. Do you think this behaviour is problematic?
Can
you make a good case for dropping this automatism? If so I'd be willing
to do so.
Yes, 'noauto' has defined semantics of 'not automatically mounted at
boot';
breaking that is bad.
Bill
10:52 a.m.
Lennart Poettering wrote:
So, to turn this around. Do you think this behaviour is problematic?
Can
you make a good case for dropping this automatism? If so I'd be willing
to do so.
That behavior might be fine, but don't add filesystems marked "noauto"
to the list of filesystems to be mounted automatically when reading fstab.
Here are my use cases and other rationale. I'm sure other people have more:
* fstab(5) documents the "noauto" option
* I manually mount network shares that aren't always available with the
"noauto" and "user" options
* Removable media that appear in fstab are usually marked noauto
* /boot doesn't always need to be mounted on every distro
* I mount large filesystems after the boot process finishes so fscking
doesn't pause booting at $dayjob
11:27 a.m.
On Mon, 23.08.10 10:52, Garrett Holmstrom (gholms(a)fedoraproject.org) wrote:
Lennart Poettering wrote:
> So, to turn this around. Do you think this behaviour is problematic? Can
> you make a good case for dropping this automatism? If so I'd be willing
> to do so.
That behavior might be fine, but don't add filesystems marked "noauto"
to the list of filesystems to be mounted automatically when reading fstab.
Here are my use cases and other rationale. I'm sure other people have more:
* fstab(5) documents the "noauto" option
Well, what it says is that noauto results in "the -a option will not
cause the filesystem to be mounted". And that's still the case. We
execute either the real "mount -a" (or actually something equivalent) at
bootup, and that by itself won't cause the fs to be mounted still.
* I manually mount network shares that aren't always available
with the
"noauto" and "user" options
That's not the issue here. systemd will never mount non-device mount points
automatically, unless listed as "auto".
* Removable media that appear in fstab are usually marked noauto
And?
* /boot doesn't always need to be mounted on every distro
And?
* I mount large filesystems after the boot process finishes so
fscking
doesn't pause booting at $dayjob
And?
Lennart
--
Lennart Poettering - Red Hat, Inc.
11:38 a.m.
On Mon, 23 Aug 2010, Lennart Poettering wrote:
On Mon, 23.08.10 10:52, Garrett Holmstrom (gholms(a)fedoraproject.org)
wrote:
>
> Lennart Poettering wrote:
> > So, to turn this around. Do you think this behaviour is problematic? Can
> > you make a good case for dropping this automatism? If so I'd be willing
> > to do so.
>
> That behavior might be fine, but don't add filesystems marked
"noauto"
> to the list of filesystems to be mounted automatically when reading fstab.
>
> Here are my use cases and other rationale. I'm sure other people have more:
>
> * fstab(5) documents the "noauto" option
Well, what it says is that noauto results in "the -a option will not
cause the filesystem to be mounted". And that's still the case. We
execute either the real "mount -a" (or actually something equivalent) at
bootup, and that by itself won't cause the fs to be mounted still.
> * I manually mount network shares that aren't always available with the
> "noauto" and "user" options
That's not the issue here. systemd will never mount non-device mount points
automatically, unless listed as "auto".
> * Removable media that appear in fstab are usually marked noauto
And?
> * /boot doesn't always need to be mounted on every distro
And?
> * I mount large filesystems after the boot process finishes so fscking
> doesn't pause booting at $dayjob
And?
And change it. The request was pretty clear.
-Mike
12:34 p.m.
On Mon, 2010-08-23 at 11:38 -0500, Mike McGrath wrote:
And change it. The request was pretty clear.
-Mike
Try to stay friendly, maybe ?
Lennart said at the outset that he was open to change it.
And, while this discussion rages here, he has in fact already
implemented the requested change.
12:41 p.m.
On Mon, 23 Aug 2010, Matthias Clasen wrote:
On Mon, 2010-08-23 at 11:38 -0500, Mike McGrath wrote:
>
> And change it. The request was pretty clear.
>
> -Mike
Try to stay friendly, maybe ?
Lennart said at the outset that he was open to change it.
And, while this discussion rages here, he has in fact already
implemented the requested change.
So sorry, it was not at all my intention to be unfriendly. I was simply
trying to keep the email short and direct. I completely understand how a
short direct email might come off as not being friendly and I am very
sorry if that is how it came off. Once again my apologies and I'll make
sure to not be short and direct in the future but excellent and friendly.
-Mike
noon
Lennart Poettering wrote:
On Mon, 23.08.10 10:52, Garrett Holmstrom (gholms(a)fedoraproject.org)
wrote:
> * fstab(5) documents the "noauto" option
Well, what it says is that noauto results in "the -a option will not
cause the filesystem to be mounted". And that's still the case. We
execute either the real "mount -a" (or actually something equivalent) at
bootup, and that by itself won't cause the fs to be mounted still.
mount(8): noauto Can only be mounted explicitly
Several other UNIX and UNIX-like systems are much more explicit about
this, saying that noauto means that a filesystem will not be mounted at
boot time. If you are going to break decades of tradition you not only
have to provide good reasons for it, but you also have to update all of
the documentation that goes with it.
> * I manually mount network shares that aren't always
available with the
> "noauto" and "user" options
That's not the issue here. systemd will never mount non-device mount points
automatically, unless listed as "auto".
That's useful to know, but inconsistent since some filesystems default
to auto and others default to noauto.
> * Removable media that appear in fstab are usually marked noauto
And?
Systemd should not try to mount them because the administrator
explicitly asked for them to *not* be mounted. There is no sense trying
to mount a device with no media just because it appears in fstab.
> * /boot doesn't always need to be mounted on every distro
And?
Systemd should not try to mount it because the administrator explicitly
asked for it to *not* be mounted. If I don't want /boot mounted then
the init system must respect that until all of the relevant system
documentation changes and a release note mentions the change.
> * I mount large filesystems after the boot process finishes so
fscking
> doesn't pause booting at $dayjob
And?
Systemd should not try to mount them because the administrator
explicitly asked for them to *not* be mounted. Doing otherwise while
ignoring noauto semantics could delay booting for hours if long-running
fscks are triggered. Your new auto/noauto semantics aren't documented
in important places like fstab(5) and mount(8), so rc scripts that, as
per documentation, expect the filesystems they work with to be unmounted
will fail.
I apologize; I thought my request was clear: please implement
auto/noauto in the traditional, documented way, use a different keyword
for this new behavior, and document any new semantics or keywords in the
relevant man pages and release notes. I think Ubuntu uses "bootwait"
and "nobootwait" if you need ideas.
6:11 p.m.
Let me explain what I think Lennart meant with those "And?" replies:
Garrett Holmstrom wrote:
Lennart Poettering wrote:
> On Mon, 23.08.10 10:52, Garrett Holmstrom (gholms(a)fedoraproject.org)
> wrote:
>> * Removable media that appear in fstab are usually marked noauto
>
> And?
Systemd should not try to mount them because the administrator
explicitly asked for them to *not* be mounted. There is no sense trying
to mount a device with no media just because it appears in fstab.
A removable media device with no media in it cannot and will not be mounted
anyway.
>> * I mount large filesystems after the boot process finishes
so fscking
>> doesn't pause booting at $dayjob
>
> And?
Systemd should not try to mount them because the administrator
explicitly asked for them to *not* be mounted. Doing otherwise while
ignoring noauto semantics could delay booting for hours if long-running
fscks are triggered.
The whole idea of the semantics being discussed is that the boot process
will NOT block on those file systems, so I don't see why this would be an
issue.
But I do see your other points. I'm just trying to explain what, I guess,
the laconic "And?" replies meant.
Kevin Kofler
12:38 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/23/10 9:27 AM, Lennart Poettering wrote:
On Mon, 23.08.10 10:52, Garrett Holmstrom (gholms(a)fedoraproject.org)
wrote:
>
> Lennart Poettering wrote:
>> So, to turn this around. Do you think this behaviour is problematic? Can
>> you make a good case for dropping this automatism? If so I'd be willing
>> to do so.
>
> That behavior might be fine, but don't add filesystems marked "noauto"
> to the list of filesystems to be mounted automatically when reading fstab.
>
> Here are my use cases and other rationale. I'm sure other people have more:
>
> * fstab(5) documents the "noauto" option
Well, what it says is that noauto results in "the -a option will not
cause the filesystem to be mounted". And that's still the case. We
execute either the real "mount -a" (or actually something equivalent) at
bootup, and that by itself won't cause the fs to be mounted still.
> * I manually mount network shares that aren't always available with the
> "noauto" and "user" options
That's not the issue here. systemd will never mount non-device mount points
automatically, unless listed as "auto".
> * Removable media that appear in fstab are usually marked noauto
And?
> * /boot doesn't always need to be mounted on every distro
And?
> * I mount large filesystems after the boot process finishes so fscking
> doesn't pause booting at $dayjob
And?
And how does a system admin/user get the old functionality back, where
there was a line in /etc/fstab that made it easy to mount certain things
manually when it was convenient and/or safe for the user to do so?
I think adding more flexibility is interesting, but not at the cost of
changing (rather drastically) the semantics of an established option.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxysgoACgkQ4v2HLvE71NXJxQCaA/SxQ5yEFxiEtmCv/dvhl7+X
DwoAniGV3PH4WiHDdt3S8iQinOqxxzIY
=q9ab
-----END PGP SIGNATURE-----
4976
days inactive
4991
days old
353 comments
73 participants
participants (73)
-
Adam Williamson -
Al Dunsmuir -
Alex Hudson -
Andrew Haley -
Arthur Pemberton -
Ben Boeckel -
Benny Amorsen -
Bill Nottingham -
Bob Arendt -
Brendan Jones -
Bruno Wolff III -
Chris Adams -
Chris Ball -
Chuck Anderson -
Dan Williams -
Dariusz J. Garbowski -
darrell pfeifer -
David Malcolm -
David Michael -
Dennis Gilmore -
drago01 -
Eli L. -
Emmanuel Seyman -
Eric Sandeen -
Frank Murphy -
Garrett Holmstrom -
Genes MailLists -
Gerald Henriksen -
Gerard Braad -
glandvador -
James Hubbard -
Jef Spaleta -
Jeff Garzik -
Jesse Keating -
Jesse Keating -
Jon Masters -
jose manimala -
Jóhann B. Guðmundsson -
Kevin Fenzi -
Kevin Kofler -
Lennart Poettering -
Mark Chappell -
Matej Cepl -
Matt McCutchen -
Matthew Miller -
Matthias Clasen -
Michael Cronenworth -
Michael Schwendt -
Michal Hlavinka -
mike cloaked -
Mike McGrath -
Miloslav Trmač -
Máirín Duffy -
Nicolas Mailhot -
Orion Poplawski -
Paul W. Frields -
Pete Zaitcev -
Piscium -
Rahul Sundaram -
Ralf Ertzinger -
Rudolf Kastl -
Seth Vidal -
Simo Sorce -
Stephen John Smoogen -
Sven Lankes -
Thomas Janssen -
Thomas Moschny -
Till Maas -
Todd Zullinger -
Tom Callaway -
Tomasz Torcz -
Toshio Kuratomi -
Vedran Miletić