OK!!! here we go again!!!!

Discuss the future of Warzone 2100 with us.
User avatar
lav_coyote25
Professional
Professional
Posts: 3434
Joined: 08 Aug 2006, 23:18

OK!!! here we go again!!!!

Post by lav_coyote25 »

...not upset yet...  i thought this was already taken care of and was a pretty "dead" issue!!!  lets get this truly DEAD!!!!!

when we were still over at the other site threads from october 2005 - it was agreed upon that the trunk was the STABLE RELEASE point and the branches were the UNSTABLE stuff ...  now if that is true then why is this comming up yet again!!!  this was one of the reasons there was a loss of personel from the old site... please!!!!  lets not do this again!!!  please!! (insert begging on knees smiley here...) :)

# [Fri 02:08:50pm] imo wz need a new branch to test changes...
# [Fri 02:09:18pm] currently branch and trunk are somewhat inverted...
# [Fri 02:11:34pm] huh?
# [Fri 02:12:24pm] currently branch has the functionalities of 'trunk'(features of the new release and relatively stable)
# [Fri 02:12:49pm] while trunk has all unstable factors and wont affect next release much
# [Fri 02:13:01pm] this is as it should be
# [Fri 02:13:12pm] trunk is the mainline for development (ie unstable)
# [Fri 02:13:32pm] stable branches are kept for minor releases (for bugfixes)
# [Fri 02:13:52pm] think of it as a tree and you'll see why the imagery fits
# [Fri 02:14:58pm] actually I think using a branch to do releases is quite unusual
# [Fri 02:15:57pm] i'd like to see where you have that notion from, because all my experience with branches and cvs/svn says otherwise
# [Fri 02:18:51pm] just like in a tree, branches fork off the trunk and then bifurcate further with smaller 'releases', while larger 'releases' come off the trunk
# [Fri 02:19:07pm] that is why the metaphor is used
# [Fri 02:19:17pm] Watermelon2: I have the exact opposite experience with SVN (i.e. usually branches are being used to stabilize the source base)
# [Fri 02:25:31pm] but trunk should be stable...or noone will be able to do further changes based on it...
# [Fri 02:25:48pm] trunk is like a shared development branch for all developers
# [Fri 02:26:11pm] to avoid the overhead and negative effects of branch per developer
# [Fri 02:27:03pm] yes, trunk should always work
# [Fri 02:27:17pm] nobody should check in stuff that breaks trunk, and if they do by accident, it should be reverted
# [Fri 02:30:25pm] Watermelon2: if you prefer something like a branch per developer you have an entirely different revision control system, something like GNU arch or monotone for example
# [Fri 02:31:32pm] and as for "trunk should be stable", it depends on what you mean with that of course, if you mean that it should always compile on every developer's system I agree
# [Fri 02:49:21pm] by 'stable' I mean it shouldnt be flooded with unpredictable massive changes in multiple files
# [Fri 02:50:48pm] if you want to have your work undisrupted, just don't "svn up" for a while
# [Fri 02:51:18pm] but in my experience, it is better to merge earlier and often rather than later
# [Fri 02:51:36pm] but my changes will undo their changes if i dont merge earlier
# [Fri 02:51:47pm] and noone wants his changes to be undo'ed
# [Fri 02:54:11pm] i don't understand
# [Fri 02:54:33pm] if you undo someone else's changes, you are doing something wrong, i would say
# [Fri 02:57:44pm] not really sometimes functions have completely different functionality after a commit and you will have to bin the changes you made,or it will 'override'/undo the changed functions
# [Fri 03:01:53pm] then the devs should probably communicate better about what they are massively rewriting at the moment
# [Fri 03:02:37pm] the key is to keep your patchsets as small as possible, and commit as frequently as you can, to avoid massive conflicts
# [Fri 03:02:54pm] giant patches are bad
# [Fri 03:03:18pm] but sometimes unavoidable when implementing something that requires a massive change
# [Fri 03:03:21pm] but then again coordination is key
# [Fri 03:03:25pm] that is true
Last edited by lav_coyote25 on 19 May 2007, 08:50, edited 1 time in total.
‎"to prepare for disaster is to invite it, to not prepare for disaster is a fools choice" -me (kim-lav_coyote25-metcalfe) - it used to be attributed to unknown - but adding the last bit , it now makes sense.
User avatar
lav_coyote25
Professional
Professional
Posts: 3434
Joined: 08 Aug 2006, 23:18

Re: OK!!! here we go again!!!!

Post by lav_coyote25 »

