F8 kernel-2.6.24.3-12.fc8

[Andrew Farris]

Anders Karlsson wrote:
> * Andrew Farris <lordmorgul at gmail.com> [20080310 13:18]:
>> Anders Karlsson wrote:
>>> * Andrew Farris <lordmorgul at gmail.com> [20080310 12:18]:
>>> [snip]
>>>> Again.. as has been stated previously by people with authority around 
>>>> here (which I am not)... testers did not provide proper feedback on this 
>>>> kernel, via the tooling in place for it [1].  Proper QA is not the 
>>>> responsibility of someone else.  It is the responsibility of the 
>>>> community.  People's lack of participation in how the system works are 
>>>> their own failure in this case.
>>> So the Fedora process is;
>>> "If *we* break it, it's *your* fault because *you* did not test it" ?
>>>
>>> I stand by my earlier comment that this shows little but contempt for
>>> the userbase.
>>>
>>>> Fedora devs have *countless* times proven they care what the users think 
>>>> about this type of situation, but users who only share what they think 
>>>> after shit breaks are useless to everyone.
>>> Oh, I'm sorry. I thought that the idea was to have a three-tier system
>>> with stable, testing and unstable repos (to borrow terms from Debian),
>>> where the idea is to run stable if you intend on doing something
>>> productive, testing if you participate in QA and unstable if you like
>>> living on the edge.
>> That is in inaccurate picture which probably has alot to do with your 
>> frustration over this.  Debian's unstable and testing are completely 
>> separate repos not intended to get flowed together at a regular timeframe.  
>> Fedoras are meant to be very temporary, for testing.  Updates-testing is a 
>> place where things desperately need testing interaction so they can be 
>> pushed because they are only there because they fix known bugs... not 
>> because its new stuff that happens to be unstable and is not getting 
>> dropped into the primary repo.
> 
> As a suggestion to improve things then, why not regularly have a
> roll-call on the standard fedora-list asking for volunteers to
> participate in using the updates-testing repo? Preferably with a short
> few lines about "how to enable it, and how to disable it again should
> you wish to stop participating" ?

Good ideas.

>>> Pushing known broken packages from testing to stable is not
>>> acceptable, just because it did not receive enough QA in testing. Yes,
>>> you get what you pay for, but work ethics should prevent these things
>>> from happening.
>> It was known to fix some bugs.  Feedback was not provided about having 
>> major breakage.  What exactly is the proper procedure in your eyes here?  
>> Not push the kernel which is known to fix bugs?  I'm really curious.
> 
> Fixing bugs is good, but pushing broken packages is bad. I'm not
> saying bugs should not be fixed, but knowingly introducing breaks
> elsewhere seems to be putting the cart before the horse a bit. If the
> bugs fixed were security related, or critical (known data corruptor or
> similar), I can see the need.

I agree, 100%.  Broken packages shouldn't be shipped.  The question is whether 
something is seriously broken, or happens to be broken for 1 or 2 people with 
strange hardware, odd configurations, or transient problems.  Keeping in mind 
this is not a distro intended to fit into the 'nothing will ever break' 
category.  The front page of fedoraproject.org should make that one pretty 
clear.  The minimal testing feedback received in that case would have made me (a 
tester) think it was perfectly reasonable to push it... up to the time the push 
comment was posted to bodhi.

> Proper process... Well, I'm just an end-user, so my opinion does not
> weigh much. I would however expect that the process in place to handle
> the situation, and in all fairness - it does seem to work quite well
> most of the time.
> 
>>> Fedora 8 is released, it is supposed to be the "stable" branch, or are
>>> you trying to tell me that Fedora 8 is still in development, even with
>>> Fedora 9 pending? If so, are users supposed to run Fedora 7 to ensure
>>> they are not being treated as lab-rats?
>> You can answer this question, see above.  Do you want known bugs to get 
>> fixed? How many weeks do you want to wait for them?  Would you prefer 
>> nothing get released until its had an 'adequate' testing, and never get 
>> released if not?  Do you realize that because there are obviously not 
>> enough testers this means that *most* updates will never get released?
> 
> Do I want bugs fixed - yes, but not with the pricetag of breaking
> other functionality *knowingly*.
> 
> What you are describing is a problem with packages not getting
> adequate exposure to testing - and I have made a suggestion earlier in
> this mail about what could be done to help that.

I agree, more testing exposure *AND* participation is needed and is the real 
root cause of this problem.  Updates cannot be shipped knowing they are valid 
unless someone tests them, and thats the point of my comments up to now.  The 
primary assumption of using Fedora is that it is as good as the community helps 
make it... a drastically different scenario to RHEL and its important to understand.

>> Welcome to CentOS (just go install it now).  That is not what Fedora is 
>> supposed to be about, at least from my perspective and why I spend my time 
>> with it.
> 
> I've got CentOS equivalent running on some systems, and for my X60s I
> went with F8 for driver reasons. I'm just surprised about the shift in
> focus in Fedora, that's all.
> 
> The kernel update did not eat any data for me, it just broke X for
> me. Rolling back kernel, problem solved.
> 
>>> I must be incredibly dense - so I'd appreciate a thorough explanation
>>> about this situation just so I know what to do to avoid having my
>>> systems sabotagued in future. If I understand you right - you are
>>> saying that Fedora does not want "just users" because they are totally
>>> useless and just a burden to the project?
>> That is not at all what I said, or meant.  What I said is people with 
>> nothing but complaints after the fact are helping nothing.  That does not 
>> mean they cannot use the distro, nor does it mean the community is not 
>> *intended* to work for them and prevent this.  What it means is they are 
>> not part of solution or prevention.  Thats it.  The community as a whole 
>> should have prevented this; yet in this case it failed to do so.  A 
>> situation to be learned from, not one to pack up camp and run away from.
> 
> And what else are the "just users" supposed to do, after the event,
> when they sit with a system that for some reason no longer will let
> them start X, use their wireless network or suspend/resume? They *are*
> reporting the problem because someone broke something for them,
> something that used to work. That's called 'regression', and that is
> usually taken quite seriously in software development.

I think its bad, very bad.  But the fact that it happened is not the end of the 
world either.  The regression can be fixed (unregressed!).  It happens in 
commercial software at *regular intervals* as well (although, the linux 
community should be better than that).

> If the required steps are to get the packages exposed to more testers,
> then I'd expect steps to be taken to recruit more testers. Advertise
> the updates-testing repo more, encourage its use, prod the mailing
> lists regularly for participants. Yes, we should learn from this, as
> that is what good organisations do. Leverage the information in Smolt
> as well, maybe have a push with that, allowing people to tick a box
> saying that "Yeah, I could be interested in doing some QA for you"
> when submitting the hardware profile and then use that to get as much
> coverage of hardware as possible.
> 
> Thanks!
> 
> /Anders

That is excellent feedback and I hope there are documentation people taking 
notice of this thread.

-- 
Andrew Farris <lordmorgul at gmail.com> www.lordmorgul.net
  gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----