HI Alex, right, I'm only saying that as part as the natural process, people should not need to ask for agreement, since what is in develop should not go to release. And if something need to be fixed in release it will happen there (of course promoted by some discussion about something is not working there), and that will, in the end merged back ro develop and master when release is done. Otherwise means people in team are not applying the before mentioned git branch model article.
Thanks El dom., 6 oct. 2019 a las 0:40, Alex Harui (<aha...@adobe.com.invalid>) escribió: > > > On 10/5/19, 7:08 AM, "Carlos Rovira" <carlosrov...@apache.org> wrote: > > Hi Alex, > > - release: Here's where I see differences. Once we decided we want to > release, is because develop has the final state to cut a release. No > more > commits are needed for that release. So once a RM start the process and > creates release branch from develop, then no more things should go to > release branch. NOW: If we have to fix something for release, this is > done > in release and then "merged" (not cherry-picked) to develop at any > time. > Finally as we get to the final process, release is merged in master and > develop. > > Notice that in parallel: develop can continue to evolve, but that will > not > go into that current release, will go to the next. > > As well, I think Cherry pick can be an option for many other use > cases. Is > like using rebase, those are very powerful tools to use when needed. > Just > we all need to know when is the right way to use it. > > I think the problem right now is that when we start the release, we > continue with open mind to add all we do in develop. This is due to our > current release process getting to long in time. I think next release > process should be very less time and will be less new things in > develop so > what we have in release will be what we really release, instead of > continue > adding new develop things. > > > IMO, because we don't have dedicated testing, we are going to find > important things when we start testing the release branch. So it isn’t "if > we have to fix something for release" it is "when we have to fix something > for release" and I am asking the other committers to be more careful in the > next release and not just commit stuff to develop. Be aware if a release > is in progress and get agreement to push your fix to the release branch. > > I sure hope the release branch is open only for a much shorter time, but > I'm also sure we will find something to fix in almost every release. > > -Alex > > -- Carlos Rovira http://about.me/carlosrovira
