[Debian-med-packaging] Git workflow issues (Was: Droping symbols file from staden-io-lib?)

[Andreas Tille]

[Sorry for not changing the subject earlier]

On Tue, Jul 07, 2015 at 06:20:33PM +0900, Charles Plessy wrote:
> Hi Andreas,
> 
> Thanks for putting this in a README file.

Thanks to my bad memory I need to write down such things somehow. :-)
 
> Le Tue, Jul 07, 2015 at 11:00:49AM +0200, Andreas Tille a écrit :
> > > 
> > >     git pull https://github.com/arq5x/bedtools2 --tags
> > 
> >    FIXME: If this leads to lot of merge conflicts, do what?
> 
> I checked the command before sending my previous email, and there was no
> conflict.  In this repository, the master branch tracks upstream's master
> branch and is never modified locally, so there should never be conflicts.

So far for the theory ...
 
> (If you tried to use git-import-orig, then things probably ended up
> badly broken)

I did a fresh

   gbp clone ssh://git.debian.org/git/debian-med/bedtools.git
   cd bedtools
   checkout master ## which makes no difference but to be sure
   LC_ALL=C git pull https://github.com/arq5x/bedtools2 --tags

leaves me with the previously attached log.

> > I do not wnat to sound stubborn and I'm perfectly willing to learn but
> > the problems I am facing as a packager (see attached conflict log) seem
> > to be larger than the difference between a pull request and a
> > 
> >    git am <quiltpatch>
> > 
> > at upstream side.  Am I missing something?
> 
> You are missing that some patches sent by email tend to end up in /dev/null :)
> Especially for spelling mistakes and other Lintian requirements when run
> with --pedantic.  With pull requests, Upstream can click on a button be
> done with the issue, regardless on whether he has access to a local clone.
> 
> Furthermore, mutt messes with lines starting with “From” by adding a “>”
> character (see below for an example !) and in my experience, this breaks git am.

I confirm that this happens but removing this ">" works fine.  I agree
that this is no good option for other people ...
 
> > >From a Debian users perspective I think bedtools last version would have
> > been uploaded yesterday (provided no build problems might occure) if
> > bedtools would have a default workflow.  This is IMHO in the interest of
> > our users.  Don't you think upstream could import quilt patches
> > similarly easy as they could pull?
> 
> Sorry for being slow on bedtools; I can do the upload later this week.

There is no need to sorry form your side.  I simply try to make everybody
"replacable" (run-over-by-bus-factor > 1).  Everybody could have time
constraints which should not affect the output of the team.

> I think that people using GitHub do not want to hear about patches.  I tried a
> few times to paste a patch in the issue tracker, and the answer was “please
> sent a proper pull request”.  I think that sending a patch to GitHub users is
> like top-posting on Debian mailing list.  In theory, one should not care, but
> in practice, it leads to culture clash.

Well, if it is about technique this might be.  If it is about culture to
my perception it is impolite to ignore the work of persons with the
obvious intent to help (be it by appended patches to mails or links to
patches on alioth for downloading).  For sure there might be impolite
upstreams around but I usually had to deal with either polite or
"vanished" upstreams.  I did not had any contact to people who asked me
to enable pull requests or go away.

Anyway, I try to learn what needs to be learned.  May be you might be
able to reproduce my problem and find a proper solution I could adopt.
 
Kind regards

     Andreas.

-- 
http://fam-tille.de