[pymvpa] /Developers only/ GIT repository/clones restructuring/migration

[Yaroslav Halchenko]

Hi Valentin,

THANKS bunch for all the feedback!  Clarifications (and few
follow up questions) are below

> > in your own clones at github -- please move them over or remove from
> > alioth::
> You neglected to mention that you had already removed them from alioth. ;p
oops, sorry:   

All branches which were already merged into master branch
present on github were removed.  So you should be safe to proceed with
just the master as a starting point.  And if you used them locally, you
still would have them ;-) so you could push them to your clones's master
correspondingly -- everyone should be safe -- we watched your backs ;)

> I moved them both to my github clone, so i guess if you still have
> '/remotes/alioth/val/*' lying around you can get rid of those with
> ' git remote prune alioth'. Assuming of course that your remote for the alioth
> repository was indeed called 'alioth'.
yes it was ;-) thanks!

> > alioth.debian.org (AKA git.debian.org) Will eventually be ...
> Why don't you remove push access for anyone except the
> core-developers?
I am not sure if we have that much of granularity of control over it
(everyone within pkg-exppsy project has rights atm), besides ACL at
filesystem level which I am not fluent with or adjusting the hook
further...  but introduced hook already should forbid most of evil
actions (besides fast-forwarding branches and pushing new tags) so
we should be safe.  We even thought to provide custom commit on top of
master which removes everything and adds README describing the migration
-- that would forbid further pushes of code, and provide proper
referencing... but we decided to postpone such radical step for now

> >   No _tent branches, nor +tent tags should be pushed in there.  Only
> >   annotated tags for upstream or distribution releases should end up
> >   there
> Again, the same comment as for alioth.
That is trickier one to assure (besides that I already hardcoded in my
.git/config only what gets pushed) since I have not got myself familiar
yet with ways on how to provide hooks on github, please see/answer
my question at nipy-devel:
http://mail.scipy.org/pipermail/nipy-devel/2010-August/004455.html

> >   - master branch -- development/integration branch, intended to be
> > 	eventually pushed (thus fast-forward only) as master of
> > 	PyMVPA/PyMVPA repository
> What does this mean exactly? Should the branches in the developers repository
> reflect the state of master in the PyMVPA repository?
They should be based on it

> Can developers use their master to develop stuff in?
yes

> Will you merge the developers masters?
yes, upon pull request (via github system or just email)

Also I've forgotten to mention that bugfixes for maintenance versions
should be in _bf/ branches on top of maint/x.y, not sure but it might be
also useful to embed maintenance version into branch name, e.g.
_bf/0.4.5_... ?

> >   - _tent/ (tentative) feature and _bf/ (bugfix) branches which you
> > 	would like us (or you into your master first) to integrate

> >   - +tent/ unsigned/unannotated tags to point at the locations when
> >     your corresponding _tent/ branch got accepted (not necessary if
> > 	feature is "minimalistic" and not worth memorizing)
> Would you want us to rebase topic branches onto the PyMVPA master, so that
> merges go cleanly?
in general rebases should be avoided as soon as branch is seen publicly,
so the flow could be

* if branch you want to be merged was not yet pushed online, please
  rebase it against corresponding branch current HEAD, before pushing it
  online

* if branch was already pushed, please do not bother with rebasing, but
  make sure that it merges fine into current HEAD before pushing -- may
  be even merge corresponding HEAD before pushing? what would you
  advise?

> This removes old tags, sure i had those locally and removed them. I didn't see
> any that were prefixed with '--' though.
good for you then ;-)

> > 	 git push <your_github_clone> :last_website_update
> > 	 git push <your_github_clone> :sg/unittests_passed
> But this only applies if i forked on gihub, before the tags were removed. Since
> i only forked today, i do not need to do this.
yes -- thank you for clarification!

> > fetch -- you will obtain all tags from that remote, and then they would
> > propagate to others who would clone you, etc... So, please
> But they would only propagate if i push them right? afaics you must push tags
> explicitly, or use the '--tags' switch for push.
yes yes yes ;)  or if you have something like
	push = refs/tags/*
for the corresponding remote in your .git/config

> It may also make sense to fetch into a temporary branch to examine the changes
> before merging:

>       git fetch git at github.com:PyMVPA/PyMVPA.git $REMOTE_BRANCH:$LOCAL_TEMPORARY
>       git log $CURRENT_BRANCH..$LOCAL_TEMPORARY
>       git merge $LOCAL_TEMPORARY
COOL -- thanks for sharing, I've not checked before either  I could
fetch using URL -- good to know!

-- 
                                  .-.
=------------------------------   /v\  ----------------------------=
Keep in touch                    // \\     (yoh@|www.)onerussian.com
Yaroslav Halchenko              /(   )\               ICQ#: 60653192
                   Linux User    ^^-^^    [175555]