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 11-19-2008, 05:38 PM
Callum Lerwick
 
Default My roadmap for a better Fedora

So, many pieces of this have been blabbed about by me and others
recently and in the past, but I think a lot of people aren't seeing the
big picture. I think it's time I fit it all together.

Problem: Fedora is buggy, and updates are rife with regressions.

Solution: We need more and wider testing.

Problem: We need more and wider testing. Why don't we get more testing?
Thw reason *I* don't go out of my way to test updates, is if there's a
regression, it's such a pain in the ass to get the system back to a
known good state and keep it that way, and report a bug. If it's a pain
in the ass for me, it's impossible for Aunt Tillie.

Solution:

1) Make it easy to report bugs. Bugzilla is complex, slow, and
inscrutable. We need to put a simpler layer on top of it. Reporting a
bug should require just a few clicks. It should automatically include
all the information needed for the bug report, the distro version,
package version, arch, and things such as how the Xorg team demands your
xorg.conf and Xorg.0.log. Make finding dupes easier. Collect stack
traces system wide and enter them in a database, which bugzilla can
reference and from which bugzilla bugs can be derived. A system wide
kerneloops. (I know this has been talked about, what's the status?)

2) Make it simple to roll back to a known good state. We need a "system
restore". I know what you're thinking, but our vastly superior,
centralized, system-wide package management (and lack of a whole
seperate "system registry" namespace) allows us to make this actually
work. We need per-package rollback. Period.

3) Make it so yum will refuse to upgrade the package rolled back in step
2 until the bug reported in step 1 is fixed.

4) For when things go really wrong, we need a rescue image in /boot. All
the above functionality must be available inside the rescue environment.

5) So how do bugs get fixed? Make it easy to cherry pick updates from
updates-testing or even direct from bodhi. How useful is it to blindly
follow every update in updates testing? For most users, it's useless.
Such adventurous people should probably just run rawhide... What we
really need is to make it easy to pick a specific release of an update
to try, such as if a user is directed to in a bug report. A user should
just be able to click on a link given in the bug report and have the
update installed. Available updates and the reasons for them needs to be
more discoverable. Don't forget step #2.

See how these things build upon and support each other?

Notice here I'm talking purely about user interface, about the end user
experience. The technical infrastructure follows from this, and I'll
save that discussion for another message. Infrastructure supports
functionality, not the other way around. I don't want to hear any "Oh
but we can't do this because blah blah technical objection blah makes
this hard". I hereby dub this the "Hard problem fallacy". Engineers
solve hard problems, that's what we do. I want to hear "To do this we
need to do x y z". The only objections I will accept are of the form
"You are an idiot and your ideas are stupid. We're not doing this."

I should probably put this on the Wiki so it doesn't get lost...
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-19-2008, 05:43 PM
Doug Ledford
 
Default My roadmap for a better Fedora

On Wed, 2008-11-19 at 12:38 -0600, Callum Lerwick wrote:
> So, many pieces of this have been blabbed about by me and others
> recently and in the past, but I think a lot of people aren't seeing the
> big picture. I think it's time I fit it all together.
>
> Problem: Fedora is buggy, and updates are rife with regressions.
>
> Solution: We need more and wider testing.
>
> Problem: We need more and wider testing. Why don't we get more testing?
> Thw reason *I* don't go out of my way to test updates, is if there's a
> regression, it's such a pain in the ass to get the system back to a
> known good state and keep it that way, and report a bug. If it's a pain
> in the ass for me, it's impossible for Aunt Tillie.
>
> Solution:
>
> 1) Make it easy to report bugs. Bugzilla is complex, slow, and
> inscrutable. We need to put a simpler layer on top of it. Reporting a
> bug should require just a few clicks. It should automatically include
> all the information needed for the bug report, the distro version,
> package version, arch, and things such as how the Xorg team demands your
> xorg.conf and Xorg.0.log. Make finding dupes easier. Collect stack
> traces system wide and enter them in a database, which bugzilla can
> reference and from which bugzilla bugs can be derived. A system wide
> kerneloops. (I know this has been talked about, what's the status?)
>
> 2) Make it simple to roll back to a known good state. We need a "system
> restore". I know what you're thinking, but our vastly superior,
> centralized, system-wide package management (and lack of a whole
> seperate "system registry" namespace) allows us to make this actually
> work. We need per-package rollback. Period.
>
> 3) Make it so yum will refuse to upgrade the package rolled back in step
> 2 until the bug reported in step 1 is fixed.
>
> 4) For when things go really wrong, we need a rescue image in /boot. All
> the above functionality must be available inside the rescue environment.
>
> 5) So how do bugs get fixed? Make it easy to cherry pick updates from
> updates-testing or even direct from bodhi. How useful is it to blindly
> follow every update in updates testing? For most users, it's useless.
> Such adventurous people should probably just run rawhide... What we
> really need is to make it easy to pick a specific release of an update
> to try, such as if a user is directed to in a bug report. A user should
> just be able to click on a link given in the bug report and have the
> update installed. Available updates and the reasons for them needs to be
> more discoverable. Don't forget step #2.
>
> See how these things build upon and support each other?
>
> Notice here I'm talking purely about user interface, about the end user
> experience. The technical infrastructure follows from this, and I'll
> save that discussion for another message. Infrastructure supports
> functionality, not the other way around. I don't want to hear any "Oh
> but we can't do this because blah blah technical objection blah makes
> this hard". I hereby dub this the "Hard problem fallacy". Engineers
> solve hard problems, that's what we do. I want to hear "To do this we
> need to do x y z". The only objections I will accept are of the form
> "You are an idiot and your ideas are stupid. We're not doing this."
>
> I should probably put this on the Wiki so it doesn't get lost...

