Requesting twig repo maple be reset

RESOLVED FIXED

Status

RESOLVED FIXED
8 years ago
4 years ago

People

(Reporter: mitcho, Assigned: fox2mike)

Tracking

Details

(Whiteboard: tabcandy)

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
(Reporter)

Comment 1

8 years ago
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

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

Comment 3

8 years ago
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.
(Assignee)

Comment 4

8 years ago
(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.
Assignee: server-ops → shyam
(Assignee)

Comment 5

8 years ago
[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.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED

Comment 7

8 years ago
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

8 years ago
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

Updated

8 years ago
Whiteboard: tabcandy
(Assignee)

Comment 9

8 years ago
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

8 years ago
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → FIXED
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.
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(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.
Lukas is right. The repos should be at least level 2 for security reasons, maybe even level 3.
(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

8 years ago
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.
(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.
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.
(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.
(Assignee)

Comment 21

8 years ago
This isn't IT anymore. Once you guys figure out what needs to be done, we'll be glad to help.
Assignee: shyam → nobody
Component: Server Operations → Release Engineering
QA Contact: mrz → release
(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.
Assignee: nobody → server-ops
Component: Release Engineering → Server Operations
QA Contact: release → mrz
(Assignee)

Updated

8 years ago
Assignee: server-ops → shyam
(Assignee)

Comment 23

8 years ago
Reverted to scm_level_2

Opened bug 580881 for further discussion.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.