Hello, On Sat 29 Jun 2019 at 03:43PM +01, Ian Jackson wrote:
> Sean Whitton writes ("Re: Bug#903392: want support for packaging-only
> maintainer views"):
>> On Sat 29 Jun 2019 at 02:55pm +0100, Ian Jackson wrote:
>> > Sean Whitton writes ("Re: Bug#903392: want support for packaging-only
>> > maintainer views"):
>> >> On Thu 27 Jun 2019 at 05:23pm +0100, Ian Jackson wrote:
>> >> > Secondly:
>> >> >
>> >> > If the user says "use upstream from git" but there is no git, the user
>> >> > gets an error message mentioning git tags and that can also say
>> >> > something about the other quilt mode.
>> >> >
>> >> > If the user says "use upstream tarball" but they had git available,
>> >> > the result is to silently ignore the upstream history and use a
>> >> > tarball import instead.
>> >> >
>> >> > In keeping with the philosophy of making doing the right thing
>> >> > convenient, suboptimals things possible, and requiring mistakes to be
>> >> > explicit, ISTM that the tarball variant should mention that.
>> >>
>> >> "mention that"? Sorry, I'm not sure about how what you say here is a
>> >> response to what I wrote.
>> >
>> > I mean, the name for the tarball variant should mention tarball.
>>
>> Okay. I do not think what you've written is right, if I'm properly
>> understanding its implications. You seem to be suggesting that
>> baredebian+git is better than baredebian+tarball, in the sense that the
>> latter is a fallback when an upstream git tag is not available. I do
>> not think that is how people who use baredebian+tarball think of their
>> workflow.
>>
>> Perhaps I'm just misunderstanding what you're trying to say.
>
> No, I mean that there is a risk of dgit accidentally and unnecessarily
> using a worse quilt mode, due to user error.
I agree that we should try to avoid this if we can do that without
getting in other people's way.
>> I think it should be renamed. Otherwise, it might unhelpfully imply
>> that the dgit developers think that baredebian+git is better than
>> baredebian+tarball in some way.
>
> But we do. I agree we don't want to make value judgements about this
> kind of thing unnecessarily, but:
>
> baredebian+tarball will always work, whereas baredebian+git will
> sometimes fail (wrong git tag, git tag contents are wrong).
>
> People will generally think that it is better to use an option which
> will always work, rather than one which might fail for additional
> reasons.
>
> Or to put it another way: users who need +tarball need it and do not
> have a choice.
>
> Users who can use +git need to be told that +git is better thaj
> +tarball because it (i) publishes upstream git history
> (ii) double checks that their package is sane.
>
> Does that make sense ?
Yes, I think I understand what you want to achieve here, and I see what
you mean about people possibly just using baredebian+tarball because
they know it will always work.
Nevertheless, I am concerned that the cost of building this into dgit's
behaviour might be too high. There are people that think
baredebian+tarball is better than baredebian+git. They are going to be
turned off dgit pretty fast if they feel pushed towards using
baredebian+git by the behaviour of the actual tool, rather than just
what we say in its docs. But we really want those people to be using
`dgit push-source` for their uploads.
I.e. I don't think that there should be anything else required, other
than setting the quilt mode to baredebian+tarball, in order to have dgit
ignore any upstream tags. It would seem to go against the dgit design
goal that no-one has to change their workflow.
So how about this. baredebian+tarball prints a prominent warning
message if it thinks that baredebian+git would work, suggesting that the
user look at the docs, where they can read under baredebian+git why it's
better, and under baredebian+tarball what we think the disadvantages
are. The warning can come close to the end of dgit's output.
The user will probably see this warning when they use `dgit sbuild` or
similar. In the worst case, they'll see the warning only when it's too
late, because they're in the middle of a dgit push, but that's unlikely
to be the first time they see it.
--
Sean Whitton
signature.asc
Description: PGP signature
