> I suppose we could look at just granting maintainers of ks'es
commit,
> but the problem there is that we would be back to not having a way to
> queue up changes during freeze.
Having a way to take only some changes (in any order) is important. I don't
think we want to give that up.
We don't have a way to take it in any order now, we take it from the
branch head, that goes in the order that things are landed into git.
The advantage of the new way is that rel-eng or QA can hold pull
requests that aren't blockers until post freeze and can apply the PRs
that are needed for a blocking issue which actually gives us more
flexibility on what lands and what doesn't so I actually think the new
method is actually more flexible for this.
The other way to do that would be to have a separate branch for each
freeze.
But I think that would end being more work trying to cherry pick changes
into and they would probably end up being dead end branches unless we wanted
to do even more work merging the develoment and freeze branches back
together after each freeze.
Yes, and it doesn't provide us more than complexity, the PRs can act
as a a gating mechanism that would provide similar functionality with
no extra complexity.
I don't see the pull requests as being a big deal for
development, since it
won't add too much work to the occasional fix, and for bigger projects where
their are many commits, they can be batched together. Getting code reviewed
outside of freezes might be a problem. For spins without multiple active
developers, recruiting help for reviews might end up being a pain.
There really isn't that much churn in the kickstarts compared to other
areas of the project, I don't see this to be a major problem, if it is
we can adjust the process, it's not set in stone and we can evolve it
as necessary.
Peter