Hi Tony,
Both you and Brad should have the necessary admin bits to create new
projects. You can create a new project from the review system. The
parent directory ('arm' in our case) should be created with 'Only serve
as parent for other projects' set and inherit permissions from
All-Projects. You can then change the configuration in your parent
project to suit your needs. A small gotcha is that you shouldn't include
a leading slash in the project name (e.g., our gem5 repo is called
arm/gem5).
We ended up adding a separate group of users that have rights to push
directly to the repo and require a member of that group to set the
maintainer flags when other users submit code. You can use our config
[1] as a starting point if you need something similar.
Cheers,
Andreas
[1] https://gem5.googlesource.com/arm/+/refs/meta/config
On 19/12/2017 17:06, Gutierrez, Anthony wrote:
Hi Andreas,
This all makes sense, and I think for our purposes a separate AMD/ repo similar
to ARM's setup (option 1 as you say) would be perfect for us. Do you have
permissions to create a new repo for AMD? Or can you give me permissions to do
so?
Thanks,
Tony
-----Original Message-----
From: Andreas Sandberg [mailto:[email protected]]
Sent: Thursday, December 14, 2017 10:01 AM
To: gem5 Developer List <[email protected]>; Gutierrez, Anthony
<[email protected]>
Subject: Re: [gem5-dev] Using branching in gem5 public
Hi Tony,
I'm generally all for using branches, we use them extensively internally. IMO,
the options we have in gerrit for what both of us are trying to accomplish, us
with SVE and you with the GPU, are as follows:
1. We create different repositories per user / institution and push between
repos.
2. We create branch "namespaces" in the main repo (e.g., arm/**, amd/**,
users/a.hacker/**)
Gerrit is able to handle permissions and policies (e.g., whether some users can
push without review and who is allowed to review) per branch as well as per
repo. There are some differences in what you can do and how you do it, but in
general, they are roughly equivalent when it comes to permissions.
We obviously already went with option one. The main benefit, as I see it, of
this option is that we don't pollute the branch namespace with pre-release
changes. I would argue that this option scales a bit better in terms of
usability as well. Once you start having a lot of working branches, cloning the
repo will be pretty annoying. The Linux uses a similar strategy and most
well-known kernel devs have their own repos on git.kernel.org and Linus curates
the master repo.
Cheers,
Andreas
On 14/12/2017 16:29, Gutierrez, Anthony wrote:
Hi All,
I have a question about using branches in the mainline gem5 repo. I see ARM
have a separate repo here:
https://gem5-review.googlesource.com/admin/projects/arm/gem5. It is used for
staging ARM features under development. At AMD we would like to do something
similar, as we have some significant changes to the GPU model we would like to
push out to the public. We were thinking about doing so with branches, and were
wondering what others thought about branches? I'm sure it's been discussed
somewhat in the past, but I can't find much searching through old posts.
What I was thinking would be to have institutional branches, like AMD or ARM
branches, and perhaps users from those institutions who are also gem5
maintainers could have user specific branches. We use branches a lot internally
and find them extremely useful. So I'd like to get a better idea why there is
an aversion to using branches on the public tree, if there is such an aversion.
-Tony
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
