[Development] Please warn of force pushes...

[Oswald Buddenhagen]

On Mon, Apr 22, 2013 at 10:19:05AM -0700, Thiago Macieira wrote:
> On segunda-feira, 22 de abril de 2013 17.44.41, Oswald Buddenhagen wrote:
> > On Mon, Apr 22, 2013 at 08:11:22AM -0700, Thiago Macieira wrote:
> > > On segunda-feira, 22 de abril de 2013 16.59.27, Oswald Buddenhagen wrote:
> > > > > And where is it documented for winrt?
> > > > 
> > > > why should it be?
> > > 
> > > Because people need to know what to expect if they are going to
> > > participate.
> > while not entirely invalid, i don't think this is of particular concern.
> > somebody who joins the work on a project is supposed to be talking to
> > the respective people.
> 
> 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.

> > > 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.

> > i don't think we should put any more energy into discussing this matter.
> > the only action point is documenting on the wiki that wip/ branches
> > (winrt should have had that prefix, obviously) may be subject to history
> > rewriting.
> 
> The "wip" prefix does help to identify that the branch is not ready and could 
> be unstable.
> 
> If most wip branches rebase, then we can declare that the entire wip/ prefix is 
> subject to rebasing. If there's just one, I'd rather have it clearly marked.
> 
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.

> 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.