On Monday, October 14, 2013 11:01:23 AM Robert Schweikert wrote:
Hi,
Sorry for budding in, but.....
On 10/14/2013 05:44 AM, agustin benito bethencourt wrote:
Hi Guido,
On Monday 14 October 2013 11:10:45 Guido Berhoerster wrote:
* agustin benito bethencourt
[2013-10-14 10:46]: The openSUSE Team at SUSE do not maintain openqa.opensuse.org. It
is run
under Bernhard's coordination with a remarkable effort, by the way.
We have developed some improvements in openQA in close
communication with
upstream (Bernhard). He is the one that will decides which improvements
should be implemented and which don't in the openQA service.
We developed the openQA V2 in the open and improved the installation to
make it easier than it was. There is room for improvements though.
Meanwhile, the openSUSE Team have a V2 instance internally to test the
distro and the improvements done.
So what makes SUSE emplyees special to get this privilege?
Priviledge?
Anybody can install an openQA V2 instance. We will provide help to those interested in doing so.
I am not certain what part of "I don't have the resources..." in Guido's response is difficult to understand. However, given that it is apparently hard to comprehend that someone cannot run openQA on their own let me ask some questions rather than making statements.
This response really hurt. openQA and openqa.o.o are owned by Bernhard M. Wiedemann. openQA was developed mainly by Bernhard himself and Dominik. In ther free time. Neither SUSE nor openSUSE Team (at SUSE) own, manage or decides in openqa.o.o During 12.3 we decided that openQA was a really cool project, and that we can help the Release Manager and the release process is we extend and improve openQA in certain ways. In an exercise of responsibility we presented a technical proposal to our managers. In this document we enumerated some basic goals that we expect to achieve is they allow us to work on openQA for 3 months. In other words, we asked SUSE to invest money on openSUSE. We worked on a local branch of os-autoinst and openQA during March, April and May, as you can check here: https://progress.opensuse.org/projects/openqa-improvement/issues/gantt?utf8=%E2%9C%93&set_filter=1&f[]=status_id&op[status_id]=*&f[]=&months=6&month=3&year=2013&zoom=2 During this time, we worked with Bernhard and Dominik to guarantee that the new features that we developed can be integrated in the real openQA (upstream). This was made explicit in its own task (as you can check in the previous Gantt). Overall, SUSE invested nearly $30K in our development time (aprox 500hrs). You can check this fact and the list of implemented features here: https://progress.opensuse.org/projects/openqa-improvement/wiki/Sprint_Report Also, we prepared packages and a tutorial, as you can learn from here: https://progress.opensuse.org/projects/openqa-improvement/wiki/Sprint_Report But all this work was made for two reasons: - To add some featured that can potentially help the release manager - To contribute to a cool open source project We helped upstream, but we are not the owner of the project: we are contributors.
Given the fact that at present we produce two different sets of results, the openQA results at openqa.opensuse.org and the forked instance operated by the openSUSE team, how do we expect a consistent view of the world for all contributors?
The 'forked' version is only an internal instance that is running in a local server. This server is a development server: the full team can access to this server in order to run, develop, break and fix openQA. We can make experiments and 'improvements' according our criteria. This internal server can't provide a service because is user for internal work.
The fork of openQA is running on non community accessible hardware and thus maintainers of packages/sub-systems cannot see the results of the tests run by the forked code. It should be reasonably obvious that this is not a good situation. How can a maintainer of anything be expected to help fix an issue he/she is not aware of?
Why? I mean: this is an internal server. The Real Thing is openqa.o.o. Upstream has the full control of openQA. They decide their own agenda, their own feature set, and their own priorities. This internal server is a internal working tool where we develop and where we break things. We don't have users and many things that The Real Thing need. Is an internal tool for an internal necessity/ Is not an internal tool because we are greedy and evil. We don't seek using the internal server something like 'a super secret openQA version', but only a tool for work on it.
How can a contributor be aware of a problem when it is only displayed on results pages he/she cannot see?
Again, The Real Thing (upstream) is openqa.o.o. So, in this case the contributor can do three different thing here: 1.- She/he can install openQA V1, V2 from Bernhard repo or V2 from openSUSE Team repo and run the tests locally 2.- Wait (and *help*) until upstream deploy the new version in the proper place. Bernhard actually put a big effort in this task as you can check here: https://hackweek.suse.com/projects/49
Why is it so hard to mirror the results from the private instance of the openQA fork to a place where factory contributors can see the results?
3.- Create an external mirror of our result page Create this mirror is not really hard (IMHO), but requires time, and we are now focused in a different task. You need to understand that one that decides in what project we need to work on is our manager and not external criteria like this one.
All of this with the understanding that if the code that powers the fork of openQA the openSUSE team is running is integrated upstream the secondary results page becomes unnecessary and goes away.
You can check that by yourself comparing both repos.
Another option is to wait until upstream include some/all of the changes we made. You can also work on V2.1
Why would you purposefully delay/impede the work of contributors that happen to work for someone other than SUSE?
Again: we are not upstream, we are contributors. How are we delaying / impeding the work from other contributors? We do no manage openqa.o.o, we do no manage upstream roadmap or deployment agenda. We do not maintain openqa.o.o neither.
If you already have the results and are aware of problems why can you not just share the results?
Why would you make the community wait for upstream inclusion of the forked code when you apparently already have results that may be useful but are not yet available upstream, for whatever reason.
We can't decide to open a new project to publish the results of the internal server (whatever that means). IMHO is unfair to demand from one contributor this kind of response. If you install OBS in your internal server, Who am I to demand that you need to publish the results for your internal instance of OBS, to invest your time to create the module that publish these results, and to maintain the server in a way that I demand?
I
maintain a whole desktop in openSUSE and openQA has been an very
important part of my workflow and I have contributed a bunch of
tests suited to my needs. And I simply do not have the resources
(i.e. bandwidth) to run an instance of my own.
Given that, would you please either mirror the results page to a
public server or provide those non-SUSE community members who
have a need for it access to the new instance?
We do not touch openqa.opensuse.org so
No one has asked you to fiddle with openqa.opensuse.org. Although closer collaboration with upstream may be a better use of everyone's time, those are decisions you have to make for your team. What is being asked is that you publish the results from your fork of openQA. This does not appear to be an unreasonable request, nor is it unfair to upstream.
Forking, public discussion, results publishing happen all the time in the FOSS community and we can all deal with it. What is not supposed to happen is that some think they are more special than others and willfully make the work of others more difficult.
We don't forked the project. We contributed to the project using a different branch. Upstream is the one that decides what to include and when.
Please publish the results from your fork of openQA in an effort to make things easier for everyone instead of just the few privileged.
The project need openqa.o.o deployed ASAP. Instead of helping Bernhard in this task you demand to a different team (that made a published contribution to openQA by technical reasons) to publish the results from their internal instance. I agree with the urge of having good feedback from openQA. Why waste the time in this fight instead of writing Perl code here: https://github.com/bmwiedemann/os-autoinst/tree/ost
My $0.02 Robert -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org