Thanks...
Basically try to separate the functionality as much as possible from the GUI, in subroutine or class files. Let's try to make them "plug and remove", for easier updating. I can't enforce things much when I didn't have time to clean up the code...
Only thing is: comment as much as possible, without over-doing it. If in doubt, over-do it...
First things we need to do are organizational:
- who wants seriously in, so I can add them to the project?
- mention if you can handle proper svn checkins, or prefer to submit patches so others check them in?
- you need to be on the vectorlinux-devel mailing list, so we can discuss stuff:
https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel- do we want to do this as a stable (always buildable) trunk and experimental branches, or a rolling devel trunk with stable branches?
Just thought of a few other points to aim for:
- we should keep tabs on the list so we don't step on each others toes and thus make code merges minimal/easier.
- keep detailed change logs and good checking comments
EDIT: I always figured to work on and finish one complete install method first, then work on the others. Lets say, for example, that we do full-auto first and work from there. We should debate and prioritize them if we decide to go that route. on the other hand, maybe we'd work best if we each start with what we understand best?
