[haiku-development] Re: Voting Aftermath

Every time I see a multi core CPU I think Be Inc was right. :)

Anyway, I think you should set deadlines. Arbitrary dates give the unfocused a 
clear limit and can keep people from straying to far off into speculative fun 
programming.

I remembered the other day why I stopped writing applets for Haiku. While 
developing Alert I looked at the argument parsing and decided "there must be a 
better way". So I looked at getopt and getoptlong and decided they were the old 
way. And then got lost investigating rule based ways to specify how to pass and 
parse arguments and how to define an arbitrary chain of interoperating applets. 
And by the time I stopped I had wasted months. If I had a deadline I would have 
looked at a looming code freeze and been less inclined to wander.

But take the middle ground. IMOSHO, after working as a Software Engineer for 
eight years ...

Create a future branch so long term features can still be developed; without 
blocking the alpha and without it blocking more major works.

Once a month create an Alpha Candidate. Set the 10th as the code freeze. Branch 
and accept only bug fixes onto that branch. Release an image on the 14th. 
Regression Test till the 18th. If it is usable then the observers on the list 
(like me) can run it and file bug reports. Then on the 24th, depending on the 
bug list and the release managers opinion, decide if the image was alpha 
quality. If it wasn't then create another candidate. If it was then build 
another images from the candidate branch with any specific fixes, regression 
test, system test and then all going well announce a release.

This will keep people interested and on track. And demonstrate progress and 
give outsiders a month to test the candidate for bugs.


      Make the switch to the world's best email. Get Yahoo!7 Mail! 
http://au.yahoo.com/y7mail

Other related posts: