Re: Allura/SourceForge to Gitlab migration

[Carl Sorensen]

On 4/9/18, 1:04 PM, "lilypond-devel on behalf of Urs Liska" <address@hidden on 
behalf of address@hidden> wrote:

    
    
    Am 9. April 2018 20:06:20 MESZ schrieb James Lowe <address@hidden>:
    >Hello,
    >
    >On Mon, 9 Apr 2018 12:56:57 -0500, Karlin High <address@hidden>
    >wrote:
    >
    >> On 4/9/2018 11:06 AM, Federico Bruni wrote:
    >> > 
    >> > I don't want to revamp this old discussion:
    >> >
    >http://lists.gnu.org/archive/html/lilypond-devel/2013-10/msg00095.html
    >> >
    >http://lists.gnu.org/archive/html/lilypond-devel/2013-10/msg00140.html
    >> 
    >> I should have read those BEFORE making my other post.
    >> 
    >> > Current obstacle is that there's no way to import
    >Allura/SourceForge 
    >> > issues into Gitlab. This is the issue to follow:
    >> > https://gitlab.com/gitlab-org/gitlab-ce/issues/45007
    >> > 
    >> > If you have a Gitlab account, click on the thumb up icon, as
    >popular 
    >> > issues should have higher chances to be tackled sooner than later.
    >> 
    >> Created account, upvoted the issue. Thanks for pointing this out.
    >
    >Does Gitlab really only just have 2 status for an 'issue' (Open and
    >Closed) or can this be refined/configured so I (as Patch Meister) can
    >keep track of what is 'making its way through' the patch countdown and
    >is at the one of the three basic states?
    >
    >For example how would one know of the ~1000 issues which ones need to
    >be reviewed and which ones are ready to push?
    
    Gitlab (like GitHub) uses Merge Requests for the process of patch review. 
The nice thing (compared to the current workflow) is that what is reviewed is 
what will eventually be merged, so it's not at the discretion of the 
contributor to recreate the patch on staging, rewriting the commits etc.
    
    I think combining Merge Requests with the projects as shown by Carl would 
be a good match to the current strategy.
    
    Urs
    
I'm really concerned about using Merge Request rather than commits as a means 
of applying patches.

Right now, our current process ensures that every commit on master builds 
properly -- master never gets broken.  The only branch that can get broken is 
staging. 

If we use merges instead of single commits, we know that the final result (the 
merge commit) is OK, but we don't know anything about the underlying commits in 
the branch being merged.  Some of those commits may not build properly.  I 
guess those commits won't be on master, but all of the interesting history is 
in those commits, not in the merge commits.

Finally, it will require somebody to process the merge requests.  I guess that 
is nice from the point of uniformity, but it will require somebody other than 
the developer who created the patch to be responsible for ensuring that the 
tree is all OK.  I don't know who that person will be.

I may just be an old dog who doesn't want to learn new tricks, but I feel like 
the current process is really secure as far as keeping master working, and puts 
the onus on the developer who is creating the patch to see that it's done 
right.  And I think that's the proper place for it.

I'm certainly willing to learn from people like Urs, who have experience in 
running a GitLab project with multiple contributors.  I could be convinced that 
it's better.  I just haven't heard an argument for why it's better.

Thanks,

Carl