991961 - new hg repo for gaia-try

Status: RESOLVED FIXED

(Developer Services :: Mercurial: hg.mozilla.org, defect)

Description

[Aki Sasaki (not active)]

Naming: right now I'm thinking hg.m.o/integration/gaia-try.

'integration' is wrong because try often contains things that aren't meant to go live, ever, but I don't know where else to put it.  'try' is at the top level, which is probably wrong but exists for historic reasons.

Once we decide we want this repo and what it's named, we can file the appropriate IT bug.

Comment 1

[Aki Sasaki (not active)]

Hal, Jonathan, bikeshedding?

Comment 2

[Aki Sasaki (not active)]

Also, will this be a multiheaded "try" or will we be able to keep this fairly single-headed?

Comment 3

[Aki Sasaki (not active)]

Also, level 1 access?

Comment 4

[Jonathan Griffin (:jgriffin)]

What's going to be in this repo?  If this is the old idea of a repo containing just a manifest that will point to a github reference, then I think a single-headed repo is all we'll need.

I'm fine with the name, and level 1 commit access seems reasonable, if only because it will trigger things to happen in CI.

Comment 5

[Aki Sasaki (not active)]

The "gaia changes only" section is https://bugzilla.mozilla.org/show_bug.cgi?id=914632#c2 is what I'm going by atm.

Comment 6

[Jonathan Griffin (:jgriffin)]

Yep, sounds good to me.

Comment 7

[Hal Wine [:hwine] use NI!]

So, I'm confused. Exactly what is being committed to this repo?

If it's just a manifest (per comment 4), then I do not think the name should be gaia-*, as all other gaia-* repos are the hg versions of the main gaia.git repo. Perhaps 'try-gaia'?

Also, as for which hooks are needed -- I think single-headed restriction will be a major pain if the commit is "manifest only". We are then recreating a race condition on commits when none is needed. The problems with resets of try repos arise due to devs loosing access to examine the code changes. In this usage, all the code is already preserved on the repository holding the code to be tested.

Other than those 2 comments, lgtm.

Comment 8

[Aki Sasaki (not active)]

(In reply to Hal Wine [:hwine] (use needinfo) from comment #7)
> So, I'm confused. Exactly what is being committed to this repo?
> 
> If it's just a manifest (per comment 4), then I do not think the name should
> be gaia-*, as all other gaia-* repos are the hg versions of the main
> gaia.git repo. Perhaps 'try-gaia'?

Hmm.  Ok, I see your point, though it's going to be confusing as heck if we have a try-gaia gecko hg repo and a gaia-try gaia hg mirror of a git repo.
gaia-try-gecko ? =\

Dealing_with_multiple_vcs_systems--

> Also, as for which hooks are needed -- I think single-headed restriction
> will be a major pain if the commit is "manifest only". We are then
> recreating a race condition on commits when none is needed. The problems
> with resets of try repos arise due to devs loosing access to examine the
> code changes. In this usage, all the code is already preserved on the
> repository holding the code to be tested.

Not sure about this one, if the tool that commits the head sees push races, pulls, rebases, repushes as opposed to creating a new head.  We can make it a "best practice" policy rather than a strictly enforced hook, though.

Comment 10

[Aki Sasaki (not active)]

Ok, according to https://bugzilla.mozilla.org/show_bug.cgi?id=914640#c0 :

* there will be nothing in this repo but the manifest
* this is a pointer to a git repo/revision

I'm going to assert at this point that

* gaia-try is more humanly understandable than gaia-try-manifest
** especially for TBPL
* we are never going to sync the try gaia repo(s)/revisions to hg
** even if we did want to go down this route, having a try-gaia (manifests) and a gaia-try (vcs-sync mirror of the git repo(s)) would not clarify things

Filing the IT bug.

Comment 11

[Aki Sasaki (not active)]

Not sure why I haven't closed this bug; the repo exists.