[discussion] New development model?

[freghar]

With the recent "switch" to the Git source control management system, several other possibilities of development style are opening. Those can be in fact applied to CVS/SVN as well, but they can gain more in Git (easier backporting, etc.).

Many people I asked about MaNGOS development style said, that the main problem is no stable releases, yes, there are milestones, but they're finished just by assigning new bugs to the next milestone and fixing current one. So I begun to think about new style(s) of the development process.

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

Since Git came from the Linux kernel project and it was originally developed the way to reflect the current needs, let me explain (in short) how it worked in the past and how it works now.

"3"

Well I wasn't there all the time so I can't say how it worked before 2.2, I just guess it worked the way I remember from times when BitKeeper wasn't in use - patches, tarballs and emails.

The crucial thing was between 2.4 and 2.6, the 2.5 tree. People wanted the 2.4 to stay stable, so unstable stuff (new features mainly) went to 2.5 and only critical and security bugfixes were backported to 2.4 (this reminds me the "odd" and "even" kernel numbering, where even versions were stable and odd ones were for testing -- adopted also by other projects).

After some time, 2.4 became too old with old drivers, some attempts were made to backport several things. Some of them worked (aargh, can't recall those famous names), but mostly, they didn't.

So the 2.5 moved to 2.6 and continued it's stabilization. There were some "where's the 2.7?" mails in the mailing list, but that one never came out. Instead of that, developers merged the new things into the 2.6. This resulted in the way we can see Linux kernel development today and speeded up the development (and testing) a bit. However, as you may imagine, there was no stable version. Many people continued to use old 2.4 just because they didn't want to have "unstable" kernel (all fixes were put in the most unstable head, not much of backports to 2.4 were made).

This was changed with the 2.6.8 version, which had really bad NFS (fcntl) bug, but there weren't just enough changes to release 2.6.9, so a 2.6.8.1 was made. It was used again some time later (can't remember exactly, it was few months before the Git came) and it's in common use since then (see 2.6.16.x called "stable", 2.4.x is also being slowly developed).

So the current release cycle is basically using release candidates. Most (80%?) of the new stuff goes to the -rc1, this means a lot of new regressions, which are being fixed in other -rcs. The final release is (should be) without any known regressions. It's that "simple". The whole thing is a bit more complicated though, there are git "snapshots", generated every day at 7:00 and 19:00 (IIRC, not sure about that), patches for almost everything (so you don't need to download full versions), etc.

New patches are "stored and tested" in the new linux-next tree (there are currently some problems with it, so, as you can see, not only "our" development model is changing)..

This is just FYI, I don't want exactly the same model for the MaNGOS project (just because there aren't too many servers to host this stuff on, a lot less developers, etc.), it's just here because it has some good points that could be used.

"3"

So we're finally at the point of this topic. You might call it "the straight dope".

"2"

I guess I don't need to write much about this one, it should be similar as is in the Linux kernel, possibly with additional modifications.

* Merge new and partially tested stuff

* Resolve regressions, problems, crashes, etc.

* Stabilize it

* Make a release

... with testing all the time around release candidates.

It's also good for bug reporting problems. Tester can say "I have this problem with 0.13-rc2" instead of saying "in r648318" or "around 21.12.2008 in 3fg8ac0".

"2"

However, some people want even more "agile" development style and "rolling releases", that simply means keeping current style as it is, with just speeding the process a bit. That's possible to do as well.

One example would be to make another "testing" branch (or more of them) and test potentially unstable stuff. Like arena patch, AV patch, etc. The unstable branch could have it's own release candidates, but it could be hard to sync it with the "master" one.

This approach is done also in kernel. Some people maintain 2.2.x trees, some 2.4.x, some other their own trees, like Alan Cox's "-ac", or Andrew Morton's unstable "-mm" tree, where new stuff is tested (not sure how it's done now, when linux-next exists) and others.

However, this approach can be also done on the patch author repo's side (and merging it into the official branch), just like barlok's changes are maintained at the moment, so it would be probably only for authors without a public git repo (and those are pretty rare as you need to play with git-format-patch anyway).

"2"

I had other ideas, but those got lost over time, maybe some of them appear in the discussion below this article and I really hope there will be any (!).

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

So, there we have pretty unexpected "end" of this small article. It's purpose is NOT to declare a new way of development, but to start a discussion about this. And I don't mean discussion about "Git vs. SVN", that's another topic.

Thanks for ideas,

Freghar

[VladimirMangos]

Mangos development fully dependent from client changes in fact.

So most stable point is just before client switch, and most unstable after client switch.

This set single proper time for any release. Any new features strongly connected to new client and can''t be backported to like stable release branch. Can be backposted only very local typos fixes.

So we have current way to development.

[Neo2003]

If you take Freghar point on drivers. New drivers exist now for "old" hardware.

Core miss many stuffs that are immortal and disconnected from client version. Features offy adds are not here for 1 month, they usually stay (except all spell related stuffs or new BG). Ex: The outdoor pvp in Outland zones and newer. So they most can be back-ported to older client and some even to 1.12.x if we had one.

[VladimirMangos]

"Can be backposted only very local typos fixes." This has bee not very correct conclusion ofc.

I backport many not local changes to mangos-0.12 for switch time. Main problem with more backporting is DB structure changes. It's hard backported: backporting break possibility safly upgrade DB to master branch DB structure.

But as i think some way for this found in result team discussion.

But main my points still same:

1) development for latest client as only possible by many reasons.

