Hi Jed,
Thanks a lot for contributing to the discussion with a fresh approach
and sorry for my big delay in answering. We should certainly agree on
the best workflow for Spyder now that the development team is growing.
The main problem with using branches in mercurial (be them in personal
clones or in the main repo) is that they become a permanent part of the
repo history. So if we start to use them, in few months we could have
dozens of branches in our history and they would certainly clutter the
log, both using the googlecode web interface or tortoisehg. As you
pointed out to Steve, I also think branches are used to maintain two
different development trees (maintenance and next-release) inside the
same repo, and probably for nothing else.
That's why mercurial devs invented a new kind of branching called
"bookmarks" (which by the way are the real equivalent of git branches).
Bookmarks are like branches but don't get recorded on history and can be
easily deleted. Unfortunately, googlecode doesn't support them, at least
to the best of my knowledge. I searched the support pages in vain and
waited several months to see if they were to appear in the interface.
That's why I finally suggested the move to github.
I really don't think googlecode or mercurial are "bad". It's just that
they don't have a such polished interface to do reviewing as github.
Believe me, if github were based on mercurial I would be really happy.
But it's more important to acknowledge that reviewing would be very
beneficial to the project. It could help to discuss changes and
approaches between us without the fear to screw things up. It could also
let us learn from the experience and knowledge of the rest. I think none
of us knows the codebase as well as Pierre but the ones who know some
parts better could help the others and viceversa.
I think all of us are eager to improve Spyder because is such a neat IDE
and it's also pretty well written but we need better communication
tools, and github seems to be the best alternative around for the task.
Cheers,
Carlos
El 10/01/12 10:56, Jed Ludlow escribió:
Today, it looks like the majority of development is done
directly in the default repo. A minor modification in the
workflow would I think produce the result we are looking for
without all the overhead of switching hosting and all the
associated loss of history that would occur. If *all*
developers were working from personal clones (and you really
need only one because you can branch inside it and keep your
clone trunk in sync with the default repo trunk) that had code
review enabled, it would allow for all changes to be reviewed
right in Google Code *before* being pushed to the default
repo. There isn't any bandwidth hit because you don't need
local copies of all the clones. Instead, those with default
repo commit access simply point to whichever clone *on the
server* that you need to pull from when you need to update the
default repo.
A less radical modification to the current workflow would be to
use named feature branches within the default repo for any major
development that might require review. Then those with commit
access could work the change together on the branch in the default
repo and request code review before merging back to the default
branch. Anyone without commit access can still pursue the personal
clone approach then request review and pull by creating an Issue
in the tracker. That lowers the admin overhead for the main
contributors while providing a good, clean way for new
contributors to provide code in a reviewable way.
After stewing on this some more, this latter branching approach might
be preferable since it would tie the majority of the code reviews to
commits in the *default project repository* as opposed to placing it
in the personal clones, which can be deleted by the individual user at
any time. Perhaps reviews in the clones would be a way to get a
preliminary acceptance. If accepted, the changes could be pulled to a
branch in the default repo where the complete review and refinement
would take place, tied to the central project repository, prior to merge.
--
You received this message because you are subscribed to the Google
Groups "spyder" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/spyderlib/-/wowOMAPVADkJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/spyderlib?hl=en.
--
You received this message because you are subscribed to the Google Groups
"spyder" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/spyderlib?hl=en.
