On Sunday, 17 September 2006 at 12:12, Dennis Schridde wrote:
> Am Samstag, 16. September 2006 23:33 schrieb Christian Ohm:
> > On Wednesday, 13 September 2006 at 0:21, Dennis Schridde wrote:
> > > Ideal case, but I know this will often be forgotten. So doing this in a
> > > regular interval seems to be safer to me currently. (I know which
> > > revisions are represented in the ChangeLog and which not just by looking
> > > at the log.)
> >
> > Well, it can't hurt to list it there, can it?
> It can.
> If you read carefully you see the sentence about the "regular interval" and
> the explanation why this could be safer is given in brackets right after
> that.
Ah, now I understood how you meant that - OK, if you want to do it that
way, go ahead.
> > > > - Check what you check in ("svn diff | diffstat", "svn diff")
> > > > - Write a descriptive log message: For new features, describe how to
> > > > use them, list possible problems
> > >
> > > Or tell a wikipage / br where to find that info.
> >
> > (what's br?)
> BugReport
> > So when the wiki page is gone, the information is gone as
> > well. Not good. I'd rather have those sent to the SVN-list,
> But also you can't include a whole Wiki in your commitlog...
I guess most changes can be described in a few sentences; I don't want
whole novels in the SVN log. But the important stuff should be in the
SVN log (possibly with a pointer to a more detailed explanation).
(And always remember: Rules are there to make you think before you break
them.)
> > Besides, I find it useful to have my changes
> > version-controlled while working on something (and it's not really
> > convenient to have to use Darcs (or whatever else) besides SVN).
> >
> > Testing the changes in the branch is a nice side-effect if it happens,
> > but not the main purpose, and testing will happen as soon as the branch
> > is merged back into the trunk (that should happen as soon as possible).
> But if that breaks a lot (you didn't catch before because of missing testing)
> you have a broken trunk...
> So if we branch we probably have to keep in mind that merging it back can
> break a lot, simply because we didn't catch all the bugs in it.
Yeah, well, then we could ask people to test the branch before merging
it back (and maybe make a test release from the branch).
> > But it should not remain that way for long, since there are people using
> > it (as you said yourself).
> As those people don't expect a trunk to be stable it doesn't matter.
> (They only care about the trunk compiling, so that needs to be taken care of.)
Oh oh, definition mismatch. I think I mean the same as you do - the
trunk can't be in a state of non-compileableness for long, because
people will complain then - a branch can be broken for a while without
problems (well, except for the people working on the branch).
> > Yeah, it's not ideal, but then, the autostuff isn't. Let's just replace
> > it, OK? It's just too annoying to work with. Do you need any help with
> > your waf evaluation?
> Compilation with waf was never a problem. Only "problem" I currently have is
> with the "autoconf" stuff. Means detection of libraries.
> That one currently has an odd API in waf and I expect it to be changed not so
> far in the future...
> I can create the configure module with the current API (a bit "von hinten
> durch die Brust ins Auge" (if someone can translate that too good english, be
> welcome) but it works).
So waf is out until the configuration stuff is solved? A pity...
> > I'd say: Fixes for bugs found in the trunk are merged from the trunk (if
> > possible), and fixes for bugs found in a release are fixed in its branch
> > and then merged into the trunk (if possible).
> If the branch differs a lot from the trunk then that sounds better.
>
> But I remember a problem we had on BerliOS. We had changes in !! tags/ !! and
> they didn't get merged back into our development branch... With that rule I
Hmmm... and I might have been responsible for some of those... shame on
me...
> tried to enforce it. Perhaps it wouldn't have worked as expected.
Yeah. What's important is to fix things in all applicable places, not
just in one.
> I think I mixed up 2 different systems I had in mind.
> This is also why my RCs had to be in testing for several weeks:
>
> x.y numbering scheme, no z bugfix releases.
> Have features in every release (like we have currently) and instead of
> releasing bugfix only releases, release RCs before the final release so bugs
> get fixed.
>
> Means:
> - when all features are in: branch 2.1 and tag 2.1_rc1
> - fix bugs
> - tag 2.1_rc2
> - fix bugs
> - tag 2.1_rc3
> - no more bugs: tag 2.1 and release.
> - do some development of new features and then branch 2.2 and tag 2.2_rc1
> ...
>
> This scheme would match the one found in many commercial games I know of.
But it doesn't work that well for an open source project with numerous
releases.
> This way you know when something is relatively bugfree (x.y) and when it can
> contain bugs (x.y_rcZ).
> The other way you know when there are new features (x.y) and you know when
> bugs have been fixed (x.y.z) but you don't know when it has stabelized.
Hey, the kernel team gave up on that idea ;) (Yes, there is 2.6.16.x,
but this is an effort done by a few individuals, not most of the kernel
developers).
> > A bit inflationary on the y number, but who cares if we have 2.23.41
> > sometime?
> Kernel has, too. ;)
>
> > As the x is reserved for something groundbreaking, 3.0 will be the perfect
> > Warzone, totally rewritten. ;-)
> Hopefully not.
Do you think once we reach 2.23.41 there will be much left of the
original code? Sure, it will take a few years until then, but if the
development (contrary to maintenance) keeps on, this will happen.
> > Tag, branch - it's all the same in SVN, it just has different names.
> And different meaning.
> Tags are snapshots and branches are ongoing development. And it should be
> that
> way, because otherwise we just confuse other people, like we did with
> branches/crossplatform on BerliOS. Or like Quamly did with me when I looked
> at his tags/0.2.3 when I tried to create a ChangeLog for all releases.
Yeah, the definition thing again... OK, branches are for development and
a tag is a specific revision carved in stone with no changes done to it.
Now I just have to remember that ;)
> > Oh, by the way: Most of the things I propose are based on watching
> > (mostly) this project work (or not), not just pulled out of thin air. ;)
> Jup. Do the same with my own proposals. ;)
> And I think most of your proposals are good, but as in daily politics there
> are sometimes many ways to approach a problem and you don't know in advance
> which one is better. :(
Yeah. As long as we actually decide on one option that's OK. (Not like
on Berlios where some discussions just faded away without leading to
anything...)
--
BOFH excuse #71:
The file system is full of it
_______________________________________________
Warzone-dev mailing list
[email protected]
https://mail.gna.org/listinfo/warzone-dev
