That's essentially what I was getting at, but I think you put it better. If I do that, then what is the best way to create a patch from the changes?
On Fri, Apr 20, 2018 at 6:15 PM, Jason Lowe-Power <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> > 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 <[email protected] > > > > > 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 <[email protected]> > > 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 > > > > > [email protected] > > > > > http://m5sim.org/mailman/listinfo/gem5-dev > > > > _______________________________________________ > > > > gem5-dev mailing list > > > > [email protected] > > > > http://m5sim.org/mailman/listinfo/gem5-dev > > > > > > > _______________________________________________ > > > gem5-dev mailing list > > > [email protected] > > > http://m5sim.org/mailman/listinfo/gem5-dev > > > > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
