Re: Allura/SourceForge to Gitlab migration

2018-04-10 Thread Karlin High
On 4/10/2018 8:31 AM, James Lowe wrote: 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

Re: Allura/SourceForge to Gitlab migration

2018-04-10 Thread Karlin High
On 4/10/2018 8:54 AM, Karlin High wrote: I was also looking for good examples of issues and "boards" displaying issue status, and code review and discussion. Here's the GitLab for the GNOME Nautilus file manager. Issue board: Merge request, rev

Re: Allura/SourceForge to Gitlab migration

2018-04-10 Thread Karlin High
On 4/10/2018 8:31 AM, James Lowe wrote: Thanks for listening. And thanks for sharing! I think that provided good insight for what patch managers need from a tracker and review system. Suggestion: Debian, GNOME, and other projects are currently live with public GitLab as Federico Bruni menti

Re: Allura/SourceForge to Gitlab migration

2018-04-10 Thread James Lowe
Hello, On Mon, 09 Apr 2018 21:04:05 +0200, Urs Liska wrote: > > > Am 9. April 2018 20:06:20 MESZ schrieb James Lowe : > >Hello, > > > >On Mon, 9 Apr 2018 12:56:57 -0500, Karlin High > >wrote: > > > >> On 4/9/2018 11:06 AM, Federico Bruni wrote: > >> > > >> > I don't want to revamp this old d

Re: Allura/SourceForge to Gitlab migration

2018-04-10 Thread Urs Liska
(CCing the list again) Am 10.04.2018 um 01:07 schrieb Carl Sorensen: On 4/9/18, 4:20 PM, "Urs Liska" wrote: Am 09.04.2018 um 21:15 schrieb Carl Sorensen: > On 4/9/18, 1:04 PM, "lilypond-devel on behalf of Urs Liska" wrote: Currently we don't have consiste

Re: Allura/SourceForge to Gitlab migration

2018-04-09 Thread Karlin High
On 4/9/2018 2:15 PM, Carl Sorensen wrote: 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. Another thing: Repository mirroring

Re: Allura/SourceForge to Gitlab migration

2018-04-09 Thread Urs Liska
Am 09.04.2018 um 21:15 schrieb Carl Sorensen: On 4/9/18, 1:04 PM, "lilypond-devel on behalf of Urs Liska" wrote: Am 9. April 2018 20:06:20 MESZ schrieb James Lowe : >Hello, > >On Mon, 9 Apr 2018 12:56:57 -0500, Karlin High >wrote: > >> On 4/9

Re: Allura/SourceForge to Gitlab migration

2018-04-09 Thread Karlin High
On 4/9/2018 4:51 PM, Carl Sorensen wrote: The problem with this workflow is that the merger is the person who needs to do the squash-and-merge. That's extra work for the merger. I'd prefer to keep the work on the patch creator. GitLab actually gave me the "squash" option at both points, req

Re: Allura/SourceForge to Gitlab migration

2018-04-09 Thread Carl Sorensen
On 4/9/18, 3:43 PM, "Karlin High" wrote: I wasn't clear on whether the free-Gold-tier-for-open-source was automatic for any public repository, or if it needed GitLab approval. So I tried it out, and the paid-version "squash and merge" feature IS available in public repos

Re: Allura/SourceForge to Gitlab migration

2018-04-09 Thread Karlin High
On 4/9/2018 3:57 PM, Federico Bruni wrote: Well, of course they use the open source version, the community edition (gitlab-ce). See for example: http://metadata.ftp-master.debian.org/changelogs/contrib/g/gitlab/gitlab_10.6.3+dfsg-1_copyright "Debian is runni

Re: Allura/SourceForge to Gitlab migration

2018-04-09 Thread Urs Liska
Am 09.04.2018 um 22:57 schrieb Federico Bruni: Il giorno lun 9 apr 2018 alle 22:23, Karlin High ha scritto: On 4/9/2018 3:05 PM, Karlin High wrote: Whether terms of service and such are aligned with GNU standards is something I haven't checked. ...But if projects like Debian and GNOME

