Make Unstable Testing Easy (Is This Even Possible?)

[vbgunz]

This is just an idea. nothing more. honest. You know how it's possible to install another desktop and switch to it before you log in? How hard would it be to add an option for 'trunk' or 'nightly' or 'alpha' or 'beta'? everyone knows these are tabooed versions of stable and any one of the former options is able to impregnate your daughter with twins *but* how hard would it be to actually separate stable from etc?

If this were completely possible the only downsides I could see to it is servers would probably be hammered to death. Also, some people would either not report bugs or seriously provide bad reports.

But, what if there was an answer to these problems and the solutions resulted in a better final KDE/Kubuntu distribution?

I don't have the answers but have some ideas. In order to get straight to the point I am going to deliberately leave some of the broader ideas right out and pretty much leave them to the imagination.

torrents (every tester is a seeder) and completely automated (full debugger support, etc) bug/crash/problem reporting. If a user cannot agree to these terms, wait for stable. makes sense?

[dibl]

Re: Make Unstable Testing Easy (Is This Even Possible?)

I give you an A+ for imagination.

However, I think a choice of stable desktop environments to boot into is a very different proposition, than a mystery system, consisting of yesterday's working system plus last night's daily package builds inserted into it. If a person wanted to inflict such an unknown mystery system onto himself/herself, then I suppose you simply install Debian Sid and then apt-get dist-upgrade it every morning, and see what happens. I don't think it will be much fun, though.

[askrieger]

Re: Make Unstable Testing Easy (Is This Even Possible?)

Dibl is correct (as usual). I suspect that you would (unpredictably) wind up with incompatible versions of libraries and programs using them. As to Debian Unstable, I can testify as a former user that my system was never disabled for more than a week, but there was always something, however trivial, that didn't work (kind of like KDE4).

[vbgunz]

Re: Make Unstable Testing Easy (Is This Even Possible?)

I think if some party really made this possible (Using Git OR Anything) to somehow insure a clean separation between stable and testing environments upon log in, the world will follow suit. When I say world I mean every DE and every distro would benefit from such a scheme. It's nice to be told about so many bugs and figure them out later but wouldn't it be greater if it were grossly automated?

Another idea to really pinpoint bugs with accuracy is 'bug tasking' on log in. In other words, get the latest high priority bugs into a human readable list and show it to every tester on every log in. e.g., Task One: Ark crashes when you do A. Could you confirm this? ... The user tries out the task, Ark crashes, an automated full debugging report and system profile is sent back... Ah, this seems to only happen on a Quad 2.6 Phenom processor with less than 512MB RAM (at least that is what all crashes have in common?).

I came up with the idea because I love KDE and Kubuntu but I was sorely let down by the 8.10 release. I never tried any alphas or betas because I didn't have room or an extra machine to test on. I am a part of the problem of letting down my fellow users/developers and sure wish I had helped out. Anyhow, I believe in both projects dearly and would love to see a way the regular average Joe user could help stabilize the next release.

I personally hate bugs and thought this up as a way to get the masses to easily help stomped them out. That's the beauty of an idea so I thought I share it

PS. Do you guys think I should bring this up on Ubuntu Brainstorm?

[askrieger]

Re: Make Unstable Testing Easy (Is This Even Possible?)

Actually, I think you should, especially as phrased in your clarifying post. However, a word of caution (or disillusionment). For a few years, e.g. Breezy through Gutsy, I made it a habit to post bug reports at Launchpad on problems reported by users at this site that I could verify for myself. However, the only responses that I ever received were requests for more information on about 20% of the reports.

Recently, I have begun to receive responses. I have been informed that bugs on obsolete releases have been cleared because those version are obsolete! Bug swatting does not appear to have beeen a high priority at Launchpad. It may be that these reports are passed upstream to Debian and that I just never get notified that the bug had been passed on or of the response, if any, from upstream.

If you can come up with a viable way to implement your idea, by all means do so. With more detailed reports in larger quantities, the developers might get more interested.

[LinuxIsInnovation]

Re: Make Unstable Testing Easy (Is This Even Possible?)

Well, isnt kde already doing this? (kde-nightly, amarok-nightly). They are totally separate with separate config folders.

[dibl]

Re: Make Unstable Testing Easy (Is This Even Possible?)

Recently, I have begun to receive responses.

Confirm - I got a very nice, personal response on the last bug I filed (I don't report many) -- it was on a Konqueror bug in the "browser ID" function, and the dev explained how it is supposed to work, and why, and that he was going to make it work like I thought it should. So, sometimes that can be a constructive thing to do.

I guess the trick with this idea, if I understand it correctly, would be to sort the hardware related bugs among those "testing users" who could actually test them. That seems to be where a lot of bugs kind of die -- if you don't have the combination of "abc" motherboard chipset and "xyz" sound chip, then you can't be of much assistance with a sound module loading bug that happens on that combination.

For software-only bugs, it seems like it could be a helpful approach.