Hi Junio,

On Tue, 19 Feb 2019, Junio C Hamano wrote:

Thomas Gummerer [off-list ref] writes:

quoted

quoted

Now, I seriously believe that we missed the best time to move
ps/stash-in-c into `next` for cooking. The best time would have been just
...
Anyway, that's my plan for now.

I must say I am not very happy about this plan.  The series has been
marked as "Will merge to 'next'" in previous iterations, but then we
found some issues that prevented that.  However I thought we were fine
fixing those on top at this point, rather than starting with a new
iteration again.

First before going into anything else, let me thank, and let me
invite readers of this thread to join me thanking, Paul (Sebi) for
sticking with this topic for this long.  It is above and beyond what
GSoC calls for.

Indeed. He put in quite a few dozen hours of work *after* GSoC.

Having said that.

I too was somehow led to believe that the topic was in a good enough
shape, with some room for clean-up by reordering the patches to make
them into a more logical progression and squashing an existing and
recently figured out "oops, that was wrong" fixes into the patches
where the breakages originate.

And that was where the "Will merge to" originally came from.  Thanks
to tools like range-diff, a topic that goes through such reordering
and squashing of patches should not have to "waste" a lot of review
cycles out of those who have seen the previous round.

It however is a totally different matter if the topic was so
unsalvageable that it needs a total rewrite---that would need
another round of careful review, of course, and it would be
irresponsive to merge a topic in such a messy state to 'next'.  But
my impression was that the topic was not _that_ bad, so Dscho's
message and the plan were something that was totally unexpected to
me, too..

My throwing hands into the air and giving up on advancing it in the
current form to `next` was based on its rotting away in `pu`...

If it had been in `next` while Hannes, others and I found and fixed bugs,
then it would truly be cooking, but in `pu`? It kind of stopped pretty
much all the development around it.

And that's the only reason why I came up with that plan (that will require
at least 50 hours from my side, I know that): because I thought that your
not advancing the patches to `next` meant that this extra work was exactly
what you were expecting.

quoted

I was always under the impression that once the problem that was
discovered here was fixed we'd advance the series to 'next' with the
patch that comes out of this discussion on top.  Whether it's in next
shortly before 2.21 or not doesn't seem to make much of a difference
to me, as this wasn't going to make the 2.21 release anyway.  My hope
was that we could get it into 'next' shortly after 2.21 is released to
get the series some further exposure (which may well turn up some
other issues that we are not aware of yet, but such is the life of
software).

I was hoping similar, but also was hoping that people would use the
time wisely while waiting for the next cycle to polish the topic with
reordering and squashing, so that it can hit 'next' early once the
tree opens.

Anyway.

I actually have a different issue with this topic, though.  It is
wonderful to see a GSoC student's continued involvement in the
project, but it is not healthy that we need so much work on top of
what was marked "done" at the end of the GSoC period.  Especially
the impression I am getting for the post GSoC work of this topic is
not "we are already done converting to built-in during GSoC, and now
we are extending the command", but "we ran out of time during GSoC;
here is what we would have seen at the end of GSoC in an ideal
world."

I wonder if this is an unfortunate indication that our expectation
is unrealistically high when we accept students' applications.

Yes, you are right. This is on me. Guilty as charged.

And I don't mean this flippantly. I thought long and hard about this, and
I've come to the conclusion that I will not offer to mentor this round of
GSoC as a consequence.

Ciao,
Dscho

Being overly ambitious is *not* students' fault, but those of us on
the list, especially those who mentor, have far deeper experience
with how our code and project is structured than any students do.
We should be able to, and should not hesitate to, say things like
"that's overly ambitious---for such and such, you'd need to even
invent an internal API---can we reduce the scope and still produce a
useful end result?"

One suggestion I have is to have success criteria (e.g. "gets merged
to 'master' before GSoC ends" [*1*]) clearly spelled out in the
application.  Something like that would help managing the
expectation and biting way too much for a summer, I'd hope.

    Side note *1*.  Of course, depending on the alignment of the
    stars ^W our ~10-12 week development cycle and the end of GSoC,
    getting merged to 'master' might become impossible if it
    coincides with the pre-release freeze period.  But we on the
    list and the mentors know how the project works, and can help
    stating a more realistic success criterion if the development
    cycle and other quirks specific to this project gets in the way.

Thanks.