Patch testing tree

[Auntie Mangos]

Where do patch testers put their reports in this case where we have several patches testig at once?

I still have to figure that out, but it will probably be one thread, since patches in there shouldn't conflict with each other either by functionality and code changes - crashdumps and such stuff should be pretty clear. Moreover, most users won't recognize to what patch is possible error related to.

How much will this help patches to get commited?

I guess you mean "pushed to mangos/master". Strictly speaking, since it's the main purpose of this tree, I won't put a patch, which isn't supposed to go mangos/master, there.

And how will you select patches for adding to your repo?

Somehow I'll figure out. As written in the first post, I don't plan adding smaller patches and/or unsupported ones (without active author), so I expect patches mainly from Ambal, balrok and such guys, but I'm open to anyone who will write me a request and make his patch more easily reviewable (see http://getmangos.eu/community/showpost.php?p=80536&postcount=2 for example).

This tree isn't supposed to be "put here your patch for testing and don't care", it should serve as a place where developers can put their patches for testing and commit fixes for them, merge new mangos/master every 14 days and so.

I expect no more than 4 patches to be there at once, preferably 1-3 patches, since they are going to be too big for conflicts.

I expect it to "start" when Ambal returns from his vacation, so we can begin with testing.

To put all this in easy scope - imagine this tree as "my implementation of mangos testing branch".

[freghar]

Hi all!

I recently got an idea how to make big patch testing possibly easier for both users and developers, I used the idea behind old Andrew Morton's -mm tree (mm = memory management originally) - testing patches which weren't ready for upstream.

So what I want is a custom tree (repository), maintained by myself, which provides a stable base for several patches for a period of time. That means "we stick with rev 12345 for, say, 14 days and instead of fixing our patches AND making them work on newer revisions, we focus only on patch bugs". After those 14 days, my tree gets updated to new revision and all patch maintainers should merge mangos/master, resolve conflicts and send me a pull request (via email, forum, automatically via cron or special github interface) and I shall include them in my tree for the next 14 days.

If any bugs are found in any patch within those 14 days, testers can report the bug, developer fixes it and then sends pull request / wait for everyday automatic pull and the fix gets to my tree as fast as possible.

End users also gain an advantage. If you look at the patches now, everyone tries to be "on latest rev", but that's changing every day several times and none of the developers is able to update and post new patch say six times a day. That results in patch incompatibility, not that the patches are conflicting with each other, but each of them is made for one or another rev, making them unusable together in most cases.

So the end user would simply clone my prepared tree with patches compatible with each other on revision level.

-----------------

An example:

Ambal wants some testing for some of his patches, say the "updating map system" one. At the same time, balrok/bogie wants to test Alterac Valley patch. And additionally, hunuza's "getting rid of the data blob" patch. So they prepare their patches for a pre-announced revision and let me git-pull from their prepared branches. End users gets the result, test it and report bugs found. If there are any, they get fixed + fixes pulled to my tree, still on the same announced revision. After some time (~14 days) a completely new tree is created from mangos/master, Ambal, balrok/bogie and hunuza gets their patches updated, pulled by me and the testing continues.

-----------------

To cut this short - yes, it's not completely clean solution. Patches may conflict with each other, but if they do, they are related to each other, meaning their developers should communicate and develop together, for example dev A does some framework which dev B uses, so B pulls from A, updates his work above that and sends me a pull request. If two patches are related to each other, but don't conflict at code level (API in src/shared/ by developer A .. versus functions using it in src/game/ by developer B), developer B can pull from A, but at the same time I can pull from A as well and the resulting merge will not conflict in any way. See examples on http://paste2.org/p/335508 .

The second problem are crashes and/or functionality anomalies. They shouldn't get really bad in most cases and if they do and we won't be able to determine the reason easily, there's a nice tool called git-bisect, which can help us here, but I don't expect really big problems that often.

So when a new big patch is to be added, it should be at least lightly tested (ie. it does compile, doesn't crash on start and such), this tree is just to fine-tune patches, catch (hopefully lesser) bugs and make improvements + get feedback on them.

Finally, as I can see around the forum, we don't have a lot of testers willing to post crash dumps or provide useful feedback, and those that wish to, are divided amongst large patches. What I want is just to "merge" them together, so that the testing would be as efficient as possible. It's just an initial idea, it can and WILL get improvements, what I want is to know the real interest of testers and developers in such system.

You don't have to fear about current mangos development style, this is just MY tree, mangos development can continue in a normal and usual way.

Thanks, Freghar.

[freghar]

This topic was meant as discussion, not an announcement. I wanted to hear your opinions on that idea, both from patch developers and testers.

If, however, there's noone interested, it shall fall into the "maybe someday" category.

[eNeRGy]

This topic was meant as discussion, not an announcement. I wanted to hear your opinions on that idea, both from patch developers and testers.

If, however, there's noone interested, it shall fall into the "maybe someday" category.

Good idea, musthave i think. So many bugs appearing after major core modifications in master tree..

[deathseeker42]

I think this is a great idea as well, I'd actually start using this instead of the master tree and submit bug reports.

[Lascax]

I would use it in a "testing-test server" to see if it's stable enough to be tested by more players.

[Patman128]

So, does this mean you are going to fix merge conflicts or will individual patch creators need to fix conflicts before doing a pull request?

Also, will you open a 0.12 experimental branch too?

[freghar]

So, does this mean you are going to fix merge conflicts or will individual patch creators need to fix conflicts before doing a pull request?

Also, will you open a 0.12 experimental branch too?

I will only provide a base for patch authors / testers. When we have something like my tree with ~5 active testers, all of them will be using the same revision with same patches (mostly), so it's easier to compare their test results.

This means yes, I plan to do a 14 days cycle with 7 day knowledge of the next revision (therefore the tree will be always 7-21 days behind mangos/master. That has disadvantages, but advantages as well - for those 7 days we can check if the rev is stable enough to become our next base. That means ~7 days for patch autors to prepare their patches for new rev and fixing possible conflicts. During that time, the "old" rev will still be in use for testing and fixes. The 7-day limit isn't hard-defined, we shall see once the tree is up and running.

I currently do not plan a 0.12 version, because all major patches are being made for mangos/master and needs testing (they're written from scratch). Backported patches to 0.12 are often tested on master, compatibility issues can be fixed in a normal way.

But if there will be interest for such branch in my tree, why not.

[rakic]

Yeah i think its nice to test that dual talent spec, vehicles patches because lots of ppl tested it and they say it works so why not to merge it with master tree and see what we will get or not.

So when this will be ready with all patches for testing?

[Diablox]

Well i like the idea very much but i still cant figure out some things

Where do patch testers put their reports in this case where we have several patches testig at once?

How much will this help patches to get commited?

And how will you select patches for adding to your repo?

Dont get me wrong im just curios how will this work. Im trying to help testing but i dont have server whit enough testers

[rakic]

I think you can implement patch for vehicles first because its realy needed for Dk start area to working nice and we can test that but well probably there missing lots of data in database for vehicles id,hp,mana and other stuff related to use of vehicles.

[Auntie Mangos]

Might it be best to recommend people get themselves to just prior to a mission change, then install patch, then continue?

That minimises the amount of stored stuff the game might have trouble with changes to.