Thomas Gummerer <t.gummerer@xxxxxxxxx> writes:
>> 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.
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..
> 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.
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.
