On Thu, 24 Jan 2019 at 15:56, Jedrzej Nowacki <jedrzej.nowa...@qt.io> wrote:
>
> Dnia środa, 23 stycznia 2019 18:09:31 CET Alex Blasche pisze:
> > > - simpler for new contributors, always push to dev
> >
> > Really? Me being the new guy wanting to fix a bug in 5.12 need to magically
> > know that I have to push to dev and know about a magic cherry-pick logic
> > and a magic tag in the commit log. Right now I need to know I want to fix
> > in 512 and push to it. Also the current model does not bother the new guy
> > with myriads of potentially following cherry-picks which may require a
> > larger commitment than he is willing to give.
>
> Really, at least that is my latest experience, when I contributed a fix to
> python standard library. I was trying to understand the branching model just
> to read that I should not bother and push stuff to master, there it was the
> reviewer responsibility to cherry-pick the change to other branches based on
> the content. I have to admit that I was impressed how easy is to make the 
> first
> time contribution to the project. In our case, gerrit allows you to change
> commit message online in the browser, that makes reviewing / re-targeting
> task easier and less prone to errors (case of accidental re-push to a wrong
> branch after bot moving it). You are assuming that the contributor knows that
> the fix has to be and can be in 5.12. Well, that may be the case, some will
> have no clue and be fine with any future release.

Well, me being a new guy wanting to fix a bug in 5.14 need to
magically know that I need
to push to 5.12 and then wait for a forward merge. With the proposed
model I push into
trunk like in every other project. As far as following cherry-picks
go, they don't necessarily
need to bother me, they could be done by other people, some called maintainers.
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to