All of lore.kernel.org
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: What's cooking in git.git (Jun 2020, #01; Wed, 3)
Date: Thu, 4 Jun 2020 23:41:45 +0000	[thread overview]
Message-ID: <20200604234145.GA6569@camp.crustytoothpaste.net> (raw)
In-Reply-To: <xmqqlfl3rhl0.fsf@gitster.c.googlers.com>

[-- Attachment #1: Type: text/plain, Size: 1906 bytes --]

On 2020-06-03 at 20:59:39, Junio C Hamano wrote:
> Here are the topics that have been cooking.  Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'.  The ones marked with '.' do not appear in any of
> the integration branches, but I am still holding onto them.
> 
> Git 2.27 has been tagged, and the first batch of topics (including
> the "throw protocol v2 to the experimental group of features" thing)
> have been merged to the 'master' branch.  I'm planning to rewind the
> tip of 'next' in a not-so-distant future.
> 
> Seeing a handful of regression reports [*] immediately after a
> feature release is made gives me a mixed feeling: people are eager
> enough to help by reporting issues they encounter, but there are not
> enough people who are eager enough to help by testing the tip of
> 'master' before the release.  Are there things we can do to help
> them become early adopters so that they do not have to scramble
> after the release?

For folks that are using Debian, Jonathan Nieder kindly keeps Debian
experimental generally within about a week or so of the latest next
(with the -rc merged into it during that period).  (As of today, the
version is from 2020-05-31.)  This is usually what I use and it's
reasonably stable, so folks who want to test things may find it
convenient to rely on existing packages.

I don't happen to use a lot of these features, so I don't notice any
issues with them, but I have seen issues in the past with other features
and reported them.  Maybe if there are companies with folks who are
using sparse-checkout and similar features it may be helpful to build
and deploy an -rc or two if they have some way of standard deployments
to developer machines (which I admit most places don't).
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

      parent reply	other threads:[~2020-06-04 23:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-03 20:59 What's cooking in git.git (Jun 2020, #01; Wed, 3) Junio C Hamano
2020-06-04  8:14 ` Elijah Newren
2020-06-04 14:32   ` Christian Couder
2020-06-04 14:39     ` Christian Couder
2020-06-06 14:53     ` Kaartic Sivaraam
2020-06-07  6:27       ` Christian Couder
2020-06-04 14:49   ` Junio C Hamano
2020-06-05  1:46     ` Elijah Newren
2020-06-06 13:57       ` Philip Oakley
2020-06-04 23:41 ` brian m. carlson [this message]

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=20200604234145.GA6569@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.