Re: [Xen-devel] [xen 4.6 retrospective] [Good and Bad] Posting a design document first is helpful

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

> On 31 Aug 2015, at 09:39, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
>>>> On 31.08.15 at 10:26, <feng.wu@xxxxxxxxx> wrote:
>> The whole point of having such design discussions is to get maintainer's 
>> feedbacks as early as possible
>> and have everyone agree on the solution architecture up front. This approach 
>> has worked great when all
>> relevant maintainers actively participate in the discussions like the case 
>> of PML patchset. Our assumption is
>> that all relevant maintainers agree with the design if they remain silent 
>> during design discussion. However,
>> when we come up with an implementation based on the agreed design and 
>> maintainers who did not participate
>> in design discussion raise design problems later, it really made engineers 
>> frustrated and defeated the whole
>> motivation of having design discussion up front.
> 
> I understand that this can be frustrating, and I for my part try to
> participate in design discussions whenever possible/reasonable.
> However, just like for patch review and any other discussions there
> is limited bandwidth, and hence determining the point in time when
> everyone potentially having an opinion has voiced theirs can be
> rather difficult (as no reply doesn't mean there isn't going to be a
> reply).

This I believe we could fix, if we had an ACK (or a +1 vote) on the last round 
of the review. Taking aside, the fact of bandwidth, at least it would provide 
clarity on who has agreed with a design. And it makes it easier for the 
contributor to either take a calculated risk before he/she starts implementing, 
or he/she can reach out to the people who have not ACKed.


> And then you have to face that sometimes a design looks
> good when looking at it from an abstract perspective, but when
> it comes to implementing what was designed it may still turn out to
> be flawed. I.e. posting (and discussing) a design early can only
> help an easier subsequent patch review process, it can't guarantee
> it.

I think that is understood. I don't know whether this is practical, but maybe 
it would make sense for the reviewer to call out such cases (aka make clear 
that maybe in this case the design was possibly wrong, or a different design 
decision at a specific point would be better). It would then allow revisiting 
the design in a more real context (to keep it up-to-date, and/or to draw extra 
on context into the discussion, or to make the conversation more efficient).
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel