Re: The integration/autoland repo
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
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&revision=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
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
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
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&revision=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
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
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
Re: The integration/autoland repo
On 06/28/2016 06:44 PM, 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. […] 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). I am not using MozReview yet, because I lack answers for the 2 following questions: Is MozReview safe for hosting security patches yet? As we remove mozilla-inbound would we have to push security patches to mozilla-central now, as we would have no access to the autoland repository? 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) -- Nicolas B. Pierron ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The integration/autoland repo
On 28/06/2016 19:44, Gregory Szorc wrote: 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). That bug includes saying we're planning to rebase csets from the autoland repo onto m-c. The rationale in that bug includes: 2) Merge commits make bisect harder than it needs to be Which I would agree with. However, AFAICT the plan is to periodically *rebase* a whole bunch of changes into mozilla-central from the autoland repo rather than merging. I'm assuming we push all those rebased changes in 1 go, instead of full-on doubling the time we spend building and testing each revision... The consequence of that would be that there's 1 push which gets 1 build and the push can no longer be correlated to a merge cset and thereby a particular range on the integration branch from which the csets came. This is unfortunate given mozregression, which is basically 99% of all the regressionhunting that gets done these days. m-c won't have builds inbetween the csets that all got rebased and pushed in one go, and there's no way to connect them up to integration branches when we're using rebase. Even if there were, some csets will exist on the integration branches but not on m-c. In principle, there's not even any particular reason to suppose that the csets get landed on m-c in the same order as on autoland, or that they are linear (if I'm reading the 'multiple heads' thing right). In other words, in practice the proposed solution might actually make bisection harder for people "on the ground" unless we do something. This is especially the case because local rebuilds and clobber files really hate each other, and clobber build times are still ridiculously high (20-40 minutes depending on the platform) and so manually bisecting by building revisions is really really painful and I avoid it at all costs. What are we doing to solve this problem we're about to create? ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
The integration/autoland repo
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