Re: The integration/autoland repo

[Gregory Szorc]

On Tue, Jun 28, 2016 at 11:44 AM, Gregory Szorc  wrote:

> As of a few minutes ago, when you land commits from MozReview they will be
> pushed to https://hg.mozilla.org/integration/autoland instead of
> https://hg.mozilla.org/integration/mozilla-inbound.
>
> For now, think of integration/autoland as just another mozilla-inbound or
> fx-team. In fact, the sheriffs will be treating the autoland repo just like
> they treat inbound and fx-team. But that will change in the weeks ahead.
>
> The integration/autoland repository is purposefully not being integrated
> into https://hg.mozilla.org/mozilla-unified and the Git mirrors. And it
> never will be. This is because integrating the autoland repo into a unified
> repo isn't compatible with things we'll be doing in the future.
>
> *Please do not pull from the autoland repo.* If you do, future changes
> that will introduce divergent commits/DAG heads will make your life painful.
>
> Since you aren't supposed to pull from the autoland repo, *Do not build
> the autoland repo or rebase your work on top of it.* As far as local
> development is concerned, pretend the autoland repo doesn't exist. The
> exception to this is if you absolutely need to pull a revision from it to
> test it explicitly.
>
> Also, the autoland repo is using a new permissions group that only 4
> people have write access to. So don't attempt to push to it because you
> won't be able to.
>
> Please follow bug 1266863 if you wish to track changes to the autoland
> repo and our future plans to get rid of inbound, fx-team, merge commits,
> and most backout commits in the final repo history (making mozilla-central
> history linear without most bad/backed out commits).
>

Since multiple people have been confused by this, I want to state
explicitly that the autoland repo does not require a Try push before
landing. The autoland repo is essentially working the same as the inbound
repo has been. There can still be bustage on the autoland repo. There can
still be backouts.

We're intentionally taking a "walk before you run" attitude towards the
autoland repo and trying not to make too many changes at once. Even with
our conservative approach, we still had a rocky first week (e.g. hook
issues allowed a push they shouldn't have, some sheriffs didn't have proper
permissions, and there were a surprising number of merge conflicts between
autoland and inbound). This week should be better. I apologize if this has
caused any trouble.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The integration/autoland repo

[Henrik Skupin]

Gijs Kruitbosch wrote on 07/01/2016 11:47 PM:
> On 01/07/2016 20:52, Henrik Skupin wrote:
>> I do not see any single merge of autoland to mozilla-central
> 
> https://treeherder.mozilla.org/#/jobs?repo=mozilla-central=61ed5c0d64195c58de57489147046aeaf14252d3
> 
> is a merge from autoland to m-c earlier today, and you are CC'd on the 
> bug...

I was able to sort out the issue with Carsten on IRC. He just posted a
message to this list about the current issues with autoland->mc updates.

-- 
Henrik
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The integration/autoland repo

[cbook]

Am Freitag, 1. Juli 2016 21:52:27 UTC+2 schrieb Henrik Skupin:

> This gives problems if you have patches for different bugs but which
> have overlapping code blocks. This requires you to keep already landed
> commits around until code found its way to mozilla-central and
> mozilla-inbound. Given that this can take up to a day or more I don't
> feel satisfied right now in using autoland for my mozreview patches.
> 
> -- 
> Henrik

Yeah for this we will try to merge more often and in general have a strategy 
for this (gps already gave us sheriffs some kind of how-to).

will add something next week on the sheriff wiki next week :) 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The integration/autoland repo

[cbook]

Am Freitag, 1. Juli 2016 21:52:27 UTC+2 schrieb Henrik Skupin:
> I'm just curious when autoland will actually be merged to
> mozilla-central the first time. Given that we have this repository for a
> while now, and sheriffs merged mozilla-central into it a couple of
> times, I do not see any single merge of autoland to mozilla-central yet.
> It's blocking some of my patches to reach Nightly builds. So for me the
> current situation is not satisfying.
> 
> Can you please clarify the merge strategy?
> 

Hi Henrik you are totally wrong here.

Short answer: we do merge autoland already since a few days. 

The thing that you "don't see" it has technically reasons. When m-c has not 
changed (like a direct backout on m-c) the first "merge" from a integration 
tree is not a hg merge its more a hg update (without the merge x to y) commit.

This was always so and we did it also with b2g-inbound etc.

