glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [glob2-devel] Evolutions vs Revolutions


From: Bradley Arsenault
Subject: Re: [glob2-devel] Evolutions vs Revolutions
Date: Thu, 16 Mar 2006 10:17:51 -0800

On 3/16/06, Kai Antweiler <address@hidden> wrote:
> Hi Steph,
>
> I think, to people that don't know much about the code, rewriting is
> more attractive than bugfixes are.  So this might be a good
> opportunity to attract new developers who have time for major rewrites.
> (if done right)

I agree. While I've tried several times ot get into a different system
and start programming it, I get lost in the code, and don't understand
why things are the way they are. And I can't document things if I
don't understand them, and it seems the only people who do understand
them are always busy (*evil stare at nct*). So, a rewrite of the
system looks much more attractive to me, as we have a chance to fix
everything thats wrong with the original system, and do all those
things big proffesional developers do, like make lots and lots of unit
tests, document the code excessivly like a bunch of english
proffessors.

>
> Imagine a developer who knows glob2 quite well and would like to change
> something on a big scale but has no time for it.
> So instead of rewriting it himself he could help others do it.
> (By starting some new code and supervising)
>
> What is left to do is:
> Put a list onto the webpage that tells what big rewrites would be
> supervised by whom.
> Including a not-to-short discription of:
> 1) the relation of the part which shall be rewritten to the whole of glob2.
> 2) why it should be rewritten.
> 3) how it shall look when finished.
> 4) what the new developers should know.
> 5) how to sign up for it.
>
> Well, something like a job advertisment.
>
> Example:
> Nicowar rewrite (supervised by Bradley Arsenault):
> 1) Nicowar is an AI that can control enemy players.  It communicates to
> the rest of glob2 through the following classes ...
> 2) The old code was not desinged to treat different buildings differently.
>    This turned out to be bad, because ...
> 3) The new code will be based on a fussy state machine.
> 4) Knowledge of the book foobar will be necessary.
>
> I don't know how to implement 5. Maybe through forum or private glob2-member
> messages.  The importent thing would be that it can be done right away
> without much effort.
>
>
> This resembles the road map webpage.  The difference would be that
> road map was not optimized to attract developers.  And the road
> map includes projects for the far future.
> The new page must be linked to the "you can help" part of the frontpage.
>
>
> I don't know if this idea will work.  There might even be too few
> developers who would be willing to supervise.
>
> --
> Kai Antweiler
>
>
>
> _______________________________________________
> glob2-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/glob2-devel
>

I don't actually see this system working, sorry. I think it would be
simpler, and more effective, just to advertise "Help Wanted In All
Areas (Programming, Graphics, Music ...) - contact
<address@hidden>" in as many places as possible, and see who
comes in. Other than that, the project needs to get organized, designs
discussed, made, implemented, tests made, implemented, and we all
cheer right at the end.

But again, I fully understand nct reasons for delaying a massive
rewrite untill after making a big release. In that case, we still need
to get organized. We need to make a list of everything we want done
for 1.0, because if we wanted nothing, we would have released 1.0
right now, so there are some reasons for us not to release 1.0 yet,
and we need to sum these reasons up and tick them off one by one
untill we have a 1.0 release.

    Bradley Arsenault




reply via email to

[Prev in Thread] Current Thread [Next in Thread]