Agreed.

--
Doug Ledford <dledford@redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford

Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-19-2008, 06:07 PM
"Jeff Spaleta"
 
Default My roadmap for a better Fedora

2008/11/19 Callum Lerwick <seg@haxxed.com>:
> 1) Make it easy to report bugs. Bugzilla is complex, slow, and
> inscrutable. We need to put a simpler layer on top of it. Reporting a
> bug should require just a few clicks. It should automatically include
> all the information needed for the bug report, the distro version,
> package version, arch, and things such as how the Xorg team demands your
> xorg.conf and Xorg.0.log. Make finding dupes easier. Collect stack
> traces system wide and enter them in a database, which bugzilla can
> reference and from which bugzilla bugs can be derived. A system wide
> kerneloops. (I know this has been talked about, what's the status?)

Maybe you can help do what's necessary to get apport integrated into
our infrastructure.
http://fedoraproject.org/wiki/Releases/FeatureApport
>
> 2) Make it simple to roll back to a known good state. We need a "system
> restore". I know what you're thinking, but our vastly superior,
> centralized, system-wide package management (and lack of a whole
> seperate "system registry" namespace) allows us to make this actually
> work. We need per-package rollback. Period.

Let me point out that rollback itself would require testing.
Obsoletes, triggers, (un)post/pre scripts, config file handling... all
this rpm functionality complicates how successful rollbacks are to get
you back to a restored system state. How are we going to test if a
rollback works before you ask people to perform the rollback?

Just start with obsoletes... describe to me how we rollback after an
obsolete calculation has occurred as part of an update transaction.

-jef

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-19-2008, 07:01 PM
Callum Lerwick
 
Default My roadmap for a better Fedora

On Wed, 2008-11-19 at 10:07 -0900, Jeff Spaleta wrote:
> Maybe you can help do what's necessary to get apport integrated into
> our infrastructure.
> http://fedoraproject.org/wiki/Releases/FeatureApport

Meh, I was kind of thinking of working on the "rescue image in /boot"
first.

> > 2) Make it simple to roll back to a known good state. We need a "system
> > restore". I know what you're thinking, but our vastly superior,
> > centralized, system-wide package management (and lack of a whole
> > seperate "system registry" namespace) allows us to make this actually
> > work. We need per-package rollback. Period.
>
> Let me point out that rollback itself would require testing.
> Obsoletes, triggers, (un)post/pre scripts, config file handling... all
> this rpm functionality complicates how successful rollbacks are to get
> you back to a restored system state. How are we going to test if a
> rollback works before you ask people to perform the rollback?

You do it in such a fundamentally simple manner as to be obviously
correct. You do it in a way that makes the system provably in the exact
same state as before, bit for bit. Think versioning filesystems. Think
distributed source control, applied to the entire filesystem. Think git.

There are many options here.

1) Ban everything that breaks rollbacks. Find some other way to do it.

2) Just refuse to rollback the packages that break rollback.

3) A combination of both

This is an example of where we need specific examples of scripts and
such that break rollback to get any farther on this.

First, could you please do something for me. Forget implementation.
Forget the details. Just answer this simple yes or no question:

Is rollback a desireable feature?

> Just start with obsoletes... describe to me how we rollback after an
> obsolete calculation has occurred as part of an update transaction.

I never said I have all the answers. I can't do this alone. "Many eyes
makes all engineering challenges shallow"
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-19-2008, 07:46 PM
"Jeff Spaleta"
 
Default My roadmap for a better Fedora

2008/11/19 Callum Lerwick <seg@haxxed.com>:
> There are many options here.
>
> 1) Ban everything that breaks rollbacks. Find some other way to do it.

these features were implemented for a reason. You grossly oversimplify
the problem by saying "find some other way to do it."
>
> 2) Just refuse to rollback the packages that break rollback.

