FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 01-09-2008, 08:51 PM
John Dennis
 
Default Linux is not about choice

Adam Jackson wrote:

But the chain of logic from "Linux is about
choice" to "ship everything and let the user chose how they want their
sound to not work" starts with fallacy and ends with disaster.


+1

FWIW, I tend to believe a good distribution is about limiting choice,
not proliferating it. Limited choice enhances robustness by reducing the
combinatorics of testing. Throwing the entire kitchen sink into the
distribution is anarchy with the expected results.

FWIW I liked the idea of Core vs. Extras because if it was in Core it
was expected to work, if it was in Extras it was buyer beware.

A good distribution works. Choice is provided by optional add-ons with
no guarantees. After an optional package is shown to be robust and well
supported it can be promoted from it's optional status, just as a core
package can be demoted to optional if it fails to meet the requirements
of robustness, security, and support required of the distribution.

--
John Dennis <jdennis@redhat.com>

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-09-2008, 08:53 PM
Thorsten Leemhuis
 
Default Linux is not about choice

On 09.01.2008 22:37, Bill Nottingham wrote:
> Thorsten Leemhuis (fedora@leemhuis.info) said:
>> So that leaves two choices:
>>
>> - we could have delayed juju until F8 (or even F9)
>> - we could have included juju in F7 (as we did) and made it optional
>> (either enabled or disabled by default)
>>
>> I think the latter is the better solution and a serious option for one
>> release.
> That way lies madness.

I suppose the users that ran into trouble would say the same about what
we did.

So both way lie madness here. Then I'm all for giving the users the
choice so they can work around something without to much trouble if they
run into problems with something new.

> Right now DRI/DRM breaks VT switch and suspend on my laptop. Should we
> ship two Intel drivers and two kernels until this is resolved? [...]

Bugs in a updated package are something totally different (everyone
tries to avoid them, but they happen, so we have to live with them) then
switching to a new completely firewire stack that doesn't support
everything yet what the old stack did.

Jesse said juju "was functional for the vast majority of uses" when we
shipped that; I doubt that, as the questions is saw in #fedora-de, the
"howto switch to the old firewire stack"-Howtos in the net and the mail
from Hans tell a different story.

Cu
knurd

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-09-2008, 09:00 PM
Douglas McClendon
 
Default Linux is not about choice

John Dennis wrote:

Adam Jackson wrote:

But the chain of logic from "Linux is about
choice" to "ship everything and let the user chose how they want their
sound to not work" starts with fallacy and ends with disaster.


+1

FWIW, I tend to believe a good distribution is about limiting choice,
not proliferating it. Limited choice enhances robustness by reducing the
combinatorics of testing. Throwing the entire kitchen sink into the
distribution is anarchy with the expected results.

FWIW I liked the idea of Core vs. Extras because if it was in Core it
was expected to work, if it was in Extras it was buyer beware.

A good distribution works. Choice is provided by optional add-ons with
no guarantees.


+42

This is where I think the intensity of this thread is somewhat
confusing. I wholeheartedly agree that what you ship in one particular
spin/strain of fedora should most often minimize choices for the user
(unless the target users of the spin/strain explicitly want the choices).


That is what is great about distro spin tools such as
livecd-tools/revisor/VirOS- they make it easy for anyone who doesn't
like the official fedora imposed choice, to as easily as possible, put
together a 'fork' distro utilizing the alternate choice.


The thing I wish would be come through clearer in this thread is that
choices are fine for the massive Fedora Everything collection. Sure
having more choices will lead to more bugs, but so what as long as the
choices made for the official spin are well tested.


$0.02

-dmc


After an optional package is shown to be robust and well

supported it can be promoted from it's optional status, just as a core
package can be demoted to optional if it fails to meet the requirements
of robustness, security, and support required of the distribution.



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-09-2008, 09:12 PM
Thorsten Leemhuis
 
Default Linux is not about choice

