Hello, On Mon, 09 Apr 2018 21:04:05 +0200, Urs Liska <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 we're talking about different things. I am not talking about actual code review as, apart from the odd TexInfo syntax errors, I cannot tell good/wrong code from bad/right code. What I am talking about is, for example, being able to manage 6 different patches from 6 different devs and knowing their current 'Review' state so that I can move them on (or back) 'one-step', all in a few minutes of my time every 3 days. While Allura isn't perfect it does have these 'labels' I can use and actually Phil created a nice scraper of Allura so I get the simplest list that I use: http://www.philholmes.net/lilypond/allura/ Allura has predefined 'searches' (again based on labels) that I, as Patch Meister, can *quickly* see if I cannot use Phil's website and easily see which patches are in which state in relation to the queue - regardless of if they are good/bad or still need work. So if Tags can come somewhere close to this then great. One other thing that I like about Rietveld and Allura is an easy way to see the discussion based on the last known 'checkin'. It is very easy to see if one patch has a lot of comments or lots of patches (for the same issue) each have one comment and this makes it easier for me to know if I need to tell the dev he needs to work some more. In a way, I still think having a tracker separate from the patch comparison tool (whatever it may be) is better than an issue also including all the noise from the arguments, because in the end the actual code is irrelevant compared to the discussion or decision. Anyway, it has to be quick and easy to see the state of the issues in relation to the Patch Countdown and for me to know if I need to prompt the dev to look at X because someone has commented. Thanks for listening. James _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
