From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git-for-windows@googlegroups.com, git@vger.kernel.org
Subject: Re: Continuous Testing of Git on Windows
Date: Mon, 13 Feb 2017 15:46:45 -0800 [thread overview]
Message-ID: <xmqq60kdbqmy.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1702101241210.3496@virtualbox> (Johannes Schindelin's message of "Fri, 10 Feb 2017 13:24:20 +0100 (CET)")
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> That is why I taught the Git for Windows CI job that tests the four
> upstream Git integration branches to *also* bisect test breakages and then
> upload comments to the identified commit on GitHub
Good. I do not think it is useful to try 'pu' as an aggregate and
expect it to always build and work [*1*], but your "bisect and
pinpoint" approach makes it useful to identify individual topic that
brings in a breakage. I wouldn't be surprised if original submitter
and I were the only two people who actually compiled the patches on
a topic in isolation while a topic is in 'pu', and chances are that
these two people didn't try their builds on Windows. A CI like this
one will help the coverage to stop premature topics from advancing
to 'pu' without getting any Windows exposure.
Thanks.
[Footnote]
*1* The reason why topics not in 'next' but in 'pu', especially the
ones merged near the tip of 'pu', exist in 'pu' are because they
are interesting enough and could be polished to become eligible
for 'next' but known to be premature for 'next' yet. They are
there primarily to give human contributors an easier way to
download them as a whole and help polish them. And I have to be
selective when I queue things on 'pu'; it is not like I have
infinite amount of time to pick up any cruft that is sent to the
list.
next prev parent reply other threads:[~2017-02-13 23:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-10 12:24 Continuous Testing of Git on Windows Johannes Schindelin
2017-02-13 23:46 ` Junio C Hamano [this message]
2017-02-14 20:55 ` [git-for-windows] " Johannes Schindelin
2017-02-14 21:08 ` Junio C Hamano
2017-02-14 23:00 ` Christian Couder
2017-02-14 23:11 ` Junio C Hamano
2017-02-14 23:27 ` Philip Oakley
2017-02-14 23:35 ` Junio C Hamano
2017-02-15 17:31 ` Philip Oakley
2017-02-15 21:26 ` Junio C Hamano
2017-02-15 23:33 ` Philip Oakley
2017-02-16 1:33 ` Junio C Hamano
2017-02-15 22:19 ` Philip Oakley
2017-02-15 22:19 ` Philip Oakley
2017-02-15 14:22 ` Johannes Schindelin
2017-02-15 23:57 ` Philip Oakley
2017-02-16 0:20 ` Junio C Hamano
2017-02-18 11:49 ` Philip Oakley
2017-02-15 14:07 ` Johannes Schindelin
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=xmqq60kdbqmy.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git-for-windows@googlegroups.com \
--cc=git@vger.kernel.org \
/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).