Jump to content
Eternal Lands Official Forums

Placid

Members
 View Profile  See their activity

  • Content count

    4751

  • Joined

  • Last visited

Posts posted by Placid

  8. Posted · Report reply

    The flow is thus:

    • Reported
    • Acknowledged
    • Confirmed
    • Assigned
    • Resolved
    • Closed

    Resolved declares that the developer who it was assigned to has fixed it. Only when someone (best it isn't the original dev, but I think we can let that slip) has confirmed it's fixed should it be set to closed.

     

    That's how I understand Mantis.

  9. Posted · Report reply

    Apart from the two issues above, how's this working for everyone? Do the developers feel it's something that's working and that could be used on a more permanent basis? Is there anything that you think needs changing?

    I like it. Feels more organised and easier to identify what needs doing and who's doing what. The only, minor downside is it's starting to feel more like proper work, I'm doing this for fun. :icon13:

    Heh, that's a very good point. Maybe I'll put some flash games on the top just to make it a little less work-like :whistle:

  12. Posted · Report reply

    Oh, yes, one more thing:

    We should create a meta-bug for each new release with the title "Needs to be done before 1.x.y", and then make the meta-bug depend on the bugs that _must_ be solved before the client can be released. (make them childs of the meta-bug). This way it'll be easier to know what needs to be resolved before the release. Bugs like #26 are good examples of this. It'll give a good overview of the status of the next release.

    I completely agree. A perfect example of why bug-tracking systems are so handy - they allow you to categorise bugs under releases, and make it a lot easier to track the status of a particular release (and great for historical information, too).

  14. Posted · Report reply

    It is working, but I think it should be a developers only thing, and only programmers or people with a strong understanding of computers should post there. Everyone else should post on the forums.

    I kind of get that feeling too. I think it works best as just a developer oriented site, as it keeps the postings and notes purely on a technical level. I do keep an eye on both this and the Bug Reports forum, so it's just a matter of making sure things are in sync.

     

    What do others think?

  15. Posted · Report reply

    I looked last night and I hadn't received anything. I remember upgrading postfix a day or two ago, so this may have caused some issues. I'll have a look tonight as a matter of urgency.

     

    Thanks to all who've reported the timestamp issue. I'm pretty sure it's just a display problem (albeit a rather crucial display), and I'm currently in a 3-day conversation with someone on #mantishelp. I'm not in screen 100% and the replies are somewhat delayed.

     

    Apart from the two issues above, how's this working for everyone? Do the developers feel it's something that's working and that could be used on a more permanent basis? Is there anything that you think needs changing?

  17. Posted · Report reply

    Sure, I can give that a try when I have the chance (I'll have some free time in the next couple weeks - getting ready for finals right now :-P), though I had issues the last time I tried to compile CVS for 64-bit, because when I tried to build using the Makefile it said my platform wasn't supported. I'll give el.ini a look as well.

     

    James

    That's because you should've set the 'arch' flag and added -DX86_64 to the compile options.

  18. Posted · Report reply

    I almost never check my pointers, unless if I know that there is a posibility for them to be NULL because of some dynamical stuff.

    Of course, testing where it's relevant. Doing:

    char[5] my_str = "hello";
if(my_str != NULL){ // some uber code }

     

    would be pointless. I meant in other cases, where it's not as clear (such as a function parameter or return value).

  20. Posted · Edited by Placid · Report reply

    ;) It was my code, and I think no one had messed with it before, so was pretty much quicker to do it that way: I solved the issue and commited the changes and closed the bug. Was much quicker because I was emailed immediately after you assigning it to me - took me only 3 or 4 minutes to do it.

     

    You can always assign stuff to people which seem to you the most appropriate - and those people can reject your assignment, based on some reason they have.

     

    Otherwise, we'll end up with lots of bugs not assigned to anyone because none is brave enough to pick them up.

     

    Álvaro

    That was my gut feeling. I knew you worked on the code, I knew you'd be notified immediately (email) and I knew you could ultimately reject it. I guess this comes down to standards of practice (I'm too used to corporate arrangements and 'ways of doing things').

     

    I may continue to do it if I feel that I'm 100% right (like in the above case). The risk is that I may not have enough knowledge on the particular bug to be doing it in the first place - in this case, it can simply be left unassigned.

     

    [Edit] spelling errors...

  21. Posted · Report reply

    Well, after several days of battling, I've backed my way out of a wholesale rewrite of the actors code and settled for some targeted bug fixing. As this was a smaller change then I was thinking, I've committed to CVS directly. My commit fixes the map change crash related to sounds and adds actors mutex locks to the bits of sound executed in a thread. There are also a few extra checks for NULL pointers and some extra MUTEX_DEBUG code. Sorry for the delay.

    Nice work, bluap. Do your fixes relate to any of the following bugs:

    http://el.beplacid.net/bugs/view.php?id=15

    http://el.beplacid.net/bugs/view.php?id=12

  22. Posted · Report reply

    Well, for some bugs I already supplied a solution patch, so somebody with CVS RW might have a look at it and commit it. (Or scream at me)

    As long as they're uploaded to the relevant bug listing on Mantis, you've done your bit ;)

     

    I accidentally assigned a bug to AlvieBoy earlier (it was directly related to his client popup stuff) which probably isn't the best practice. I think it's best if people pickup bugs as and when they're working on them - that is, that they assign the bug to themself on Mantis and then code away - so we can keep the bug tracking ball rolling (and prove to Ent it's a Good Thing).

  23. Posted · Report reply

    CVS doesn't compile:

    gcc -march=k8 -Wall -Wdeclaration-after-statement -O0 -ggdb -pipe -DLINUX -DELC  -DAFK_FIX  -DALPHA_ACTORS  -DATI_9200_FIX  -DAUTO_UPDATE  
