Hi Przemysław! I understand your motivation, it is quite frustrating to see that it takes so long to get pull request into the official repository. But i'm not so sure about the solution. Your pull requests are a good example for the problem - they are around since february without beeing merged, and this has nothing to do with a feature freeze for a release. The only reason why this happened is because of missing time from my site for testing the code earlier this year..
In my opinion the bottleneck comes from the fact that at the moment i'm the only one who merges pull requests with the master branch. It would be great if there would be other developers helping out with that. In the past there we're like 2-3 persons working on hydrogen more or less regularly, this is made the development process of course more "responsive". Of course it is also helpful if non-developers test the outstanding issues. For example the discussion in Pull request #338 was quite productive.. The model which you are proposing has of course its advantages, but it seems too complex for me since it targets a problem which (in my opinion) is not really existing at the moment in hydrogen. A feature freeze won't be a big deal - we can always merge other features in the meantime after forking off the 0.9.7-release branch (as we did in the past with previous releases). The bottleneck i'm seeing at the moment is the testing that needs to be done before the pull request gets accepted (especially for the audio engine related stuff). Maybe i'm too conservative at this point, but we had really frustrating experiences in 0.9.5 and 0.9.6 with merging large patches without testing them enough. This is why i like the feature branches a lot - you can test features without interfering with other feature "candidates". Another point is that we really have a problem with keeping the manual up-to-date with so many new features :) So.. to make a long story short: It would be great if we can reduce the time to get new pull requests into the main branch for 0.9.8. Best regards, Sebastian Am 15.08.2016 20:44, schrieb Przemysław Sitek: > Hi, > > Currently, Hydrogen development takes place in one master branch ans > several feature branches. That model is simple, but is not optimal > because upcoming releases "clog” master branch and pull requests are > kept in limbo state, gradually becoming out of sync with master. In > order to fix this, I propose to split master branch into three > branches: „development”, „testing” and „release” branches. > > Features would be developed in feature branches, just like now. When > completed, feature branches would be merged into „development” branch. > This would allow to shorten feedback loop for developers, who get > chance to see earlier how their features integrate with other peoples’ > features, and advanced users could check this branch to see what’s > going on in Hydrogen development. > > Once enough features have been accumulated in „development” branch, it > is merged into „testing” branch. Release candidates (beta versions) > are created from this branch. Any bugs would be fixed in branches > created from „testing” and merged back into „testing” and then > backported to „devel”. > > When code in „testing” branch matures, it is merged into „release” > branch. Regular releases would be made from this branch. Bugs found in > released versions would be fixed in branched started from „release” > branch and merged back there, then backported to „testing” and > „development”. > > That model adds some bookkeeping comared to current model, but is more > flexible at the same time - it allows to work on new features, prepare > releases and fix bugs at the same time. I have succesfully used this > model at my previous employer and very similar model at my current > employer and find it very powerful. > > Please let me know what do you think about it. > > Regards, > Przemek > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and > traffic > patterns at an interface-level. Reveals which users, apps, and > protocols are > consuming the most bandwidth. Provides multi-vendor support for > NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning reports. http://sdm.link/zohodev2dev > _______________________________________________ > Hydrogen-devel mailing list > Hydrogen-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hydrogen-devel ------------------------------------------------------------------------------ _______________________________________________ Hydrogen-devel mailing list Hydrogen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
