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 _______________________________________________ gPXE mailing list [email protected] http://etherboot.org/mailman/listinfo/gpxe
