Hi, > > > fwiw, I'm also not using git-buildpackage and I don't want to. (Step > > > learning > > > curve, too much magic, hard to debug and I dont see benefits for the > > > packages > > > I maintain.) I'm also not a beginner. And I love gbp-dch. > > I think git-buildpackage is great, and I am a happy user. However, it > > took me quite a while to figure out what is the optimal way to use it, > > as it has so many options. Can you elaborate what is the specific > > action/workflow you think git-buildpackage you were frustrated with? > > sigh. see above.
I obviously saw above and I think asking for more details I think is fair so we can discuss if the thing you experienced as "hard to learn" or "had too much magic" was fundamentally bad and can't be fixed, or perhaps if better docs or better error handling etc can make that frustration go away. I feel we should try to polish and improve the existing tooling that the majority uses, rather than giving up on it and demand an entirely new tool or workflow. > in addition to the above: gbp is great if it works, if it doesn't I can > start to learn to debug a complex system, while on the contrary, if I use > git and debuild/pbuilder/sbuild manually all the time, I know those tools, > they are rather easy to debug etc. Personally I think gbp is very easy to debug. You just add --verbose to any command and it will print out what it is doing. Example: ± gbp import-orig --uscan --verbose gbp:debug: ['git', 'rev-parse', '--show-cdup'] gbp:debug: ['git', 'rev-parse', '--is-bare-repository'] gbp:debug: ['git', 'rev-parse', '--git-dir'] gbp:debug: ['git', 'for-each-ref', '--format=%(refname:short)', 'refs/heads/'] gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream'] gbp:error: Repository does not have branch 'upstream' for upstream sources. If there is none see file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.CONVERT on howto create it otherwise use --upstream-branch to specify it. I am sure you already knew this, but pasting here an example for the sake of discussion. The output and debuggability can for sure further be improved still, I am not saying gbp is perfect, but it is by far the best we have and deserves to be the thing any team or large group standardize on today to have an easier time collaborating. > > I think this will be more successful if you frame this as good patterns > > to follow for people who wish to opt-in on the premise of adopting this > > workflow. That framing follows other DEP's. Now it reads as a mandate > > for everything. Acknowledging existance of exceptions to the rules > > within the rules may also help to gain acceptance. > > This! Thanks for the feedback, I will try to further iterate on the introduction part in DEP-18 to make is more clear what is the purpose and that a DEP-18 is not a policy and is opt-in like all the other DEPs.
