Hi, there has been quite many comments about why rebasing might be complicated for some people, but so far I think the advantages for the WinRT branch has not been highlighted. So let me try to summarize why the team thinks that it is beneficial to do so:
a) We do lots of changes upstream and get them back into the WinRT branch very quickly this way. Of course we could do that via other means, but b) the team bases on dev and wants to ensure that integration back into dev will be a simple step once the port is stable enough. Without any/much rebasing/squashing/history-rewrite efforts when time has come. For both previous ports (Android and iOS) there have been lots of discussions how to get things back "properly", where so far we failed to make everyone happy. Taking a rebased branch seemed to be beneficial here. I do agree to Kai that having some official guidelines will benefit future ports as well, but I also fail to see why the WinRT branch now is so much of a difference compared to other ones. Maybe we should move the discussion into a generic one with WinRT being one example beside others instead of complaining about WinRT, but getting to no conclusion after all. BR, Maurice > -----Original Message----- > From: development-bounces+maurice.kalinowski=digia....@qt-project.org > [mailto:development-bounces+maurice.kalinowski=digia.com@qt- > project.org] On Behalf Of Oswald Buddenhagen > Sent: Tuesday, April 23, 2013 7:12 PM > To: development@qt-project.org > Subject: Re: [Development] Please warn of force pushes... > > On Tue, Apr 23, 2013 at 09:46:03AM -0700, Thiago Macieira wrote: > > On terça-feira, 23 de abril de 2013 18.20.11, Oswald Buddenhagen wrote: > > > > I, for one, will not touch any of the rebasing branches, not even to > > > > test > > > > them. It's too much work to rebase on top of a moving base. > > > > > > i call that making a mountain out of a molehill. > > > $ git fetch > > > $ git rebase --onto @{u} HEAD~4 > > > > Would you call me experienced with Git? > > > > Well, I have never successfully used git rebase --onto without reading the > man > > page first and paying attention to the ASCII Art graphs. > > > that's unfortunate. :P > > > Besides, that's unwieldy. I don't carry a handful of commits in my branches. > I > > carry somewhere from 60 to 120. So, no, moving target == off-limits for me. > > > this is an entirely constructed example. you are not going to have 100 > changes on top of a wip branch which is too quickly moving to adhere to > the mainline submission policies. > and, ehm, you are the only person within qt-project who has 100 pending > changes in a single branch. seriously. > > > > > Especially if they're bypassing the CI, they could and should just use > > > > a repository elsewhere. When the branch is ready, it will be submitted > > > > as individual patches to be reviewed by the regular reviewers, maybe > > > > starting the work branch. > > > > > > it's unreasonable to ban everything that does not comply with the > > > standard workflow for mainline branches. > > > > Yes, it is. Why do they need to use the mainline repositories if they are > > not > > going to adhere to the policies that are in place? > > > > No, really, why do those branches need to be in the main repositories? > > > > I'll give one answer, out of past discussion, and just to prove that yes I > > am > > trying to understand both sides: > > > > it is nice to be there because other people sometimes see the commits > coming > > in and will comment on them. > > > > > > With that in mind, I change my proposal and I will say that rebasing > branches > > are acceptable in the mainline repositories, provided they are clearly > marked. > > It's minimal impact and it solves the problem of surprise by selecting the > > people who may use that branch. > > > as far as i can see, the admin who created the winrt branch (not me) > failed to comply with the wip/ policy. i'm sure adding more naming > policies will improve that situation ... not. > > > > and if you did, you'd need to ban playground repos as well (where > > > typically non-approvers can approve changes). > > > > By definition, a playground repository is not a mainline repository. > > > but it lives on our gerrit, so it's "official". > i don't see a difference between a non-mainline branch of an "accepted" > repository and the branches of a playground repository. there is no such > thing as a mainline _repository_ - on the server, we don't clone: we > branch. > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
