From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: "Michael Muré" <batolettre@gmail.com>,
git@vger.kernel.org,
"Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Subject: Re: git-bug: Distributed bug tracker embedded in git
Date: Sat, 18 Aug 2018 14:24:26 +0200 [thread overview]
Message-ID: <874lfrrhfp.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <20180818054300.GB241538@aiede.svl.corp.google.com>
On Sat, Aug 18 2018, Jonathan Nieder wrote:
> Hi,
>
> Michael Muré wrote:
>
>> I released today git-bug, a distributed bug tracker that embeds in
>> git. It use git's internal storage to store bugs information in a way
>> that can be merged without conflict. You can push/pull to the normal
>> git remote you are already using to interact with other people. Normal
>> code and bugs are completely separated and no files are added in the
>> regular branches.
>
> I am a bit unhappy about the namespace grab. Not for trademark
> reasons: the Git trademark rules are pretty clear about this kind of
> usage being okay. Instead, the unhappiness comes because a future Git
> command like "git bug" to produce a bug report with appropriate
> diagnostics for a bug in Git seems like a likely and useful thing to
> get added to Git some day. And now the name's taken.
>
> Is it too late to ask if it's possible to come up with a less generic
> name?
Wouldn't we call such a thing "git-reportbug", or "git gitbug", with
reference to Debian reportbug or perl's perlbug?
Addressing the more general issue, if we're concerned with 3rd party
tools usurping the core namespace trying to convince individual authors
of 3rd party tools to change the names of those tools to something more
unique is pissing in the wind.
That's never going to make a dent in the vast amount of git-whatever
tools, most of which won't be discussed as ideas on this mailing list
before they're released.
I think we basically have these options:
1) Accept the status quo where people do create third party tools, much
of which are way too obscure to matter (e.g. I'm sure someone's
created a tool/alias called range-diff before, but we didn't
care).
If those tools become popular enough in the wild they get own that
namespace, e.g. we're not going to ship a "git-annex" or "git-lfs"
ourselves implementing some unrelated features (re parallel on-list
discussion; "git annex" could also be a "git commit --amend" alias).
2) #1, but hope we catch new tools early enough to convince their
authors to change the names.
3) Make some structural change to git where only things we ourselves
compile get to be called as "git <whatever>", and you'd need to call
e.g. "git-bug" as "git ext::bug" or something. We'd need to have a
large hardcoded list of older tools (lfs, annex, ...) to grandfather
in if we went for this approach.
I think we should just go for #1, and if we're concerned about #1 not
being OK we really need something like #3, because #2 isn't going to
work.
> Separately from that, I'm happy to see progress being made in the
> distributed bug tracker world; thanks for that!
>
> Thanks,
> Jonathan
next prev parent reply other threads:[~2018-08-18 12:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-17 22:06 git-bug: Distributed bug tracker embedded in git Michael Muré
2018-08-17 23:20 ` Tacitus Aedifex
2018-08-18 5:43 ` Jonathan Nieder
2018-08-18 12:24 ` Ævar Arnfjörð Bjarmason [this message]
2018-08-18 20:42 ` Jonathan Nieder
2018-08-18 21:53 ` Ævar Arnfjörð Bjarmason
2018-08-18 22:08 ` Jonathan Nieder
2018-08-18 22:19 ` Ævar Arnfjörð Bjarmason
2018-08-18 22:26 ` Jonathan Nieder
2018-08-19 21:08 ` Jeff King
2018-08-18 16:21 ` Junio C Hamano
2018-08-19 1:27 ` Jonathan Nieder
2018-08-19 4:00 ` Kyle Meyer
2018-08-19 5:01 ` Jonathan Nieder
2018-08-18 22:50 ` Jonathan Nieder
2018-08-19 0:45 ` Michael Muré
2018-08-19 1:14 ` Michael Muré
2018-08-19 2:06 ` Elijah Newren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874lfrrhfp.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=batolettre@gmail.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).