2) old client branch not for development but for fixes and for backporting approriate parts from master branch.

[hikikomori18]

I like how it is now. It also makes everyone become a tester/bug reporter because they find the new stuff.

If it was the other way people and even the newbies would all use the stable version and few would be left testing for the next "milestone". No one would test, most would just leech and beg for an update.

Sorry if I don't have that much faith in human nature, lol. but you've seen how there's a moderate majority of people, who want one click installs and spamming threads without searching.

[SaBrak]

Definitely go for a Civ 3 model with the bargaining table, where anything you and the other civ have, and treaties, can be proposed in any combination. Its obviously superior to the current model.

[freghar]

Civ 3 model = ?

[caeruleaus]

it looks like either he's the same person from this forum (Second poster):

http://apolyton.net/forums/showthread.php?t=103143

or he just copied and pasted something that looked nice...

[FragFrog]

To be frank, I would very much welcome a milestoned release cycle, with appropriate feature-freezes and bugfix periods.

Currently I am working with the 0.12 branch. Tested out about a dozen versions between 8138 and 8452 so far, but none of them was stable. Some were quite stable (uptimes of half a day to a day ), others not so (we're lucky if they'd stay up for more than an hour). Especially from an old branch like 0.12 I would expect a certain level of stability and 'finalisation', but this seems a wild dream - 8406 or so even introduced a major bug in the 0.12 branch (which was fixed in 8414).

Yes, new features and an agile paradigm have their uses, but the Windows Crashdump threat is full of people with the exact same crashdump (some loop in spellCastAura it seems) and the only response to this I have seen was from Vladimir (here) who did some work on it in 8404 - unfortunately this did not resolve our problems.

There are two points I am trying to make here:

1. If you want a 'stable' version, there is absolutely no telling which release should be picked. Maybe 8137 is more stable than 8452, maybe 8463 is even more stable and maybe 8478 is crashy as hell (random examples) - there is simply no way to tell except testing, which on a live platform is not something you want to be doing.

2. Development focusses primarily on new features and bugs, not stability or code-maintainance. I have seen some commits from Vladimir to refactor and clean up code, but he seems to be the only one concerned with this.

The net result of this for server owners is that if you do happen to find a stable version, you stick to it no matter what since even a small update may cause all sorts of trouble. I am a professional software developer myself and from experience I know that cleaning up, refactoring and in general code maintainance is not the most fun thing to do. Let alone concentrating solely on stability and bugs instead of adding fun new features. But that does not mean it should not be done. I work professionally primarily with MySQL, Apache, PHP, all open source projects (or used to be to some degree), and all of them 100% stable with hundreds of users. So why does Mangos have to crash every 5 minutes if a user casts the wrong kind of spell against someone with the wrong kind of aura (example)?

My apologies if I sound unsatisfied - I really do appreciate all the great work you guys are doing. But the current development model is a nightmare for me and server owners everwhere

[VladimirMangos]

0.12 branch isn't like normal software stable branch, it more like branch for old OS version after switch main development to new OS version support. It continue developement in terams backporting fetures. If some not client specific feature implemented why not add its support to another client supporting version?

In general most stable version for mangos is mangos release that mostly done before support switch to another client.

Just update only from release to release. But i know, you want more working features no, not half year later But what you expect in like case?

Also just fixes apply, but for example spell crash at cast can required backporting some new writed framwork for some spell types that it self ofc have chance adding another bugs...

Providing as examples normal desctop application incorrect: online game server work is event driven mostly - some event triggering code that can set another triggers (like auras, object in world, etc) that can triggred with some delay with infinity possible combinations.

And this event dependent from code but also from DBC/DB data that we not control fully and impossible checks at 100% at loading. We have many checks for avoid problems but most crashes related to infinity event trigering sequences or triggering events from object list processing with in result modify this list by inderect called another event code... this impossible solve in generic (at least without make code really slow).