All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: Plans for 2.7.1?
Date: Mon, 01 Feb 2016 11:24:49 -0800	[thread overview]
Message-ID: <xmqqvb68utby.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1602011740540.2964@virtualbox> (Johannes Schindelin's message of "Mon, 1 Feb 2016 17:54:05 +0100 (CET)")

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> at tinyurl.com/gitCal I see a pretty timeline regarding 2.8.0, but I do
> not see 2.7.1 planned anywhere.

Yup, because maintenance releases are inherently "not planned" ;-)

Unlike feature releases that are largely time-based, we cut
maintenance releases only when we need to push out fixes.  We do not
even know in advance what breakages we would have in 2.7.0, or what
fixes we would apply for them, and when these fixes would happen.

> Due to signature problems (I failed to realize that SHA-1 based
> .exe signatures are no longer considered valid starting from
> January 1st, 2016), I got a metric ton of private and non-private
> bug reports regarding "corrupt signatures", and therefore I would
> like to prevent those reports from taking over my entire working
> hours by simply issuing a new release of Git for Windows.
>
> Is 2.7.1 around the corner? Otherwise I'll just make a 2.7.0(2).

Let me see what are slated for 'maint' in the current draft release
notes.  This actually lists what could technically be merged to
'maint'; some clean-up patches may not be worth merging down.

    $ Meta/ML <RelNotes
    ps/push-delete-option # 2 (3 weeks ago) 
    nd/stop-setenv-work-tree # 1 (3 weeks ago) 
    nd/dir-exclude-cleanup # 1 (12 days ago) 
    nd/ita-cleanup # 3 (12 days ago) 
    ew/send-email-mutt-alias-fix # 1 (12 days ago) 
    jk/clang-pedantic # 2 (12 days ago) 
    dw/signoff-doc # 1 (12 days ago) 
    dk/reflog-walk-with-non-commit # 1 (12 days ago) 
    nd/exclusion-regression-fix # 1 (12 days ago) 
    js/fopen-harder # 2 (12 days ago) 
    ho/gitweb-squelch-undef-warning # 1 (12 days ago) 
    jk/ok-to-fail-gc-auto-in-rebase # 1 (6 days ago) 
    js/close-packs-before-gc # 4 (6 days ago) 
    jk/filter-branch-no-index # 1 (4 days ago) 
    jk/sanity # 1 (4 days ago) 
    ss/user-manual # 4 (12 days ago) 
    ew/for-each-ref-doc # 1 (12 days ago) 
    sg/t6050-failing-editor-test-fix # 1 (12 days ago) 
    ss/clone-depth-single-doc # 3 (12 days ago) 

I think we have enough important fixes already in 'master' for some
time that we should merge them and tag 2.7.1.  Tentatively, among
the above, I think the following might be a good set of topics for
2.7.1:

$ cat MAINT
nd/stop-setenv-work-tree
nd/dir-exclude-cleanup
dw/signoff-doc
dk/reflog-walk-with-non-commit
nd/exclusion-regression-fix
js/fopen-harder
ho/gitweb-squelch-undef-warning
jk/ok-to-fail-gc-auto-in-rebase
js/close-packs-before-gc
jk/sanity
ss/user-manual
ew/for-each-ref-doc
sg/t6050-failing-editor-test-fix
ss/clone-depth-single-doc

And here would be the shortlog:

$ git shortlog ^maint $(cat MAINT)
David A. Wheeler (1):
      Expand documentation describing --signoff

Dennis Kaarsemaker (1):
      reflog-walk: don't segfault on non-commit sha1's in the reflog

Eric Wong (1):
      for-each-ref: document `creatordate` and `creator` fields

Jeff King (1):
      rebase: ignore failures from "gc --auto"

Johannes Schindelin (6):
      commit: allow editing the commit message even in shared repos
      Handle more file writes correctly in shared repos
      fetch: release pack files before garbage-collecting
      am: release pack files before garbage-collecting
      merge: release pack files before garbage-collecting
      receive-pack: release pack files before garbage-collecting

Junio C Hamano (1):
      test-lib: clarify and tighten SANITY

Nguyễn Thái Ngọc Duy (3):
      Revert "setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR"
      dir.c: clean the entire struct in clear_exclude_list()
      Revert "dir.c: don't exclude whole dir prematurely if neg pattern may match"

SZEDER Gábor (1):
      t6050-replace: make failing editor test more robust

Sebastian Schuberth (3):
      docs: clarify that passing --depth to git-clone implies --single-branch
      docs: say "commits" in the --depth option wording for git-clone
      docs: clarify that --depth for git-fetch works with newly initialized repos

Stephen P. Smith (4):
      user-manual: remove temporary branch entry from todo list
      glossary: define the term shallow clone
      user-manual: add section documenting shallow clones
      user-manual: add addition gitweb information

Øyvind A. Holm (1):
      gitweb: squelch "uninitialized value" warning


I would want to see jk/list-tag-2.7-regression and ew/
svn-1.9.0-auth topics also in 2.7.x track soonish, but they
currently are still in 'next', so perhaps late this week or early
next week?

  reply	other threads:[~2016-02-01 19:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-01 16:54 Plans for 2.7.1? Johannes Schindelin
2016-02-01 19:24 ` Junio C Hamano [this message]
2016-02-02  7:56   ` 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

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

  git send-email \
    --in-reply-to=xmqqvb68utby.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --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.
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.