On Tue, Oct 21, 2014 at 11:38:34AM +0200, Marc Sune wrote: > Thomas, > > On 21/10/14 11:28, Thomas Monjalon wrote: > >2014-10-21 11:14, Marc Sune: > >>On 21/10/14 10:46, Thomas Monjalon wrote: > >>>My balance is different because I have a simpler solution for Marc's > >>>problem: > >>> git fetch && git merge $(git tag | grep -v -- -rc | tail -n1) > >>We all know we _can_ do this. But is it really necessary? We should be > >>all as lazy as possible and make it easy for users IMHO. `git pull` is > >>easier :) > >Yes and lazy users download tarballs. > > At least for me, I stopped downloading DPDK tarballs after the third time I > had to upgrade the release. > >>I don't see any drawback of using a development branch, except if you > >>consider the extra push to master per release a drawback. > >No I don't care to push one more thing. > >But I care about the message brought by such change. It would mean that > >we can break the development branch and that most of developers don't test > >it nor base their patches on the latest commit. It's all about simple rules > >and messages. > > I understand your concern but, isn't peer reviewing meant to prevent this? > > >>Also think about new users downloading the repo for the first time. They > >>are forced to do this right now if they want to checkout the latest stable. > >New users will get the latest release and expect to see current work in > >progress right after cloning the git tree (in master branch). > >It's also more common to see work in progress in default branch in cgit. > I know, but I also know other projects do the way I proposed with success. > In any case it was just a suggestion to try to improve things. > > marc >
Ideally, I think the best solution (and I've proposed this on the list several times), is to create a release branch when you begin tagging -rc branches, and use that branch for stabilization/testing prior to a release. Only fixes are allowed in such a branch, and can be merged with master post release-tagging. That would allow master to continue patch integration undeterred. Alternatively, doing like Linus does is also a fine idea, announce a merge window during which features are integrated, and after which new features are disallowed during the pre-release stabilization period. Doing so however requires a high degree of commitment to not make exceptions. If that is a concern, then a release branch is the safer approach, as it separates fixes from other patches. Neil
