Richard Hally wrote:

Will Woods wrote:

...

Fedora 9 will have a lot of new and exciting things. Naturally, we want those things to be stable and well-polished for the final release.

With that in mind, here's a list of things that deserve especially close attention.

1. PackageKit

This *replaces* pup and pirut, by default, on all new installs. If you're following rawhide, *please* disable or remove pup and pirut and test this. It's very important that you file bugs about *any* problems with PackageKit. Use the "gnome-packagekit" component in bugzilla for bugs about confusing (or missing) UI pieces, and "PackageKit" for bugs about backend errors, missing capabilities, or other (non-UI) problems.

Holy smoke! Batman that packagekit is lame. It's not ready for prime time yet. The first two minutes and I have a list of things wrong. Where to start:

1. No help.
2. under the "groups" tab, the list of groups is disorganized.

do see something in this tab ? I get an message box saying: "No packages cache is available. Yum cache was invalid and has been rebuilt." I asked this course I want to fill a bz today, but if you see something more then me, I'm not sure what to fill.

3. the list of packages in a group needs to be sorted.
4. just having a different color to indicate installed or not installed

is *bad* ui design. think of colorblind people. 5. How do you select multiple packages to install at the same time? 6. how do you expand the "description" text box?

number 5 is a real usability problem. I cannot understand how people are thinking this is ready to be the default s/w management app.

+1 That's what I was asking myself yesterday also, when I investigated the above problem a little bit deeper.

Good luck with your bugzilla. I'll resume putting things in bugzilla when I start getting responses to things I have already put in.

HTH Richard

Will Woods wrote:

You can make the argument that PackageKit is not ready all you want - I've made the same argument myself. But it's irrelevant. pup and pirut are basically unmaintained now. FESCo has considered the issue and decided to go with PackageKit as the default.

Thanks for the info.

So the only way to make sure PackageKit *is* ready to be the default package manager is to test it, file bugs, and get the maintainers to *improve* it.

Shouldn't the "maintainers" be testing it themselves as well? The problems I saw were so obvious they should never gotten out the door.

Perhaps this "release early and often" approach has gone too far. It looks to much like "quick and dirty, throw it over the wall" to me. But hey, I'm an old gray beard that would like to see the *quality* of s/w in Fedora improve. The results so far have not demonstrated the incremental improvement over time that would result from more fixing bugs and less feature churn. See the number of bugs in bugzilla.

Complaining on -test-list but *refusing* to report bugs improves *nothing*. It's the lazy way out and it's a waste of your time and mine. Either test and report bugs, or quietly stick with pup and pirut.

I saw complaining about and refusing to report bugs as a reminder to "maintainers" that not responding to bugs promptly will reduce the number of bug reporters and thus reduce the feedback they need, especially if they do not test their own work themselves as is apparent with PackageKit.

The bug triage process is moving forward but it will be wasted if "maintainers" do not improve their response to bugs.

HTH Richard

Rahul Sundaram wrote:

Richard Hally wrote:

Many maintainers are busy and prioritizing things. The large majority of them are volunteers.

Even volunteers should expect to do their best, and to commit to what they can do in the available time; I don't volunteer to do package maintenance because, over time, I don't think I'd do it well.

I _would_ expect the Fedora project to have some procedures in place to minimise the likelihood of software that plain doesn't work getting released.

At one time I was doing some work on IBM's PL/1 compiler, and we had some thousands of tests that it had to pass before release beyond the development team.

Rahul Sundaram wrote:

John Summerfield wrote:

...

Rahul Sundaram wrote:

...

Richard Hally wrote:

...

Many maintainers are busy and prioritizing things. The large majority of them are volunteers.

Even volunteers should expect to do their best, and to commit to what they can do in the available time;

We haven't seen many indications they aren't.

Richard mentioned a specific example where the package didn't seem to have had even a rudimentary test, and I thought you were defending the packager.

...

