| Re: Let |
| by Mithrandir on 2005/9/1 18:54:20 I got ahead of myself on this one. I am thankful for the work done so far, with the number of people willing to do organised testing and I'm sure that we will benefit greatly from it. but just now we'll slow things down just a notch. Internally in the core developer team, we need to work out some rules and procedures to go by, before we can load things on your shoulders. So disregard what I said about the weekly betas etc. but stay ready for beta testing, when we get there. |
| Re: Let's validate our process |
| by Mithrandir on 2005/8/31 13:49:33 Forgot to answer this: Quote: Do the Core devs wish to do the upgrade/install on the beta server? For each release I will probably have one test site for an upgrade and another for clean install, just to check both aspects. No, I don't think that is a good idea. When I update or install, I rarely make mistakes or put in invalid data... when a beta tester updates or installs, he/she SHOULD make mistakes and put in invalid data on purpose. So it would be best if the beta testing team had a couple of people with credentials to the beta sites so they can update them. |
| Re: Let's validate our process |
| by Mithrandir on 2005/8/31 13:46:42 I think what we would like the best (but will have to get this cleared with the rest) is a fixed weekday, where betas are available (we can perhaps use a cron job like with the CVS Nightly releases) and then the beta testers will have x days to test it and report problems. I think that a release on Wednesdays and reports due by Sunday is a good scheme. With automated releases, we can also focus on writing some information for you instead of spending the time exporting and packaging stuff from XOOPS CVS. For example, every Wednesday at 10.00 AM GMT, I will have written a report on what has changed in the core files since last week, so beta testers know what to test. I could probably also let bugs "carry over" from one week to another - like "We know this one exists, but haven't fixed it/cannot reproduce it yet" Since available time is just as unstable for us as it is for most people here, it is important to have some room for slow pace from time to time. |
| Re: Let's validate our process |
| by Lance_ on 2005/8/31 13:25:17 Quote:
Hence the reason we have setup a couple of testing sites for the team. A bug, unless very specifically caused by server setup, should be reproduced on the test servers which run common webserver specs. About timetable, do we organize things on weekly basis? so that all releases are done the same day of the week (Tuesday or Wednesday for example). This way the team knows that all testing needs to be done by the Sunday for bug reports to be, hopefully, applied to the next RC release of that week. Do the Core devs wish to do the upgrade/install on the beta server? For each release I will probably have one test site for an upgrade and another for clean install, just to check both aspects. Cheers. 
|
| Re: Let's validate our process |
| by m0nty on 2005/8/31 10:48:08 Quote: One thing, though, how do we do about errors that we cannot reproduce? When we are debugging and troubleshooting, but cannot test? Who do we talk to? i don't think there is much you can do about that, other than if possible to contact the person who reported it and get as much info from them as possible. phpinfo() etc, what they did to get the error. in the end it could just be a corrupted file during transfer that maybe the problem. but i would concentrate more on the errors that can be reproduced as they are more general to affect everyone. |
Search
Recent Posts
Who's Online
Donat-O-Meter
| Stats | |
| Goal: | $15.00 |
| Due Date: | Jul 31 |
| Gross Amount: | $0.00 |
| Net Balance: | $0.00 |
| Left to go: | $15.00 |
|
|