On Thu, Mar 01, 2012 at 11:45:40AM +0300, Alexey Shvetsov wrote:
> Not sure if its for council.
I don't think it's suitable for council, but it does need more
discussion than it's been getting on the scm list.

> Define timeframe for cvs->git migration. Technical issues almount 
> finished
> 1. Thin manifests already in portage
> 2. Git commit signing already there (if git-1.7.9 will be keyworded due 
> to issue with svn 1.7 [git-svn functionality with SVN 1.7 if your
>    SVN repo URL, branch name or tag names contains characters that need 
> URL escaping])
Do you have a fix for the Git SVN 1.7 problem then?

Other items not included in the above, that we need some agreement on.
- Initial tree state:
  Single commit, signed by me, with a graft of history available as a
  separate download (it's ~1200MB) . This ensures that all of the
  history is available AND that the usual downloads for developers are
  very small.
  Alternatively, how much history should we include in the base
  download?
- Log generation
- Potentially dropping Changelogs in Git (generate
  shortly during rsync tree generation?)
- Merge policies
  This is the hardest political topic.
  Do we force users to rebase before they push to the tree?
  Before you say yes, of course, there is a catch:
  If the user publishes their work in MORE than one place, and does push
  to remote A/master, pull from remote B/master, rebase master on
  B/master, push to remote B/master. Now what do they do about the state
  of remote A? They _HAVE_ to either have a merge of A/master, or
  destroy the history at A/master with a forced push.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@g.o
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85