Folding Forum

It could be really helpful if the project description webpage would tell the status of a WU, like wether it is in beta or advanced.

Please explain what "really helpful" means. How would I benefit from this knowledge? Could I use this information to fold faster? How would this status get updated? Please explain how this helps the project. Sell your idea to the rest of us...

if I knew the WU i had was clearly marked for beta, I would know that any concerns about it is to be placed in the beta forum. really simple for me to click on the project number in the v7 app and get to the project info page.

I am well aware that if i have client-type=beta, that I'm likely to have a beta WU but there is a possibility that no other beta wu are available and receive advanced or just regular non-beta WU, but I wouldn't know unless I checked.

on that thought, it would be nice if the project description page had a link to a forum thread that covers the current project. this would take me straight to the thread (no searching required) and maybe someone will have solved the problem, or told staff about an issue. that is a real time saver to me.

I actually agree with theteofscuba: I have actually often thought it would be handy to have that information available, I guess easier than attempting to search through the psummaries - if the beta process is now 'open' then there is nothing stopping it other than the effort required to recode things (which may be too much effort).

There is a recurring question on this forum: "Why do I get WU X instead of WU Y"

A note on the project description and/or on the Project Summary, to define that a WU is:
a) Beta/Advanced/Full Release
b) Big/Normal/Small
c) Uni/SMP/Bigadv or GPU2/GPU3(ATI or Nvidia)

would go a long way to helping donors work out which WU's they might be getting, and whether or not they need to change their client parameters.

k1wi wrote:I actually agree with theteofscuba: I have actually often thought it would be handy to have that information available, I guess easier than attempting to search through the psummaries - if the beta process is now 'open' then there is nothing stopping it other than the effort required to recode things (which may be too much effort).

But, if you had an internal psummary like browser in fahControl, and from there it would link to any forum section, would that be enough? But even then the psummary's don't have an field for 'beta/advanced/normal', beta is supposed to be only on psummaryC, but advanced is on C and the normal one, making that also not a good place to judge a work unit from.

I'm not only asking for fahControl, I'm working on an alternative for the control application and I already have this in coding, just not making a difference between beta/advanced work unit's, nor linking to specific forum sections ( which is a great idea and I will certainly use it! ).

MtM wrote:I'm not only asking for fahControl, I'm working on an alternative for the control application and I already have this in coding, just not making a difference between beta/advanced work unit's, nor linking to specific forum sections ( which is a great idea and I will certainly use it! ).

I'm not sure I understand exactly what you said, but if I'm interpreting it correctly DO NOT create an alternative fahcontrol which makes beta/adv/regular WUs interchangeable. The Pande Group intentionally keeps them separated. Beta testing is not for everyone. An unsuspecting donor who thinks they're running released WUs should NEVER get an advmethods assignment or a beta assignment without having explicitly consented and accepted the increased risk of instability associated with non-production projects.

No it's just a project browser from an old project, based on the psummary fields, but if you remember it I already linked to the forum's just not specific for each core/client. I would like to do that, but the summary afaik doesn't show which work unit's are advanced and which one in beta ( well maybe beta from what's on psummaryC and not on the regular one, but for advanced idk.. ). Would require to much work I suppose to add a field to the summary indicating in what development stage it's in? Or do you have another suggestion how to link directly to a section...

Thinking about it, advanced wu's are spoken/discussed in the same section, no need for a new field. Just have to link to the right section for the project ( for instance gpu, and ati or nvidia based on hardware, link to the old v6 nvidia / ati section??? ) Or, better yet, the structure is copied to the v7 client ( which I think you're waiting for till it leaves beta, one section is enough and offers a better oversight on issues ).

theteofscuba wrote:if I knew the WU i had was clearly marked for beta, I would know that any concerns about it is to be placed in the beta forum. really simple for me to click on the project number in the v7 app and get to the project info page.

I am well aware that if i have client-type=beta, that I'm likely to have a beta WU but there is a possibility that no other beta wu are available and receive advanced or just regular non-beta WU, but I wouldn't know unless I checked.

on that thought, it would be nice if the project description page had a link to a forum thread that covers the current project. this would take me straight to the thread (no searching required) and maybe someone will have solved the problem, or told staff about an issue. that is a real time saver to me.

It's an interesting idea, but the project description pages are static pages, updated once when the project is released. Having to update dozens of projects 3 or 4 times as each project moves from internal, to beta, to adv, to fah full release is a lot of work for not much benefit, and only duplicates information that can already be gathered elsewhere.

If knowing where to post about a work unit is your only concern, then look on the Project Summary page. If the Work Unit appears there, then the work unit is public. If not, post in beta. And as a beta tester, you're more than willing to keep up on that stuff anyway. Like all the Project related announcements in the Pande Group topic... http://foldingforum.org/viewforum.php?f=24

Yes, it would be nice if all this could be done automatically, so they wouldn't have to update those announcement threads either, but that's what we have now. Maybe your idea will spark an even better way to do it.


As for X vs Y work units, the answer is always the same. The selection is based on your client and hardware, and then Stanford gives you what they need done the quickest. You can't really change WU selection, so no need to worry about that. If you want beta, use the beta flag. Otherwise it doesn't really matter why type of WU you got, beta or not.

...unless you want this info to chase particular work units because they get a few extra PPD. If that's that case, you're on your own to devise your own PPD hunting tools and skills.

I sent a pm to PantherX but I just realized there is a better way through parsing the announcements section of the forum linked above and hosting that content in xml off the forum ( forums usually don't like the extra load I'd guess ).

7im, a better idea on how to do it? The psummary pages are generated by which servers? Assignment servers should have sufficient logic to know them selfs in what stage of release any project is or they wouldn't know how to distribute them. It's 'just' a matter of generating the psummary with that info. Just written such that it implies there probably are allot of complications or it would have been done if there was enough request to do so.

Edit: that won't replace the announcements section btw as the announcements are afaik meant to be made before the project's change status ( release-beta/advanced/public ). But it does imply there is off course a way to include the status of a project in psummary, the information is there it's a question of making it available and displaying it. Just how complicated that would be is outside my crystal sphere

MtM wrote:The psummary pages are generated by which servers? Assignment servers should have sufficient logic to know them selfs in what stage of release any project is or they wouldn't know how to distribute them. It's 'just' a matter of generating the psummary with that info.

jcoffland wrote:Psummary just reports what the project maintainer puts in their configuration files.

SOURCE


My guess is those configuration files are on the WS, thus WS > AS > PS. And if the info needed is in those files than it 'should' be possible to incorporate it into Psummary.

Yes, let's not forget the multiple versions of the Psummary page. That should help you sort out what project is in what state.

maybe one day the ideas in this thread will be built, when the case to reengineer what is nessecary becomes more compelling in the future.