git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Lars Schneider <larsxschneider@gmail.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Johannes Sixt <j6t@kdbg.org>, git <git@vger.kernel.org>,
	Jeff King <peff@peff.net>
Subject: Re: [PATCH] t0021, t5615: use $PWD instead of $(pwd) in PATH-like shell variables
Date: Mon, 14 Nov 2016 09:21:22 -0800	[thread overview]
Message-ID: <xmqqshqux9il.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <0BEC2674-20B5-4AD1-851A-97CA34C0CE7F@gmail.com> (Lars Schneider's message of "Mon, 14 Nov 2016 10:11:12 +0100")

Lars Schneider <larsxschneider@gmail.com> writes:

>> On 13 Nov 2016, at 02:13, Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>> Earlier you said 'pu' did even not build, but do we know where this
>> "still times out" comes from?  As long as I don't merge anything
>> prematurely, which I need to be careful about, it shouldn't impact
>> the upcoming release, but we'd need to figure it out before moving
>> things forward post release.
>
> What is the goal for 'pu'?
>
> (1) Builds clean on all platforms + passes all tests
> (2) Builds clean on all platforms
> (3) Builds clean on Linux
> (4) Just makes new topics easily available to a broader audience
>
> My understanding was always (4) but the discussion above sounds 
> more like (1) or (2)?

The purpose of 'pu' is none of the above, but its intended effect
for people other than me is (4).  It is primarily meant as a way for
me to avoid having to go back to the mailing list archive to find
topics that I felt that were potentially interesting but not yet
ready and may want to get commented on later.  When queued on 'pu',
it is not unusual that I haven't really looked at the patches yet,
and it is not surprising if it does not build on any platform.

When queued to 'pu', the reason of the initial "not yet ready"
assessment may not have anything to do with the quality of the
patches but based on the phase of the development (e.g. during a
feature-freeze, it is less efficient use of our time to take new
topics to 'next'), so what was queued on 'pu' may get merged to
'next' without any update, after getting looked at by me or by
other people and deemed to be worth trying out.

Dscho's mention of 'still times out' may be an indiciation that
something unspecified on 'pu' is not ready to be merged to 'next',
but blocking all of 'pu' with a blanket statement is not useful,
and that was where my response comes from.  We need to know more
to say "this particular topic is not ready", so that we can unblock
other innocent topics.

  parent reply	other threads:[~2016-11-14 17:21 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-11 16:29 [PATCH] mingw: hot-fix t5615 Johannes Schindelin
2016-11-11 17:06 ` Junio C Hamano
2016-11-11 17:11   ` Johannes Sixt
2016-11-11 17:31     ` [PATCH] t0021, t5615: use $PWD instead of $(pwd) in PATH-like shell variables Johannes Sixt
2016-11-11 18:16       ` Jeff King
2016-11-11 18:55       ` Junio C Hamano
2016-11-12 11:40         ` Johannes Schindelin
2016-11-13  1:13           ` Junio C Hamano
2016-11-14  9:11             ` Lars Schneider
2016-11-14 16:35               ` Torsten Bögershausen
2016-11-14 17:01                 ` Jeff King
2016-11-14 19:45                   ` Ramsay Jones
2016-11-14 17:21               ` Junio C Hamano [this message]
2016-11-15 16:54                 ` Johannes Schindelin
2016-11-16  9:47                   ` Johannes Schindelin
2016-11-16 21:51                     ` Junio C Hamano
2016-11-11 18:12 ` [PATCH] mingw: hot-fix t5615 Jeff King

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqshqux9il.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=j6t@kdbg.org \
    --cc=larsxschneider@gmail.com \
    --cc=peff@peff.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).