How do you know they will break roll back? How do you test rollback in
an organized way?

>
> 3) A combination of both
>
> This is an example of where we need specific examples of scripts and
> such that break rollback to get any farther on this.

Since noone tests for rollback there are no obvious examples of known
rollback breakage. We don't look..we don't test... so we don't know
what currently breaks. You'd have to take each special case...and
attempt to trigger the condition and test for differences. But since
we are talking about scripted actions which could literally do pretty
much anything...how do you set up a test which attempts to measure
whether rollback across a trigger boundary put you back to where you
were? How much of a different in state counts as 'break rollback'?

rpm -qa --qf "%{NAME}:
%{TRIGGERSCRIPTS}
"

If for example the conditions are met which fire off hal's triggered
scripts... if you rolled back hal across that condition
boundary..would things get reverted? That's probably not relevant for
current, expected, update needs. But until we test all triggers for
rollbacks we don't know where we stand.

And then there are obsoletes. How many new obsoletes do we introduce
in updates? Any idea? a run of repoquery against the f9 release and f9
updates tree would be able to tell us that. When an obsolete is
introduced in an update... can we rollback and get what we had?

> First, could you please do something for me. Forget implementation.
> Forget the details. Just answer this simple yes or no question:

>
> Is rollback a desireable feature?

That's a horrible pointless question. There are many features which
are desirable..but not necessary easily compatible with each other.
Drop dead easy smooth upgrades are not necesssarily going to be
compatible with rollback. So the right question is.... is rollback
more desirable than other packaging features. What packaging
mechanisms are we willing to give up in order to make rollback at the
individual package level easier to achieve? I honestly don't think
there is a single mechanism that we are willing to give up. So if
rollback is going to be a compatible its going to take a much more
clever monkey than myself to figure out the "details" which work.


> I never said I have all the answers. I can't do this alone. "Many eyes
> makes all engineering challenges shallow"

I'm pointing out known complications to the problem. I suggest you
read up on Carrier Grade Linux which I think attempts to makes
rollback an important specification deliverable..but my knowledge is
somewhat dated. If there is a group that has thought hard about
rollback...its them. Whether or not what they've come up with is at
all applicable is another question entirely.

-jef

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-19-2008, 07:53 PM
Seth Vidal
 
Default My roadmap for a better Fedora

On Wed, 19 Nov 2008, Jeff Spaleta wrote:




I never said I have all the answers. I can't do this alone. "Many eyes
makes all engineering challenges shallow"


I'm pointing out known complications to the problem. I suggest you
read up on Carrier Grade Linux which I think attempts to makes
rollback an important specification deliverable..but my knowledge is
somewhat dated. If there is a group that has thought hard about
rollback...its them. Whether or not what they've come up with is at
all applicable is another question entirely.




I'm pretty sure the rollback functionality the CGL wanted was removed from
rpm recently.


-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-19-2008, 07:57 PM
"Peter Lemenkov"
 
Default My roadmap for a better Fedora

2008/11/19, Callum Lerwick <seg@haxxed.com>:
> 1) Make it easy to report bugs. Bugzilla is complex, slow, and
> inscrutable.

Agree. I told it thousands times in many different places. Bugzilla is
the ugly monster. Btw recently NASA chosed bugzilla for their space
programs ( http://news.cnet.com/8301-13772_3-10097880-52.html ) - poor
astronauts on Endeavour!

Very few users will decide to report bugs utilizing Bugzilla, even
less of them will do actual bugreports. Even some developers (like me)
sometimes don't know how to describe problem correctly (assign to
proper component, for example).

BTW why we are enforcing users to register on bugzilla, just to be
able to tell us that something wrong with Fedora?

--
With best regards!

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-19-2008, 07:59 PM
Bill Nottingham
 
Default My roadmap for a better Fedora

Peter Lemenkov (lemenkov@gmail.com) said:
> BTW why we are enforcing users to register on bugzilla, just to be
> able to tell us that something wrong with Fedora?

Because it's not a one-way communication (at least, not if you want it
to be effective.)

Bill

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-19-2008, 08:23 PM
"Peter Lemenkov"
 
Default My roadmap for a better Fedora

2008/11/19, Bill Nottingham <notting@redhat.com>:
> Because it's not a one-way communication (at least, not if you want it
> to be effective.)

I think you misundestood something. If order to effectively hunt
issues, we definitely need HUGE number of bugreports (remember
Necrosoft's "Send crash dump" utility). That definitely means one-way
communication. I'm insisting - one-way communication (e.g. user will
send bugreport to invisible-to-him blackhole, w/o answer, with some
handy tool).

Bugzilla is (probably) suitable for large ineffective developer's
teams with large amounts of old, dying, poorly maintained code.

