Hi Junio, On Tue, 19 Feb 2019, Junio C Hamano wrote: > 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. 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. > > 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. >
