Am Montag, den 07.07.2008, 14:04 +0100 schrieb Matt Zimmerman: > On Mon, Jul 07, 2008 at 08:30:28AM -0400, Scott Kitterman wrote: > > This is not sustainable in the long term. Before long people will be > > saying, "Everyone know not to upgrade Ubuntu until the first point > > release". Then we don't get the end user base to test until .1 and we have > > to bugfix from there. > > While this is a natural assumption, if you think about it a bit further, I > think you'll agree that this is not the case in practice, because we don't > have a single "end user base" which behaves consistently. > > Ubuntu serves a wide variety of different users, who have different > expectations and levels of willingness to participate. These range from > hard-core developers who are already running Intrepid, through power users > who may upgrade during the beta period, through enthusiasts who will upgrade > as soon as a new release is out, through casual users who will wait until > later, to conservative users who will only consider LTS. > > By orienting our quality processes toward these different groups, we allow > our users to choose their own tradeoffs between stability and timeliness.
I agree.
If you need the highest stability in Ubuntu, you will install only LTS
releases anyway.
If all users behaved like that, all releases in the two years between
LTS releases would be untested.
Most people will still install the regular 6-month releases though.
For me, it's mostly an unconscious barrier of *really* testing alphas
and betas: Between IRC, mailing list, alpha page and the download page,
from every corner I get "THIS IS ALPHA SOFTWARE! DON'T USE! IT *WILL*
BREAK!".
While the actual releases are of course never bug-free, I have no
problem with installing something that the developers consider "ready
for release".
The belief of the users in the Ubuntu developers is what drives people
to use the regular releases, even if they may not be perfectly tested.
------------------------------
Another point:
It seems that it's one of two evils:
1) Either free up time from work to thoroughly test and install alphas
and betas
2) Or install releases that are not tested enough, and lose time at work
because of bugs
The problem is that people like me would like to test alpha/beta
software and report bugs, but fear the breakage and the unusability of
their work machine.
When I need to have software ready the next day, I can't accept some
development application not working.
When friends come around, I can't accept my MP3 player or sound
subsystem not working.
So, maybe it is somehow technically possible to combine "test alpha/beta
software" with the concern for stability.
I don't know how though.
Maybe packages in the alpha need to have some kind of quality stamp by
the developer/packager, like "will definitely break", "probably won't
break", "will break but has SO COOL FEATURES! ;P", "is ready for
production", and so on... and users could decide if they want to install
that or not.
Of course, then we still have the dependency problem, and the problem of
changing architecture in the alphas, which is unsolvable with different
package states for each user...
Sorry, these are all just random thoughts.
I just want to provide some insight in what goes on in my head when it
comes to testing.
It's not that I don't want to test the alphas, it's the fear that I
might not be able to do my work tomorrow.
And separate alpha installs just don't do the testing job. ;)
Bye,
Sebastian.
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
-- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
