> On 27 Jul 2017, at 14:28, Marc-André Lureau <marcandre.lur...@redhat.com> > wrote: > > Hi > > ----- Original Message ----- >> >>> On 26 Jul 2017, at 11:23, Marc-André Lureau <marcandre.lur...@redhat.com> >>> wrote: >>> >>> Hi >>> >>> ----- Original Message ----- >>>> Now, any objection to >>>> >>>> 1. Recommending that we use git URLs in patches? >>> >>> If that may help, but as Christophe said, this may be overkill for small >>> series. Let's not make it a rule. >>> >>>> 2. Having a shared location for branches under review? >>> >>> This is really contrary to the distributed nature of git. >> >> If that was true, why would the inventor of git, Linus Torvalds, use a public >> shared place like kernel.org? >> >> Git gives you the freedom to have multiple repos and sync them easily. It >> does not place a restriction that you can’t have a shared one for a team. >> >>> >>> Add a remote remote repo if you are interested by tracking someone else >>> work, it works just as well. >> >> No, it does not. It means you need to git fetch multiple places. It’s >> complicated enough that there are 17 repositories in the spice project. For >> one of them I have 12 remotes already. That does not scale well. > > git remote add/update, it scales fine..
Here is a recent example. For the work on the streaming agent, I recently ran into a compilation error because spice-prootocol was not the “right one” for the code being reviewed, which was IIRC in the spice server. It turns out that the only one I found that was “right” was some personal branch that Frediano has somewhere. How does git remote add/update help solve that, when the problem was precisely to find the remote and branch? > >>> >>> Imho, we could benefit using a system tracking patch series state from the >>> mailing list, such as patchew. But it would probably need some work to fit >>> Spice needs. >> >> We would benefit from that, yes. But that’s another issue entirely. > > If the issue is about tracking patch series state, then it's not not entirely > different. It looks more like a way to manage incoming emails. Useful too, and related on the CI aspect. > > Thanks > _______________________________________________ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org <mailto:Spice-devel@lists.freedesktop.org> > https://lists.freedesktop.org/mailman/listinfo/spice-devel > <https://lists.freedesktop.org/mailman/listinfo/spice-devel>
_______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
