Re: thoughts on a Merge Request based development workflow

[Dmitry Vyukov <dvyukov@google.com>]

On Fri, Oct 11, 2019 at 9:12 AM Nicolas Belouin
<nicolas.belouin@gandi.net> wrote:
> > <nicolas.belouin@gandi.net> wrote:
> >> On 10/10/19 1:56 AM, Konstantin Ryabitsev wrote:
> >>> On Wed, Oct 09, 2019 at 10:21:56PM +0000, Eric Wong wrote:
> >>>> One of my long-term visions is to have an agreed upon way to
> >>>> have entirely forkable development communities.  Git already
> >>>> gave us forkable code repositories.
> >>> FYI, this does already exist in the form of Fossil:
> >>> https://www.fossil-scm.org/home/doc/trunk/www/index.wiki
> >>>
> >>> The main reason why we can't really consider it is because it requires
> >>> moving away from git, which is a non-starter for anyone.
> >>>
> >>> -K
> >> Maybe the solution is to build such kind of features within git,
> >> many proposed solutions with tools over git or using git.
> >> A tool over git has the issue of conveying the data and making
> >> it non-centralized, whereas a tool using git is non-scalable because
> >> of the way git is *currently* storing things.
> >> Improving git to make it able to store many more objects (be it in-review
> >> commits or previous versions of patches) and then use it to get the kind
> >> of features we can envy from fossil.
> > Hi Nicolas,
> >
> > I am trying to imagine how a complete solution based on git could look
> > like, but I am failing. It seems that there is a number of problems
> > beyond scalability/storage.
> > First, that git probably should be orthogonal to the kernel source git
> > trees, right? People work with multiple kernel trees, sometimes
> > changes migrate, parts of a series can be merged into different trees,
> > etc.
> This I think can't be helped if going through a Merge/Pull request workflow
> as a request will always be seen as a whole applied to a specific tree,
> I agree
> though the external tool solution might help for tree migration though.
> And I
> don't really have a solution for these issues.
> > Then, do we do a single git where everybody has write access, or
> > per-developer git? If we do a global git and everybody has write
> > access, this looks somewhat problematic. If we have multiple
> > per-developer gits, then it does not solve the whole problem of
> > synchronization and data exchange, one can't pull from thousands of
> > unknown gits every time.
> For this one I thought of per-developer git with a branch per series
> with MR discussion attached to the branch on the developer side and on
> maintainer/reference tree side a reference indicating a remote MR is in
> progress, with only those kind of special refs being writable.
>
> On MR acceptance the discussion/history of branch gets into the maintainer/
> reference tree through the merge commit object and gets included
> whenever one
> pulls from this tree
>
> > Where is this git[s] are hosted?
> Wherever the developper/maintainer wants it to be hosted
> > What about force pushes?
> Well a force-push as per the rule of no changing the commits of a public
> branch
> end-up as new reference linking to the old one for traceability.
> > What about authorization/user identification?
> For this one I thought of a X.509 like tree where you need to get your
> key/identity signed
> by some kind of AC so that you create an account through that AC and can
> push on whatever tree
> that trust that AC or one of its parent. I thought about a root with two
> main branches one for
> "Anonymous" kind of registration where you can use something like OpenId
> to get identified
> and get your matching certificate signed and another one for "Higher
> trust" given to e.g Linus
> so he can sign his maintainers and so they can also sign sub-maintainers
> and so on. Then you can
> set-up your repository to trust the root if you want anyone to be able
> to push or some sub-AC to
> restrict and maybe even a depth restriction to allow a hierarchical work
> as done today.
> >
> > It would be nice to reuse git's persistent storage format and ability
> > to push/fetch incremental changes, but we would need to figure out
> > answers to these questions. Maybe I am missing something obvious.
> > Could you outline how a solution based on git could look like?
> > Also in this case git is only a transport layer (like email/SSB), it
> > won't solve the application layer (how patches/comments/issues/CI
> > results are described, systems that consume, act and present that,
> > etc). So building a solid transport, even if we will need to
> > reimplement some git functionality, will be a smaller part of the
> > overall effort. And building a solid transport layer that will solve
> > fundamental infrastructure problems well may be worth it.

Thanks! This clears some of my doubts.
However, I still don't see the complete picture:
1. If I setup a git on github (a new contributor), is it possible to
setup github repo to trust an AC? I have not seen such option. I
assume you need to be configuring you git server manually for this
type of thing?
2. Restricting write access to some refs. Again, this does not seem to
be possible with github. Is it possible with own stock server?
3. If the "comments" ref is writable, can user A delete user B's
comments? Can change/repo owner delete "unwanted" comments?
4. git transport will also need DoS/spam protection, right? Because
it's easy to create 1000 new users each sending 1000 new merge
requests.
5. To sync my local view of the world, I need to fetch, say, net tree
git, then from that find set of other git trees with pending merge
requests and pull these trees, right? There may be a potential problem
with availability: if people setup gits on github, gitlab, kernel.org,
private hostings, etc, some of them may be down.