577802 - Requesting twig repo maple be reset

Status: RESOLVED FIXED

(mozilla.org Graveyard :: Server Operations, task)

Description

[Michael Yoshitaka Erlewine [:mitcho]]

Please run the below script and reset maple to users/edward.lee_engineering.uiuc.edu/tabcandy-central/ . We would like this to be available through July and perhaps some of August.

--

export REPO_PATH = users/edward.lee_engineering.uiuc.edu/tabcandy-central/
export TWIG = maple

cd /repo/hg/scripts/
./reset_pp_repo.sh -s /repo/hg/mozilla/$REPO_PATH -r tip -d $TWIG

Comment 1

[Michael Yoshitaka Erlewine [:mitcho]]

General question: once this disposable project branch is created, I assume we should start pushing to the new branch rather than Mardak's tabcandy-central... is that correct? If so, how can we specify commit access for that new repo?

Comment 2

[Aza Raskin [:aza]]

Also, do these branches come with builds? It would be super helpful.

Comment 3

[Ed Lee :Mardak]

There should be a build on each push (except the very first push), so no nightlies that live in a fixed download spot, but there should be directories created based on the time of the build.

Comment 4

[Shyam Mani [:fox2mike]]

(In reply to comment #2)
> Also, do these branches come with builds? It would be super helpful.

In case they don't, you can ask release engineering about it.

Comment 5

[Shyam Mani [:fox2mike]]

[root@dm-svn02 scripts]# export REPO_PATH=users/edward.lee_engineering.uiuc.edu/tabcandy-central/
[root@dm-svn02 scripts]# export TWIG=maple
[root@dm-svn02 scripts]# ./reset_pp_repo.sh -s /repo/hg/mozilla/$REPO_PATH -r tip -d $TWIG
Cloning revision tip from /repo/hg/mozilla/users/edward.lee_engineering.uiuc.edu/tabcandy-central/ to maple
Deleting repo /repo/hg/mozilla/projects/maple
Proceed? (y/n): y
Okay, here we go!
updating to branch default
44428 files updated, 0 files merged, 0 files removed, 0 files unresolved
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

All done.

(In reply to comment #1)
> is that correct? If so, how can we specify commit access for that new repo?

Right now, /repo/hg/mozilla/projects/maple requires level 2 access.

Comment 6

[Ed Lee :Mardak]

So just checking, the repository is here:
http://hg.mozilla.org/projects/maple/

Will there be nightly builds like other project branches like places?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-places/

Twigs only build on push yeah?
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/maple-macosx/
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/maple-win32/
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/maple-linux/

Comment 7

[Aza Raskin [:aza]]

Is it possible to move /repo/hg/mozilla/projects/maple to level 1 access? All of our commiters (including me) sans Edward only have level 1 HG commit privileges.

Comment 8

[Ed Lee :Mardak]

I've pushed some changes to maple, but I don't see any activity in tinderbox or the ftp build outputs:

http://tinderbox.mozilla.org/showbuilds.cgi?tree=Maple

Comment 9

[Shyam Mani [:fox2mike]]

Stuff like builds aren't automatically setup IIRC :) Please file a separate bug with release engineering so they can look into it.

(In reply to comment #7)
> Is it possible to move /repo/hg/mozilla/projects/maple to level 1 access? All
> of our commiters (including me) sans Edward only have level 1 HG commit
> privileges.

/projects seems to be scm_level_2. I'm not sure who to ping about that.

Comment 10

[Ed Lee :Mardak]

I don't see what use a twig would be compared to user repos if it didn't provide builds:

https://wiki.mozilla.org/DisposableProjectBranches

(In reply to comment #9)
> /projects seems to be scm_level_2. I'm not sure who to ping about that.
If it's not possible to give access per repository, it probably wouldn't be good to lower /projects level as it contains stuff like jaegermonkey, etc. I suppose I could be in charge of pushing changes from the user repo to the twig to get builds when it's set up to do builds.

Comment 11

[Aravind Gottipati [:aravind]]

I am okay with moving maple to a level_1 repo (since its mostly a disposable repo anyway).  Please re-open if thats not the case and there is some strong reason to keep this at level_2.  Also, reopen if you have problems pushing to the repo.

Comment 12

[Nick Thomas [:nthomas] (UTC+12)]

I have reconfig'd the buildbot master so that it's requesting changes properly from pushlog. Checkins from now on should be picked up.

This would should really happen between the IT clone and the first push. I'll fix 
the docs for that.

(In reply to comment #6)
 > Will there be nightly builds like other project branches like places?
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-places/

No, what do you want nightlies for ? Technically Places doesn't have any either nightlies. That lone shark build is now disabled.

Comment 13

[Lukas Blakk [:lsblakk] use ?needinfo]

Actually - these branches use our production build slave pool and so we cannot have a level 1 access to the repos.  That level of access is available on try only which has its own builders.

Comment 14

[Aravind Gottipati [:aravind]]

(In reply to comment #13)
> Actually - these branches use our production build slave pool and so we cannot
> have a level 1 access to the repos.  That level of access is available on try
> only which has its own builders.

Afaik, the point of making something level_2 or level_3 is to limit who can checkin code into the repo.  That's a fine a valid goal for our central repos.  But for these repos, I don't think levels shouldn't be used to limit checkins.  The whole point of these repos is to encourage adhoc teams to collaborate in some central place, and validate their code with the entire mozilla build/test cycle?

I will defer to you guys (Build & Release).. but I think these repos should be left at level_1.

Comment 15

[Reed Loden [:reed]]

Lukas is right. The repos should be at least level 2 for security reasons, maybe even level 3.

Comment 16

[Aravind Gottipati [:aravind]]

(In reply to comment #15)
> Lukas is right. The repos should be at least level 2 for security reasons,
> maybe even level 3.

Should we be updating https://wiki.mozilla.org/DisposableProjectBranches to say that these repos are meant only for level_2 (and above) contributors only?

Comment 17

[Aza Raskin [:aza]]

While I understand the need for security, my understanding is that of Aravind's: the purpose of these repos is to encourage adhoc teams and collaborators outside the normal Mozilla circle-of-power to be able to use the infrastructure of build/test. It seems to me to defeat the purpose to keep these at level_2 or above.

For point of reference, the only person on the Tab Candy team who has more than level_1 access is Edward Lee. If he wasn't helping out, we would then be barred from using these repos. But, perhaps I don't understand the purpose of the twigs.

Comment 18

[Reed Loden [:reed]]

(In reply to comment #17)
> While I understand the need for security, my understanding is that of
> Aravind's: the purpose of these repos is to encourage adhoc teams and
> collaborators outside the normal Mozilla circle-of-power to be able to use the
> infrastructure of build/test. It seems to me to defeat the purpose to keep
> these at level_2 or above.

I'm sorry, but there's just too much at stake to leave repos open that are processed by the prod builders. It would be way too easy to come in, get level 1 access, submit a changeset that gets built on the prod machines containing some type of trojan or exploit, use owned machine to infect other machines and/or compromise production firefox builds, and then get the twig repo reset so there's no trace of the changeset ever existing. We just can't afford that chance, imho.

Comment 19

[:Gavin Sharp [email: [e-mail]]]

Making a distinction between level_1 and level_2 access is not a useful mitigation of that risk, especially given the cost it represents (increased burden to collaboration). I think these repos are fine at level 1.

Comment 20

[Reed Loden [:reed]]

(In reply to comment #19)
> Making a distinction between level_1 and level_2 access is not a useful
> mitigation of that risk, especially given the cost it represents (increased
> burden to collaboration). I think these repos are fine at level 1.

I disagree. It is a useful differentiation. Anybody and his grandmother can get level 1, as has been demonstrated lately. It's more difficult to get level 2. Honestly, I'd prefer the repos be level 3 to match mozilla-central.

Comment 21

[Shyam Mani [:fox2mike]]

This isn't IT anymore. Once you guys figure out what needs to be done, we'll be glad to help.

Comment 22

[Reed Loden [:reed]]

(In reply to comment #21)
> This isn't IT anymore. Once you guys figure out what needs to be done, we'll be
> glad to help.

It's still IT in the sense that the repos need to be reverted to level 2, as per comment #13. I'd prefer level 3, personally, but level 2 is far better than level 1.

Comment 23

[Shyam Mani [:fox2mike]]

Reverted to scm_level_2

Opened bug 580881 for further discussion.