Don't know how much it is worth, but as a part-time contributor to _many_ Open Source projects (and once having worked with a computer science degree as a software engineer for a software company that does software environments for software development) I would like to express my wholehearted support for Oliver's position.
Quick summary: Developments in branches that branch from master and are merged back to master once the development has completed. Strategic adjustments have an influence on the developments that are started but have no direct effect on the master branch. Of course you can always fork or name master something else. But you always have something stable to branch your new developments from. Steffen On 21.07.17 09:49, Oliver Bock wrote: > Hi David, > > On 21/07/17 0:50 , David Anderson wrote: >> This discussion comes down to two contrasting models for software >> development: > Sorry, no, that's not the point. > >> 1) The "waterfall model": >> 2) The "agile model": > I know both models very well, professionally and scientifically. > >> Requirements and design can change on the fly. >> New features are divided into smaller self-contained pieces, >> which are completed and merged with master frequently. > Yes, totally right. > > (master serving as integration branch in this case) > >> Development need not be done in a separate branch. > Where does this conclusion come from? To the contrary: agile > development, due to its velocity, needs separate feature/topic/fix > branches because many developers need to work on the same codebase at > the same time, without interfering with each other. One needs > coordination (by workflow). Also, developers need a stable base to start > off from, not something that's broken most of the times. How do you want > to achieve that when everyone develops (let alone tests) in the same > branch? How do you want to do integration tests without affecting > development or release maintenance? > > Please ask yourself why tools like git, global agile development and > particular SCM workflows like GitFlow more or less arrived and spread > massively at the same time. Mere correlation or actual causality...? > >> Oliver prefers the waterfall model, > The opposite is true. I'm all for agile development like Scrum and I'm > even evangelizing to do so wherever I go (and see fit). Why have I tried > for years to convince BOINC to move to git and make use of Continuous > Integration for instance? Because I prefer the waterfall model? > >> so strongly that he won't work with people who use agile. > This all leaves me kind of speechless. I can't even fathom how one can > reach a conclusion like that, based on what I've described. In > particular since SCM (that's all we talked about in this thread) is just > one part of implementing a process model instance, it doesn't define it. > > There are obviously severe misunderstandings at play here and I'm > honestly starting to doubt they can be overcome - unless other projects > step up and chime in as well. > >> I prefer the agile model for several reasons: > All those reasons/motivations (first sentence of each given bullet) are > absolutely fine. Unfortunately the conclusions/consequences reached are > wrong. What I and others proposed *will help you* with what you're doing > and trying to achieve as it's at the heart of agile development. So far > we've just failed to show you how. > > Apart from that there are other developers, projects and contributors > (existing and prospective) who depend on how BOINC's SCM is done. I > think we agree that their needs need to be taken into account as well, > even if you have the impression that their needs are at odds with yours > - which might not even be the case. > >> Also, let's not confuse the choice of model with how we do stable branches. > Precisely! > > > HTH, > Oliver > > > > _______________________________________________ > boinc_dev mailing list > boinc_dev@ssl.berkeley.edu > https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
