Even if i am not a developer in this proyect, may I give an advice?
1) You need two trunks, one experimental, the other 1 day old "booting trunk". 2)Your bot build the experimental trunk (you already have the build bot). 3) Once a day a "boot bot" would try boot the experimental trunk, if it is sucessful (i supouse, sending a "all ok" message throug com1) then it overwrithe the "booting trunk" with that experimental revision. 4)That way there is always a very recent trunk that is stable enough to boot, the testing is automatic, and you have quite narrowed the revisions with the problem.
That way you could be working in a somewhat stable trunk, that can not be older than 1, 2 or 3 days if the experimental is failing.
Best Regards, Lucio Diaz-Flores
---------------------------------
LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com
Lucio Diaz wrote:
Even if i am not a developer in this proyect, may I give an advice?
- You need two trunks, one experimental, the other 1 day old "booting
trunk". 2)Your bot build the experimental trunk (you already have the build bot). 3) Once a day a "boot bot" would try boot the experimental trunk, if it is sucessful (i supouse, sending a "all ok" message throug com1) then it overwrithe the "booting trunk" with that experimental revision. 4)That way there is always a very recent trunk that is stable enough to boot, the testing is automatic, and you have quite narrowed the revisions with the problem.
That way you could be working in a somewhat stable trunk, that can not be older than 1, 2 or 3 days if the experimental is failing.
Best Regards, Lucio Diaz-Flores
While it all sounds great, it suffers the same problem as any other attempt at an automated solution that divides stable vs unstable. You can't develop against stable, and if unstable is constantly broken than other coders can't get work done. The only solution I can see is developer diligence and a system that helps detect breakage.
We are currently working on several related things.
BuildBot/Master already build all revisions and list/log the status/success in several ways (html, irc bot msg, etc.), and there are investigations ongoing to add scripts to test the builds in a virtual machine (setup, regression testing test apps, etc.). Plus there will be two start pages on the website, one for the community and one for development around ReactOS. Both pages will present the latest activity which is interesting for each group of people.
community: forum, wiki, compatibility and svn commit activity development: svn commits, buildbot, bugzilla and translations (ros itself and website)
So, if you want to test ReactOS trunk, just visit the community (or dev) page and copy&paste the latest known good revision to your svn client.
If you have any suggestions/ideas, just mention them here.
On Oct 18, 2006, at 11:41 PM, Lucio Diaz wrote:
Even if i am not a developer in this proyect, may I give an advice?
- You need two trunks, one experimental, the other 1 day old
"booting trunk".
That's called "stable branch"
2)Your bot build the experimental trunk (you already have the build bot).
That's how it is now
- Once a day a "boot bot" would try boot the experimental trunk,
if it is sucessful (i supouse, sending a "all ok" message throug com1) then it overwrithe the "booting trunk" with that experimental revision.
It should try every revision, otherwise there is no use from it at all. And automerge from trunk to stable branch is not possible, because patches usually depend on each other.
4)That way there is always a very recent trunk that is stable enough to boot, the testing is automatic, and you have quite narrowed the revisions with the problem.
Unfortunately world is not that easy :-)
That way you could be working in a somewhat stable trunk, that can not be older than 1, 2 or 3 days if the experimental is failing.
Best Regards, Lucio Diaz-Flores
WBR, Aleksey Bragin
-
Aleksey Bragin -
Klemens Friedl -
Lucio Diaz -
Reuel ben Yisrael