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 > >Regards > >James > > > > > >_______________________________________________ >lilypond-devel mailing list >firstname.lastname@example.org >https://lists.gnu.org/mailman/listinfo/lilypond-devel _______________________________________________ lilypond-devel mailing list email@example.com https://lists.gnu.org/mailman/listinfo/lilypond-devel