Re: thoughts on a Merge Request based development workflow

[Nicolas Belouin <nicolas.belouin@gandi.net>]

On 10/10/19 4:21 PM, Dmitry Vyukov wrote:
> On Thu, Oct 10, 2019 at 9:39 AM Nicolas Belouin
> <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.

Nicolas