[gPXE] DHCP Client ID in gPXE 1.0.0?

[Marty Connor]

Hello Michael,

While I respect your right to express your opinion on this and other
matters, and am always interested to hear your technical ideas, I think
your point about etherboot is not really germane since there were
several reasons why etherboot was not an OEM preference, and I think the
fact that it varied significantly from the industry standard (PXE) was
much more significant than its extensive use of #ifdefs.

But, more to the point, I think it's important to step back and explain
something that you may not have been aware of. When you stepped away
from the project for nine-or-so months without warning or communication,
I needed to set up some new processes to ensure the continued health and
growth of our project and our codebase.

Instead of having a single lead developer, as before, we have a team
that works collaboratively to support gPXE, and whose technical judgment
I respect and rely on.

This core development team  sponsors, reviews, and discusses potential
features and patches. Based on discussion amongst the team, we may
decide to promote a patch or not. We have retained you on this core team
due to your history with the project and your technical expertise, but
please understand that you are now a member of a team.

This means that your opinion is no longer the sole authoritative voice
for the architecture, features, or code. You are now a respected voice
among several, and I know that is a change you might not have understood
until now.

An additional point is that, in our new process, I have final say on
what features and code go into the main gPXE tree. When a patch has
passed review and I agree it should be applied, I am the person who
applies the patch. Again, I know this different from before, so I wanted
to explain this so you would not be confused.

In the current situation, as I noted in my original reply to this
thread, I generally agree with your point about the use of #ifdef in the
abstract, but perhaps not in this specific situation. And, to repeat a
point from my reply that you did not copy in your response:

> I'd like to see a patch, and hear other opinions before deciding.
> 
> I appreciate all that you have done to make gPXE the excellent piece
> of software that it is, but yours is no longer the only voice that
> matters when we decide what goes into gPXE.
> 
> I sincerely hope that you are able and willing to work cooperatively 
> with our growing team of developers.

I hope my point makes more sense now.

I understand that these process changes may not be comfortable for you
to adjust to, but I feel they are necessary to ensure the continued
health of our project.

/ Marty /

On 3/19/10 3:08 PM, Michael Brown wrote:
> On Thursday 18 March 2010 07:27:52 Marty Connor wrote:
>>> I absolutely, absolutely disagree on this.  The problem with #ifdef
>>> proliferation is never any one patch.  Each individual #ifdef is
>>> generally quite harmless in its own right.  The problem is that after a
>>> mere 32 harmless individual #ifdef patches, each of which is fine when
>>> judged individually on its own merits, you suddenly have 4 billion build
>>> combinations to test.
>>
>> I understand (and generally approve of) your view on this, but design
>> purity is only useful to a point.
>>
>> We may have some of the most subjectively beautiful code in the world,
>> but I believe we also must balance this design aesthetic with respect
>> for the needs of the people who use our code to do real-life things.
>>
>> Automated testing is not a solution to all functional ills, and testing
>> all possible build combinations does not completely ensure that software
>> will function properly in real-world environments.  It certainly can be
>> useful, but should not, in my view, be too heavily relied upon.  We have
>> existed 15 years without such exhaustive testing.
> 
> And for the vast majority of those 15 years, almost no OEMs were shipping 
> Etherboot.  You yourself said on this topic, shortly before we launched 
> gPXE, "Would you bet everything on Etherboot?  I wouldn't".  We're no longer 
> in that position.
> 
> This is not a question of code aesthetics, and nor is it particularly relevant 
> to automated testing; it's a very simple, practical matter of code 
> maintainability.  If you disagree with this, try going back to the 
> #ifdef-riddled Etherboot 5.4 codebase and adding a major core feature such as 
> iSCSI boot without breaking anything.  I'll bet US$1000 that you won't be 
> able to.  Feel free to prove me wrong if you can.
> 
> Michael