Hi Feri,
Here is a list of things that I see as potential problems: (I haven't checked the code, so they may already be handled)
1. Multiple builds
For a given BUILD_ID, we can have reports comming from different builds now, that is from different winetest-*.exe. That means a much of URLs, etc.
2. Multiple reports
For a given BUILD_ID, we may get multiple reports from the same client (same Tag). This is because of (1), we can ask each client to run not one, but a bunch of the available tests (this is very useful, say we have each client run a mingw build, and a msvc build).
3. Build Info
This is a minor issue, and we can safely ignore it for now, but maybe we can provide a little icon beside each URL that we list in (1), that would popup a window and display the Build Info.
4. Template
Not a biggie, but maybe we can transform the generated report into a template so that it integrates nicely with the rest of the site (menu to the left, etc). Jer, what do we need to do to achive that? I think it should be very easy, but...
"Dimitrie O. Paun" dimi@intelliware.ca writes:
- Multiple builds
For a given BUILD_ID, we can have reports comming from different builds now, that is from different winetest-*.exe. That means a much of URLs, etc.
That's abuse. :) BUILD_ID is intended to identify winetest, not Wine. We can change the design, basically it's about the need of seeing any two reports on the same screen.
- Multiple reports
For a given BUILD_ID, we may get multiple reports from the same client (same Tag).
Yes, it's the same problem as above.
- Build Info
Yes, that's easy.
- Template
I don't know about it anything. Given some guidance I'm willing to change gather, but seems like Jer is bogged down too much...
On Fri, 2004-04-23 at 09:30, Ferenc Wagner wrote:
willing to change gather, but seems like Jer is bogged down too much...
Heh, just a tad. CodeWeavers is close to releasing it's next version of CrossOver so we are all busy here. And on top of that, we are going to be moving to a new office. So between website updates here, and sys/net admin stuff for the move... yeah I'm fairly buried. :-D
Just bad timing. By June, things should be back to normal around here.
On Fri, 23 Apr 2004, Ferenc Wagner wrote:
"Dimitrie O. Paun" dimi@intelliware.ca writes:
- Multiple builds
For a given BUILD_ID, we can have reports comming from different builds now, that is from different winetest-*.exe. That means a much of URLs, etc.
That's abuse. :) BUILD_ID is intended to identify winetest, not Wine. We can change the design, basically it's about the need of seeing any two reports on the same screen.
Well, we had different understandings :) What we need is for the BUILD_ID to identify the _sources_ the tests were build from. But we may have different binaries (even if we build from the exact same sources), because we use different tool chains for example. I am sure we would want all results with the same build id to show up on the same page, so we can easily see the differences between them. Moreover, it would be crazy to create more than one page per day, it would be information overkill, nobody will take the time to go through them.
- Template
I don't know about it anything. Given some guidance I'm willing to change gather, but seems like Jer is bogged down too much...
It looks like the changes are trivial, from what Jer is saying, no?
"Dimitrie O. Paun" dimi@intelliware.ca writes:
On Fri, 23 Apr 2004, Ferenc Wagner wrote:
"Dimitrie O. Paun" dimi@intelliware.ca writes:
For a given BUILD_ID, we can have reports comming from different builds now, that is from different winetest-*.exe. That means a much of URLs, etc.
That's abuse. :) BUILD_ID is intended to identify winetest, not Wine. We can change the design, basically it's about the need of seeing any two reports on the same screen.
Well, we had different understandings :) What we need is for the BUILD_ID to identify the _sources_ the tests were build from. But we may have different binaries (even if we build from the exact same sources), because we use different tool chains for example. I am sure we would want all results with the same build id to show up on the same page, so we can easily see the differences between them. Moreover, it would be crazy to create more than one page per day, it would be information overkill, nobody will take the time to go through them.
That's clear. What about stuffing all this info into the Tag dashes and dots are allowed in there.
I don't know about it anything. Given some guidance I'm willing to change gather, but seems like Jer is bogged down too much...
It looks like the changes are trivial, from what Jer is saying, no?
Yes. I'm a little worried about having the files all across the web server. Currently the page uses relative links to lots of small text files (report fragments). How should we handle these? And what about the permissions? Will Jer give us lostwages/templates/en/reports so that gather can do all its business there?
On April 23, 2004 9:55 pm, Ferenc Wagner wrote:
That's clear. What about stuffing all this info into the Tag dashes and dots are allowed in there.
In effect yes, but this is an implementation detail, we should do it internally on the server side, not expose it outside.
The format shouldn't need to change. The Summary is computed as it is now, as if all these reports had different tags. The breakdown per OS would remain the same, with the difference that things should be: -- grouped by TagID (user). So all reports comming from one box should be grouped together. -- we should try _hard_ to maintain the order of reports in each of these groups. If we sort the alphabetically... -- somehow show discretely these groupings, and identify each run?
Yes. I'm a little worried about having the files all across the web server. Currently the page uses relative links to lots of small text files (report fragments). How should we handle these? And what about the permissions? Will Jer give us lostwages/templates/en/reports so that gather can do all its business there?
I don't think that should be a problem, that's the beauty of having our dir. In fact, you shouldn't care, we can either make reports a symlink to our current dir, or change the config file to point to this new report dir. Nothing should change.
On Fri, 2004-04-23 at 09:00, Dimitrie O. Paun wrote:
Not a biggie, but maybe we can transform the generated report into a template so that it integrates nicely with the rest of the site (menu to the left, etc). Jer, what do we need to do to achive that? I think it should be very easy, but...
1. name the file {filename}.template 2. no need for <html>, <head>, <body> tags. 3. the files would need to be copied into the templates/en subdir of the website. 4. the url would then be /site/{filename}
I'd prefer they were copied to a subdir of templates/en. Maybe /reports or something.
On Fri, 23 Apr 2004, Jeremy Newman wrote:
- name the file {filename}.template
- no need for <html>, <head>, <body> tags.
Just to clarify: we *shouldn't* have these.
- the files would need to be copied into the templates/en subdir of the website.
- the url would then be /site/{filename}
I'd prefer they were copied to a subdir of templates/en. Maybe /reports or something.
So is the 'template/' namespace flat? That is, no matter in what subdir we place the file, we always access it as /site/{filename}?
On Fri, 2004-04-23 at 10:08, Dimitrie O. Paun wrote:
So is the 'template/' namespace flat? That is, no matter in what subdir we place the file, we always access it as /site/{filename}?
No, subdirs are carried over. So if you put a file as: templates/en/foo/bar.template
The website url would be: /site/foo/bar
-
Dimitrie O. Paun -
Dimitrie O. Paun -
Ferenc Wagner -
Jeremy Newman