On 09.01.2008 23:00, Douglas McClendon wrote:
> John Dennis wrote:
>> A good distribution works.
+1

But Juju afaics didn't work well for to many people when we shipped it
for the first time, thus choice here IMHO is a temporary solution.

> This is where I think the intensity of this thread is somewhat
> confusing. I wholeheartedly agree that what you ship in one particular
> spin/strain of fedora should most often minimize choices for the user
> (unless the target users of the spin/strain explicitly want the choices).

+1

> That is what is great about distro spin tools such as
> livecd-tools/revisor/VirOS- they make it easy for anyone who doesn't
> like the official fedora imposed choice, to as easily as possible, put
> together a 'fork' distro utilizing the alternate choice.

You might want to look at a idea that came up on the list now and then
by different people that Jesse added to the wiki:
http://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos

I like the idea, but the amount of work that might create is likely a lot.

> [...]

Cu
knurd

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-09-2008, 09:13 PM
"Jeff Spaleta"
 
Default Linux is not about choice

On Jan 9, 2008 12:27 PM, Jesse Keating <jkeating@redhat.com> wrote:
> And if we had chosen that, it likely still wouldn't be where it is
> today, because it wouldn't have had the exposure. It was functional
> for the vast majority of uses and the exposure got more and more things
> fixed on it. If there was an alternative then everybody would just
> switch back to the old method, and no bugs would get filed and no
> corner cases would get discovered.

We need to build an accurate perception as to what we are offering in
our releases. When we have the manpower to support it
we drive technologies forward aggressively. We need to build the
perception that our releases aren't just consumables, but they instead
collaborative partnerships will our users to meet the goals of driving
long term value into the open source software stack. We need to build
the perception that when you choose to use fedora, you are choosing to
be a part of the collaboration, and not just taking a product off the
shelf giving it a spin.

In areas where we have Fedora contributors who are active upstream
developers, we tend to make integration decisions in release N which
have the best potential for long term benefit for release N+1, N+2 and
out into the future (especially in the area of hardware interaction).
We know our process is not regression intolerant. But our process
accommodates that fact by having an aggressive update process so
people suffering hardware regressions can obtain fixes in a responsive
manner. This isn't a policy, or a set of rules, this is how our
development culture operates in broad brush strokes. It would be
deeply disruptive to the project to attempt to suppress this essential
nature.

So how do we fix the perception that this is a bad thing? How do we
attract users and contributors who are comfortable with some level of
regression, for the sake of long term benefit?

Naively, I would suggest continuing to enhance our Feature-scoping so
that it includes known or suspected regression areas. And we need to
be able to have our developers who are aggressively driving new
technologies into our releases, make public commitments that they will
work to address regressions as part of the update process. We can't
make guarantees, but we can certainly project a perception that our
developers care about hardware regressions and are willing to work
with people to fix them.

-jef

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-09-2008, 09:17 PM
Colin Walters
 
Default Linux is not about choice

On Wed, 2008-01-09 at 16:51 -0500, John Dennis wrote:

> FWIW I liked the idea of Core vs. Extras because if it was in Core it
> was expected to work, if it was in Extras it was buyer beware.

The Core/Extras split still exists in the sense of "some packages are
more important than others"- it's just now defined as the set of
packages included in the Live image kickstart files and comps.


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-09-2008, 09:18 PM
"KH KH"
 
Default Linux is not about choice

2008/1/9, Jesse Keating <jkeating@redhat.com>:
> On Wed, 09 Jan 2008 22:18:25 +0100
> Thorsten Leemhuis <fedora@leemhuis.info> wrote:

> And if we had chosen that, it likely still wouldn't be where it is
> today, because it wouldn't have had the exposure. It was functional
> for the vast majority of uses and the exposure got more and more things
> fixed on it. If there was an alternative then everybody would just
> switch back to the old method, and no bugs would get filed and no
> corner cases would get discovered.

