{"thread":{"id":"41301","subject":"Plans for 2.7.1?","startedAt":"2016-02-01T16:54:05Z","lastAt":"2016-02-02T07:56:59Z","messageCount":3,"participants":["Johannes Schindelin","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"277171","messageId":"alpine.DEB.2.20.1602011740540.2964@virtualbox","threadId":"41301","inReplyTo":null,"subject":"Plans for 2.7.1?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-02-01T16:54:05Z","receivedAt":"2016-02-01T16:54:05Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nat tinyurl.com/gitCal I see a pretty timeline regarding 2.8.0, but I do\nnot see 2.7.1 planned anywhere.\n\nDue to signature problems (I failed to realize that SHA-1 based .exe\nsignatures are no longer considered valid starting from January 1st,\n2016), I got a metric ton of private and non-private bug reports regarding\n\"corrupt signatures\", and therefore I would like to prevent those reports\nfrom taking over my entire working hours by simply issuing a new release\nof Git for Windows.\n\nIs 2.7.1 around the corner? Otherwise I'll just make a 2.7.0(2).\n\nThanks,\nDscho\n"},{"id":"277180","messageId":"xmqqvb68utby.fsf@gitster.mtv.corp.google.com","threadId":"41301","inReplyTo":"alpine.DEB.2.20.1602011740540.2964@virtualbox","subject":"Re: Plans for 2.7.1?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-01T19:24:49Z","receivedAt":"2016-02-01T19:24:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> at tinyurl.com/gitCal I see a pretty timeline regarding 2.8.0, but I do\n> not see 2.7.1 planned anywhere.\n\nYup, because maintenance releases are inherently \"not planned\" ;-)\n\nUnlike feature releases that are largely time-based, we cut\nmaintenance releases only when we need to push out fixes.  We do not\neven know in advance what breakages we would have in 2.7.0, or what\nfixes we would apply for them, and when these fixes would happen.\n\n> Due to signature problems (I failed to realize that SHA-1 based\n> .exe signatures are no longer considered valid starting from\n> January 1st, 2016), I got a metric ton of private and non-private\n> bug reports regarding \"corrupt signatures\", and therefore I would\n> like to prevent those reports from taking over my entire working\n> hours by simply issuing a new release of Git for Windows.\n>\n> Is 2.7.1 around the corner? Otherwise I'll just make a 2.7.0(2).\n\nLet me see what are slated for 'maint' in the current draft release\nnotes.  This actually lists what could technically be merged to\n'maint'; some clean-up patches may not be worth merging down.\n\n    $ Meta/ML <RelNotes\n    ps/push-delete-option # 2 (3 weeks ago) \n    nd/stop-setenv-work-tree # 1 (3 weeks ago) \n    nd/dir-exclude-cleanup # 1 (12 days ago) \n    nd/ita-cleanup # 3 (12 days ago) \n    ew/send-email-mutt-alias-fix # 1 (12 days ago) \n    jk/clang-pedantic # 2 (12 days ago) \n    dw/signoff-doc # 1 (12 days ago) \n    dk/reflog-walk-with-non-commit # 1 (12 days ago) \n    nd/exclusion-regression-fix # 1 (12 days ago) \n    js/fopen-harder # 2 (12 days ago) \n    ho/gitweb-squelch-undef-warning # 1 (12 days ago) \n    jk/ok-to-fail-gc-auto-in-rebase # 1 (6 days ago) \n    js/close-packs-before-gc # 4 (6 days ago) \n    jk/filter-branch-no-index # 1 (4 days ago) \n    jk/sanity # 1 (4 days ago) \n    ss/user-manual # 4 (12 days ago) \n    ew/for-each-ref-doc # 1 (12 days ago) \n    sg/t6050-failing-editor-test-fix # 1 (12 days ago) \n    ss/clone-depth-single-doc # 3 (12 days ago) \n\nI think we have enough important fixes already in 'master' for some\ntime that we should merge them and tag 2.7.1.  Tentatively, among\nthe above, I think the following might be a good set of topics for\n2.7.1:\n\n$ cat MAINT\nnd/stop-setenv-work-tree\nnd/dir-exclude-cleanup\ndw/signoff-doc\ndk/reflog-walk-with-non-commit\nnd/exclusion-regression-fix\njs/fopen-harder\nho/gitweb-squelch-undef-warning\njk/ok-to-fail-gc-auto-in-rebase\njs/close-packs-before-gc\njk/sanity\nss/user-manual\new/for-each-ref-doc\nsg/t6050-failing-editor-test-fix\nss/clone-depth-single-doc\n\nAnd here would be the shortlog:\n\n$ git shortlog ^maint $(cat MAINT)\nDavid A. Wheeler (1):\n      Expand documentation describing --signoff\n\nDennis Kaarsemaker (1):\n      reflog-walk: don't segfault on non-commit sha1's in the reflog\n\nEric Wong (1):\n      for-each-ref: document `creatordate` and `creator` fields\n\nJeff King (1):\n      rebase: ignore failures from \"gc --auto\"\n\nJohannes Schindelin (6):\n      commit: allow editing the commit message even in shared repos\n      Handle more file writes correctly in shared repos\n      fetch: release pack files before garbage-collecting\n      am: release pack files before garbage-collecting\n      merge: release pack files before garbage-collecting\n      receive-pack: release pack files before garbage-collecting\n\nJunio C Hamano (1):\n      test-lib: clarify and tighten SANITY\n\nNguyễn Thái Ngọc Duy (3):\n      Revert \"setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR\"\n      dir.c: clean the entire struct in clear_exclude_list()\n      Revert \"dir.c: don't exclude whole dir prematurely if neg pattern may match\"\n\nSZEDER Gábor (1):\n      t6050-replace: make failing editor test more robust\n\nSebastian Schuberth (3):\n      docs: clarify that passing --depth to git-clone implies --single-branch\n      docs: say \"commits\" in the --depth option wording for git-clone\n      docs: clarify that --depth for git-fetch works with newly initialized repos\n\nStephen P. Smith (4):\n      user-manual: remove temporary branch entry from todo list\n      glossary: define the term shallow clone\n      user-manual: add section documenting shallow clones\n      user-manual: add addition gitweb information\n\nØyvind A. Holm (1):\n      gitweb: squelch \"uninitialized value\" warning\n\n\nI would want to see jk/list-tag-2.7-regression and ew/\nsvn-1.9.0-auth topics also in 2.7.x track soonish, but they\ncurrently are still in 'next', so perhaps late this week or early\nnext week?\n"},{"id":"277212","messageId":"alpine.DEB.2.20.1602020845300.2964@virtualbox","threadId":"41301","inReplyTo":"xmqqvb68utby.fsf@gitster.mtv.corp.google.com","subject":"Re: Plans for 2.7.1?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-02-02T07:56:59Z","receivedAt":"2016-02-02T07:56:59Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Mon, 1 Feb 2016, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > at tinyurl.com/gitCal I see a pretty timeline regarding 2.8.0, but I\n> > do not see 2.7.1 planned anywhere.\n> \n> Yup, because maintenance releases are inherently \"not planned\" ;-)\n\nOf course, I know. Though as you dropped a hint that it might be imminent\nin http://article.gmane.org/gmane.comp.version-control.git/283579 I\nthought it might be in that calendar somewhere.\n\n> Let me see what are slated for 'maint' in the current draft release\n> notes.\n>\n> [...]\n> \n> I would want to see jk/list-tag-2.7-regression and ew/\n> svn-1.9.0-auth topics also in 2.7.x track soonish, but they\n> currently are still in 'next', so perhaps late this week or early\n> next week?\n\nNo rush. I'll just do a 2.7.0(2) today.\n\nThanks for the detailed information!\nDscho\n"}]}