I _would_ expect the Fedora project to have some procedures in place to minimise the likelihood of software that plain doesn't work getting released.

Of course there are many. One example would be

https://www.redhat.com/archives/fedora-announce-list/2008-March/msg00010.htm...

That's _after_ it's released to users. Richard's example was one that should not have gone that far.

In many instances, it would require more people participating and providing feedback which is currently lacking.

Basic testing varies, but some examples: anaconda should do a successful install or two

rpm should be able to install/remove packages and detect deps problems. It should also be able to build packages.

yum should be able to install/remove packages and deal with deps problems.

gcc test suite should run

postgresql test suite should run

I don't expect a lot of testing in Fedora, if a failure is anything more than a nuisance (as opposed to costing serious money) to people they shouldn't be using it, but there should be a fair bit of effort in avoiding silly mistakes that just waste everyone's time.

By Richard's account that didn't happen this time, and I think the proper response is to see what happened, how it happened and what needs to be done to prevent its recurrence.

We all make mistakes, and we're all careless sometimes. The real problem is not how to prevent mistakes and carelessness, but how to alleviate their consequences.

That means procedures and training.

I expect a lot of the volunteers are professions, and that some who aren't would like to be. Learning the value of proper procedures and training in their use will help in their careers, even outside of IT.

The question is not "Who spilled that pancake batter on the floor?" but "how do we make it safe?" "How do we clean it up?" "How do we prevent it from happening again?"

Matthias Clasen wrote:

On Fri, 2008-03-28 at 11:47 +0900, John Summerfield wrote:

...

That's _after_ it's released to users. Richard's example was one that should not have gone that far.

But it _hasn't_ been released to users yet. What has happened is a _test_ release to help us fix these issues before we release...

And those testers aren't users?

On 2008-03-28, 03:01 GMT, John Summerfield wrote:

And those testers aren't users?

Not if they are downloading and using beta version of distribution. If you have clicked that "Install anyway" and don't know what that meant, I have no pitty with you.

Matej

Rahul Sundaram wrote:

John Summerfield wrote:

...

Richard mentioned a specific example where the package didn't seem to have had even a rudimentary test, and I thought you were defending the packager.

Then you thought wrong. I was explaining the general scenario. Not a

Richard: "Shouldn't the "maintainers" be testing it themselves as well? The problems I saw were so obvious they should never gotten out the door. "

specific instance. The specific instance doesn't fail any rudimentary test anyway IMO. It installs, removes and updates packages just fine. Sure, there are UI bugs and I have been filing them one by one. Remember, we are talking about rawhide, the development version of Fedora.

And?

Rawhide users are still users. Sure they ought have lower expectations of the reliability of the software, but still it needs some testing before it hits the mirrors.

...

...

Of course there are many. One example would be

https://www.redhat.com/archives/fedora-announce-list/2008-March/msg00010.htm...

That's _after_ it's released to users. Richard's example was one that should not have gone that far.

Packages in the development, updates-testing repository can be tested and feedback provided which determines whether it goes released or not to general users.

_I_ didn't say "general users." Rawhide users are still users.

The earlier a problem is found, the less expensive (in whatever measure you choose) it is.

Fixing a problem found by the maintainer[1] probably takes minutes of one person's time.

Once it hits the mirrors, it's costing a lot of (volunteers) time and money[2], and if (as Richard suggested) it basically doesn't work then it really should not get that far.

[1] There may be developers before and testers after, I'm trying to keep it really simple.

[2] The mirror operators are sinking real money into this, and I don't think they're all getting a return.

John Summerfield debian@herakles.homelinux.org wrote:

[...]

At one time I was doing some work on IBM's PL/1 compiler, and we had some thousands of tests that it had to pass before release beyond the development team.

Would that perhaps have been the one I saw going into lala-land (i.e., into an infinite loop)? ;-)

[Shi^WMistakes do happen, even with the best procedures in place.]

On Fri, 2008-03-28 at 12:45 -0300, Horst H. von Brand wrote:

