On 02/08/19 18:33, Rebecca Cran wrote: > > On February 8, 2019 at 2:01:59 AM, Laszlo Ersek > (ler...@redhat.com(mailto:ler...@redhat.com)) wrote: > >> I don't see the workflow modification as viable. The "patch series" >> concept is integral to every single open source project that I've ever >> worked with. The evolution of a feature or a bug fix over a series of >> patches is a core facet of programming and reviewing. It communicates a >> thinking process, and that's what programming is about. > > I don’t recall coming across the patch series (e.g. the 1/5 email patches) in > other projects. In other projects people post a single patch and then update > it following feedback on the same review. This can be either in a single, > rebased commit, or new commits on a bug/feature branch - review systems deal > with both.
How do they contribute a feature consisting of 1500-3000 lines, in one well-structured, coherent "package"? I don't think that any single patch can carry that weight. Only a patch series can. Regarding "new commits on a bug/feature branch" -- that really doesn't look good to me, as a way to develop a focused, larger feature. Even if the initial patch looks good (in separation), it cannot really be evaluated without getting some kind of perspective, i.e. seeing where the whole thing leads in mid-distance. Sometimes we find a design bug in patch 08/12 that invalidates patch 03/12. I wouldn't want to push 03/12 until I review (and maybe even test / regression-test) the full dozen. We need this to scale to 50+ patches in a series. Such a series is not posted every day, but it does happen. That's when we need the tooling to carry us the most. [...] Obviously: I welcome all comments on this, in disagreement too! Thanks! Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