‎"to prepare for disaster is to invite it, to not prepare for disaster is a fools choice" -me (kim-lav_coyote25-metcalfe) - it used to be attributed to unknown - but adding the last bit , it now makes sense.
User avatar
Watermelon
Code contributor
Code contributor
Posts: 551
Joined: 08 Oct 2006, 09:37

Re: OK!!! here we go again!!!!

Post by Watermelon »

Thanks for the old mailinglist link,think the problem cybersphinx mentioned such as the lack of visible development/coordination/roadmap still exist.

To clear things up,I listed my problems with development here:

1.You will never know what the next commit does/changes
2.My patches to mailing list are like silent raindrops fell-sound of silence
3.The patches are dead/conflicted due to the delay,and I dont have the time to synchronize them,then the efforts are wasted
4.The speed of releases are too slow to draw enough attentions/keep ppl interested in this project,you may say 'we cant release the stuff in development trunk because they are unstable',but that is exactly what the Release Candidates/Nightlies are for

Both users and developers will benefit from RC's/Nightlies,because they not only show the users what the developers have been after,but also make the bug squashing much more easier.

Having a 'we have 2 bugs fixed' release will give the users nothing but a image of 'project dead',because they might think the 2 bugfixes are the only things that happened in the interval(usually months in our case) between current release and the last release.WRP's popularity wont be the same if we get a page-long changelog flooded on major OSS gaming site's news page every 1 month or 2.
tasks postponed until the trunk is relatively stable again.
User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: OK!!! here we go again!!!!

Post by DevUrandom »

I don't see where the SVN manual says something different than the current policy is.
And actually you mean something different than Watermelon who means something different than I.

You:
Releases are created from the trunk, so it shall always be stable, never crash, have no bugs.
Development goes into branches and will one day be merged back into the trunk.

