Web lists-archives.com

Re: Preferred git branch structure when upstream moves from tarballs to git




>>>>> "Ian" == Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx> writes:

    Ian> Sam Hartman writes ("Re: Preferred git branch structure when
    Ian> upstream moves from tarballs to git"):
    >> I'm aware I'm making a typing error, and speaking in
    >> generalities.  I agree that my statement is true for debrebase,
    >> but I meant the dgit ecosystem.

Thanks so much for both this  mail and your previous one.
As an aside, frustration is part of the game.
What I'm happy about is that we're working to respect each other and
that we're reaching understanding.
I expect to be frustrated; it's part of life and being passionate about
what we do.
I'm happy when people work with me as you're doing and we get past that.
Thank you very much for working with me.


    Ian> The latter point is because using dgit push is an ethical
    Ian> imperative, not because the two somehow have some deep
    Ian> technical linkage.  IMO almost *any* tutorial being written now
    Ian> about how to do Debian packaging, and which mentions git at
    Ian> all, ought to say to use dgit.

I think this is at the crux of our disagreement.
I'm going to need to think about this for myself.
I think it's safe to say there is not a project consensus that dgit is
an ethical imperative.
And yes understanding that you believe that's the case makes it a lot
easier to understand the rest of your mail.

As I said I'll need to think about whether I agree with that.  A lot of
my thinking in this discussion is that I consider dgit a nice to have,
not a requirement.


    >> Dgit and debrebase are not really separate in terms of teaching.
    >> If you look at the documentation for debrebase, you'll find that
    >> there are a lot of cross references from debrebase docs to dgit.

    Ian> dgit and gbp pq are not separate in terms of teaching either!

If you accept the premis that everyone should be using dgit, I agree
with you.
I don't think the gbp documentation has adopted that premis.

    >> Dgit is harder overall even if you ignore debrebase because it
    >> has a lot of moving parts that in my experience sometimes fail
    >> and because dgit wants to get involved in your build process,
    >> wants to be aware of your patch management, etc.

    Ian> When dgit fails it is, almost always, because the "source code"
    Ian> you are uploading to the Debian archive is not the same as what
    Ian> you are actually working with as the source code in your own
    Ian> workflow.

For me I'm finding I need to include or not include some overwrites, or
running into trouble with keys or random stuff like that.
I find it takes me two or three attempted pushes to get it right and
about half the time dgit's right that I should adjust something and half
the time I'm fairly sure I disagree with it.
And yeah, I should file bugs, and I have sometimes, and will file more
in the future.

    Ian> The only reason dgit needs to get involved in your build
    Ian> process is because of the .gitignore bug.  (#908747)

Well, and dgit wants to construct my dsc, which means it wants to
construct my changes, which... means it wants to call sbuild or
something else for me.


Anyway, thanks; I think your message clarified where I need to think
more.