Bugzilla is in no way suitable to help hear crying of users (because,
as I said before, it's too complex). That means we have no tools and
communication channels, to track down enduser's problems, at all. Some
of us sometimes will fill bugreports (in some extraordinary cases),
but it's not enough.

Mediawiki will be easier to enduser in case of reporting bugs. However
some easiest utility (with appropriate server side, of course) would
be more appropriate.

--
With best regards!

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-19-2008, 08:42 PM
Gilboa Davara
 
Default My roadmap for a better Fedora

On Wed, 2008-11-19 at 12:38 -0600, Callum Lerwick wrote:
> So, many pieces of this have been blabbed about by me and others
> recently and in the past, but I think a lot of people aren't seeing the
> big picture. I think it's time I fit it all together.
>
> Problem: Fedora is buggy, and updates are rife with regressions.
>
> Solution: We need more and wider testing.
>
> Problem: We need more and wider testing. Why don't we get more testing?
> Thw reason *I* don't go out of my way to test updates, is if there's a
> regression, it's such a pain in the ass to get the system back to a
> known good state and keep it that way, and report a bug. If it's a pain
> in the ass for me, it's impossible for Aunt Tillie.
>
> Solution:
>
> 1) Make it easy to report bugs. Bugzilla is complex, slow, and
> inscrutable. We need to put a simpler layer on top of it. Reporting a
> bug should require just a few clicks. It should automatically include
> all the information needed for the bug report, the distro version,
> package version, arch, and things such as how the Xorg team demands your
> xorg.conf and Xorg.0.log. Make finding dupes easier. Collect stack
> traces system wide and enter them in a database, which bugzilla can
> reference and from which bugzilla bugs can be derived. A system wide
> kerneloops. (I know this has been talked about, what's the status?)

Agreed.
Though you're missing thing - automated bug report system generate
-huge- amount of noise. Lowering the signal-to-noise ratio to something
usable is -very- labor intensive.
Far worse, people (who send such report) tend to forget about them (as
opposed to manual bug reports) making them far less effective.

So, question is:
A. Who will do the heavy lifting of developing such system?
B. Who will triage 1000's of orphaned bug reports.


>
> 2) Make it simple to roll back to a known good state. We need a "system
> restore". I know what you're thinking, but our vastly superior,
> centralized, system-wide package management (and lack of a whole
> seperate "system registry" namespace) allows us to make this actually
> work. We need per-package rollback. Period.

Assuming, of course, that you can pin-point what exactly broken
evolution within the 150 package update push.
Will you roll back all the updates? Only updates that had -something- to
do with the breakage? (Let alone kernel updates that can more-or-less
break everything in sight...)
Oh, and what do you do when at least 50% of these updates are
high-priority security updates?

>
> 3) Make it so yum will refuse to upgrade the package rolled back in step
> 2 until the bug reported in step 1 is fixed.

Say-what?!?
Are we building a second Vista here?

>
> 4) For when things go really wrong, we need a rescue image in /boot. All
> the above functionality must be available inside the rescue environment.

/+100.
Though this idea has come up a number of times before. AFAIR it was
dropped due to space considerations and possible kernel-version
problems. (In theory, you may need a different rescue image for each
installed kernel - unless you plan to keep the original kernel)

>
> 5) So how do bugs get fixed? Make it easy to cherry pick updates from
> updates-testing or even direct from bodhi. How useful is it to blindly
> follow every update in updates testing? For most users, it's useless.
> Such adventurous people should probably just run rawhide... What we
> really need is to make it easy to pick a specific release of an update
> to try, such as if a user is directed to in a bug report. A user should
> just be able to click on a link given in the bug report and have the
> update installed. Available updates and the reasons for them needs to be
> more discoverable. Don't forget step #2.

Not sure what that means.
You can always enable updates-testing and selectively install what you
need.

>
> See how these things build upon and support each other?
>
> Notice here I'm talking purely about user interface, about the end user
> experience. The technical infrastructure follows from this, and I'll
> save that discussion for another message. Infrastructure supports
> functionality, not the other way around. I don't want to hear any "Oh
> but we can't do this because blah blah technical objection blah makes
> this hard". I hereby dub this the "Hard problem fallacy". Engineers
> solve hard problems, that's what we do. I want to hear "To do this we
> need to do x y z". The only objections I will accept are of the form
> "You are an idiot and your ideas are stupid. We're not doing this."

Yes, but in the is case, the UI has a profound influence on the why
Fedora works.

On a side note, I'm not sure what you're trying to achieve by this last
paragraph. But if you intention was to start yet-another-flame-war, I
have a bad feeling you're on the right track.

- Gilboa


>
> I should probably put this on the Wiki so it doesn't get lost...
> --


--
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 12:43 PM.

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