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

Reply via email to