git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Nico Williams <nico@cryptonector.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH 00/18] Signed push
Date: Tue, 19 Aug 2014 22:57:56 -0700	[thread overview]
Message-ID: <CAPc5daWTeiW_4k9nCH_CQGPPva-dLtmWFu4KN-cxxw6J1MQFUw@mail.gmail.com> (raw)
In-Reply-To: <CAPc5daWJj1oM3ebc59sbpORggoigyq-hSOvfc0ueFHD=WeCYWg@mail.gmail.com>

On Tue, Aug 19, 2014 at 7:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Sorry, but I cannot answer, as the only thing that I recall when
> I hear "branch object" was that I heard the phrase used but
> without much substance.

Just to avoid unnecessary misunderstanding, by the above, especially
the "without much substance" part, I do not mean that those without
code have no say in the way the project improves its product. It is true
that this project does not operate in such a way that visionaries throw
ideas for coding minions to implement. A person with an itch and idea
on how to scratch that itch is expected to lead the design and code,
possibly with help from others. But in order to ask others evaluate and
join force to help with the design and make it real with code, you need
to present your idea to sufficient level of detail to be actionable.

By "actionable", consider the level of detail in which the proposed log
message (not code or documentation update) of PATCH 15/18. Even
though the message alone does not give any working code, or it does
not even spell out the byte-level detail of how the protocol messages
look like, people should be able to read enough details such as what
kind of information a push certificate is to contain, when a certificate is
created, how it is transferred, when and by whom it is received, how it
will be used by the receiver, how a server operator can tweak his or
her system to make use of the information, and how the newly added
system component would fit into the existing system. In other words,
the description should be sufficient to assess both how useful the end
result would be, how much new work needs to be done to get there,
and how well the resulting system as a whole would fit together well.

I went back to the old thread to re-read the mention of "branch object",
but I did not get an impression that the idea was presented to the
actionable level of detail; at least not yet.

  reply	other threads:[~2014-08-20  5:58 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-19 22:06 [PATCH 00/18] Signed push Junio C Hamano
2014-08-19 22:06 ` [PATCH 01/18] receive-pack: do not overallocate command structure Junio C Hamano
2014-08-19 22:06 ` [PATCH 02/18] receive-pack: parse feature request a bit earlier Junio C Hamano
2014-08-19 22:31   ` Junio C Hamano
2014-08-19 22:06 ` [PATCH 03/18] receive-pack: do not reuse old_sha1[] to other things Junio C Hamano
2014-08-19 22:32   ` Junio C Hamano
2014-08-19 22:06 ` [PATCH 04/18] receive-pack: factor out queueing of command Junio C Hamano
2014-08-19 22:06 ` [PATCH 05/18] send-pack: move REF_STATUS_REJECT_NODELETE logic a bit higher Junio C Hamano
2014-08-19 22:06 ` [PATCH 06/18] send-pack: refactor decision to send update per ref Junio C Hamano
2014-08-19 22:06 ` [PATCH 07/18] send-pack: always send capabilities Junio C Hamano
2014-08-19 22:06 ` [PATCH 08/18] send-pack: factor out capability string generation Junio C Hamano
2014-08-19 22:06 ` [PATCH 09/18] send-pack: rename "new_refs" to "need_pack_data" Junio C Hamano
2014-08-19 22:06 ` [PATCH 10/18] send-pack: refactor inspecting and resetting status and sending commands Junio C Hamano
2014-08-19 22:06 ` [PATCH 11/18] send-pack: clarify that cmds_sent is a boolean Junio C Hamano
2014-08-19 22:06 ` [PATCH 12/18] gpg-interface: move parse_gpg_output() to where it should be Junio C Hamano
2014-08-19 22:06 ` [PATCH 13/18] gpg-interface: move parse_signature() " Junio C Hamano
2014-08-19 22:06 ` [PATCH 14/18] pack-protocol doc: typofix for PKT-LINE Junio C Hamano
2014-08-19 22:06 ` [PATCH 15/18] the beginning of the signed push Junio C Hamano
2014-08-20  2:48   ` brian m. carlson
2014-08-20  6:57   ` Bert Wesarg
2014-08-20 23:41     ` Junio C Hamano
2014-08-19 22:06 ` [PATCH 16/18] receive-pack: GPG-validate push certificates Junio C Hamano
2014-08-20 16:56   ` David Turner
2014-08-20 17:29     ` Junio C Hamano
2014-08-20 17:56       ` David Turner
2014-08-20 19:38         ` Junio C Hamano
2014-08-21 23:59           ` David Turner
2014-08-22  0:11             ` Junio C Hamano
2014-08-19 22:06 ` [PATCH 17/18] send-pack: send feature request on push-cert packet Junio C Hamano
2014-08-19 22:06 ` [PATCH 18/18] signed push: final protocol update Junio C Hamano
2014-08-21 19:28   ` Shawn Pearce
2014-08-21 23:40     ` Junio C Hamano
2014-08-22  3:06       ` Kyle J. McKay
2014-08-22 17:59       ` Junio C Hamano
2014-08-22 23:54         ` Shawn Pearce
2014-08-25 17:59           ` Junio C Hamano
2014-08-26 17:33             ` Shawn Pearce
2014-08-26 19:38               ` Junio C Hamano
2014-08-26 19:52                 ` Junio C Hamano
2014-09-04 23:57           ` Junio C Hamano
2014-09-05  2:41             ` Shawn Pearce
2014-08-22  4:20     ` Junio C Hamano
2014-08-22  0:22   ` David Turner
2014-08-19 23:07 ` [PATCH 00/18] Signed push Duy Nguyen
2014-08-19 23:29   ` Junio C Hamano
2014-08-20  1:19 ` Nico Williams
2014-08-20  2:54   ` Junio C Hamano
2014-08-20  5:57     ` Junio C Hamano [this message]
2014-08-20  2:39 ` Junio C Hamano
2014-08-20  6:28   ` Nico Williams
2014-08-22 19:59 ` Stefan Beller
2014-08-22 20:03   ` Junio C Hamano
2014-08-22 20:22     ` Stefan Beller
2014-08-22 20:33       ` Junio C Hamano
2014-08-22 20:38         ` Stefan Beller
2014-08-22 22:32           ` Junio C Hamano
2014-08-22 22:51             ` Stefan Beller
2014-08-25 17:54               ` Junio C Hamano
2014-08-25 18:38                 ` Jason Pyeron

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=CAPc5daWTeiW_4k9nCH_CQGPPva-dLtmWFu4KN-cxxw6J1MQFUw@mail.gmail.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=nico@cryptonector.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).