Taylor Blau <me@xxxxxxxxxxxx> writes: >> > That way, the bottom part can be merged sooner to 'next' than the >> > rest. It always is cumbersome to have some part of the series in >> > 'next' and remainder in 'seen', so at that point, the lower half >> > would naturally gain a different name before it gets merged to >> > 'next', I would think. >> >> That seems to me like it ends up being _more_ work than just making them >> into two branches in the first place. More work to contributors? How? As long as each of 20-patch and 8-patch series is marked clearly to manage the risk of mistakes and confusion down to the same level as a single long series, I am perfectly OK. Examples of help contributors could have made, which would have avoided past confusion (these are not "potential" ones, but I had to redo day's intergration in the past because of one long topic building on top of another) are: - When sending either topic, not limited to the initial round but in all the subsequent rounds, remind that the top topic is to be applied on top of the bottom topic. - When updating the bottom topic (e.g. 20-patch one in this case), send out the top one (e.g. 8-patch one), too (or instruct me to discard the top one tentatively). The worst case that happened in the past was that a quite minor tweak was made to a bottom topic that was depended on another topic, so I just queued the new iteration of the bottom topic again, without realizing that the other one needed to be rebased. We ended up two copies of the bottom topic commits in 'pu' (these days we call it 'seen') as the tweak was so minor that the two topics cleanly merged into 'pu' without causing conflict. The next bad case was a similar situation with larger rewrite of the bottom topic, which caused me to look at quite a big conflict and waste my time until I realized that I was missing an updated top half. If the inter-dependent topics that caused me trouble were managed as a single long patch series, either with "this is a full replacement of the new iteration" or "these are to update only the last 8 patches; apply them after rewinding the topic to commit f0e1d2c3 (gostak: distim doshes, 2021-01-08)", would have had a lot less risk to introduce human error on this end. > I agree, but I also wasn't aware that you would consider queuing part of > a series. If that's the route you want to take, I'm OK with that. Discarding broken part of a series and only queuing a good part can happen with or without multiple topics. Merging one topic to 'next' but not the other also happens. Merging early part of a topic to 'next' while leaving the rest to 'seen' is possible but I'd prefer to avoid it. Because of the last one, a single long topic, when a bottom part stabilizes enough, would likely to gain a separate name and its tip would be merged to 'next'. > But I > tend to agree with Peff that (in this case since a clear deliniation > already exists) it may save us time to just send two separate series > from the get-go. As long as the two serieses are marked as such clearly, not just in the initial round but in all subsequent rounds, it is OK. But in an unproven initial round, you may regret having to move a patch across topics, from the bottom one to the top one or vice versa, instead of just reordering inside a single topic. >> So I guess I remain skeptical that ad-hoc splitting of longer series is >> easier than doing so up front. Nobody suggested ad-hoc splitting. I was saying that splitting would naturally grow out of reviews toward stabilization.
