Hi
there is this problem, that Factory is sometimes broken but it would be nice if people had a safer way to test new software even between milestone-releases (which are manual factory-snaphots).
via https://fedoraproject.org/wiki/QA/Tools I found something I wanted to have for openSUSE, too: https://fedoraproject.org/wiki/Israwhidebroken.com_Proposal
I did s/rawhide/Factory/ s/chewtoy/Factory-tested/ and seeded this onto http://en.opensuse.org/openSUSE:Factory-tested_Proposal
It is about creating a snapshot of Factory whenever it passes all basic automated tests (aka critical path) - preferably with minimal human intervention (aka hard work) needed. I have much of the automated testing done, so what is missing is a way to trigger+do the snapshotting.
Ciao Bernhard M.
Den 16. nov. 2010 12:03, skrev Bernhard M. Wiedemann:
Hi
there is this problem, that Factory is sometimes broken but it would be nice if people had a safer way to test new software even between milestone-releases (which are manual factory-snaphots).
...snip
It is about creating a snapshot of Factory whenever it passes all basic automated tests (aka critical path) - preferably with minimal human intervention (aka hard work) needed. I have much of the automated testing done, so what is missing is a way to trigger+do the snapshotting.
Do I understand you right that Factory iso sometimes are broken and should undergo a better QA testing on each build before being published?
I.e comparing the current builds for Milestone-3 with Factory, we have
openSUSE-NET-Build0845-x86_64.iso 08-Nov-2010 21:42 161M http://download.opensuse.org/distribution/11.4-Milestone3/iso/
openSUSE-NET-x86_64-Build0876-Media.iso 18-Nov-2010 17:57 161M http://download.opensuse.org/factory/iso/
By the way, I've found myself soon on the latest Factory iso, or rather using online update to Factory with 'zypper', even if I started out with the latest Milestone distribution. This to find out if issues are solved before reporting new bugs or to test fixes after reporting bugs.
A question aside, after using 'zypper up' first: Why can thereafter 'zypper dup' suggest to downgrade some packages with the same repositories available? I thought that 'zypper dup' should upgrade at least to the same or newer versions than 'zypper up'.
Terje J. Hanssen
Am 18.11.2010 22:24, schrieb Terje J. Hanssen:
Den 16. nov. 2010 12:03, skrev Bernhard M. Wiedemann:
Hi
there is this problem, that Factory is sometimes broken but it would be nice if people had a safer way to test new software even between milestone-releases (which are manual factory-snaphots).
...snip
It is about creating a snapshot of Factory whenever it passes all basic automated tests (aka critical path) - preferably with minimal human intervention (aka hard work) needed. I have much of the automated testing done, so what is missing is a way to trigger+do the snapshotting.
Do I understand you right that Factory iso sometimes are broken and should undergo a better QA testing on each build before being published?
The current Factory distribution (not only isos, but mainly repos to use with "zypper up") does have uses, too. But often enough, bugs creep in there and can prevent developing+testing+using this completely. So my idea was to have this backup repo of factory that gets updated 2-7 times a week, but only if automated tests showed that it was good. e.g. during last week, you could not install factory for 36h so it would have been nice to have something older (yet still newer than MS3)
I.e comparing the current builds for Milestone-3 with Factory, we have
openSUSE-NET-Build0845-x86_64.iso 08-Nov-2010 21:42 161M http://download.opensuse.org/distribution/11.4-Milestone3/iso/
openSUSE-NET-x86_64-Build0876-Media.iso 18-Nov-2010 17:57 161M http://download.opensuse.org/factory/iso/
By the way, I've found myself soon on the latest Factory iso, or rather using online update to Factory with 'zypper', even if I started out with the latest Milestone distribution. This to find out if issues are solved before reporting new bugs or to test fixes after reporting bugs.
A question aside, after using 'zypper up' first: Why can thereafter 'zypper dup' suggest to downgrade some packages with the same repositories available? I thought that 'zypper dup' should upgrade at least to the same or newer versions than 'zypper up'.
yes, this can happen. updating is about finding solutions with certain constrains. e.g. "zypper up" should never propose to change vendors, but dup does.
Downgrading could happen if some new application is built against a specific old version of a library. Then to dup the application, it would have to downgrade the lib.
And then some people change their versioning scheme from xyz-20101119.rpm to xyz-1.0.rpm which might also count as downgrade.
Ciao Bernhard M.
On Thursday 18 November 2010 23:47:45 Bernhard M. Wiedemann wrote:
The current Factory distribution (not only isos, but mainly repos to use with "zypper up") does have uses, too. But often enough, bugs creep in there and can prevent developing+testing+using this completely. So my idea was to have this backup repo of factory that gets updated 2-7 times a week, but only if automated tests showed that it was good. e.g. during last week, you could not install factory for 36h so it would have been nice to have something older (yet still newer than MS3)
We need fallback options all over the distro that will mitigate sometimes serious problems that creep in with updates.
Something that can be used by users that are not skilled in software troubleshooting for instance ability to install software and if it has problem that they can't troubleshoot, revert to previously working, and report that. In my humble, if that would be present, we would have 80% of openSUSE users doing that.
The problems with current workflow that prevent this are: * shared responsibility for bug fixing by distro and upstream; only developer knows what patches are used only by openSUSE, so when we report something we need answers fast * missing contacts between developers taking care of packages and reporters that appear mainly on forums, ** few volunteers that are willing to be liaisons between developers and unskilled users need much more attention in bugzilla when they report bugs then random reporter ** they need instructions that they can translate to user level troubleshooting techniques, ** they need that fast because they serve users that are not patient when computer doesn't work
And then some people change their versioning scheme from xyz-20101119.rpm to xyz-1.0.rpm which might also count as downgrade.
How that works depends on how smart is version comparison. If it is meant for 1.0.0-1 schema then it will fail on any other string. Also the last part -1 (build version) in above can produce problems between projects (vendors) that have independent build numbers. It is basically meaningless to compare that part, but how it works in reality we should ask someone from zypper or YaST team.
-
Bernhard M. Wiedemann -
Rajko M. -
Terje J. Hanssen