Re: [Swig-devel] SWIG on Github

[Geert J. <in...@ko...>]

On Tuesday 23 April 2013 23:47:49 William S Fulton wrote:
> On 20/04/13 08:35, Geert Janssens wrote:
> > On Friday 19 April 2013 19:28:29 William S Fulton wrote:
> >  > On 23/03/13 13:15, Geert Janssens wrote:
> >  > > A meta question...
> >  > > 
> >  > > 
> >  > > 
> >  > > I have cloned the master repository and have been playing on a
> >  > > private
> >  > > 
> >  > > branch for my guile updates.
> >  > > 
> >  > > 
> >  > > 
> >  > > I don't think my work is ready yet to be merged into the main repo.
> >  > > But
> >  > > 
> >  > > I'd like to publish what I have so far to gather feedback.
> >  > > 
> >  > > 
> >  > > 
> >  > > Since I have been working on a private branch so far, it was easy to
> >  > > 
> >  > > rebase my branch to the latest master HEAD. But I read here and there
> >  > > 
> >  > > that rebasing published branches is not really recommended.
> >  > > 
> >  > > 
> >  > > 
> >  > > So I wonder what swig's public branch policy is ?
> >  > 
> >  > In the official swig repo, it will be frowned upon to rebase.
> > 
> > Understood
> > 
> >  > > I can push my branch to a cloned git repo, so others can look into it
> >  > > 
> >  > > there or pull it into their own local repos. Can I still rebase it
> >  > > 
> >  > > afterwards without causing too much frustration for other developers
> >  > > ?
> >  > 
> >  > For your own clone, you can do what you like. If other people are
> >  > 
> >  > collaborating with you in your repo, then rebasing would be a bad idea.
> >  > 
> >  > How about a private guile dev branch that you merge to a public guile
> >  > 
> >  > dev branch which you advertise for general use?
> >  > 
> >  > > Or should I start merging the master branch into my personal branch
> >  > > 
> >  > > regularly from there on ?
> >  > 
> >  > Yup. Eventually I'd like one patch to apply to master for your initial
> >  > 
> >  > guile update. We could do it via a merge from your repo/branch, but it
> >  > 
> >  > seems that git bisect doesn't like branches, so I'm wondering if we
> >  > 
> >  > should avoid branches and keep the development linear. It seems there
> >  > 
> >  > are two schools of thought on best development practices for git, but
> >  > we
> >  > 
> >  > are still learning our way.
> >  
> >  From some quick search on the internet, it seems that bisect can work
> > 
> > perfectly fine with branches (1). But I haven't had real life experience
> > with bisection across branches myself so I'm in no position to actually
> > make statements about best practice. If you like to keep development
> > linear, how about cherry-picking the individual commits on my branch ?
> > 
> > I'm currently at 6 commits. Two for the actual introduction of guile 2.0
> > support, one cleanup commit before, one for dropping guile 1.6 support,
> > one for dropping the guile gh interface and the last one to fix the
> > deprecation warnings.
> > 
> > Theoretically I could reduce this into one big patch, but that would
> > make it much harder to understand what I actually did and why. So I
> > prefer to keep them in separate commits.
> 
> No, that is a nice manageable number of commits for what is a fairly big
> impact change. Perfect!
> 
> You update your repo to the HEAD of master as with the latest fixes
> applied, you will probably have a full pass of the test-suite. There are
> a couple of silly warnings which would be nice to fix. If you don't, I
> will fix them as I try keep the number of warnings right down to
> suppress the noise they make.
> 
> The nspace feature is missing in all the scripting languages, so don't
> worry about that. One day I'd like this feature finished off for all the
> languages.
> 
> Before merging to master, I'd like you to have the Travis builds showing
> green in your github repo. First you should set up Travis on your repo
> which is dead easy, see
> http://about.travis-ci.org/docs/user/getting-started/ Then commit the
> attached .travis.yml patch. Instead of using 'git am', you can simply
> use 'git apply' and use 'git commit --author ...', although I wouldn't
> bother with putting me as the author. It should be clear that the patch
> uses guile-2.0.
> 
> The examples probably still need some work though. The 'check' target in
> each needs fixing to run the tests properly... I'm not sure how to run
> guile for the examples which have no runtest in the 'check' target.
> 
I can look at those and see what I can improve. But I will have to postphone it a bit. Can this wait until after 
the integration of guile2 into master ?