The merge work is now the following

1.) update/merge autoland to m-c (as mentioned its not a hg merge commit in 
most cases)
2. the integration trees (mostly with fx-team and then inbound) follows *with* 
a hg merge and so commit. 

So yeah as short we do our work ;)

- Tomcat
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The integration/autoland repo

[Gijs Kruitbosch]

On 01/07/2016 20:52, Henrik Skupin wrote:

I do not see any single merge of autoland to mozilla-central


https://treeherder.mozilla.org/#/jobs?repo=mozilla-central=61ed5c0d64195c58de57489147046aeaf14252d3

is a merge from autoland to m-c earlier today, and you are CC'd on the 
bug...


~ Gijs
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The integration/autoland repo

[Henrik Skupin]

Gregory Szorc wrote on 06/28/2016 08:44 PM:
> As of a few minutes ago, when you land commits from MozReview they will be
> pushed to https://hg.mozilla.org/integration/autoland instead of
> https://hg.mozilla.org/integration/mozilla-inbound.
> 
> For now, think of integration/autoland as just another mozilla-inbound or
> fx-team. In fact, the sheriffs will be treating the autoland repo just like
> they treat inbound and fx-team. But that will change in the weeks ahead.

I'm just curious when autoland will actually be merged to
mozilla-central the first time. Given that we have this repository for a
while now, and sheriffs merged mozilla-central into it a couple of
times, I do not see any single merge of autoland to mozilla-central yet.
It's blocking some of my patches to reach Nightly builds. So for me the
current situation is not satisfying.

Can you please clarify the merge strategy?

> *Please do not pull from the autoland repo.* If you do, future changes that
> will introduce divergent commits/DAG heads will make your life painful.

This gives problems if you have patches for different bugs but which
have overlapping code blocks. This requires you to keep already landed
commits around until code found its way to mozilla-central and
mozilla-inbound. Given that this can take up to a day or more I don't
feel satisfied right now in using autoland for my mozreview patches.

-- 
Henrik
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The integration/autoland repo

[glob]

I am not using MozReview yet, because I lack answers for the 2 following
questions:

Is MozReview safe for hosting security patches yet?


no.  mozreview will prevent you from pushing a patch associated with a 
bug that isn't public.


there's parts of the mozreview infrastructure that make that complicated 
right now; specifically the review repository you push to is public. 
it's on the roadmap but we want to address the core features and UX 
issues first.



Also, I want to notice that, if persons who have access to security
issues are using MozReview & autoland for all their patches which are
not attached to a security issues, then this would highlight all the
remaining patches as being involve in a fix for a security issue. Thus a
simple filter on the committer name would be able to filter all security
patches. (without the need to query bugzilla)


this isn't accurate: when a patch is autolanded, the committer is set to 
the person who triggered autolanding, not a generic 'autoland' account. 
 you cannot use the commiter name to filter our patches that were not 
autolanded.



-glob
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

The integration/autoland repo

[Gregory Szorc]

As of a few minutes ago, when you land commits from MozReview they will be
pushed to https://hg.mozilla.org/integration/autoland instead of
https://hg.mozilla.org/integration/mozilla-inbound.

For now, think of integration/autoland as just another mozilla-inbound or
fx-team. In fact, the sheriffs will be treating the autoland repo just like
they treat inbound and fx-team. But that will change in the weeks ahead.

The integration/autoland repository is purposefully not being integrated
into https://hg.mozilla.org/mozilla-unified and the Git mirrors. And it
never will be. This is because integrating the autoland repo into a unified
repo isn't compatible with things we'll be doing in the future.

*Please do not pull from the autoland repo.* If you do, future changes that
will introduce divergent commits/DAG heads will make your life painful.

Since you aren't supposed to pull from the autoland repo, *Do not build the
autoland repo or rebase your work on top of it.* As far as local
development is concerned, pretend the autoland repo doesn't exist. The
exception to this is if you absolutely need to pull a revision from it to
test it explicitly.

Also, the autoland repo is using a new permissions group that only 4 people
have write access to. So don't attempt to push to it because you won't be
able to.

Please follow bug 1266863 if you wish to track changes to the autoland repo
and our future plans to get rid of inbound, fx-team, merge commits, and
most backout commits in the final repo history (making mozilla-central
history linear without most bad/backed out commits).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform