On Sun, Jul 12, 2020 at 19:16, Jessica Clarke <jrt...@debian.org> wrote:
On 12 Jul 2020, at 18:39, Pirate Praveen <prav...@onenetbeyond.org>
wrote:
On Sun, Jul 12, 2020 at 21:50, Pirate Praveen
<prav...@onenetbeyond.org> wrote:
Erm… I did add buster-backports, the official one.
You absolutely cannot have a thing called buster-backports on the
fasttrack server because that’s too easily confused with the
official one.
Let me think about it.
Usually with the same suite name, I just have to upload the same
.changes file when the package enters testing. So changing the name
just adds extra busy work (multiple changelog entries and rebuilds)
without any real benefit. Like in the case of ruby-faraday, I just
had to dput the .changes file I already created for
fasttrack/buster-backports to official buster-backports. So I will
stick with it unless someone can show me some real advantage.
This response is, quite frankly, extremely rude and disrespectful
towards
Thorsten. Your "without any real benefit" completely disregards the
original
reason given which, as you can see above is "because that’s too
easily confused
with the official one.". As for the approach, do not do this.
Seriously.
Whatever your motivation. If seasoned DDs are being confused by you
creating
your own thing with an identical name to a core part of Debian, how
on earth do
you expect users to not be confused out of their minds? Not to
mention it's
going to seriously aggravate those who manage the real backports
suites and
those who follow these lists, as there will no doubt be users coming
along
complaining about things that apply to your name-hijacked version and
not the
actual backports suites. So call it something else; I doubt many DDs
will view
your project favourably if you don't. Also, a word of advice: never
prioritise
your own convenience over user experience. It portrays you as
selfish, and in
this case stubborn, neither of which are a good look.
Sorry about that particular line. I should have been more careful with
my words. I wanted to say I'm open to change, but ended up disregarding
the original reason.
We accepted his suggestion about dropping priority to 100 and setting
the automatic upgrades setting to match buster-backports suite, so it
was not the intention to be rude or disregard his suggestions
completely. I have not shared this info here earlier because we have
not implemented it yet.
Now, for some constructive _technical_ advice. You don't need to
require
rebuilds if you don't want to. I see two options for what you can do
to avoid
that:
1. Manually edit the .changes file, changing Distribution:, and then
re-sign.
You'll need to configure your DAK instance to not have the lintian
tag
distribution-and-changes-mismatch in its lintian.tags though (or
override it
in the package, but that's a bit weird and dangerous).
2. Configure SuiteMappings in your dak.conf to redirect
buster-backports
uploads to buster-foo. That's it. You can present whatever name
you like to
users, and uploads to your service for buster-backports magically
end up in
the right place.
The second one is probably the better approach, though does come with
the risk
that anyone can inject a signed -backports .changes file into your
service.
That's generally frowned upon, but in this case you probably view it
as a
feature. I'm in two minds about that, but that's ultimately up to you
running
the service to decide.
I think we will take the second approach and name it
fasttrack-buster-backports (like we have buildd-buster-backports for
incoming.debian.org).
What frustrates me is that, had you responded more appropriately and
simply
explained your motivations for doing what's currently implemented, we
could
have skipped that whole first paragraph and gone straight to
solutions which I
believe solve the problem for both sides. If you want people to be
more willing
to help you, work with them, not against them, and especially don't
disregard
their views. You may find solutions you didn't even know were
possible (or even
thought to consider), like I suspect is the case here.
Thanks to both of you for your suggestions and time.
Jess