Then we might have a fallback method for people that want to test firewire.
Because if it does not work for some userland apps, then people will
just escape.(to RHEL based or others). If we really want to have
valuable testers for firewire, I think they have to be taken with
care.

For now i'm building a own kmod-ieee1394 but it is not interesting to
have it build that way... instead of within the kernel.
then providing a compat-libraw1394 (without juju support) with the
appropriate blacklisting for kernel modules, and that's would be
all...
See experiments here: http://kwizart.free.fr/fedora/testing/8/SRPMS/

I do think the firewire problem is different from others.


Nicolas (kwizart)



>
> --
> Jesse Keating
> Fedora -- All my bits are free, are yours?
>
> --
> fedora-devel-list mailing list
> fedora-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-09-2008, 09:18 PM
Jesse Keating
 
Default Linux is not about choice

On Wed, 09 Jan 2008 23:12:57 +0100
Thorsten Leemhuis <fedora@leemhuis.info> wrote:

> +1
>
> But Juju afaics didn't work well for to many people when we shipped it
> for the first time, thus choice here IMHO is a temporary solution.

Some people. Lets not confuse a few vocal folks for whom a part of it
didn't work with the large amount of folks who just plain didn't notice
that juju was there vs something else because things just kept working
(or got better). I mistakenly claimed that it worked for most people,
when in reality I have no way of proving that. Instead,
most /functionality/ was working, and I extrapolated that into most
people.

--
Jesse Keating
Fedora -- All my bits are free, are yours?
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-09-2008, 09:26 PM
Will Woods
 
Default Linux is not about choice

On Wed, 2008-01-09 at 17:17 -0500, Colin Walters wrote:
> On Wed, 2008-01-09 at 16:51 -0500, John Dennis wrote:
>
> > FWIW I liked the idea of Core vs. Extras because if it was in Core it
> > was expected to work, if it was in Extras it was buyer beware.
>
> The Core/Extras split still exists in the sense of "some packages are
> more important than others"- it's just now defined as the set of
> packages included in the Live image kickstart files and comps.

Live and/or the Default Install set. We should probably have a better
way of listing of what that set of packages actually is so we can make
sure they get extra attention during updates and whatnot.

-w
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-09-2008, 09:47 PM
Patrice Dumas
 
Default Linux is not about choice

On Wed, Jan 09, 2008 at 03:58:45PM -0500, Adam Jackson wrote:
> > Linux is about choice.
>
> The complaints up-thread about juju and pulse are entirely valid, but
> the solution is not to try to deliver two things at once. If you try to
> deliver both at once you have to also deliver a way of switching between
> the two. Now you have three moving parts instead of one, which means
> the failure rate has gone up by a factor of _six_ (three parts, and
> three interactions). We have essentially already posited that we have
> insufficient developer effort to have 100%-complete features at ship
> time, so asking them to take on six times the failure rate when they're
> already overburdened is just madness. Alternatively, we could say that

Who 'essentially already posited that we have insufficient developer
effort'? Who decided that, and for what task? Isn't the fedora
contributors time used like they want to? If there are three parts,
and three interactions but dozens of contributors willing to fix
them where is the issue?

> worse than the old stack. But the chain of logic from "Linux is about
> choice" to "ship everything and let the user chose how they want their
> sound to not work" starts with fallacy and ends with disaster.

This is right. But care should be taken not to shift from constraining
the user to constraining the developper. We should ship everything that
a contributor has interest in maintaining. It should not be at the
expense of innovating, so breaking some packages some time because
they are not ready for changes in other packages is acceptable (in
rawhide). In the design of new feature, however existing stuff should be
taken into account such that, if possible, previous habits are still
possible and there are no regression. Developpers of new features
should look at it, even to discard it, in fedora I see too much 'this is
old cruft no need to look at it is broken by design' even when it is
untrue.

--
Pat

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 03:15 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org