-DCLICKABLE_CONTINENT_MAP  -DCLUSTER_INSIDES  -DCOUNTERS  -DCUSTOM_LOOK  -DCUSTOM_UPDATE  -DCXX_MISC  -DEYE_CANDY  -DFONTS_FIX 
-DFUZZY_PATHS  -DIDLE_FIX  -DMASKING  -DMINES  -DMINIMAP  -DNEW_ACTOR_ANIMATION  -DNEW_ACTOR_SCALE  -DNEW_FILE_IO  -DNEW_SOUND 
-DNEW_TEX  -DNOTEPAD  -DOGG_VORBIS  -DOPTIONS_I18N  -DPNG_SCREENSHOT  -DPOPUP  -DSFX  -DSIMPLE_LOD  -DUSE_INLINE
 -DUSE_SEND_VIDEO_INFO  -DZLIB -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/libxml2 -fno-strict-aliasing  -c -o 2d_objects.o 2d_objects.c
In file included from 2d_objects.c:9:
load_gl_extensions.h:281: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ELglUniformMatrix2x3fv'
load_gl_extensions.h:282: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ELglUniformMatrix2x4fv'
load_gl_extensions.h:283: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ELglUniformMatrix3x2fv'
load_gl_extensions.h:284: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ELglUniformMatrix3x4fv'
load_gl_extensions.h:285: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ELglUniformMatrix4x2fv'
load_gl_extensions.h:286: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ELglUniformMatrix4x3fv'
make: *** [2d_objects.o] Error 1

    Using default options... question: am I supposed to put that on Mantis instead? I didn't see anything like this there, so I posted here.

     

    edit: edited the compiler command line to make it fit on screen (of suitable size ;))

     

    In this case, I'd say both. It could be related to bugs that have been fixed or are in resolution, which means it would be helpful to check the existing bugs list and see if it is related. If it isn't, then here's fine. If it is, then posting on that relevant bug listing on Mantis would be helpful. Even if a new bug was added for this, it's not hard to chase it down and close it if it's not really necessary.

×