On Monday, May 21, 2012 11:00:17 AM Rich Freeman wrote:
> On Mon, May 21, 2012 at 7:58 AM, Ultrabug <ultrabug@g.o> wrote:
> > It also may be interesting to use the github workflow with
> > proxy-maintainers (which might also make the proxy-maintainers project
> > even more visible) ?
> 
> Tend to agree, although a big liability will be the fact that we're
> still not on git ourselves.  So, to be useful that github tree would
> to get regular cvs updates incorporated, and then any content would
> need to be manually moved over.  The trees would be constantly
> slightly out of sync - what happens if somebody commits a fix without
> a revbump to git and then the cvs tree refreshes git not showing the
> change, and so on?
> 
> I guess for proxy-maintained packages we could just consider the
> git-tree "official" and do all forward work there without publishing
> cvs changes automatically.  Then cvs updates are just manual copies
> when things are good in the git tree.  However, the second somebody
> comes along with some library package move or other tree-wide change
> they're going to make things out of sync unless they know to go update
> git.
> 
> Seems like overlays are the best candidate for a place to start since
> they largely use git already.  Maybe this is just one more reason to
> get the main tree onto git as well...
> 
> Rich

Managing more than a few eclass/builds fromthe main tree while watching 
upstream (Gentoo) for conflicts is a very difficult workflow. For those projects 
already using git like Kde and Haskell it's at least helpful to be able to 
look at logs and do diffs on my own machine. Users get much more out of having 
git available than those with commit access.

-- 
Dan Douglas