Matthieu Moy <[EMAIL PROTECTED]> writes: > Michael Olson <[EMAIL PROTECTED]> writes: > >> I would like to be able to present a 1.0 release to RMS at some point in >> January 2008 so that I can try to get it accepted into Emacs. > > Good idea. It can help me to get motivation to invest more time in DVC > too ;-). > >> It feels like we're pretty close to 1.0-quality. What do others think?
I use dvc/tla since years. It was always very usable - at least for me ;-) Releases are an important thing to tell people that the project is active. Another important thing is packaging. Since I use ubuntu, I would like to see dvc available via ubuntu. So consider my response as another wish to get dvc in ubuntu. >> Here are some things that might need work before 1.0 that come to mind: >> >> - Tips need to mention DVC, not Xtla. We could even add some more tips for the new backends and it would be nice to show only tips for the selected backends... >> - Massage the manual in various ways. One idea I have since some time is to use muse as markup language. I don't use texinfo so it is hard to write correct markup. Michael, would it be possible to convert the current manual to muse? Muse is much easier to learn. So it would be easier to make changes to the manual. >> - (If it's ready) Merge in stephe's status/diff-related branch -- I >> don't recall what this was, exactly >> - Get Darcs backend to be more functional; if I recall correctly, this >> one was lagging behind the others. Darcs is lagging behind. I started to look at xmonad currently. This project uses darcs as revision control system. So this raised again some interest in darcs for me... > Something we've always had on our TODO-list, which we never completed: > > - Remove tla-* code from dvc*.el files. > - Remove all dependancies from dvc*.el files to tla*.el > > Currently, > > $ grep tla dvc*.el | grep -v autoload | wc -l > > 146 > > :-( > >> - Rewriting dvc-log to be asynchronous (not enough time on my part, and >> it's still fast enough so as to not annoy me). > > This has one consequence : currently, we have two distinct hg-log > implementation. One within the DVC framework, with the DVC-related > features, and one standalone, faster, but not integrated in DVC. > > It would be nice to have the DVC version as fast as the other before > we drop it, and it would be rather bad to have two hg-log in our 1.0. The same holds for tla: tla-changelog is much faster than tla-logs. > Anyway, we definitely need to get into a numbered-release cycle, we > can start with a 0.9, as a symbolic step. I would also start with 0.9 or 0.8 We had several times some discussions about releasing a new revision of dvc. The reason why we didn't release it, from my point of view a lack of time from the developers combined with some ambitious goals (most of them are mentioned above). On the other hand is dvc working really well. One idea to master this step now, is to release dvc on a fixed date, because it is already in a very good shape. The biggest problem from a users point of view is the outdated manual... Stefan. _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