Ronald Warsow rwarsow@online.de wrote:

...

Richard Hally wrote:

...

Will Woods wrote:

...

Fedora 9 will have a lot of new and exciting things. Naturally, we want those things to be stable and well-polished for the final release.

With that in mind, here's a list of things that deserve especially close attention.

1. PackageKit

This *replaces* pup and pirut, by default, on all new installs. If you're following rawhide, *please* disable or remove pup and pirut and test this. It's very important that you file bugs about *any* problems with PackageKit.

Can't uninstall pirut, as system-config-kickstart-2.7.15-2.fc9.noarch depends on it. Any replacement for that?

I'm hopefully going to whip something up for that this afternoon

Jeremy

On Thursday 27 March 2008 15:57:31 Michal Jaegermann wrote:

On Thu, Mar 27, 2008 at 10:30:30AM +0000, Tony Molloy wrote:

...

Fresh install of F9-Beta with static IP address. NetworkManagerDispatcher runs on firstboot and overwrites the resolv.conf file. Also the static network data from /etc/sysconfig/network-scripts/ifcfg-eth0 is not being honoured.

The second is likely a consequence of the first. Bugzilla number?

I don't have access to the machine until after the weekend. I'll do a fresh install on monday and bugzilla it if necessary.

...

It gets a 169.xx adddress.

An address on 169.254.0.0/16 network, right? That will be a "Bonjour" (or "ZeroConf", or whatever name-of-the-day for that happens to be) address for an avahi use. If you will get that address too, in an addition to what you specified, then this is like it should be. If this is the only address you are ending up with then this is a problem.

No ifconfig just gave the Zeroconf address and not the address from ifcfg-eth0.

Tony

Michal

Mary Ellen Foster wrote:

On 29/03/2008, Kevin Kofler kevin.kofler@chello.at wrote:

...

We could also use all the testing we can get for KDE 4. While feedback for the version 4.0.2 in the Beta is probably useful, what we could use even more urgently is some testing for 4.0.3 which is hitting Rawhide in the next nightly push (i.e. a few minutes/hours from now). Except in the case of major surprise schedule changes, KDE 4.0.3 will be the version in the Fedora 9 release. It fixes some bugs in 4.0.2.

Any chance of a Live CD with KDE 4.0.3 on it? I'm not really in a position to install Rawhide at the moment and I'd love to help out.

Preview release is in 8 days

http://fedoraproject.org/wiki/Releases/9/Schedule

Rahul

Janina Sajka wrote:

've successfully upgraded two machines from F-8 to the F-9 beta. A diff against my old /etc/gdm/custom.conf indicates Anaconda didn't touch that fil. Even after disabling pulseaudio, however, I am NOT getting audio out of GDM--snipet from custom.conf follows.

Please note this presents a serious a11y issue, as those of us unable to use display screens now have no indication when we might login to the desktop. The audio I dinciate doesn't play, and there is no beep when backspacing in the Login and Password fields.,

..snip..

PS: It's a corollary issue, but preventing all audio before completion of gdm login presents a serious a11y issue. In addition to the above noted problem with this approach, there are significant use cases for console audio which may, or may not, be logged in before the gui. Indeed, some may never login on the gui. In a11y that would include users of speakup, emacspeak, and brltty among others.

I have yet to play with pulseaudio as a system daemon to see if that resolves the problem of console audio, but having no audio until a login is successful as the default circumstance doesn't make Fedora an a11y friendly OS.

As another (relatively small) issue of this same problem, the logoff sound is cut short and does not completely play due to access to the sound device dropping off too quickly. Either the logoff sound needs to be played without pulse, or pulse needs to be started by GDM as well (a GDM pulse daemon) and the logoff sound actually gets played by that daemon not the user logging off?

If GDM had its own pulse daemon running it may be that a system-wide daemon isn't necessary, the login screen would have sound, the user would have sound once logged in. I wonder if its possible for GDM to run a pulse daemon of its own?