Hi Andrew,
I worked a bit on the doco, and got some developer doco in. Sorry I
wasn't able to push something earlier. Sunday afternoon was lost on
setting up my netbook for doing development stuff (that works, because
I have a netbook with 4Gb ram, 320Gb hd, and Intel su4100 chip), but
at least I can now develop on all my machines :)...
There is also a link to the old Trac wiki page in the dev doco,
because I added information to Trac on how to setup Putty for
connecting to SSH on windows (wiki is like a notebook for me). Using
Putty for SSH is nicer than OpenSSH, because OpenSSH uses CygWin stuff
and will not install together with CygWin (Cygwin is a pain anyway,
but that aside...).
With respect to the getting started guide. I deliberately removed the
line about two popular modes of development. Let's first steer people
in one direction, namely Maven GWT plugin and later (in Developer
Guide) explain how to work on the project using different
environments.
I think the site content should suffice for now and I will continue to
work on doco for the next point release (completely porting it to apt,
and try make a pdf version).
What should we do to wrap up the release? Can you get a 0.5 build into
the Maven repo? Will that take up time for some form of approval? Do
you want me to make a zip of the files and upload that?
Do you agree that we should get rid of the branches in Hg and go to
one default branch? MercurialEclipse makes it easy to work with
branches, but I think we should not keep branches around that are not
a real separate line of development. Your Mercurial knowledge is
superior to mine, so I hoped you would be able to help out.
By the way, I found a tutorial site called HgInit which is just
awesome: http://hginit.com/top/.
I have also been looking briefly at Bitbucket. Just to be clear, As I
understand it, Moving to Bitbucket doesn't look appealing to me at
this point, but I was interested in how it works there. Bitbucket
seems to make it easy to create an online accessible clone of the
central repo for individual developers. Their clone will be managed by
Bitbucket and changesets can be pulled from it. On SF this seems more
painful, because, the way I understand it, we as project admins are
responsible for creating hg repos for each developer that wants one.
Am I missing something or do you have an idea how we could easily have
people that are not on the project team clone the repo and then pull
back changes. Right now I suggest we use hg export/import.
Greetings,
Edwin
|
