James Antill wrote:


That may or may not be true and it may or may not matter. All you need
is some large representative sample doing the early testing and a way to
ensure feedback to improve everyone's experience. And letting users
control their exposure to new bugs might increase the user base in both
categories.


This is what updates-testing _already does_. As Jesse has already said,
there are two big problems:

1. Too many people want to be consumers of the testing but not the
providers of it.


I think that's an unwarranted assumption. How many people even know
about updates-testing compared to people that never change defaults?
How does someone using updates-testing ensure that their usage
'provides' something?



Indeed IMO the whole updates-tested argument seems to devolve to "I'm
going to be clever and switch to this, but I'm pretty sure a bunch of
other people aren't going to know immediately and so will become my
unwilling testers".


No, the argument is this:
If I had a way to be moderately sure that my main work machine would be
usable every day running fedora and I could test things on a less
important machine, I'd be much more likely to run fedora more of the
time and on more machines.



2. The people who are the providers of the testing, aren't necessarily
running the same kinds of workloads as the people who want to just be
consumers of the testing.


Exactly - it doesn't work that well as is. And even if I wanted to test
exactly the same work on exactly the same kind of machine, I don't think
I could predictably 'consume' that testing value - that is, there is no
way for me to know when or if a 'yum update' on my production machine is
going to reproduce exactly the software installed on my test machine.
(Personally I think this is a generic yum problem and it should provide
an option for reproducible installs regardless of what is going on in
the repositories, but that's a slightly different issue...).



...and to be fair, there are certainly improvements that could be done
on the tools side to help people test and report, and the limited
resources currently available are working to make that better. But,
personally, I don't see how an updates-tested or updates-after-1-month
etc. etc. is going to help in the long run. Sure, in the short term.
it'll help all the people that know about it at the expense of those
that don't ... but that isn't a good feature, IMO.


I think there will always be a mix of machines where testing is
appropriate and desired and ones where more predictability is a
requirement and often the same people will have have some of both types.
The question is whether it is possible for fedora to be appropriate to
run on both. If it isn't, I don't see much value to be obtained from
the testing part. If it is possible to manage the repos or updating
tool to do the right thing for both environments without a lot of extra
work, I think you'd see a big increase in both usage types.


--
Les Mikesell
lesmikesell@gmail.com


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

James Antill wrote:


1. Too many people want to be consumers of the testing but not the
providers of it.
Indeed IMO the whole updates-tested argument seems to devolve to "I'm
going to be clever and switch to this, but I'm pretty sure a bunch of
other people aren't going to know immediately and so will become my
unwilling testers".

One of Fedora's goals is to turn users into contributors. What better
way to do that than to make every default-retaining user an unwitting
brick in a colossal meat wall?


--CJD

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

Callum Lerwick wrote:


Regressions are inevitable. Why are people afraid of regressions?
Because it breaks their system. Why are people so afraid of breaking
their system? Because they're afraid they can't fix it.

Solution: Make recovery from regressions easy. So easy a trained
monkey could do it. Make it routine. Make it familiar and
non-threatening. Make it a normal part of everyone's daily life.


The problem is that the reason you want to recover is that there were
bugs in what you installed. The same reason for having bugs in what you
installed is going to cause you to have bugs in your recovery mechanism.
So, while this is a reasonable thing to want, it is not reasonable to
depend on it to work every time. Something like a clonezilla image copy
off to an external disk or network storage might be safe, but not always
convenient.



Embrace change. Embrace regressions, instability and bugs. Fedora is
Extreme Linux. I posted my roadmap for doing this in the "My roadmap
for a better Fedora" thread.


It's only really extreme when you are the first one running a particular
package in a particular environment. If I had a handy way to run
updates on a test machine a week or two before getting exactly that same
update on a more critical machine (and bailing completely when problems
are found) I'd be a lot less concerned about regressions.


--
Les Mikesell
lesmikesell@gmail.com

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

On Wed, 2008-11-19 at 15:35 -0500, Casey Dahlin wrote:
> James Antill wrote:
> >
> > 1. Too many people want to be consumers of the testing but not the
> > providers of it.
> > Indeed IMO the whole updates-tested argument seems to devolve to "I'm
> > going to be clever and switch to this, but I'm pretty sure a bunch of
> > other people aren't going to know immediately and so will become my
> > unwilling testers".
> >
> One of Fedora's goals is to turn users into contributors. What better
> way to do that than to make every default-retaining user an unwitting
> brick in a colossal meat wall?

If you want to ask Jesse to enable updates-testing by default, feel
free to do so. It's certainly better in many ways than creating an
updates-tested repo.

However I think there is a big difference between wanting people to
opt-in to contributions and doing it for them.

--
James Antill <james@fedoraproject.org>
Fedora

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

On Wed, 2008-11-19 at 14:26 -0600, Les Mikesell wrote:
> James Antill wrote:
> >
> >> That may or may not be true and it may or may not matter. All you need
> >> is some large representative sample doing the early testing and a way to
> >> ensure feedback to improve everyone's experience. And letting users
> >> control their exposure to new bugs might increase the user base in both
> >> categories.
> >
> > This is what updates-testing _already does_. As Jesse has already said,
> > there are two big problems:
> >
> > 1. Too many people want to be consumers of the testing but not the
> > providers of it.
>
> I think that's an unwarranted assumption. How many people even know
> about updates-testing compared to people that never change defaults?

Certainly everyone in this thread knows about it.

> How does someone using updates-testing ensure that their usage
> 'provides' something?

bodhi -k +1 -c 'pkg FOO, works for me'

...or even just leave the comment.

> > Indeed IMO the whole updates-tested argument seems to devolve to "I'm
> > going to be clever and switch to this, but I'm pretty sure a bunch of
> > other people aren't going to know immediately and so will become my
> > unwilling testers".
>
> No, the argument is this:
> If I had a way to be moderately sure that my main work machine would be
> usable every day running fedora and I could test things on a less
> important machine, I'd be much more likely to run fedora more of the
> time and on more machines.

So subscribe your work machine to just updates, and your test machine
to updates-testing ... what is the problem here?

> > 2. The people who are the providers of the testing, aren't necessarily
> > running the same kinds of workloads as the people who want to just be
> > consumers of the testing.
>
> Exactly - it doesn't work that well as is. And even if I wanted to test
> exactly the same work on exactly the same kind of machine, I don't think
> I could predictably 'consume' that testing value - that is, there is no
> way for me to know when or if a 'yum update' on my production machine is
> going to reproduce exactly the software installed on my test machine.
> (Personally I think this is a generic yum problem and it should provide
> an option for reproducible installs regardless of what is going on in
> the repositories, but that's a slightly different issue...).

Sure, it's one of the many things on the TODO list to fix ... and with
yum-debug-dump / yum shell / etc. there are a couple of ways of hacking
this kind of thing in.
However if you were running updates-testing refreshes fairly often then
anything going into updates would be fine for you, by definition.

--
James Antill <james@fedoraproject.org>
Fedora

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

James Antill wrote:



1. Too many people want to be consumers of the testing but not the
providers of it.
I think that's an unwarranted assumption. How many people even know
about updates-testing compared to people that never change defaults?


Certainly everyone in this thread knows about it.


So maybe a dozen people...

How does someone using updates-testing ensure that their usage
'provides' something?


bodhi -k +1 -c 'pkg FOO, works for me'

...or even just leave the comment.


That's (a) not something many people are likely to do, and (b) not quite
what I want to know. I want to know that the combination of packages
installed on machine X at time Y worked together correctly (including
the kernel and base libs that may affect but not be specifically tied to
the package in question) before I install that same set on machine Z at
time Y + something.



Indeed IMO the whole updates-tested argument seems to devolve to "I'm
going to be clever and switch to this, but I'm pretty sure a bunch of
other people aren't going to know immediately and so will become my
unwilling testers".

No, the argument is this:
If I had a way to be moderately sure that my main work machine would be
usable every day running fedora and I could test things on a less
important machine, I'd be much more likely to run fedora more of the
time and on more machines.


So subscribe your work machine to just updates, and your test machine
to updates-testing ... what is the problem here?


Is the flow exactly predictable? That is, can I know that the package
set I get from updates will correspond exactly to what I tested earlier?
What is the process for problems detected in testing?



2. The people who are the providers of the testing, aren't necessarily
running the same kinds of workloads as the people who want to just be
consumers of the testing.
Exactly - it doesn't work that well as is. And even if I wanted to test
exactly the same work on exactly the same kind of machine, I don't think
I could predictably 'consume' that testing value - that is, there is no
way for me to know when or if a 'yum update' on my production machine is
going to reproduce exactly the software installed on my test machine.
(Personally I think this is a generic yum problem and it should provide
an option for reproducible installs regardless of what is going on in
the repositories, but that's a slightly different issue...).


Sure, it's one of the many things on the TODO list to fix ... and with
yum-debug-dump / yum shell / etc. there are a couple of ways of hacking
this kind of thing in.
However if you were running updates-testing refreshes fairly often then
anything going into updates would be fine for you, by definition.


Are sets of updates moved atomically from one repo to the next, holding
back the whole set for a problem in one package, or will I really get an
unpredictable grouping out of updates?


--
Les Mikesell
lesmikesell@gmail.com


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

Jesse Keating <jkeating@redhat.com> writes:

> How often have you ran into bad updates that are just thrown away,
> rather than fixed? (and by fixed I mean either the bug caused in the
> update has been fixed with even newer bits, or the old bits were
> re-issued with higher e:n-v-r)

>From that question I gather that this is uncommon. Very well, I am
enabling updates-testing now in a few places. We'll see how it goes.


/Benny

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