On 20.06.2008, at 21:04, Anton Novikov wrote: >> - we need to merge the autotools environment and IDE project files of >> F1 and F2, so that *both* libraries *plus* F3 will be built, and both >> F1 and F2 link against F3 (which is still empty at this point)
> that would be a bit confusing - fltk1 and fltk2 depending on fltk3 :) > I like the idea of having them all bundled together, > but I'm for the abstraction layers being a separate library. Ah no. fltk1 and 2 don't depend on fltk3. The f1 and f2 compatibility layer will. ven though we are starting out with the full library, we will end up with very little code in the f1 and f2 directories, sometimes just with a header file. >> - we need to set up a system for regression testing > yep, that would be nice. everything but windowing can be tested > automatically. > by the way, if we go for it, that would be a good time for changes > in infrastructure. > for ex.: > 1. Switch to a distributed revision control(git, mercurial). I > myself switched from > SVN to Mercurial some time ago very easily. It has its > advantages(most evident - local commits). I have used GIT and SVN. SVN was always sufficient for me and has a great front end. Please explain (or give me a reference where I can read this up) how GIT will improve revision control. > 2. Make a web interface to revision control system. Like: > http://hg.sharesource.org/sharesource/ I never needed that because TortoiseSVN provides that much faster, but again, I am happy to learn why this is useful. > 3. Improve bug trackers - add keywords, for ex. to group bugs based > on the subsystem involved OK, that should not be too hard. You can do much more complex text searches than meets the eye already though. I will put this in the hand of those who know more about regression testing and version control than I do. When I studied Computer Science, version control meant "using another audio tape to store your source code and keeping the old one away from the little sister" ;-) . >> 1: no coding is done twice (we need to keep a minimal glue layer >> between F1 and F3, and F2 and F3 though) > I think fltk2 needs no compatibility layer. the moved interface will > be itself usable. > Those who use fltk2 don't expect the API to be immutable, I guess ;) I do not want to predict to what extent we will change the F3 API, but a simple compat layer may coem in handy. That's up to the FLTK2 folks though. Matthias ---- http://robowerk.com/ _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