Re: Allura/SourceForge to Gitlab migration

2018-04-09 Thread Federico Bruni
Il giorno lun 9 apr 2018 alle 22:23, Karlin High ha scritto: On 4/9/2018 3:05 PM, Karlin High wrote: Whether terms of service and such are aligned with GNU standards is something I haven't checked. ...But if projects like Debian and GNOME are using GitLab, as Federico Bruni pointed out,

Re: Allura/SourceForge to Gitlab migration

2018-04-09 Thread Karlin High
On 4/9/2018 3:23 PM, Karlin High wrote: Whether terms of service and such are aligned with GNU standards is something I haven't checked. ...But if projects like Debian and GNOME are using GitLab, as Federico Bruni pointed out, the chances of a terms-of-service conflict with GNU and FSF seem r

Re: Allura/SourceForge to Gitlab migration

2018-04-09 Thread Karlin High
On 4/9/2018 3:05 PM, Karlin High wrote: Whether terms of service and such are aligned with GNU standards is something I haven't checked. ...But if projects like Debian and GNOME are using GitLab, as Federico Bruni pointed out, the chances of a terms-of-service conflict with GNU and FSF seem r

Re: Allura/SourceForge to Gitlab migration

2018-04-09 Thread Karlin High
On 4/9/2018 2:15 PM, Carl Sorensen wrote: 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 commit

Re: Allura/SourceForge to Gitlab migration

2018-04-09 Thread Carl Sorensen
On 4/9/18, 1:04 PM, "lilypond-devel on behalf of Urs Liska" wrote: Am 9. April 2018 20:06:20 MESZ schrieb James Lowe : >Hello, > >On Mon, 9 Apr 2018 12:56:57 -0500, Karlin High >wrote: > >> On 4/9/2018 11:06 AM, Federico Bruni wrote: >> > >> > I do

Re: Allura/SourceForge to Gitlab migration

2018-04-09 Thread Urs Liska
Am 9. April 2018 20:06:20 MESZ schrieb James Lowe : >Hello, > >On Mon, 9 Apr 2018 12:56:57 -0500, Karlin High >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.ht

Re: Allura/SourceForge to Gitlab migration

2018-04-09 Thread Carl Sorensen
On 4/9/18, 12:14 PM, "Karlin High" wrote: On 4/9/2018 1:13 PM, Carl Sorensen wrote: > In my GitLab usage we use tags. This feature, perhaps? Yes, we attach labels to issues. And th

Re: Allura/SourceForge to Gitlab migration

2018-04-09 Thread Karlin High
On 4/9/2018 11:06 AM, Federico Bruni wrote: This is just a call for all contributors who are not quite satisfied with current setup and think that moving to Gitlab "one day™" might be an improvement. Which edition of Gitlab should we be looking at for this discussion? Or are the feature differe

Re: Allura/SourceForge to Gitlab migration

2018-04-09 Thread Karlin High
On 4/9/2018 1:13 PM, Carl Sorensen wrote: In my GitLab usage we use tags. This feature, perhaps? -- Karlin High Missouri, USA ___ lilypond-devel mailing list lilyp

Re: Allura/SourceForge to Gitlab migration

2018-04-09 Thread Carl Sorensen
On 4/9/18, 12:06 PM, "lilypond-devel on behalf of James Lowe" wrote: Hello, 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 co

Re: Allura/SourceForge to Gitlab migration

2018-04-09 Thread James Lowe
Hello, On Mon, 9 Apr 2018 12:56:57 -0500, Karlin High 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/

Re: Allura/SourceForge to Gitlab migration

2018-04-09 Thread Karlin High
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 o

Re: Allura/SourceForge to Gitlab migration

2018-04-09 Thread Karlin High
On 4/9/2018 11:06 AM, Federico Bruni wrote: This is just a call for all contributors who are not quite satisfied with current setup and think that moving to Gitlab "one day™" might be an improvement. Do you want the discussion limited to just the Gitlab proposal, or expanded to the larger wor