> On Sep 16, 2015, at 9:58 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > > On Wed, Sep 16, 2015 at 9:38 AM, Rohit Yadav <rohit.ya...@shapeblue.com> > wrote: > >> 1. Only BLOCKER fixes to master. If there's something else that needs to >> get in, it can be discussed with the RMs on a case-by-case basis. >> >> >> -1 -ish >> What you’re effectively saying is to freeze/block master from new changes >> until 4.6.0 releases which could take anywhere from one week to many weeks. >> In reality that may be undesirable and can contribute to loss of developer >> productivity time. >> > agree and >
Since we are so close to 4.6, it seems freezing it is totally legitimate. You can keep on working on your own branch and bring master changes in as they are made. Once 4.6.0 is out, you can submit your PR and merge back in master... I don’t think this slows you down, it just delays your changes to get into master. > >> >> Few suggestions, though I’m not sure that best way to go forward: why not >> create a 4.6 branch and merge it back when 4.6.0 releases? Alternatively, >> create a development branch on which development can continue and we merge >> it back to master when that branch is stable enough and 4.6.0 has released? >> > I don't feel we should create a developer branch, branching 4.6.0 now and > fixing blockers there to merge them back to master as they are fixed seems > the way to go to me. > > > >> >> 2. Atleast one of the reviewers of a PR should do the actual tests. We do >> not have good CI in place and travis just does simulator tests. >> >> >> +1 some of us talking in the background to setup an automated QA system to >> use existing marvin tests to do long running integration tests but other >> than Travis or Jenkins (b.a.o) we don’t have anything. >> > I hate this but still +1 (CI is/should be there so we don't need this) > > > > -- > Daan