Flaws:
Loss of history: You got to merge (not copy changes from the dev-branch (or even multiple branches, when working like on BerliOS) into the trunk. This will not happen when you do it the other way round, since you can copy from /trunk/ to /branches/2.1/.
You will have problems maintaining multiple versions at once, since once you merge the development branch back, you have no chance to work on the previous version.
Ever seen a tree which grows more in its branches than in its trunk?

Watermelon:
Trunk shall contain current development, but not recieve any big modifications.
Big modifications shall go into branches.

Flaws:
How do you want to get changes into the trunk at all? One day or the other they have to be commited/merged...

To explain this once and for all:
trunk is where the development of new features etc. takes place. It shall compile and run, but nothing more. One day, when the day of the release comes nearer, it will move into an own branch. That is also when it becomes stable, not earlier.
branches/2.0 is where the bugfixing for the 2.0 release series goes on. This shall be stable and not recieve any new bugs. This is also where the releases are created from.
Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3780
Joined: 03 Aug 2006, 19:39

Re: OK!!! here we go again!!!!

Post by Per »

We could use a roadmap. If we could agree on some goals for the next release (2.1), we could perhaps pull in the same direction gettings those things finished.

I think the most important goal should be to make Warzone work flawlessly for multiplayer LAN usage. That means no async bugs, no problems playing with Linux, Windows and Mac users together, and no reproducable crashes during play. If we say that this is the one goal for 2.1, and everything else comes as it may, then we would at least have a direction and a finish line.
"Make a man a fire, you keep him warm for a day. Set a man on fire, you keep him warm for the rest of his life."
User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: OK!!! here we go again!!!!

Post by DevUrandom »

(New post since I bet there will be posts since my last and this one, which is in reply to Watermelon.)

My idea how to fix the issues mentioned by Watermelon:
1. Talk more.
I think we just need to say "I am working on this or that area, expect huge diffs."
One obvious problem is that we don't have deadlines for such kind of work, so "I am working" can extend over several weeks or months.
2,3. I am terribly sorry about this, but they are quite huge and seem to need special care.
4. My idea was to have a commit digest like the KDE Commit Digest to get people informed about current development. Problem is that it is time consuming to find the commits which may be interesting to the users and describe the changes in a few simple sentences. (I am currently at r600 with extraction, but didn't write the text yet.)

The "nightlies" are an interesting idea.
Problem here is that they will be merely "weeklies", we usually are too lazy to update the ChangeLog often enough. I would turn that into snapshots once in a while, without any big annoucements, since that would be a really really unstable version.

RC != Nightly builds...
To me (and thus this project) RCs were always versions which I (we) though would be good enough to make a new release from, but want to test in a wider environment first. Hence the name.
A nightly is just a snapshot, without any relation to a release and any claim to be stable.
Per wrote: We could use a roadmap. If we could agree on some goals for the next release (2.1), we could perhaps pull in the same direction gettings those things finished.

I think the most important goal should be to make Warzone work flawlessly for multiplayer LAN usage. That means no async bugs, no problems playing with Linux, Windows and Mac users together, and no reproducable crashes during play. If we say that this is the one goal for 2.1, and everything else comes as it may, then we would at least have a direction and a finish line.
What I think we need to achive:
- Full x86_64 compatibility. I think the last report is that there are still several issues in the code, we are just lucky enough to not hit them very often.
- LAN stability, as Per said.
- Speed (My work on the terrain renderer might want to get integrated after it got some visibility testing. We might also want to consider changing a few parts of the setup process to make further changes easier. (Most notably texture coordinates.))
- Modability (My work on this can be discarded, since I didn't even meet my own goals.)
- Artistic freedom (Most notably a model loader for some format which supports marked vertices (connectors).)
Last edited by DevUrandom on 19 May 2007, 13:46, edited 1 time in total.
UrbanVoyeur
Trained
Trained
Posts: 50
Joined: 10 Mar 2007, 05:03
Location: NYC

Re: OK!!! here we go again!!!!

Post by UrbanVoyeur »

Some of the issue may be practical as well:

Parts of the WZ code appear very convoluted with rendering, AI, and game engine code mixed in with other things.

The dev versions (branch) are moving very rapidly to clean this up - but it makes them function very differently from the 2.0x trunk. So when you try to reconcile the two and merge a change back in, I can see where it can be very challenging.

Maybe this will be easier once the code is more modular? Then incremental changes can be limited to a smaller, more manageable area...
Last edited by UrbanVoyeur on 19 May 2007, 17:40, edited 1 time in total.
User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: OK!!! here we go again!!!!

Post by DevUrandom »

Yes, that's the plan with all that cleaning up. The issue that some seem to have is that cleanups are not visible to the user.
DevUrandom wrote: 4. My idea was to have a commit digest like the KDE Commit Digest to get people informed about current development. Problem is that it is time consuming to find the commits which may be interesting to the users and describe the changes in a few simple sentences. (I am currently at r600 with extraction, but didn't write the text yet.)
PS: In case someone is interested in doing something like this:
I think a Warzone- (but not necessarily technically) experienced person could accomplish this very well. Simply watch the Warzone warzone-commits mailinglist (or the SVN logs directly) and whenever you see something interesting, write it down.
If you don't understand something or want to know more about it, ask the developer who worked/works on this. Maybe even in an interview style.
Probably the digest should then be quickly controled by a dev, so we don't get any big misunderstandings.
My final target is to have such a summary roughly once in a month, but of course this could come more often.
Kamaze
Regular
Regular
Posts: 1017
Joined: 30 Jul 2006, 15:23

Re: OK!!! here we go again!!!!

Post by Kamaze »

Well, i would approve a 'fixed' road map, for some orientation. And i think the Weekly snapshots would be fine too.

And about the trunk, i see the trunk as some kind of "thing to work on" for a special series like currently 2.0.x.
For the 'big' things i think own branches are fine, like the current branch /sound/.
This should be expanded with /renderer/ and maybe /network/. And keep the trunk for all the smaller things.
At least, this branches should be the development road for 2.1.x and not back ported to 2.0.x.
We all have the same heaven, but not the same horizon.
UrbanVoyeur
Trained
Trained
Posts: 50
Joined: 10 Mar 2007, 05:03
Location: NYC

Re: OK!!! here we go again!!!!

Post by UrbanVoyeur »

DevUrandom wrote: Yes, that's the plan with all that cleaning up. The issue that some seem to have is that cleanups are not visible to the user.
PS: In case someone is interested in doing something like this:
I think a Warzone- (but not necessarily technically) experienced person could accomplish this very well. Simply watch the Warzone warzone-commits mailinglist (or the SVN logs directly) and whenever you see something interesting, write it down.
If you don't understand something or want to know more about it, ask the developer who worked/works on this. Maybe even in an interview style.
- What kinds of things should be in the summaries?

- Does it make sense to do big cleanup in the next rev - even further than in the current dev release, but hold back on some of the other big changes, then incorporate them in later revs in a more modular design?

- Does it make sense to do smaller changes in the sub-point releases, then do a road map for the big changes?

- Or may be just a schedule - dev becomes the beta release trunk every X months. Whatever is in there at that point gets tested for release. If it a particular change can't be fixed in x weeks, roll it back and leave it to the next release.

This may be one way to keep the trunk in line with the dev releases without too much effort.
Last edited by UrbanVoyeur on 19 May 2007, 18:12, edited 1 time in total.
User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: OK!!! here we go again!!!!

Post by DevUrandom »

UrbanVoyeur wrote: - What kinds of things should be in the summaries?
Everything that might interest endusers. (This includes modders.)
Most of the time the details (esp. implementation details) are not necessary, imo.
UrbanVoyeur wrote: - Does it make sense to do big cleanup in the next rev - even further than in the current dev release, but hold back on some of the other big changes, then incorporate them in later revs in a more modular design?
rev = SVN revision?
Which "current dev release"?
I think it will be a while till we can't cleanup anything anymore. So yes, there will be further cleanup. I don't know whether such cleanup should block other changes. Most of the time a cleanup happens, because someone wants to change something, but first cleans up the current code, so the real changes afterwards are minimal.
UrbanVoyeur wrote: - Does it make sense to do smaller changes in the sub-point releases, then do a road map for the big changes?
You mean import minor features into 2.0 and keep the rest for 2.1?
That is current practice. Things like (eg) PNG screenshots recently went back into 2.0.
UrbanVoyeur wrote: - Or may be just a schedule - dev becomes the beta release trunk every X months. Whatever is in there at that point gets tested for release. If it a particular change can't be fixed in x weeks, roll it back and leave it to the next release.
dev? release trunk?
I don't think such a practice will be good. I am more a fan of clear facts. Eg. that I know I can make a change in the trunk which may not be stable, but doesn't need to, since I have enough time to fix it, without having to look at the clock since the next release is only 1 week away.
And actually we had that "only the trunk, no branches" layout last year and I think it introduced bugs which were not detected in time and thus annoyed the users.
UrbanVoyeur wrote: This may be one way to keep the trunk in line with the dev releases without too much effort.
trunk? dev releases?
UrbanVoyeur
Trained
Trained
Posts: 50
Joined: 10 Mar 2007, 05:03
Location: NYC

Re: OK!!! here we go again!!!!

Post by UrbanVoyeur »

i used confusing terms, sorry

svn r1xxx = dev release = svn revision  --> updated almost daily, as new code is written/updated

2.06 = latest trunk

What changes from the current SVN development code do you think should be in the next release (2.07)? What should wait until 2.1 or later?

Do you think the current SVN code (r129x) is sufficiently different from 2.06 that it should be considered a branch at this point?
User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: OK!!! here we go again!!!!

Post by DevUrandom »

Ok, again... For the last time. I will not answer this question another time.

Code which is or is going to be released, resides in /branches/. Eg. 2.0.6 is in /branches/2.0/. This is for bugfixes and tiny features.
Code which is in active development is in /trunk/.
The revision is a versioning number SVN provides for the whole source. It is not specific for stable or development version. From a simple revision number you can not immediately see whether it was a change to the /trunk/ or to /branches/2.0/. This number is not updated by us, but by SVN when we "upload" code into the repository. It can _not_ be seen as a release. It merely is something for developers so they know about which change to the sourcecode someone is talking.
Maybe you want to have a look into the SVN manual for the basics...

The /trunk/ is allready extremely different from /branches/2.0/ (and thus 2.0.6) when it comes to the code. That's also what makes backports more difficult. Not all of those changes are visible to the user.

What will go into 2.0(.7)? Bugfixes. Tiny features which are strongly requested and possible without possibly breaking anything. http://svn.gna.org/viewcvs/*checkout*/w ... /ChangeLog contains the current changes. There was a post on the mailinglist where 2 or 3 additional fixes where requested to be backported from /trunk/ to /branches/2.0/.

What should wait until 2.1? What currently is in /trunk/ will not appear before 2.1.
What will go into the /trunk/? Anything that involves bigger changes (measured in lines of code) or might break something (including backwards compatibility). This includes any new features.

// Edit Giel: wrapped viewcvs URL in a url-bbtag
Last edited by Giel on 20 May 2007, 12:53, edited 1 time in total.
User avatar
kage
Regular
Regular
Posts: 751
Joined: 05 Dec 2006, 21:45

Re: OK!!! here we go again!!!!

Post by kage »

DevUrandom wrote: Ok, again... For the last time. I will not answer this question another time.
someone should sticky dev's last post, then, and perhaps wikify it
UrbanVoyeur
Trained
Trained
Posts: 50
Joined: 10 Mar 2007, 05:03
Location: NYC

Re: OK!!! here we go again!!!!

Post by UrbanVoyeur »

Ok - i added it to the wiki here: http://wz2100.net/wiki/development:codi ... d_branches

Thanks for the clarification, though I should have read some other threads and saved you trouble..
Post Reply