3 ms·
i'm confused, are you saying that hacking is a bad thing? while there is a certain "release engineering" process that goes on every 6 months to slow down devel
by there 16y ago
i'm confused, are you saying that hacking is a bad thing?
while there is a certain "release engineering" process that goes on every 6 months to slow down development, stabilize the code, freeze it, tag it, test it, and ship it, all of the development work that is done between releases is just hacking. there isn't a roadmap of features and what gets worked on is whatever anyone feels like working on.
openbsd developers gather at hackathons (http://www.openbsd.org/hackathons.html http://www.openbsd.org/hackathons.html) every so often to work closely with others on specific features or projects, hash out ideas, test on weird hardware, and just get to socialize with other developers that live in different parts of the world. nobody is told what to do at those events and unless it's a specific mini-hackathon for ports or pf or something, everyone is kind of doing their own thing independently or in small teams.
- fiveo 16y agoNot quite to a typical engineering process but I'm guessing it's much better than a typical open source project where people just keep hacking the code and do not care much the quality (security, performance, code quality, etc). I think the idea is that developers should have some sort of SOP (Standard Operating Procedure). I know some people will moan when they heard that abbreviation, especially if people just want to "hack some code". It comes down to discipline and professionalism really. Interesting video: http://www.youtube.com/watch?v=i7pkyDUX5uM http://www.youtube.com/watch?v=i7pkyDUX5uM "Twelve years ago OpenBSD developers started engineering a release process that has resulted in quality software being delivered on a consistent 6 month schedule -- 25 times in a row, exactly on the date promised, and with no critical bugs. This on-time delivery process is very different from how corporations manage their product releases and much more in tune with how volunteer driven communities are supposed to function. Developer and testing laziness is mostly circumvented and leader frustration is kept to a minimum. The reasons, mechanics and social workings of our process have never been detailed outside the project, but now will be, hopefully providing some insight to others who face delays and quality issues with their own product lines."