On 4/9/18, 1:04 PM, "lilypond-devel on behalf of Urs Liska"
<lilypond-devel-bounces+c_sorensen=byu....@gnu.org on behalf of
li...@openlilylib.org> wrote:
Am 9. April 2018 20:06:20 MESZ schrieb James Lowe <james.l...@runbox.com>:
>Hello,
>
>On Mon, 9 Apr 2018 12:56:57 -0500, Karlin High <karlinh...@gmail.com>
>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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
