From: Junio C Hamano <hidden> Date: 2016-10-22 17:11:54
Johannes Schindelin [off-list ref] writes:
This patch series marks the '4' in the countdown to speed up rebase -i
by implementing large parts in C (read: there will be three more patch
series after that before the full benefit hits git.git: sequencer-i,
rebase--helper and rebase-i-extra).
...
It would be *really* nice if we could get this patch series at least into
`next` soon, as it gets late and later for the rest of the patches to make
it into `master` in time for v2.11 (and it is not for lack of trying on my
end...).
This "countdown 4" step can affect cherry-pick and revert, even
though we were careful to review changes to the sequencer.c code. I
prefer to cook it in 'next' sufficiently long to ensure that we hear
feedbacks from non-Windows users if there is any unexpected breakage.
There isn't enough time to include this topic in the upcoming
release within the current https://tinyurl.com/gitCal calendar,
however, which places the final on Nov 11th.
I am wondering if it makes sense to delay 2.11 by moving the final
by 4 weeks to Dec 9th.
Thoughts?
Speaking of what to and not to include in the upcoming release, we
do want to include Stefan's off-by-one fix to the submodule-helper,
but that is blocked on Windows end due to the test. I think
everybody agreed that a longer time "right thing to do" fix is to
address the "when base is /path/to/dir/., where is ../sub relative
to it?" issue, but if we are to do so, it would need a longer
gestation period once it hits 'next', as it can affect the current
users and we may even need B/C notes in the release notes for the
change. Giving ourselves a few more weeks of breathing room would
help us to make sure the fix to relative URL issue is sound, too.
As to "countdown 3" and below steps, I am guessing that some of them
can start cooking in 'next' before 2.11, but even with lengthened
schedule, it is likely that they need to cook there beyond the end
of this cycle, unless they are truly trivial changes that do not
even need any reviews.
Thanks.
From: Johannes Schindelin <hidden> Date: 2016-10-23 09:55:25
Hi Junio,
On Sat, 22 Oct 2016, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
This patch series marks the '4' in the countdown to speed up rebase -i
by implementing large parts in C (read: there will be three more patch
series after that before the full benefit hits git.git: sequencer-i,
rebase--helper and rebase-i-extra).
...
It would be *really* nice if we could get this patch series at least
into `next` soon, as it gets late and later for the rest of the
patches to make it into `master` in time for v2.11 (and it is not for
lack of trying on my end...).
This "countdown 4" step can affect cherry-pick and revert, even
though we were careful to review changes to the sequencer.c code.
As I pointed out in another mail in this thread: we should not fall into
the trap of overrating review.
In the case of the rebase--helper patches, so far the review mainly
resulted in more work for me (having to change spellings elsewhere, for
example), not in improving the changes I intended to introduce into
git.git's code.
Sure, there has been the occasional improvement, but it certainly feels as
if I spent about 80% of the work after each -v1 iteration on things that
have positively nothing at all to do with accelerating rebase -i.
I prefer to cook it in 'next' sufficiently long to ensure that we hear
feedbacks from non-Windows users if there is any unexpected breakage.
FWIW I am using the same patches not only on Windows but also in my Linux
VM.
There isn't enough time to include this topic in the upcoming
release within the current https://tinyurl.com/gitCal calendar,
however, which places the final on Nov 11th.
More is the pity.
Thank you, though, for being upfront with me. I will shift my focus to
tasks that require my attention more urgently, then.
Ciao,
Dscho
From: Johannes Schindelin <hidden> Date: 2016-10-23 09:58:24
Hi Junio,
On Sun, 23 Oct 2016, Johannes Schindelin wrote:
On Sat, 22 Oct 2016, Junio C Hamano wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
This patch series marks the '4' in the countdown to speed up rebase -i
by implementing large parts in C (read: there will be three more patch
series after that before the full benefit hits git.git: sequencer-i,
rebase--helper and rebase-i-extra).
...
It would be *really* nice if we could get this patch series at least
into `next` soon, as it gets late and later for the rest of the
patches to make it into `master` in time for v2.11 (and it is not for
lack of trying on my end...).
This "countdown 4" step can affect cherry-pick and revert, even
Oh, I forgot to comment on this tidbit of your mail, sorry.
This *is* the countdown 4, as the remaining 3 patch series depend on each
other in the order I sent them out.
Ciao,
Dscho
On 23 Oct 2016, at 11:54, Johannes Schindelin [off-list ref] wrote:
Hi Junio,
On Sat, 22 Oct 2016, Junio C Hamano wrote:
[...]
quoted
There isn't enough time to include this topic in the upcoming
release within the current https://tinyurl.com/gitCal calendar,
however, which places the final on Nov 11th.
More is the pity.
Thank you, though, for being upfront with me. I will shift my focus to
tasks that require my attention more urgently, then.
Junio did go on, though:
quoted
I am wondering if it makes sense to delay 2.11 by moving the final
by 4 weeks to Dec 9th.
I was reading this as an offer to delay things to accommodate the integration your work into 2.11. I.e. "within the current plan, there is no time for this, but we could adjust the plan". But maybe I am misinterpreting?
Cheers,
Max
From: Johannes Schindelin <hidden> Date: 2016-10-24 14:08:39
Hi Max,
On Mon, 24 Oct 2016, Max Horn wrote:
quoted
On 23 Oct 2016, at 11:54, Johannes Schindelin [off-list ref] wrote:
On Sat, 22 Oct 2016, Junio C Hamano wrote:
[...]
quoted
quoted
There isn't enough time to include this topic in the upcoming release
within the current https://tinyurl.com/gitCal calendar, however,
which places the final on Nov 11th.
More is the pity.
Thank you, though, for being upfront with me. I will shift my focus to
tasks that require my attention more urgently, then.
Junio did go on, though:
quoted
quoted
I am wondering if it makes sense to delay 2.11 by moving the final
by 4 weeks to Dec 9th.
I was reading this as an offer to delay things to accommodate the
integration your work into 2.11. I.e. "within the current plan, there is
no time for this, but we could adjust the plan". But maybe I am
misinterpreting?
There is no indication that the rebase--helper patches would make it into
2.11 even with four more weeks.
I will now focus on other things that I postponed in favor of the
interactive rebase patches. In fact, I *have* to focus on some quite
pressing tasks that I neglected over those patches.
It's not like the process would magically improve just because a release
date is pushed. To the contrary, pushing the release date to allow for the
rebase--helper to be included may very well have the counterintuitive
effect of delaying things beyond even that pushed date "because there is
now so much time left" (until there isn't). It's a variation of
[Parkinson's Law](https://en.wikipedia.org/wiki/Parkinson%27s_law) ;-)
Anyway, back to work,
Dscho
From: Stefan Beller <hidden> Date: 2016-10-24 19:36:56
On Sat, Oct 22, 2016 at 10:11 AM, Junio C Hamano [off-list ref] wrote:
There isn't enough time to include this topic in the upcoming
release within the current https://tinyurl.com/gitCal calendar,
however, which places the final on Nov 11th.
I am wondering if it makes sense to delay 2.11 by moving the final
by 4 weeks to Dec 9th.
Thoughts?
Speaking of what to and not to include in the upcoming release, we
do want to include Stefan's off-by-one fix to the submodule-helper,
but that is blocked on Windows end due to the test.
I'd be happy either way, i.e. we could revert that fix and make a release?
AFAICT, Windows only has broken tests, not broken functionality with that
submodule bug fix.
I think
everybody agreed that a longer time "right thing to do" fix is to
address the "when base is /path/to/dir/., where is ../sub relative
to it?" issue, but if we are to do so, it would need a longer
gestation period once it hits 'next', as it can affect the current
users and we may even need B/C notes in the release notes for the
change. Giving ourselves a few more weeks of breathing room would
help us to make sure the fix to relative URL issue is sound, too.
If we want a longer gestation period, we'd ideally merge it to master
just after a release, such that we "cook" it in master without having
it in any release (we had a similar discussion for the diff heuristics IIRC).
So please don't let the release schedule depend on my ability to deliver a
proper patch for the submodule path issue.
Thanks,
Stefan
From: Junio C Hamano <hidden> Date: 2016-10-24 20:03:21
Johannes Schindelin [off-list ref] writes:
quoted
I prefer to cook it in 'next' sufficiently long to ensure that we hear
feedbacks from non-Windows users if there is any unexpected breakage.
FWIW I am using the same patches not only on Windows but also in my Linux
VM.
Thanks for a datapoint, but when I said "non-Windows users", I was
not referring you as "the" Windows user. I am expecting that you
would hear from Windows users who got exposure to your series by its
inclusion in Git for Windows. They are the ones that I had in mind
as "Windows users"---and not hearing breakage reported by them would
be a good sign.
The primary reason why we want to cook a new topic in 'next' is to
expose it to people with different workflows using it on different
things, and that is especially more important for a change that
affects features that are flexible and can be used in different
ways---the set of options and commands used by the original author
of the series are often different from other people's.
Any change, when it hits 'next', is expected to be sufficiently
tested by the original author [*1*], but that is only true in the
context of the original author's daily use. Both reviews and
author's tests are not sufficient to find bugs [*2*].
Topics that touch parts of the system that are more important to
users' daily Git life deserve extra time to find any unexpected
breakage in them. Windows users are participating in that test by
inclusion of the topic in the released version of Git for Windows.
I want to see the the test for the rest of the world done by early
adopters who run 'next' (as 'pu' is too scary for daily use).
[Footnote]
*1* And me, as topics geting ready to be in 'next' are first merged
to my private edition branch that is slightly ahead of 'next' to
be used in my everyday use, but just like the original author is
merely one user, I am also merely one user with a specific set
of workflows that is different from others'.
*2* Bug finding is not the primary purpose of the review in the
first place. It is to find design mistakes both at the external
and internal level, and bug finding "here you have off-by-one"
is merely a side effect. End user tests may expose the former
(e.g. the design based on a wrong assumption may not accomodate
certain workflow the original author and the reviewers failed to
consider while writing and reviewing), but no amount of test
will uncover the latter (e.g. internal API that is misdesigned
will make future enhancement unnecessarily harder).
I think it was one of the achievements of the review cycle of
this particular series that we got rid of the _entrust() thing,
for example. That had no visible external effect that would
have been caught by cooking on 'next' or releasing it to the
public, but was the kind of thing the code review was expected
to find and fix.