Re: [Warzone-dev] Commit guidelines are in effect
Per Inge Mathisen schreef: >> Also this would make incremental development (i.e. where change B >> depends on change A) nearly impossible (due to the minimum of 48 hrs >> wait time before committing if no one commented by then), thus it would >> actually promote "mega patches" which no one understands anymore (this >> due to the fact that Subversion is only capable of tracking a single >> change from "public" HEAD). git-svn could alleviate this somewhat, but >> only for changes that require no other changes than file modifications. > > Shall we try this system for a little while before spelling doom and > gloom over it? I'm not saying that *will* happen, I'm saying that I think that is a *possible* outcome of it and that I don't like that one. I hope you can understand how I came to this as a possible outcome and also agree that it is something that should be prevented. As long as we agree on that, we can at least look out for this problem and try to prevent it. I was just sharing my concerns... >> Then regarding: >>> If a subsystem of the code has its own maintainer, that person is >>> free to make commits to this code without posting to the list first. >> I hope you don't mean this to translate to "subsystems are owned by >> their maintainers" ? As I think that code ownership is a *very*, *very* >> bad thing. This because it will demotivate people that are not the >> "owner" to touch that code, which would result in only the "owner" >> having real knowledge about how that code works. > > Well, it works for the linux kernel, so I suppose it cannot be all that bad. Honestly, I don't think Warzone can be properly compared with the Linux kernel. The two are on two completely different orders of magnitude, both in the code's size and complexity as well as the community's size and complexity. Plus I don't see how scaring people from modifying certain parts of the code could ever be a good thing (not even for the Linux kernel). -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Commit guidelines are in effect
I applied the patch by hand, since we use Trac 0.11. However, I created a test ticket, but somone needs to approve [EMAIL PROTECTED] as sender. http://developer.wz2100.net/ticket/40 -- Kamaze Giel van Schijndel schrieb: > Per Inge Mathisen schreef: > > NOTE: Setting up Trac to send a mail to the mailinglist for every > *change* to a ticket (includes ticket creation) is trivial. Just adding > an address to the smtp_always_cc will do. Only automatically notifying > the mailing list when tickets are created is significantly less trivial. > See Trac ticket #6613 [1] for the hack approach I took to implement it > (Trac 0.10). > > > I'm afraid that this approach translates to "every non-bugfix & > non-documentation change has to go through the patch tracker". This > approach would result in flooding the patch tracker, effectively > demotivating almost anyone (it would demotivate me) from even looking at > it. Also this would make incremental development (i.e. where change B > depends on change A) nearly impossible (due to the minimum of 48 hrs > wait time before committing if no one commented by then), thus it would > actually promote "mega patches" which no one understands anymore (this > due to the fact that Subversion is only capable of tracking a single > change from "public" HEAD). git-svn could alleviate this somewhat, but > only for changes that require no other changes than file modifications. > > Then regarding: > > I hope you don't mean this to translate to "subsystems are owned by > their maintainers" ? As I think that code ownership is a *very*, *very* > bad thing. This because it will demotivate people that are not the > "owner" to touch that code, which would result in only the "owner" > having real knowledge about how that code works. Thus for the purpose of > maintaining that code we would come to depend on whomever "owns" that > code. What I'm talking about now is, in part, the "bus-factor" [2], > which we should keep as high as possible. The linked video in that > wikipedia page, [3], also addresses this in a rather interesting way. > I'd recommend to see the whole video if you have the time (1 hour), the > "bus-factor" is dealt with in the time frame from 16:30ish to 20:30ish. > > [1] http://trac.edgewall.org/ticket/6613 > [2] http://en.wikipedia.org/wiki/Bus_factor > [3] http://video.google.com/videoplay?docid=-4216011961522818645 > > > > > > ___ > Warzone-dev mailing list > Warzone-dev@gna.org > https://mail.gna.org/listinfo/warzone-dev ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Commit guidelines are in effect
On Mon, Aug 25, 2008 at 2:59 PM, Giel van Schijndel <[EMAIL PROTECTED]> wrote: >> No. But if the tracker doesn't email the list, please do so manually. > > NOTE: Setting up Trac to send a mail to the mailinglist for every > *change* to a ticket (includes ticket creation) is trivial. That is fine by me. >> If the fix is a few lines, fine. If you have to rewrite a lot of code >> (ie has a high chance of introducing new bugs), then post the patch >> for review first. > > I'm afraid that this approach translates to "every non-bugfix & > non-documentation change has to go through the patch tracker". This > approach would result in flooding the patch tracker, effectively > demotivating almost anyone (it would demotivate me) from even looking at > it. It won't be flooded if people close tickets when they are done with them. > Also this would make incremental development (i.e. where change B > depends on change A) nearly impossible (due to the minimum of 48 hrs > wait time before committing if no one commented by then), thus it would > actually promote "mega patches" which no one understands anymore (this > due to the fact that Subversion is only capable of tracking a single > change from "public" HEAD). git-svn could alleviate this somewhat, but > only for changes that require no other changes than file modifications. Shall we try this system for a little while before spelling doom and gloom over it? > Then regarding: >> If a subsystem of the code has its own maintainer, that person is >> free to make commits to this code without posting to the list first. > > I hope you don't mean this to translate to "subsystems are owned by > their maintainers" ? As I think that code ownership is a *very*, *very* > bad thing. This because it will demotivate people that are not the > "owner" to touch that code, which would result in only the "owner" > having real knowledge about how that code works. Well, it works for the linux kernel, so I suppose it cannot be all that bad. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Commit guidelines are in effect
Per Inge Mathisen schreef: > On Mon, Aug 25, 2008 at 5:03 AM, bugs buggy <[EMAIL PROTECTED]> wrote: >> About these guidelines, take this: >> >> " Patches as a rule go into the patch tracker. Give a quick run down of what >> it does and what it changes." >> >> Does it matter which tracker? > > No. But if the tracker doesn't email the list, please do so manually. NOTE: Setting up Trac to send a mail to the mailinglist for every *change* to a ticket (includes ticket creation) is trivial. Just adding an address to the smtp_always_cc will do. Only automatically notifying the mailing list when tickets are created is significantly less trivial. See Trac ticket #6613 [1] for the hack approach I took to implement it (Trac 0.10). >> " Patches that only fix bugs (no rewrites which fix bugs...) or build errors >> can go in at once." >> >> What do you mean by that? Most of the time you have to rewrite some stuff >> to fix the bug, unless you mean really simple errors that involve less than >> a few lines? > > If the fix is a few lines, fine. If you have to rewrite a lot of code > (ie has a high chance of introducing new bugs), then post the patch > for review first. I'm afraid that this approach translates to "every non-bugfix & non-documentation change has to go through the patch tracker". This approach would result in flooding the patch tracker, effectively demotivating almost anyone (it would demotivate me) from even looking at it. Also this would make incremental development (i.e. where change B depends on change A) nearly impossible (due to the minimum of 48 hrs wait time before committing if no one commented by then), thus it would actually promote "mega patches" which no one understands anymore (this due to the fact that Subversion is only capable of tracking a single change from "public" HEAD). git-svn could alleviate this somewhat, but only for changes that require no other changes than file modifications. Then regarding: > If a subsystem of the code has its own maintainer, that person is > free to make commits to this code without posting to the list first. I hope you don't mean this to translate to "subsystems are owned by their maintainers" ? As I think that code ownership is a *very*, *very* bad thing. This because it will demotivate people that are not the "owner" to touch that code, which would result in only the "owner" having real knowledge about how that code works. Thus for the purpose of maintaining that code we would come to depend on whomever "owns" that code. What I'm talking about now is, in part, the "bus-factor" [2], which we should keep as high as possible. The linked video in that wikipedia page, [3], also addresses this in a rather interesting way. I'd recommend to see the whole video if you have the time (1 hour), the "bus-factor" is dealt with in the time frame from 16:30ish to 20:30ish. [1] http://trac.edgewall.org/ticket/6613 [2] http://en.wikipedia.org/wiki/Bus_factor [3] http://video.google.com/videoplay?docid=-4216011961522818645 -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Commit guidelines are in effect
On Mon, Aug 25, 2008 at 5:03 AM, bugs buggy <[EMAIL PROTECTED]> wrote: > About these guidelines, take this: > > " Patches as a rule go into the patch tracker. Give a quick run down of what > it does and what it changes." > > Does it matter which tracker? No. But if the tracker doesn't email the list, please do so manually. > " Patches that only fix bugs (no rewrites which fix bugs...) or build errors > can go in at once." > > What do you mean by that? Most of the time you have to rewrite some stuff > to fix the bug, unless you mean really simple errors that involve less than > a few lines? If the fix is a few lines, fine. If you have to rewrite a lot of code (ie has a high chance of introducing new bugs), then post the patch for review first. > What about other patches that aren't really code changes per se, they just > change comments and or add things to debug statements? Just commit them. Perhaps should add to the commit guidelines that documentation updates can go in without review. > And then we got patches in the tracker that are many months old. > Since it has been longer than 48 hours, those are ok to integrate? Use common sense. :-) Some of these patches are many months for a reason. > And finally, you should also add a 'modify the changelog when patch is > integrated' rule. Unless we go with just svn log dumps of what was done? > Also, more descriptive comments in the svn log while committing would also > be a good rule. I agree. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Commit guidelines are in effect
On 8/24/08, Per Inge Mathisen <[EMAIL PROTECTED]> wrote: > > See http://wiki.wz2100.net/Commit_guidelines About these guidelines, take this: " Patches as a rule go into the patch tracker. Give a quick run down of what it does and what it changes." Does it matter which tracker? The Trac tracker is *much* better, (no need to download the patch to see what it does, it shows a color coded diff view as well, so you can see what it changes also). That means that reviewing said patches is about 100% easier on http://developer.wz2100.net/ than on GNA's tracker. The only thing missing on Trac is that it isn't setup to e-mail the ML about it, but it does spam the IRC channel with the info. " Patches that only fix bugs (no rewrites which fix bugs...) or build errors can go in at once." What do you mean by that? Most of the time you have to rewrite some stuff to fix the bug, unless you mean really simple errors that involve less than a few lines? Case in point, my next patch fixes a long standing bug, but I needed to rewrite the logic so the bug wouldn't occur. What about other patches that aren't really code changes per se, they just change comments and or add things to debug statements? Another of my patches deals with making the game more 'mod' friendly, in that, in the debug statements that are already there, I add a function that gets the real directory information that physfs is using. (That is how I found bug https://gna.org/bugs/?12053 ) And then we got patches in the tracker that are many months old. Since it has been longer than 48 hours, those are ok to integrate? And finally, you should also add a 'modify the changelog when patch is integrated' rule. Unless we go with just svn log dumps of what was done? Also, more descriptive comments in the svn log while committing would also be a good rule. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Commit guidelines again
Am Sonntag, 3. August 2008 00:27:32 schrieb Dennis Schridde:
> - I am unsure whether the "style rules" are too strict. For example I do
> not think it makes much difference whether I put braces on the same line as
> the if or not. Something like this also sounds ok to me:
> """
> Keep the style of the surrounding code (and do not change existing
> formating), unless you rewrite it anway. Whatever you write, make it
> readable. (If in doubt better add more spaces or newlines.)
> """
> And if someone is never in doubt, he can still be asked to change his
> style. I do not know how this is handled elsewhere, though, and we had this
> quite some times already, so I understand if you do not want to pick it up
> again. Just felt that I was not alone with the feeling that the current
> rules are a bit strict.
Or maybe it wont work like that...
(After some talk with examples I am convinced...)
http://techbase.kde.org/Policies/Kdelibs_Coding_Style
What I like there is the "recommended" in it. I assume that means: If a line
or two do not conform, well, shit happens.
In case you do not read the following, the first paragraphs may still be
commented on independently. ;)
Something on my personal "coding style" :
I do not do any alignment, just logical indention.
Example:
if (a == b &&
c == d)
vs.
if (a==b &&
c == d)
Result: Looks not as pretty (but then coding is no art of beauty to me), but
the logic is transfered ("this belongs to if()"), it is extremely easy to
type (just one keypress, no "how many keypresses are required to align it"),
you cannot accidentially mix spaces and tabs (since there is only one, not
two types per line) and some editors automatically replace x-spaces with a
tab when pasting (particularly useful when taking code from other locations,
and honestly I do not even know how to stop Kate from doing it, and no, no
vim for me...).
Just in case you see it, now you know who is to blame for it. ;)
(And maybe it sounds logical enough to make everyone a believer, who knows.
But then it still depends whether you prefer something for the eye or not...)
Reason I talked about it: The 3 negative points I mentioned. I'd rather prefer
spaces only than mixed, it is just easier. (I even know how to setup Kate for
that. ;) )
--Devurandom
signature.asc
Description: This is a digitally signed message part.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Commit guidelines again
Am Samstag, 2. August 2008 22:49:21 schrieb Per Inge Mathisen: > http://wiki.wz2100.net/Commit_guidelines > > Last call for comments. In general fine with me, just have some notes: - Should be made clear that this is for feature patches only. (For example I doubt that it is needed for "change colour of X from green to red" or other minor changes.) Otherwise it might soon become overkill. - I would like to get maintainership of parts of the sourcecode temporarily, namely those I am heavily working on at the moment. (Hypthetically.) - I am unsure whether the "style rules" are too strict. For example I do not think it makes much difference whether I put braces on the same line as the if or not. Something like this also sounds ok to me: """ Keep the style of the surrounding code (and do not change existing formating), unless you rewrite it anway. Whatever you write, make it readable. (If in doubt better add more spaces or newlines.) """ And if someone is never in doubt, he can still be asked to change his style. I do not know how this is handled elsewhere, though, and we had this quite some times already, so I understand if you do not want to pick it up again. Just felt that I was not alone with the feeling that the current rules are a bit strict. - Change in wording: "at least 48 hours", maybe more for bigger changes and less for small ones? - We are probably not enough people to feed all changes through maintainers? (The workflow you proposed on IRC.) - Is there an ok by someone needed to commit? Or can I commit if the others are too slow in vetoing? (A joke, obviously, but it can also happen accidential...) --Dennis signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Commit guidelines
Am Samstag, 21. Juni 2008 17:19:14 schrieb Giel van Schijndel: > Currently I have 973MB of such "backed-up" installers on my local HDD. I > could of course upload them to > http://download.gna.org/warzone/snapshots/ . I'm not sure if Gna! would > have any problems with storing that amount of data though... Last time I talked to the staff, they said that neither diskspace nor bandwith or traffic/month is an issue to them. --Dennis signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Commit guidelines
bugs buggy schreef: > The twist in the bucket is, even with 96h in the tracker, we still > might not catch bugs that the community will catch. Nightly builds > are very helpful (and should be archived IMO--so we can narrow down > bugs quickly) > They also need to have a more prominent spot, so people can help us > find issues quicker. I dunno, we could make a contest, to see who can > find the most bugs, and the winner gets a feature they want put into > warzone at a higher priority than all the other feature requests? > > And *all* testing/nightly builds need to be debug builds. Release > builds could also be made, but if space is tight, I prefer debug > builds. To get back on the archiving bit. Due to size constraints I *do* remove all the older nightlies from time to time. I keep a back up of them on my own system though (actually the ones on my own system are rebuilds with LZMA compressed installers, which are some MBs smaller). Currently I have 973MB of such "backed-up" installers on my local HDD. I could of course upload them to http://download.gna.org/warzone/snapshots/ . I'm not sure if Gna! would have any problems with storing that amount of data though... PS The revisions for which I've got backed-up installers (both debug and non-debug, aka release build): 4843, 4853, 4875, 5100, 5125, 5145, 5196, 5215, 5239, 5243, 5250, 5252, 5253, 5260, 5277, 5279 and 5280. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Commit guidelines
Am Dienstag, 17. Juni 2008 06:57:28 schrieb bugs buggy: > On 6/16/08, Per Inge Mathisen <[EMAIL PROTECTED]> wrote: > > After some discussion, I would like to soften the suggestion a bit: > > > > Commit guidelines: > > 1) All larger patches should go into the patch tracker. Give people > > time to comment on it. Add yourself to the cc: list of patches you are > > interested in. > > 2) Try to break up larger changes into smaller patches when possible. > > 3) Do not mix unrelated cleanup and feature changes or bug fixes in > > the same patch. > > 4) Fix the coding style of lines you edit, but try to avoid doing that > > to any other lines. > > 5) Be very careful about cleaning up code that other people may be > > working on. > > > > I would like to emphasise the last point. It is very demotivating to > > see someone else's quick cleanup work rip asunder the careful > > rewriting you've been carrying on over several months to some part of > > the codebase, but not yet committed. > > > > - Per > > Most of that sounds good (in theory), guess we will see how it holds > up in practice. :) > I would also like to add, *test* your patch, and if you can't, then > please let others know. > > What do I mean by testing your patch? I know that most people test > their patches in some form, but, warzone is pretty complex, in how > everything works with everything else. > A) We have multiple platforms. We must take care to make something > work on all platforms. (Be it not using C99 coding, endian, build > system or whatever else. I know it isn't always possible/people > forget, or people might not have the know how, but keep this in mind). > 1) It might be very hard to get the OK on windows & linux & macs > before the 48h period expires--especially the mac, since we lack > people using them. It would be cool if we were able to build up a tester staff. Chojun said they were having a good QA team for wz22, so maybe we could share a few of them for the Windows platform? Automated unittests might help a little bit here too. > B) We have SP, MP, and Skirmish. > 1) for SP, we have multiple code paths depending on what is going on, > from offworld missions, to datasets changing, to them not changing, to > a mission inside another mission, and so on. This is perhaps the > hardest thing to test, since we have so many different variables > involved. (And try NOT to use cheats like the 'give all' or 'get off > my land' ones) I doubt I will play through the whole campaign to test i.e. my projectile rewrite. See: I never finished the campaign before, and I am not really a good player either, so it could take me weeks to complete the testing alone... > 2) for MP & Skirmish (yes, there is a difference--depending on what > your changing), we have multiple maps, and multiple tech levels. Also > have multiple players & multiple AIs involved. Usually, if it works > on 8p games, then it should work on 2p & 4p games. For maps, we have > all sorts of sizes involved, and certain maps are better for testing > certain things than others. (ie, flat maps vs non flat maps, 'maze' > type maps vs wide open maps). We could add a random-map feature accessible from the commandline. This might encourage testing a wider range of maps, since currently I just quickly click through the screens to check Sk-Rush... > C) For specific tests, like AI, rendering, pathing, whatever else, we > need to come up with a better way of testing, since things are > slipping through the crack. I am not ever sure a 48h period would be > enough to test some of these things fully. I tried adding unittest to the projectile system. Due to the quirky way everything depends on everything in WZ, this proved ... difficult. I instead just copied the relevant function out of projectile.c. Though this works for initial testing and tweaking, this is obviously not good enough for a unittest. The important part about this was that the unittests could be run without starting full-blown warzone, and that they can be run independendly, i.e. on buildtime. If someone has a good idea how to achieve this, would be nice. > The twist in the bucket is, even with 96h in the tracker, we still > might not catch bugs that the community will catch. Nightly builds > are very helpful (and should be archived IMO--so we can narrow down > bugs quickly) > They also need to have a more prominent spot, so people can help us > find issues quicker. I dunno, we could make a contest, to see who can > find the most bugs, and the winner gets a feature they want put into > warzone at a higher priority than all the other feature requests? Sounds like a nice thing. Though I would like to reduce the bugcount before that, so it becomes interesting. ;) What about doing this slightly after 2.1.0? > And *all* testing/nightly builds need to be debug builds. Release > builds could also be made, but if space is tight, I prefer debug > builds. Due to the optimizations being done in
Re: [Warzone-dev] Commit guidelines
On Tue, Jun 17, 2008 at 6:57 AM, bugs buggy <[EMAIL PROTECTED]> wrote: > I would also like to add, *test* your patch, and if you can't, then > please let others know. Yes, good point. More testing before commits are made would be very welcome. I play a bit with rush2, load a savegame, try to play through cam1 in 3x speed, then 'let me win' do the first away mission before committing larger changes, and I think in addition to running the unit tests, that should give a good indication that the changes do not break things. I would also love to see more people contribute to the unit tests. The last few months, with the exception of yesterday, I cannot recall having done much more on Warzone than fixing bugs. That is not fun. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Commit guidelines
On 6/16/08, Per Inge Mathisen <[EMAIL PROTECTED]> wrote: > After some discussion, I would like to soften the suggestion a bit: > > Commit guidelines: > 1) All larger patches should go into the patch tracker. Give people > time to comment on it. Add yourself to the cc: list of patches you are > interested in. > 2) Try to break up larger changes into smaller patches when possible. > 3) Do not mix unrelated cleanup and feature changes or bug fixes in > the same patch. > 4) Fix the coding style of lines you edit, but try to avoid doing that > to any other lines. > 5) Be very careful about cleaning up code that other people may be working > on. > > I would like to emphasise the last point. It is very demotivating to > see someone else's quick cleanup work rip asunder the careful > rewriting you've been carrying on over several months to some part of > the codebase, but not yet committed. > > - Per Most of that sounds good (in theory), guess we will see how it holds up in practice. :) I would also like to add, *test* your patch, and if you can't, then please let others know. What do I mean by testing your patch? I know that most people test their patches in some form, but, warzone is pretty complex, in how everything works with everything else. A) We have multiple platforms. We must take care to make something work on all platforms. (Be it not using C99 coding, endian, build system or whatever else. I know it isn't always possible/people forget, or people might not have the know how, but keep this in mind). 1) It might be very hard to get the OK on windows & linux & macs before the 48h period expires--especially the mac, since we lack people using them. B) We have SP, MP, and Skirmish. 1) for SP, we have multiple code paths depending on what is going on, from offworld missions, to datasets changing, to them not changing, to a mission inside another mission, and so on. This is perhaps the hardest thing to test, since we have so many different variables involved. (And try NOT to use cheats like the 'give all' or 'get off my land' ones) 2) for MP & Skirmish (yes, there is a difference--depending on what your changing), we have multiple maps, and multiple tech levels. Also have multiple players & multiple AIs involved. Usually, if it works on 8p games, then it should work on 2p & 4p games. For maps, we have all sorts of sizes involved, and certain maps are better for testing certain things than others. (ie, flat maps vs non flat maps, 'maze' type maps vs wide open maps). C) For specific tests, like AI, rendering, pathing, whatever else, we need to come up with a better way of testing, since things are slipping through the crack. I am not ever sure a 48h period would be enough to test some of these things fully. The twist in the bucket is, even with 96h in the tracker, we still might not catch bugs that the community will catch. Nightly builds are very helpful (and should be archived IMO--so we can narrow down bugs quickly) They also need to have a more prominent spot, so people can help us find issues quicker. I dunno, we could make a contest, to see who can find the most bugs, and the winner gets a feature they want put into warzone at a higher priority than all the other feature requests? And *all* testing/nightly builds need to be debug builds. Release builds could also be made, but if space is tight, I prefer debug builds. Just think, I was only going to say 'ditto' before all this. :p ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Commit guidelines
Am Montag, 16. Juni 2008 23:25:54 schrieb Giel van Schijndel: > Per Inge Mathisen schreef: > > After some discussion, I would like to soften the suggestion a bit: > > > > Commit guidelines: > > 1) All larger patches should go into the patch tracker. Give people > > time to comment on it. Add yourself to the cc: list of patches you are > > interested in. > > 2) Try to break up larger changes into smaller patches when possible. > > 3) Do not mix unrelated cleanup and feature changes or bug fixes in > > the same patch. > > 4) Fix the coding style of lines you edit, but try to avoid doing that > > to any other lines. > > 5) Be very careful about cleaning up code that other people may be > > working on. > > > > I would like to emphasise the last point. It is very demotivating to > > see someone else's quick cleanup work rip asunder the careful > > rewriting you've been carrying on over several months to some part of > > the codebase, but not yet committed. > > This last point (5) of course depends on people communicating that they > are working on some large portion of code. Thus if you are working on a > large patch and expect other people to help prevent conflicting changes, > then communicate it through *this* list. You can use other communication > channels as well of course, but this list is the surest way of getting > any kind of "guarantee". Also if you're finished make sure to > communicate that through thist list as well. > > Thus: don't expect people to magically know that some piece of code is > undergoing extensive work by you. Communicate it! Sounds ok. (The proposal, too.) Though I think we shouldn't get too strict about this. It's still open, fun, colourful and so on. ANNOUNCEMENT: I claim the raycasting and projectile code to be mine for the next weeks. :) --Dennis signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Commit guidelines
Per Inge Mathisen schreef: After some discussion, I would like to soften the suggestion a bit: Commit guidelines: 1) All larger patches should go into the patch tracker. Give people time to comment on it. Add yourself to the cc: list of patches you are interested in. 2) Try to break up larger changes into smaller patches when possible. 3) Do not mix unrelated cleanup and feature changes or bug fixes in the same patch. 4) Fix the coding style of lines you edit, but try to avoid doing that to any other lines. 5) Be very careful about cleaning up code that other people may be working on. I would like to emphasise the last point. It is very demotivating to see someone else's quick cleanup work rip asunder the careful rewriting you've been carrying on over several months to some part of the codebase, but not yet committed. This last point (5) of course depends on people communicating that they are working on some large portion of code. Thus if you are working on a large patch and expect other people to help prevent conflicting changes, then communicate it through *this* list. You can use other communication channels as well of course, but this list is the surest way of getting any kind of "guarantee". Also if you're finished make sure to communicate that through thist list as well. Thus: don't expect people to magically know that some piece of code is undergoing extensive work by you. Communicate it! -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
