[Development] Please warn of force pushes...

[Thiago Macieira]

On terça-feira, 23 de abril de 2013 11.18.33, Oswald Buddenhagen wrote:
> On Mon, Apr 22, 2013 at 10:19:05AM -0700, Thiago Macieira wrote:
> > Not necessarily. They may have simply found out about the branch due to
> > our
> > public posts and blogs, so they're just looking around. Hypothetically,
> > there are also people maybe working for companies who cannot yet disclose
> > their interest on WinRT.
> 
> sure
> 
> > These people need to be warned that the branch rebases.
> 
> why would they? they can adapt once it happens. i mean, it's a bit of a
> surprise, but it doesn't change much in the end.

Because the surprise is quite big. If you do a git pull --rebase or git pull, 
it might blow up after dozens lines have scrolled out. People don't pay 
attention to the output of the fetch part.

Though I have to grant that novice users are unlikely to be following those 
branches in the first place. But then, we're left with somewhat knowledgeable 
users following the branches, so they are more likely to have extra commits 
and then have no clue on how to rebase their work on top of the rebased base.

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.

> > > > Ok, then add "rebasing" to the branch name somewhere. Preferably:
> > > > 	wip/rebasing/xxx
> > > 
> > > sounds over-engineered to me.
> > > and unnecessarily restrictive, as the policy may change ad-hoc as things
> > > progress.
> > 
> > Change the branch name when the policy changes.
> 
> i really wouldn't want to do that.

But you're not offering a better solution either. You're just dismissing the 
problem completely:

> i'd say it's perfectly mixed, so just wip/ is not a sufficient
> discriminator. and i really don't think we need one, because i don't see
> it as a practical problem.

I'm sorry, just because it is not a problem for you and for the handful of 
developers working on that branch, it does not mean it's not a problem for 
anyone.

And maybe it isn't the case for the winrt branch, but who knows what other 
branches we may have in the future.

Sorry, I want it to be a policy that either:
 a) branches do not rebase (no force pushes allowed, period)
or b) branches that do rebase have "rebasing" in their names

I'd much rather it be option (a).

> > In any case, why does this branch rebase? Can't they live with merges?
> 
> well, the wip/ branches often have rather lax review policies (often
> bypassing domain experts in the case of platform ports) and no CI. this
> results in a messy history (and sometimes bug fixes that actually need
> to be applied to more stable branches to start with). therefore i'm
> advocating history reshaping and early mainline submission of generic
> fixes (which of course means rebasing in turn). it worked really well
> for ios, sort of well for android (they went for a squash merge instead
> of rebasing, which kind of made sense given the history of the import),
> and appears to be going just fine for winrt.

If they're bypassing the reviewers and bypassing the CI, why do they need to 
be in the main Git repositories in Gerrit in the first place?

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.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130423/e6726501/attachment.sig>