@Oliver, Yes, I mean 'no write access', sorry for misprint. Also I totally agreed with you but currently we have another situation: master branch can not be a start point for new release branch. Ok, it can be but in this case it will require much more testing I afraid. I think we need David here. If he will decide to create 7.7 branch based on master branch than I'll just create a list of issues which were fixed in this release.
Thanks Best regards, Vitalii Koshura 2017-03-29 14:06 GMT+03:00 Oliver Bock <oliver.b...@aei.mpg.de>: > On 29/03/2017 12:30 , Vitalii Koshura wrote: > > I will not do any any cherry-picks because I have write access to the > repo. > > You mean "no write access"? > > > If you will look at the current branch tree you will see that every new > > release branch bases on previous release branch. And master branch is a > > sandbox. It contains some commits which are too risky to be included > > into release. > > Both of that needs to be changed anyway to ensure proper release > management. Since master is used for integration is should always be as > stable as possible (don't break master!). That usually means development > has to happen in dedicated feature branches. This also ensures that > independent developments don't affect each other which will make the > whole process more efficient. > > > Also if you will take a look at any release banch you will > > see that all commits were integrated there separately one by one. > > This doesn't mean that this approach is sensible or that it should be > continued in the future. Again, cherry-picking like that is error-prone > (as you said, it's hard) and cumbersome. Our goal needs to be to make > the release process much safer/simpler and even more efficient/faster. > > > I think it is the best way to continue this work. > > I strongly disagree for the reasons above :-) > > > If you think this is a wrong way to do this please suggest your own. > > It's basically what I outlined in my previous mail and above. > > > Cheers, > 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.
