Hi Alec, What you're describing is *hard* and requires a lot of coordination between people. I think the best way to do it today is to use something out-of-band like a github mirror and then have one person rebase, etc. and submit to the mainline. That's basically what AMD and ARM do internally. It's harder to do with a geographically diverse set of people.
If you need hosting and want to use gerrit for code review during development, we can set you up with a repository on gem5.googlesource.com. However, I think the path of least resistance is to set up a github repo. E.g., I have a github repo for my research group and that's what we used when I was at Wisconsin, too. Cheers, Jason On Thu, Apr 19, 2018 at 12:02 PM Alec Roelke <ar...@virginia.edu> wrote: > I'm not trying to suggest that there should be an "official" way to > collaborate on patches, since that's probably not a common enough > occurrence to warrant the effort of maintaining such a feature; I was > mostly wondering if there was a way to leverage what's already available to > do it. Downloading and uploading revisions to others' patches is clunky > and, as Gabe mentioned, can lead to loss of work. I was thinking more of > something like what Jason mentioned with creating a "riscv-fs" clone of > gem5 in GitHub or similar and creating patches out of commits to it > somehow. Is that possible? > > I think overall what I'm trying to figure out is proper version control for > patches before they're uploaded to Gerrit so that two or more people can > work on one thing without worrying about losing work to conflicts. > > On Wed, Apr 18, 2018 at 8:49 PM, Gabe Black <gabebl...@google.com> wrote: > > > In my past experience with gerrit, anybody can overwrite anybody else's > > patch. That may not be true for our instance here, but I suspect it is. > All > > you have to do is make sure the Change-Id: field is the same since that's > > how gerrit identifies changes. It's generally something to avoid since it > > can be inconvenient for the original author to download your new version > to > > replace their own locally, to make your edits locally, etc., to avoid > > blowing away your changes when they upload their own new version. > > > > I think the linux kernel uses both multiple git repositories and multiple > > git branches within those repositories to separate independent projects. > A > > big problem with that approach is that it takes concerted effort to keep > > all those different threads in sync and make sure they reconverge at all, > > and ideally frequently. They have vastly more developers and projects to > > coordinate than we do, and I don't think the overhead of that approach > > makes a lot of sense for us at this point and with our current capacity > for > > administrative overhead. > > > > If you want to push up your own independent version of somebody's CL for > > some reason, all you have to do is replace the Change-Id field (delete it > > and let git recreate it with a new value, for instance) and gerrit will > > treat it as a new patch even if everything else is the same. There are > > other ways to put changes up on gerrit which are work in progress sorts > of > > things. Those used to be draft changes, but I think they (the gerrit > > developers) reworked that into one or two similar but different > features. I > > think one is actually called a work in progress CL? > > > > Gabe > > > > On Wed, Apr 18, 2018 at 3:18 PM, Jason Lowe-Power <ja...@lowepower.com> > > wrote: > > > > > Hi Alec, > > > > > > First, I'm not sure if collaborating on a single changeset is a common > > use > > > case for code review platforms. Though, I have run into a number of > times > > > where it would have been useful. > > > > > > Am I understanding your suggestion correctly? What you're envisioning > is > > > there would be a feature branch (say, riscv-fs) and many people could > > push > > > changesets onto that branch. Then, when the feature is working you > would > > > merge into master? Or, squash and go through code review? I'm not sure > > how > > > the final part would work. > > > > > > I'm open to this kind of workflow. We can create branches on gerrit. > > > Another option is what ARM and AMD are doing which is having their own > > repo > > > hosted on gem5.googlesource.com. > > > > > > What does the Linux kernel do in this case, I wonder. They have done a > > good > > > job working out procedures for massive open source development. They > are > > > usually a good inspiration. > > > > > > Second, as a maintainer, I believe you have enough access to just > > overwrite > > > someone else's commit. For instance, if you download a changeset, then > > > rebase, then push to refs/for/master it will update the review request. > > So, > > > as a maintainer, you can make a small change instead of asking the > > original > > > author. (I think this is right... I know *I* can modify patches and I > > think > > > it's the maintainer flag, not admin. If I'm wrong we can talk about > > > changing this permission.) > > > > > > Cheers, > > > Jason > > > > > > On Wed, Apr 18, 2018 at 1:02 PM Alec Roelke <ar...@virginia.edu> > wrote: > > > > > > > Hi Everyone, > > > > > > > > Is there a way to allow multiple people to collaborate on a patch? > > Right > > > > now it looks to me like the only person who can make changes to a > patch > > > is > > > > the owner, which means that others' contributions have to be manually > > > > added. Would it be possible for a person to create a personal branch > > of > > > > gem5 on GitHub or other git repository and then somehow push changes > > from > > > > there to Gerrit? > > > > > > > > Thanks, > > > > Alec Roelke > > > > _______________________________________________ > > > > gem5-dev mailing list > > > > gem5-dev@gem5.org > > > > http://m5sim.org/mailman/listinfo/gem5-dev > > > _______________________________________________ > > > gem5-dev mailing list > > > gem5-dev@gem5.org > > > http://m5sim.org/mailman/listinfo/gem5-dev > > > > > _______________________________________________ > > gem5-dev mailing list > > gem5-dev@gem5.org > > http://m5sim.org/mailman/listinfo/gem5-dev > > > _______________________________________________ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
