[Development] Please warn of force pushes...

[Oswald Buddenhagen]

On Tue, Apr 23, 2013 at 08:02:23PM +0200, Koehne Kai wrote:
> Hi guys,
> 
> don't want to stop your discussion, but personally I see that mainly as a documentation issue. Surely having some convention about branch names (and sticking to it) would help, but even better would be to put the details about the branches on something that shows up very high in google "qt git branches" :) Right now there's 
> 
> http://qt-project.org/wiki/Branches
> 
> which is qt creator only. We should have the same for qt.git, or list both on the page.
> 
this is a very good point.
in fact, there were/are several branches in qtbase where i simply don't
know what they are for (which is kinda suboptimal, given that i'm
supposed to be one of the admins). i have repeatedly been chasing behind
people to find out who is responsible and whether a branch is still
relevant.

i made some additions to the existing page. i expect the branch owners
to fill the sections with meat and add any missing branches (from other
repos than qtbase).

also, somebody with a better overview of the wiki structure should
add/replace the category tags to mark the page as relevant also for qt,
and link the page appropriately.

> 
> Regards
> 
> Kai
> 
> PS: Yet another example: http://gcc.gnu.org/svn.html, where all the gcc branches are described.
> 
> 
> ________________________________________
> From: development-bounces+kai.koehne=digia.com at qt-project.org [development-bounces+kai.koehne=digia.com at qt-project.org] on behalf of Oswald Buddenhagen [oswald.buddenhagen at digia.com]
> Sent: 23 April 2013 19:11
> To: development at 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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development