Re: Proposal to deploy GitLab on gnome.org
On Mon, Sep 25, 2017 at 09:03:00PM +0200, Tobias Mueller wrote: > Hi. > > On Mi, 2017-05-17 at 14:21 +, Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, May 17, 2017 at 01:49:21PM +0200, Sébastien Wilmet wrote: > > > By attaching a patch to a bugtracker ticket, we loose the information of > > > the parent commit: where the commit has been initially created in the > > > git history. > > If the patch is created by git format-patch, it contains the hash of > > the parent, so git knows the original parent > I couldn't find the hash of the parent commit in my git format-patch > exported patch, e.g. https://bug778584.bugzilla-attachments.gnome.org/a > ttachment.cgi?id=345698. > Do I need to do anything special in order to export the parent also? > The man page for git-format-patch does not show anything useful for > "parent". Any patch formatted by git format will things like this: diff --git a/file.c b/file.c index e14a869321..0a8628c26a 100644 --- a/file.c +++ b/file.c @@ -847,7 +847,6 @@ int function_name( Where e14a869321 is the old version of the file, and 0a8628c26a is the new one. This allows git to see the evolution of the file from e14a869321 to the one in HEAD. (I shouldn't have said "hash of the parent", since it's the "hash of the version of the file that a hunk of the patch was based on".) Zbyszek ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Mon, Sep 25, 2017 at 09:03:00PM +0200, Tobias Mueller wrote: > On Mi, 2017-05-17 at 14:21 +, Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, May 17, 2017 at 01:49:21PM +0200, Sébastien Wilmet wrote: > > > By attaching a patch to a bugtracker ticket, we loose the information of > > > the parent commit: where the commit has been initially created in the > > > git history. > > If the patch is created by git format-patch, it contains the hash of > > the parent, so git knows the original parent > I couldn't find the hash of the parent commit in my git format-patch > exported patch, e.g. https://bug778584.bugzilla-attachments.gnome.org/a > ttachment.cgi?id=345698. > Do I need to do anything special in order to export the parent also? > The man page for git-format-patch does not show anything useful for > "parent". It contains the hashes of the parent *objects*: typically it refers to the last time that the file was modified. But a patch often depends on more recent changes made in *other* files, for example when calling a function of another class that was recently implemented or changed. So there is a loss of information when creating a patch with git format-patch, at least with the default parameters. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hi. On Mi, 2017-05-17 at 14:21 +, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, May 17, 2017 at 01:49:21PM +0200, Sébastien Wilmet wrote: > > By attaching a patch to a bugtracker ticket, we loose the information of > > the parent commit: where the commit has been initially created in the > > git history. > If the patch is created by git format-patch, it contains the hash of > the parent, so git knows the original parent I couldn't find the hash of the parent commit in my git format-patch exported patch, e.g. https://bug778584.bugzilla-attachments.gnome.org/a ttachment.cgi?id=345698. Do I need to do anything special in order to export the parent also? The man page for git-format-patch does not show anything useful for "parent". Cheers, Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Sat, Jun 17, 2017 at 11:29 PM Florian Müllner wrote: > I hope that subscribers to an issue will receive a notification when a > mentioned issue is closed > To answer my own question: It looks like that's not the case, so anyone interested will need to explicitly subscribe to the related issue. Still, hardly a deal breaker IMHO. Florian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Sat, Jun 17, 2017 at 4:48 PM Michael Catanzaro wrote: > I think we had > some rough consensus on this list that the primary missing enterprise > feature we need in the open source edition is rebase-style merge > requests. Was there anything else? > It looks like related issues are an EE feature, at least for now: https://gitlab.com/gitlab-org/gitlab-ce/issues/4058 Although personally this bothers me a lot less than forced merge commits, assuming that the suggested workaround of using free-form comments ("This depends on the stuff in #12345") works well enough. I hope that subscribers to an issue will receive a notification when a mentioned issue is closed, but if not and I'll have to manually subscribe to related issues where necessary, then that's an annoyance I can live with ... Florian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
At the risk of reopening this debate, here's an interesting LWN article about why Debian has rejected a proposed move to GitLab: https://lwn.net/SubscriberLink/724986/c26a7fab6ab5981b/ (For those unfamiliar with LWN, the subscriber link is just to allow you to bypass the paywall.) It looks like the primary concern was the open core business model and enterprise features missing from the community edition. I think we had some rough consensus on this list that the primary missing enterprise feature we need in the open source edition is rebase-style merge requests. Was there anything else? Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 02:21:55PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, May 17, 2017 at 01:49:21PM +0200, Sébastien Wilmet wrote: > > By attaching a patch to a bugtracker ticket, we loose the information of > > the parent commit: where the commit has been initially created in the > > git history. > If the patch is created by git format-patch, it contains the hash of > the parent, so git knows the original parent. > > > I've already had the problem that git-bz apply fails (there was a > > conflict), while git was able to resolve automatically the conflict when > > rebasing the branch. > 'git am -3' is the same as a rebase. Thanks for correcting me. Indeed a patch created with `git format-patch` includes the hashes of the parent objects. When using git-bz it hides a little the use of git am, so I was not aware of all the possiblities of git am. It's possible to configure the am.threeWay setting in git, by default it's false. But it doesn't seem easy (or even possible) with git am to create a branch at the original place in the git history where the patches were created. The parent *commit* is not known, only the parent objects. I think it can be useful to know where the contributor has created the commits. With a pull request workflow like in GitHub and GitLab, when we fetch the branch we know the parent commit. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hey Felipe, What is that you are no fan of in the merge request workflow? Would a command line application thay works similarly to git bz fox these issues? Regarding useless forks, why is that a problem? (Definitely something to take care on our infra though if it grows too big) Cheers Original Message On 23 May 2017, 11:21, Felipe Borges wrote: On Tue, May 23, 2017 at 11:00 AM, Milan Crha wrote: > On Thu, 2017-05-18 at 15:12 -0500, mcatanz...@gnome.org wrote: >> I think we should remove this extension immediately. > > Hi, > that sounds quite radical, does it not? > > Removing everything what has bugs, instead of fixing them, what would > you ship to your users? > >> It provides limited value, since you almost always want to skip >> through the pretty little trace to see the full backtrace anyway. > > Different people, different usages. What you do not use maybe others > do. I see many regressions in the recent changes in GNOME bugzilla > which simply break my workflow with it, built and fine-tuned during > many years of using it, but nobody cares. They know better what I > should do and how, it seems. > >> And this confusing bug is very serious. > > Hmm, did you hit that bug yourself? I did not. I see it's filled since > 2015, with 18 CC'ed users. That's not a low number, but there had been > filled thousands of backtraces during that time, with no problem so far > (I believe so at least, I do not have exact numbers, thus if anyone can > correct my expectations, then I'm all fine). > Bye, > Milan > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list +1: I am supportive of the initiative. After catching up with the discussion, my personal pros and cons are: Pros: - reviewing patches is significantly clearer in gitlab - code browsing is better than cgit - gitlab snippets introduce a bit more flexibility than pastebin - easy to publish new repositories with toy/new projects Cons: - not a big fan of the merge-request workflow - we will have a bunch of useless forks across the users' accounts In terms of issue/bug tracking, I am more concern about the migration itself. I would initially use gitlab to replace cgit and pastebin, and keep bugzilla as the bug tracker for a little while (not introducing new components/modules on bugzilla anymore, pointing at gitlab). One common thing I do with git-bz is interactively applying patches. Is there a clear 101 workflow for this kind of review with gitlab? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On 23 May 2017 at 13:21, Felipe Borges wrote: >> At least with GitHub and Gogs [1] it's possible to create merge requests from >> a branch *in the same repository* (I use branches named >> “/” >> now and then). If everybody who is a maintainer is going to have push access >> in the GNOME GitLab instance, they can just push their branch to repository >> and create the merge request from there — without needing to fork the >> repository into their user space. > > Sure, but this creates a distinction between maintainers and other > contributors, as I think Bastien mentioned before. I honestly don't understand what the fuss is all about. This "difference" already exists. Either you have a Git account on git.gnome.org, in which case: congrats, you can already push to a branch on GitLab without requiring a forked repo; or you don't have it, in which case, *right now* you need to create a separate public repo on some other hosting, or you need to create a patch from a local clone and attach it somewhere. With GitLab, on the other hand, in either cases you'll have a forked repo on the *same* infrastructure. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, 23 May 2017 14:21:02 +0200, Felipe Borges wrote: > On Tue, May 23, 2017 at 2:13 PM, Adrian Perez de Castro > wrote: > > Hi there, > > > > No strong opinion here about GitLab, just a comment below... > > > > On Tue, 23 May 2017 11:21:25 +0200, Felipe Borges > > wrote: > > > >> [...] > >> > >> Cons: > >> - not a big fan of the merge-request workflow > >> - we will have a bunch of useless forks across the users' accounts > > > > I have seen this concern pop several times in this thread. Does GitLab > > strictly require that a merge request is always started from a fork? > > > > At least with GitHub and Gogs [1] it's possible to create merge requests > > from > > a branch *in the same repository* (I use branches named > > “/” > > now and then). If everybody who is a maintainer is going to have push access > > in the GNOME GitLab instance, they can just push their branch to repository > > and create the merge request from there — without needing to fork the > > repository into their user space. > > Sure, but this creates a distinction between maintainers and other > contributors, as I think Bastien mentioned before. Oh, that's an interesting point. Somehow I missed that while skimming through the long thread O:-) Br. -- 💻 Adrián pgp7g_rZ2wdFy.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, May 23, 2017 at 2:13 PM, Adrian Perez de Castro wrote: > Hi there, > > No strong opinion here about GitLab, just a comment below... > > On Tue, 23 May 2017 11:21:25 +0200, Felipe Borges > wrote: > >> [...] >> >> Cons: >> - not a big fan of the merge-request workflow >> - we will have a bunch of useless forks across the users' accounts > > I have seen this concern pop several times in this thread. Does GitLab > strictly require that a merge request is always started from a fork? > > At least with GitHub and Gogs [1] it's possible to create merge requests from > a branch *in the same repository* (I use branches named “/” > now and then). If everybody who is a maintainer is going to have push access > in the GNOME GitLab instance, they can just push their branch to repository > and create the merge request from there — without needing to fork the > repository into their user space. Sure, but this creates a distinction between maintainers and other contributors, as I think Bastien mentioned before. > > Cheers, > > -- > 💻 Adrián “2¢” Pérez > --- > [1] > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, 2017-05-23 at 15:13 +0300, Adrian Perez de Castro wrote: > Hi there, > > No strong opinion here about GitLab, just a comment below... > > On Tue, 23 May 2017 11:21:25 +0200, Felipe Borges il.com> wrote: > > > [...] > > > > Cons: > > - not a big fan of the merge-request workflow > > - we will have a bunch of useless forks across the users' accounts > > I have seen this concern pop several times in this thread. Does > GitLab strictly require that a merge request is always started from a > fork? No, this works exactly like in Github. > At least with GitHub and Gogs [1] it's possible to create merge > requests from a branch *in the same repository* (I use branches named > “/” now and then). If everybody who is a > maintainer is going to have push access in the GNOME GitLab instance, > they can just push their branch to repository and create the merge > request from there — without needing to fork the repository into > their user space. Exactly. Only new contributors who don't have the permissions yet would need to create their own forks. -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hi there, No strong opinion here about GitLab, just a comment below... On Tue, 23 May 2017 11:21:25 +0200, Felipe Borges wrote: > [...] > > Cons: > - not a big fan of the merge-request workflow > - we will have a bunch of useless forks across the users' accounts I have seen this concern pop several times in this thread. Does GitLab strictly require that a merge request is always started from a fork? At least with GitHub and Gogs [1] it's possible to create merge requests from a branch *in the same repository* (I use branches named “/” now and then). If everybody who is a maintainer is going to have push access in the GNOME GitLab instance, they can just push their branch to repository and create the merge request from there — without needing to fork the repository into their user space. Cheers, -- 💻 Adrián “2¢” Pérez --- [1] pgp0SNdIrcjCQ.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Mon, 2017-05-22 at 11:50 +0100, Philip Withnall wrote: > I would also be supportive of a solution using Phabricator+cgit. Phab > for task management and patch review, since its task management is > more > powerful than gitlab’s, and its patch review workflow doesn’t have > the > problems of gitlab’s branch-and-merge approach (its inter-diff > reviews > are great). cgit for viewing the repositories, as normal. I was given examples of inter-diff views in a deployed gitlab instance (framagit), and it seems to work pretty well. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, 2017-05-23 at 11:21 +0200, Felipe Borges wrote: > > +1: I am supportive of the initiative. > > After catching up with the discussion, my personal pros and cons are: > > Pros: > > - code browsing is better than cgit Seeing the history of a single file is unfortunately much harder than in cgit. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, May 23, 2017 at 11:00 AM, Milan Crha wrote: > On Thu, 2017-05-18 at 15:12 -0500, mcatanz...@gnome.org wrote: >> I think we should remove this extension immediately. > > Hi, > that sounds quite radical, does it not? > > Removing everything what has bugs, instead of fixing them, what would > you ship to your users? > >> It provides limited value, since you almost always want to skip >> through the pretty little trace to see the full backtrace anyway. > > Different people, different usages. What you do not use maybe others > do. I see many regressions in the recent changes in GNOME bugzilla > which simply break my workflow with it, built and fine-tuned during > many years of using it, but nobody cares. They know better what I > should do and how, it seems. > >> And this confusing bug is very serious. > > Hmm, did you hit that bug yourself? I did not. I see it's filled since > 2015, with 18 CC'ed users. That's not a low number, but there had been > filled thousands of backtraces during that time, with no problem so far > (I believe so at least, I do not have exact numbers, thus if anyone can > correct my expectations, then I'm all fine). > Bye, > Milan > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list +1: I am supportive of the initiative. After catching up with the discussion, my personal pros and cons are: Pros: - reviewing patches is significantly clearer in gitlab - code browsing is better than cgit - gitlab snippets introduce a bit more flexibility than pastebin - easy to publish new repositories with toy/new projects Cons: - not a big fan of the merge-request workflow - we will have a bunch of useless forks across the users' accounts In terms of issue/bug tracking, I am more concern about the migration itself. I would initially use gitlab to replace cgit and pastebin, and keep bugzilla as the bug tracker for a little while (not introducing new components/modules on bugzilla anymore, pointing at gitlab). One common thing I do with git-bz is interactively applying patches. Is there a clear 101 workflow for this kind of review with gitlab? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Thu, 2017-05-18 at 15:12 -0500, mcatanz...@gnome.org wrote: > I think we should remove this extension immediately. Hi, that sounds quite radical, does it not? Removing everything what has bugs, instead of fixing them, what would you ship to your users? > It provides limited value, since you almost always want to skip > through the pretty little trace to see the full backtrace anyway. Different people, different usages. What you do not use maybe others do. I see many regressions in the recent changes in GNOME bugzilla which simply break my workflow with it, built and fine-tuned during many years of using it, but nobody cares. They know better what I should do and how, it seems. > And this confusing bug is very serious. Hmm, did you hit that bug yourself? I did not. I see it's filled since 2015, with 18 CC'ed users. That's not a low number, but there had been filled thousands of backtraces during that time, with no problem so far (I believe so at least, I do not have exact numbers, thus if anyone can correct my expectations, then I'm all fine). Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote: > In recent months we have got together to examine the possibilities > for GNOME’s development infrastructure. We’ve spent a lot of time on > this, because we want the community to have faith in our conclusions. > If you are interested in this, you can read our research on the wiki > [1]. I’m excited for this. I think my main concerns have already been raised by others, but I’ll raise them as a +1: - Dependencies between issues (the workaround of listing them all in a comment isn’t very satisfying, but will do in the interim if we are sure a proper solution is coming) - First-class support for a fast-forward merge workflow, including not losing comments when doing a force-push to an MR - Not breaking any old links when migrating cgit/Bugzilla bugs/Bugzilla attachments With those concerns in mind, I’m enthusiastic for gitlab. I would also be supportive of a solution using Phabricator+cgit. Phab for task management and patch review, since its task management is more powerful than gitlab’s, and its patch review workflow doesn’t have the problems of gitlab’s branch-and-merge approach (its inter-diff reviews are great). cgit for viewing the repositories, as normal. Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Fri, May 19, 2017 at 9:55 PM Shaun McCance wrote: > I don't disagree with anything you're saying. As long as there's an > easy way to get a list of issues with a specific label across all > projects (and projects in different groups?), then we'll figure it out. > And if there's not, we'll figure it out another way. It looks like labels can be defined by either the project or the group: https://gitlab.gnome.org/groups/GNOME/issues?label_name[]=newcomers So as long as all the canonical GNOME repos are under that umbrella, it should work just fine. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Thu, 2017-05-18 at 18:08 +0200, Andre Klapper wrote: > On Tue, 2017-05-16 at 10:51 -0400, Shaun McCance wrote: > > > > That said, here's a potential pain point: in Bugzilla, you can have > > different components auto-assign to different accounts, and we made > > these @gnome.bugs fake accounts for teams. The docs team uses this > > to > > make it easy to follow docs bugs across products. I don't think > > GitLab > > has any sense of components, preferring the more casual labels for > > categorization. > When all that overcategorization in a ticket (Bugzilla: 1 "product" > per > ticket, 1 "component" per ticket, 0-∞ "keywords" per ticket, random > freetext in a "whiteboard" entry, upstream's "tags" fields that GNOME > hides via custom CSS) is turned into a single "Labels" field, with 0- > ∞ > labels associated to a ticket, and everybody tries to remember adding > that #user-docs label, and if a GitLab user can receive notifications > for certain labels (so docs team members could follow activity), I > don't see a real problem? :) > > Our "@gnome.bugs virtual assignee" setup in Bugzilla is a horrible > hack, due to unavailability of an "allow me to receive notifications > for these products / components" functionality for ages [1]. I don't disagree with anything you're saying. As long as there's an easy way to get a list of issues with a specific label across all projects (and projects in different groups?), then we'll figure it out. And if there's not, we'll figure it out another way. This will likely affect other teams that work across projects, like the translation teams or the newcomers initiative. > andre > > [1] To be fair, a downstream bgo extension got upstreamed at > https://github.com/bugzilla/extensions-ComponentWatching > but that's not shipped /by default/ which makes following anything > that > is neither a ticket nor a user to stalk rather > complicated/cumbersome. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Thu, May 18, 2017 at 11:36 AM, Andre Klapper wrote: The Traceparser is another (basically) unmaintained custom extension we have in our Bugzilla, with some confusing bugs (e.g. bug 744491). I think we should remove this extension immediately. It provides limited value, since you almost always want to skip through the pretty little trace to see the full backtrace anyway. And this confusing bug is very serious. It will be a shame to lose the feature that notifies you if your backtrace is similar to a backtrace in another bug, but we can live without and it's not worth the cost of bug 744491. Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hi, One thing we missed from the translators requirements is the workflow for tracking issues. At the moment, there's a "l10n" product [1] at Bugzilla where users report bugs choosing a language from "Components" list. My question here is, how things are going to work with Gitlab now that all bug are per project? At first thought, i'd say a repo only for reporting translations bugs could work. Another potential solution is to use labels and assignees (translation teams) per project. Both solutions have their pros and cons (for project maintainers and translation maintainers), so i'd appreciate your input on this. Regards, Tom [1] https://bugzilla.gnome.org/page.cgi?id=browse.html&product=l10n ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Thu, 2017-05-18 at 12:17 +0200, Milan Crha wrote: > please, do not forget of Bugzilla integration with backtraces. It can > colorize them, it can show possible duplicates with score when the > backtrace is opened in its own window, and it can even notify the > reporter that the backtrace matches some other bugs and it offers the > reporter to eventually join an existing bug, instead of filling a new > bug report. Of course, an average user cannot decipher backtrace of > random projects, thus it's fine he/she files a new bug report, but my > main point for Bugzilla is that it knows what to do with inline > backtraces. Does gitlab issue tracker know it too? The Traceparser is another (basically) unmaintained custom extension we have in our Bugzilla, with some confusing bugs (e.g. bug 744491). GNOME Bugzilla does not receive gazillions of crasher bug reports anymore (like after the 2.16 release, which was the reason to write this extension if I remember correctly) and most distributions nowadays ship their own tools (and own backends) for automatic crasher analysis. The Traceparser is convenient but I would not strongly miss it if there was nothing similar in GitLab. I'd say a regression we could live with? > I've seen a screenshot of the gitlab issue tracker in an early stage of > the wiki page [1], which I cannot find right now. It was full of > colored tags, which effectively hid the main purpose, the information > which had been meant to be shared. The page looked like a rainbow, not > like a clean interface to share information between the reporter and > the developer. I do not know GitLab much but I'd expect functionality to set a color when creating a label. So color rules could be established if wanted / needed [4]. I'd call GitLab a way cleaner interface than Bugzilla. :) andre [4] notorious Wikimedia example for project/tag/label coloring rules: https://www.mediawiki.org/wiki/Phabricator/Project_management#Types_of_Projects -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, 2017-05-16 at 10:51 -0400, Shaun McCance wrote: > That said, here's a potential pain point: in Bugzilla, you can have > different components auto-assign to different accounts, and we made > these @gnome.bugs fake accounts for teams. The docs team uses this to > make it easy to follow docs bugs across products. I don't think GitLab > has any sense of components, preferring the more casual labels for > categorization. When all that overcategorization in a ticket (Bugzilla: 1 "product" per ticket, 1 "component" per ticket, 0-∞ "keywords" per ticket, random freetext in a "whiteboard" entry, upstream's "tags" fields that GNOME hides via custom CSS) is turned into a single "Labels" field, with 0-∞ labels associated to a ticket, and everybody tries to remember adding that #user-docs label, and if a GitLab user can receive notifications for certain labels (so docs team members could follow activity), I don't see a real problem? :) Our "@gnome.bugs virtual assignee" setup in Bugzilla is a horrible hack, due to unavailability of an "allow me to receive notifications for these products / components" functionality for ages [1]. andre [1] To be fair, a downstream bgo extension got upstreamed at https://github.com/bugzilla/extensions-ComponentWatching but that's not shipped /by default/ which makes following anything that is neither a ticket nor a user to stalk rather complicated/cumbersome. -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, 2017-05-16 at 17:54 +0100, Allan Day wrote: > On Tue, May 16, 2017 at 5:36 PM, wrote: > ... > > We need a much better migration plan than that. If we don't have a > > script to migrate Bugzilla issues, comments, and attachments to our > > new GitLab instance, then we should not be considering using > > GitLab's issue tracker at all. > > We're committed to creating the necessary migration tooling; I think > that Alberto already has something in the works. The "Release often, release early" mantra makes me reply by "Please show me the code." andre -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, 2017-05-16 at 10:28 -0400, Carlos Soriano wrote: > 2- what are the migration plans for bugzilla: bugzilla URL, bug numbers and > the actual content [...] > Also, different projects might have different needs for migration. While that is true, it is more confusing if I can find all the Bugzilla tickets I created about project X now in GitLab while I cannot find all Bugzilla tickets I created about project Y now in GitLab but you expect me to find out myself what to find where (some BZ, some GitLab?). > For example, for Nautilus we could migrate just specific important > bugs or just file new bugs in GitLab while preserving the old ones in > Bugzilla, where I can still follow/fix/comment them. [...] > As I'm the one maintaining it, I prefer a slow and smooth transition > rather than a hard one and take the opportunity to focus on the > priority ones. If I interpret "slow" and "hard" correctly and if "old ones" means "older unresolved tickets", you propose running two task tracking systems in parallel with some tickets or some projects here and some there and I (simple user) may have no idea where to do or find what. When Wikimedia killed their Bugzilla instance they made a hard cut (first migration step was turning Bugzilla entirely read-only [1]). https://xkcd.com/927/ also applies. andre [1] https://phabricator.wikimedia.org/T1234 -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hey, On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote: > [Written on behalf of Alberto Ruiz, Carlos Soriano, Andrea Veri, > Emmanuele Bassi and myself.] > > Please bear in mind that this is just a recommendation! We are not > claiming to have complete knowledge and we would like to hear > questions and comments. At the same time, we do ask that members of > the community approach this proposal with an open mind: please read > the wiki pages and try to resist making assumptions about GitLab > without familiarising yourself with it. I've now read through the documentation, and annotated my early thoughts on the migration. - Keep bugzilla URLs working, along with history This is very important for code history purposes, and has been mentioned as an explicit goal at: https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/#Migration_Possibilities - Keep cgit URLs working Again, important for code history purposes. We often link to those in bug reports and commit messages. This could probably be achieved through redirections rather than keeping the cgit instance alive - Keep git URLs working While not a problem for developers (you'd change your gitconfig and update jhbuild, and done, mostly), it has the potential to break a lot of flatpaks, possibly also upstream packaging. I know something similar was done in the Fedora package repos when they migrated, so maybe it's possible? - Component bug assignment: g-c-c/g-s-d or gnome-documents/gnome-books This is probably the most important one for bug handling. Otherwise managing bugs for g-c-c and g-s-d, the different components of which require a lot of domain-specific knowledge, would be terribly unwieldy. - Equivalent to NEEDINFO? This status was pretty important in terms of bug triaging, as the reporter was allowed to remove that flag when they were done providing the information, removing the burden from the bug triager to monitor the bug. Is there an equivalent? - Cross-module issue searching? Again, quite useful in terms of bug triaging, allowing to find a "root cause" bug, possibly assigned to a different component than the top level application. For example, a crash in Videos could be in about 7 different modules, being able to search the whole instance would be useful. - Mail for own replies (a-la bugzilla) - This is also a useful tool for bug triaging, as all the comments end up in my Bugzilla folder, and I can search through them. I'm guessing/hoping it's possible. - Handling of private bugs? Bugzilla has the ability to create private bugs, for security and community feedback management purposes. Does GitLab allow that? - Bugzilla yearly reports Is there some statistics tool builtin to GitLab? - Bugzilla points Will they be migrated? :) Overall, the migration is a good idea, especially the ability to report bugs and contribute without a GNOME specific account. I hope the information about how different teams and bugzilla triagers use Bugzilla, in particular, was of interest. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Heya, Good discussion, nice input from everyone involved! I summarized what we have so far in a new page with community input in https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/CommunityInput Keep in mind I tried to extract the most important points, to have an effective list of actions to take. Feel free to put more comments in the comments section https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/Comments and/or continue with the emails. Cheers, Carlos Soriano Original Message Subject: Re: Proposal to deploy GitLab on gnome.org Local Time: May 17, 2017 9:02 PM UTC Time: May 17, 2017 7:02 PM From: jehan.marmott...@gmail.com To: Mathieu Bridon Carlos Soriano , desktop-devel-list@gnome.org , Bastien Nocera Hi, On Wed, May 17, 2017 at 5:59 PM, Mathieu Bridon wrote: > On Wed, 2017-05-17 at 17:44 +0200, Jehan Pagès wrote: >> On Wed, May 17, 2017 at 5:01 PM, Mathieu Bridon > > wrote: >> > On Wed, 2017-05-17 at 16:47 +0200, Jehan Pagès wrote: >> > > IMO this is a completely broken and over-complicated workflow. >> > > For >> > > long term contributors, having their own remote can be >> > > understandable. >> > > But for one-time contribs? >> > >> > One-time contributions can be done entirely in the web UI, for >> > example: >> >> Ok. Sorry but no. >> I code in my text editor, not in my browser. > > That's fine, me too. > > But you're not a one-time contributor to GNOME, are you? GNOME is a lot of projects. I have been a one-time contributor to several GNOME projects and will likely continue to do so for the same or other projects. Even though I have a GNOME git account, I (obviously) don't push to random projects which never heard of me. I am still going through the normal bugzilla procedure and will continue to go through the normal gitlab procedure if the migration is done. > Remember that I'm responding to your thread about how the fork+merge- > request workflow is too complex for trivial one-time contributions. > >> > For one-time contributions, this is a **much** simpler workflow >> > than cloning the repository, making the changes, committing the >> > change, making a patch, then sending the patch by email/bugzilla. >> > It even enables non-technical people to contribute! >> >> Well much simpler for developers who like to push buttons. We are >> many who don't like this. Let's not generalize! >> >> Also such patches are acceptable for very simple stuff. For instance >> typo fixes, or string fixes, or similar. > > Well yes, that's exactly what this thread was about: simple one-time > contribution that are so trivial that they make the fork+merge-request > workflow prohibitive. Since I kind of started the discussion on this topic, it's good to assume I know what it is about. I never discussed about trivial contributions, and I don't think to remember anyone else discussing on this topic as an answer to my emails. So no, the discussion was on the contribution workflow (for people who don't push directly, but will make bug reports/merge requests/patches/etc. Most of them being one-time contributors). >> But other than this, even >> one-liners of actual code, I don't want to encourage people who do >> things without actually testing (and expecting us to test for them). > > That's why you have a CI that runs before merging. > >> > And if I send you a patch, you might find it easier to test it >> > locally. But that completely bypasses your pre-merge CI. >> >> CI test basic stuff like "it builds", and "the tests don't fail". But >> there is much more in a patch than this. > > A CI can do pretty much anything you want it to, it's not limited to > "basic stuff" at all. Yes you can do tests for a lot of things. Anything is scriptable. It doesn't mean that everything is scripted in tests. Otherwise software who succeed all the tests would have no bugs by definition. So we still need to test many things manually. >> Of course, you could say that the tests should include every case. >> But the fact is that if there is a bug that was not seen before, that >> probably means there is no tests for it (otherwise we'd have seen >> it!). Even if we add a test, then we have to check first that the >> test is fine by building locally. Back to square 1. > > And the person doing that is not the one-time contributor, but you, the > maintainer. Yes, which is why I say that I still test the patches locally before pushing and don't rely only on CI. > Seriously, you started complaining that the fork+clone is too
Re: Proposal to deploy GitLab on gnome.org
On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote: > The outcome of this evaluation process is that we are recommending > that GNOME sets up its own GitLab instance, as a replacement for > Bugzilla and cgit. Hi, with respect of the cgit, it lets me download sources (snapshot) as a .zip and a .tar.xz. The gitlab offers .zip, .tar.gz, .tar.bz2 and .tar. I think there had been some good reasoning for projects to do releases as .tar.xz (maybe it was even a GNOME Goal, I do not recall, neither cannot find it), it's quite efficient with compression, thus it would make sense to teach gitlab to use it beside .zip, instead of those three not-that-useful-these-days .tar variants. Would they do it upstream, or you'll need to patch it downstream, or it's just some option somewhere? Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, 2017-05-16 at 10:51 -0400, Shaun McCance wrote: > That said, here's a potential pain point Hi, please, do not forget of Bugzilla integration with backtraces. It can colorize them, it can show possible duplicates with score when the backtrace is opened in its own window, and it can even notify the reporter that the backtrace matches some other bugs and it offers the reporter to eventually join an existing bug, instead of filling a new bug report. Of course, an average user cannot decipher backtrace of random projects, thus it's fine he/she files a new bug report, but my main point for Bugzilla is that it knows what to do with inline backtraces. Does gitlab issue tracker know it too? Also, with respect of searching in Bugzilla, what some folks in this thread call complicated, I call powerful. Bugzilla is powerful in searching. The search UI can be complicated, that's why there is a Simple and Advanced search page, but it allows you do many good things. I've seen a screenshot of the gitlab issue tracker in an early stage of the wiki page [1], which I cannot find right now. It was full of colored tags, which effectively hid the main purpose, the information which had been meant to be shared. The page looked like a rainbow, not like a clean interface to share information between the reporter and the developer. One of the test issues [2] also looks somehow odd, but maybe if I would get use to it, then it might not be that bad as it looks like now. How many comments does it show? Four? One? Something in between? It looks like there are four of them, all grey thin font (hard to read), and wasting like 1/3 of my browser window height. Height is problem, not width, with wide screens. I didn't try how it looks like on a cell phone. The issue [3] also says: > Carlos Soriano @csoriano mentioned in issue #30668 (closed) 2 weeks ago Should that "mentioned" be "is marked as duplicate" instead? I can mention bugs between itself and I do it all the time (like "this is partly related to bug #1234", or even "can be duplicate of bug #1234", which used to do bug squad folks in the past too), but it doesn't mean they are duplicates, neither that I want to add some possibly misleading automated comment into the other bug report. I would mark them as a duplicate, or add them to Depends/Blocks, if I'd be sure. >From my point of view, it doesn't make much sense to have both Bugzilla and gitlab issue tracker running at the same time and let the product maintainers decide what is better for them. There should be some consistency. You cannot tell the reporter that the issue he/she filled belongs to other project, but that project issues are hosted elsewhere (even still under gnome.org domain). I understand this whole initiative to also make life easier for sysadmins, where maintaining two issue trackers doesn't sound like less work for them. Bye, Milan [1] https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/ [2] https://gitlab.gnome.org/GNOME/nautilus/issues/30668 [3] https://gitlab.gnome.org/GNOME/nautilus/issues/20958 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, 2017-05-17 at 08:50 -0400, Carlos Soriano via desktop-devel- list wrote: [...] > > > > > - git-bz attach equals to git push origin HEAD:fix2340issue, then > > > click create merge request. > > > > Does this rewrite the commit message to include the PR or bug > > number? > > No, as written in the wiki you write "Closes: $number" and it will > handle things automatically. > Of course some addition could be done to do the rewrite. This is a point of interest to me. To clarify: o Accepting a merge request will automatically close the merge request and apply the branch with (if enabled) an additional superficial commit saying MR ${number} was merged. o If the commit messages say "Closses ${number}" in them, gitlab will scan this and do automatic things too, iiuc it will close issues automatically when the merge request is accepted. In gitlab this automation is quite configurable, so my question is; will individual project maintainers in GNOME have the power to configure this how they like for their own modules ? This is a feature I personally want disabled, closing a bug report is a manual thing in my mind, a patch itself should not be allowed to dictate that it closes an issue, although that patch might presume to do so, someone should stop by and close the issue. Cheers, -Tristan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hi, On Wed, May 17, 2017 at 5:59 PM, Mathieu Bridon wrote: > On Wed, 2017-05-17 at 17:44 +0200, Jehan Pagès wrote: >> On Wed, May 17, 2017 at 5:01 PM, Mathieu Bridon > > wrote: >> > On Wed, 2017-05-17 at 16:47 +0200, Jehan Pagès wrote: >> > > IMO this is a completely broken and over-complicated workflow. >> > > For >> > > long term contributors, having their own remote can be >> > > understandable. >> > > But for one-time contribs? >> > >> > One-time contributions can be done entirely in the web UI, for >> > example: >> >> Ok. Sorry but no. >> I code in my text editor, not in my browser. > > That's fine, me too. > > But you're not a one-time contributor to GNOME, are you? GNOME is a lot of projects. I have been a one-time contributor to several GNOME projects and will likely continue to do so for the same or other projects. Even though I have a GNOME git account, I (obviously) don't push to random projects which never heard of me. I am still going through the normal bugzilla procedure and will continue to go through the normal gitlab procedure if the migration is done. > Remember that I'm responding to your thread about how the fork+merge- > request workflow is too complex for trivial one-time contributions. > >> > For one-time contributions, this is a **much** simpler workflow >> > than cloning the repository, making the changes, committing the >> > change, making a patch, then sending the patch by email/bugzilla. >> > It even enables non-technical people to contribute! >> >> Well much simpler for developers who like to push buttons. We are >> many who don't like this. Let's not generalize! >> >> Also such patches are acceptable for very simple stuff. For instance >> typo fixes, or string fixes, or similar. > > Well yes, that's exactly what this thread was about: simple one-time > contribution that are so trivial that they make the fork+merge-request > workflow prohibitive. Since I kind of started the discussion on this topic, it's good to assume I know what it is about. I never discussed about trivial contributions, and I don't think to remember anyone else discussing on this topic as an answer to my emails. So no, the discussion was on the contribution workflow (for people who don't push directly, but will make bug reports/merge requests/patches/etc. Most of them being one-time contributors). >> But other than this, even >> one-liners of actual code, I don't want to encourage people who do >> things without actually testing (and expecting us to test for them). > > That's why you have a CI that runs before merging. > >> > And if I send you a patch, you might find it easier to test it >> > locally. But that completely bypasses your pre-merge CI. >> >> CI test basic stuff like "it builds", and "the tests don't fail". But >> there is much more in a patch than this. > > A CI can do pretty much anything you want it to, it's not limited to > "basic stuff" at all. Yes you can do tests for a lot of things. Anything is scriptable. It doesn't mean that everything is scripted in tests. Otherwise software who succeed all the tests would have no bugs by definition. So we still need to test many things manually. >> Of course, you could say that the tests should include every case. >> But the fact is that if there is a bug that was not seen before, that >> probably means there is no tests for it (otherwise we'd have seen >> it!). Even if we add a test, then we have to check first that the >> test is fine by building locally. Back to square 1. > > And the person doing that is not the one-time contributor, but you, the > maintainer. Yes, which is why I say that I still test the patches locally before pushing and don't rely only on CI. > Seriously, you started complaining that the fork+clone is too complex > for trivial one-time contributions, and now you've completely changed > the goal-posts, complaining how the wokflow that was specifically > designed for trivial one-time contributions doesn't allow bigger > changes. Once again, I was not speaking about trivial changes. Quite the opposite since we were discussing about the issue of rebuilding a tree, what happens on timestamps when you checkout a branch based on older code, etc. Also yes, sometimes the discussions evolve anyway. That's how discussions work. Someone says something, that makes someone else say something related but different, and so on. Fortunately. That would be very boring if we were to discuss on the exact same point of detail for 10 emails. > Seriously, you started complaining […] complaining how […] Please, let's keep it civil. I am not complaining. The whole point of this email thread was to hear members' comments and inputs. So I gave mine. I also explained that I still think it is a good change in many ways, and I listed a few features that I really appreciate in systems like gitlab. But then I also list some of my worries. One of these worries (for me) is about the workflow which is encouraged by gitlab and which I really dislike.
Re: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 5:01 PM, Mathieu Bridon wrote: > One-time contributions can be done entirely in the web UI, for example: One-time doesn’t necessarily mean trivial. What you describe is the workflow for a trivial change. One may still want to clone, compile, test locally even for a one-time contribution. > For one-time contributions, this is a **much** simpler workflow than > cloning the repository, making the changes, committing the change, > making a patch, then sending the patch by email/bugzilla. It even > enables non-technical people to contribute! Which is a great thing. That’s not what one-time contribution means though. -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, 2017-05-17 at 17:44 +0200, Jehan Pagès wrote: > On Wed, May 17, 2017 at 5:01 PM, Mathieu Bridon > wrote: > > On Wed, 2017-05-17 at 16:47 +0200, Jehan Pagès wrote: > > > IMO this is a completely broken and over-complicated workflow. > > > For > > > long term contributors, having their own remote can be > > > understandable. > > > But for one-time contribs? > > > > One-time contributions can be done entirely in the web UI, for > > example: > > Ok. Sorry but no. > I code in my text editor, not in my browser. That's fine, me too. But you're not a one-time contributor to GNOME, are you? Remember that I'm responding to your thread about how the fork+merge- request workflow is too complex for trivial one-time contributions. > > For one-time contributions, this is a **much** simpler workflow > > than cloning the repository, making the changes, committing the > > change, making a patch, then sending the patch by email/bugzilla. > > It even enables non-technical people to contribute! > > Well much simpler for developers who like to push buttons. We are > many who don't like this. Let's not generalize! > > Also such patches are acceptable for very simple stuff. For instance > typo fixes, or string fixes, or similar. Well yes, that's exactly what this thread was about: simple one-time contribution that are so trivial that they make the fork+merge-request workflow prohibitive. > But other than this, even > one-liners of actual code, I don't want to encourage people who do > things without actually testing (and expecting us to test for them). That's why you have a CI that runs before merging. > > And if I send you a patch, you might find it easier to test it > > locally. But that completely bypasses your pre-merge CI. > > CI test basic stuff like "it builds", and "the tests don't fail". But > there is much more in a patch than this. A CI can do pretty much anything you want it to, it's not limited to "basic stuff" at all. > Of course, you could say that the tests should include every case. > But the fact is that if there is a bug that was not seen before, that > probably means there is no tests for it (otherwise we'd have seen > it!). Even if we add a test, then we have to check first that the > test is fine by building locally. Back to square 1. And the person doing that is not the one-time contributor, but you, the maintainer. Seriously, you started complaining that the fork+clone is too complex for trivial one-time contributions, and now you've completely changed the goal-posts, complaining how the wokflow that was specifically designed for trivial one-time contributions doesn't allow bigger changes. -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hi, On Wed, May 17, 2017 at 5:01 PM, Mathieu Bridon wrote: > On Wed, 2017-05-17 at 16:47 +0200, Jehan Pagès wrote: >> IMO this is a completely broken and over-complicated workflow. For >> long term contributors, having their own remote can be >> understandable. >> But for one-time contribs? > > One-time contributions can be done entirely in the web UI, for example: Ok. Sorry but no. I code in my text editor, not in my browser. And I am not going to change that. The web GUI has some great stuff that we can't do at this time on a text editor. Like I cannot review and comment line by line a patch. So I do it in the browser, out of luck. But that doesn't mean that I am going to push my workflow and start coding in a browser. It's nice that it's possible for others, but it should only be used in very rare cases. > 1. find the file in the source code you want to modify > 2. click the "edit" button > 3. "You don't have permission to edit this file. Try forking this > project to edit the file." -> click the "fork" button > 4. you get presented with a web-based editor for the file you wanted to > edit, in your fork, do your changes, write a commit message, click > "commit changes" > 5. this **automatically** opens a form to create a merge request, you > can just submit it > > For one-time contributions, this is a **much** simpler workflow than > cloning the repository, making the changes, committing the change, > making a patch, then sending the patch by email/bugzilla. It even > enables non-technical people to contribute! Well much simpler for developers who like to push buttons. We are many who don't like this. Let's not generalize! Also such patches are acceptable for very simple stuff. For instance typo fixes, or string fixes, or similar. But other than this, even one-liners of actual code, I don't want to encourage people who do things without actually testing (and expecting us to test for them). When I do a fix to a code, even if it's my code, even if it's a very simple code and I'm like 100% sure that it's good, I compile (when on compiled code) and run the code to test if that does what I expected and did not bring undesirable side effects that I failed to foresee. This is also the minimum I expect from contributors to a code I maintain. So in the end, this feature of editing and pushing everything on the web GUI should be used very rarely. > And if I send you a patch, you might find it easier to test it locally. > But that completely bypasses your pre-merge CI. CI test basic stuff like "it builds", and "the tests don't fail". But there is much more in a patch than this. There is code logics. Yes I test contributed patches locally after the first visual check of the diff. I assume/hope others do the same. Of course, you could say that the tests should include every case. But the fact is that if there is a bug that was not seen before, that probably means there is no tests for it (otherwise we'd have seen it!). Even if we add a test, then we have to check first that the test is fine by building locally. Back to square 1. Also in reality, everyone knows that tests cannot possibly test each and every piece of a code, especially in a project as big as GIMP. So it's not that I find it "easier", it's that I find it totally complementary and non-optional. Jehan > With a pull-request, your CI can run **before** merging any change, > which means you can try and keep master always building and with > passing tests. > > > -- > Mathieu -- ZeMarmot open animation film http://film.zemarmot.net Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, 2017-05-17 at 16:47 +0200, Jehan Pagès wrote: > Hi, > […] > The typical workflow as advised by github (and therefore I believe > that's similar in gitlab), if not mistaken, is: Unless you have push privileges, in which case you'd just create a wip- or feature branch and make a merge request. This is what's recommended on the GitLabWorkflows[1] page. > […] So I just clone the upstream, and only if I end up doing a patch, > I would only then "fork" on github, then update my local repository > to point to my "fork", so that I can push then click the "pull > request" button. That's still very cumbersome. For most of us active in this discussion, this won't be an issue since we'll have push privileges (see above). However. What you describe above is how I make drive-by patches on GitHub, and I agree it can be a bit cumbersome. Fortunately there are tools to help you. I use git-spindle[2] which has support for GitHub, GitLab and Bitbucket. The, above manual steps becomes something like this with git-spindle (using graphene as an example repo): $ git hub clone ebassi/graphene && cd graphene $ git checkout -b wip/my-cool-fix [ do some work ] $ git commit -a -m "My awesome fix" $ git hub fork $ git hub pull-request [ Write merge message ] > IMO this is a completely broken and over-complicated workflow. For > long term contributors, having their own remote can be > understandable. > But for one-time contribs? > With proper tooling, the workflow isn't very complicated at all. And it's definitely not "completely broken" as you suggest. Regards, Mattias 1: https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/GitLabW orkflows 2: https://github.com/seveas/git-spindle ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 04:36:48PM +0200, Jehan Pagès wrote: > Hi, > > On Wed, May 17, 2017 at 4:30 PM, Zbigniew Jędrzejewski-Szmek > wrote: > > On Wed, May 17, 2017 at 04:25:09PM +0200, Jehan Pagčs wrote: > >> Hi, > >> > >> On Wed, May 17, 2017 at 2:44 PM, Carlos Soriano > >> wrote: > >> > Ah, I see what you mean now. But then you can rebase yourself in master > >> > right? And the build time would be exactly the same no? > >> > >> Not sure what you mean. You don't want to rebase master under any > >> circumstances (unless you rebase over origin/master to be able to push > >> new commits of course). Anyway you usually won't be able to, since > >> force push should be forbidden in master. And in any cases, this does > >> not solve the issue I was talking about. > >> > >> What I want is rebasing a patch branch over master. And no, you cannot > >> do it *from* master. You have to first checkout the branch so that you > >> can rebase. Once you checked out, it's too late. Timestamps of various > >> files are changed even though they didn't change between master and > >> the rebased branch (but they changed in the in-between step). > > > > 'git cherry-pick ..branch' ? > > That's what I said I would likely do indeed a few emails ago. :P > But I was answering about the problems of rebasing for timestamp as an > alternative. > > cherry-pick still has a problem though. Unless the patch is trivial > and looks like it's totally good from reading the diff (I would still > do a quick build just to be sure), I don't really like to work on > master with commits. You never know, some day, just a reflex, you git > push… Hopefully it has never happened, but still. That's like working > on a production server. Yeah, I have pushed to master a few times by mistake… Embarrassing *and* permanent ;( There's always git cherry-pick -n. That works as long as the PR has only one commit. Apart from that, I don't think there's a general solution to this problem… You could always play with setting branch.master.pushRemote to your private repo, so that an explicit 'git push origin' is required to actually push. But once you get into the habit of doing that, you're back to square one. So I don't think any automatic solution is possible. > That's why I like to work on master (so that I don't checkout outdated > branches and have long builds), but with git apply as a first step. One option is to improve the build system… Gnome is in the process of switching to meson, and meson does much better in this regard. So that might make this issue moot — by the time gitlab is implemented, branching might be cheap again. Zbyszek ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, 2017-05-17 at 16:47 +0200, Jehan Pagès wrote: > IMO this is a completely broken and over-complicated workflow. For > long term contributors, having their own remote can be > understandable. > But for one-time contribs? One-time contributions can be done entirely in the web UI, for example: 1. find the file in the source code you want to modify 2. click the "edit" button 3. "You don't have permission to edit this file. Try forking this project to edit the file." -> click the "fork" button 4. you get presented with a web-based editor for the file you wanted to edit, in your fork, do your changes, write a commit message, click "commit changes" 5. this **automatically** opens a form to create a merge request, you can just submit it For one-time contributions, this is a **much** simpler workflow than cloning the repository, making the changes, committing the change, making a patch, then sending the patch by email/bugzilla. It even enables non-technical people to contribute! And if I send you a patch, you might find it easier to test it locally. But that completely bypasses your pre-merge CI. With a pull-request, your CI can run **before** merging any change, which means you can try and keep master always building and with passing tests. -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 4:08 PM Mathieu Bridon wrote: > On Wed, 2017-05-17 at 15:55 +0200, Bastien Nocera wrote: > > > No, as written in the wiki you write "Closes: $number" and it will > > > handle things automatically. > > > Of course some addition could be done to do the rewrite. > > > > Right, so that's not automated, and you can't know what to put in the > > commit messages until you've create the merge request. Kind of a > > chicken and egg problem. > > The merge request gets automatically closed when you merge it. > > The "Closes #number" is to associate the commit to the corresponding > issue (and have it closed automatically), not the pull request. > Can we please have the full issue URL there, either by convention (as we do now) or enforced by the tooling? In the best case, the raw number is inconvenient when looking up the issue from the commit (outside the web UI): "Select+copy number, switch to browser, go to gitlab.gnome.org, paste number" vs. "click a link". In the worst case it's confusing, because it is unclear what the number refers to - for example the github mirror will likely turn them into links to non-existent issues on github, and if we ever decide to migrate to something else in the future, you need to know which issue tracker was used at the time of the commit. Florian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hi, On Wed, May 17, 2017 at 3:55 PM, Bastien Nocera wrote: > On Wed, 2017-05-17 at 08:50 -0400, Carlos Soriano wrote: >> > Original Message >> > Subject: Re: Proposal to deploy GitLab on gnome.org >> > Local Time: May 17, 2017 2:10 PM >> > UTC Time: May 17, 2017 12:10 PM >> > From: had...@hadess.net >> > To: Carlos Soriano >> > desktop-devel-list@gnome.org >> > >> > On Wed, 2017-05-17 at 06:36 -0400, Carlos Soriano via desktop- >> > devel- >> > list wrote: >> > > Hey Bastien, >> > > >> > > Not sure if you read the wiki and the workflow we outlined in >> > there, >> > > since we mention how this works. You will realize that's not >> > > necessary for you, neither a git-bz alternative since you will >> > use >> > > just git: >> > > - git-bz apply equals to git checkout remoteBranch >> > >> > No, it doesn't. git-bz apply on a master or version branch will >> > allow >> > me to amend commits. It does everything but push. The above doesn't >> > allow me to apply the same set of patches to a development and a >> > stable >> > branch for example. >> >> Doesn't git rebase do precisely this? > > I don't quite understand the workflow for users to create merge > requests with patches added, compared to my experiences with GitHub for > example, so bear with me. > > If I'm a registered developer for the GNOME org, or that particular > module, I'd create my merge requests as wip branches in the main > repo?Or as branches in a separate repo that I have the control of? > > What about developers that don't have GNOME commit access? Do they > fork, play in their corners and then create a merge request? The typical workflow as advised by github (and therefore I believe that's similar in gitlab), if not mistaken, is: 1/ clone the repo you want to fix into a new public remote by clicking a "fork" button in the web GUI. So for instance if your nickname is 'bastien' in git.gnome.org, let's assume that 'gnome-shell' repo is under git.gnome.org/git/gnome/gnome-shell, then clicking the button will create a new remote git.gnome.org/git/bastien/gnome-shell. Notice that the origin URL is slightly different from current (adding gnome/), that's because github/gitlab need are all prefixed with some kind of project or user namespace (so I guess git.gnome.org will have to update project URLs with this concept, no?). 2/ Clone your personal repo into a working branch on your computer. 3/ Make your commits and push. 4/ Go back to the web GUI and click the merge request button. Personally I don't think I ever did this, because I want to checkout a code before even being sure I would do a patch. Creating a public repo just to read code is dumb. So I just clone the upstream, and only if I end up doing a patch, I would only then "fork" on github, then update my local repository to point to my "fork", so that I can push then click the "pull request" button. That's still very cumbersome. IMO this is a completely broken and over-complicated workflow. For long term contributors, having their own remote can be understandable. But for one-time contribs? > Does that > merge request automatically create a branch in the upstream repo? How > do we stop merge request spam, or the unbounded growth of the repo with > all the wip branches, if that's the case? No. AFAIK, merge requests don't create an upstream branch. Fortunately this would be a very bad security issue! Jehan >> > > - git-bz attach equals to git push origin HEAD:fix2340issue, then >> > > click create merge request. >> > >> > Does this rewrite the commit message to include the PR or bug >> > number? >> >> No, as written in the wiki you write "Closes: $number" and it will >> handle things automatically. >> Of course some addition could be done to do the rewrite. > > Right, so that's not automated, and you can't know what to put in the > commit messages until you've create the merge request. Kind of a > chicken and egg problem. > >> > Do we end up with separate merge requests and bug numbers, >> > segregating >> > users and developers? And yes, clicking a button is a problem when >> >> Yes. They are different concepts in this tool, which I though it was >> an improvement. The bug is more about the discussion of what is >> wanted/motivation/reasoning/design/etc., the merge request is about >> pure code. >> Not sure I would frame it as
Re: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 01:23:43PM +0200, Christoph Reiter wrote: > On Wed, May 17, 2017 at 12:47 PM, Jehan Pagès > wrote: > > The only thing I am annoyed at is this forking workflow. Both as a > > contributor, and as a code committer/reviewer. Having to fetch a new > > remote for every single-commit contribution out there is terrible. > > In case you didn't know, just like with github you can fetch the PRs > from the main remote if you adjust the git config accordingly: > https://docs.gitlab.com/ce/user/project/merge_requests/#checkout-merge-requests-locally > > $ git fetch > $ git branch -a # look for PR branch > $ git checkout origin/merge-requests/42 > $ git checkout master I have the following config (for github): [alias] pr-fetch = "!f() { git fetch -fu ${2:-origin} refs/pull/$1/head:pr/$1; }; f" pr = "!f() { git fetch -fu ${2:-origin} refs/pull/$1/head:pr/$1 && git checkout pr/$1; }; f" pr-merge = "!f() { git fetch -fu ${2:-origin} refs/pull/$1/head:pr/$1 && git merge pr/$1 --no-ff --edit -m 'Merge pull request #'$1; }; f" pr-clean = "!git for-each-ref refs/heads/pr/* --format=\"%(refname)\" | while read ref ; do branch=${ref#refs/heads/} ; git branch -D $branch ; done" (git pr checks out the PR as a new branch, and git pr-fetch just creates the new branch but does not check out.) IIUC, you want to rebase the PR onto your master to do a ff-merge. This should be fairly easy to do with 'git cherry-pick ..pr/'. From another mail: > When it's a separate remote, I even wonder if git will still make the > link between the 2 remotes? Will it try to rebuild everything from > scratch? This would be absolutely terrible. I think there's some confusion as to what git is doing when you switch branches. All it does is: 1. compare the two trees from the old commit and new commit, 2. write out the files that are different, delete files that are missing from the new tree. So it does not touch any files that are identical between two trees. When git writes out files, it doesn't do anything special, so the os updates the mtime to "now". This means that the build system will rebuild everything which has the updated files as deps. How much is rebuilt is depends on the build system and the changeset... autotools will usually rebuild almost everything if configure.ac was touched, but that's an issue with autotools, and git just dumbly updates the files it is told to. (In particular, whether the commits you are switching between are from the same remote, or different remotes, or even from two trees which do not share a common parent — doesn't matter. Only the SHA1 of the contents is relevant.) Zbyszek ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 2:20 PM Jehan Pagès wrote: > On Wed, May 17, 2017 at 2:10 PM, Bastien Nocera wrote: > > I don't like the fact that the bug report and the merge request are > > separate. > > I don't like this either. This just makes no sense. > While I tend to agree, I do see a use case for the separation - multiple pull requests for a single issue, if a fix involves changes to multiple products. We currently often avoid the overhead of cloning the issue, and just attach all patches in the same report (say, a gsettings-desktop-schemas patch and the settings consumer, mutter/gnome-shell). That assumes that whoever applies the patches knows where the different bits go, and linkified commit hashes get messed up for non-matching products. That said, going from a attached-patches-only workflow to a branches+pull-requests-only workflow looks like swapping a toolbox full of hammers for a toolbox full of screwdrivers - the current workflow gets awkward with bigger patch sets, while pull requests add overhead that's fairly pointless when dealing with just a couple of patches (most issues really) ... Florian > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hi, On Wed, May 17, 2017 at 4:30 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, May 17, 2017 at 04:25:09PM +0200, Jehan Pagčs wrote: >> Hi, >> >> On Wed, May 17, 2017 at 2:44 PM, Carlos Soriano >> wrote: >> > Ah, I see what you mean now. But then you can rebase yourself in master >> > right? And the build time would be exactly the same no? >> >> Not sure what you mean. You don't want to rebase master under any >> circumstances (unless you rebase over origin/master to be able to push >> new commits of course). Anyway you usually won't be able to, since >> force push should be forbidden in master. And in any cases, this does >> not solve the issue I was talking about. >> >> What I want is rebasing a patch branch over master. And no, you cannot >> do it *from* master. You have to first checkout the branch so that you >> can rebase. Once you checked out, it's too late. Timestamps of various >> files are changed even though they didn't change between master and >> the rebased branch (but they changed in the in-between step). > > 'git cherry-pick ..branch' ? That's what I said I would likely do indeed a few emails ago. :P But I was answering about the problems of rebasing for timestamp as an alternative. cherry-pick still has a problem though. Unless the patch is trivial and looks like it's totally good from reading the diff (I would still do a quick build just to be sure), I don't really like to work on master with commits. You never know, some day, just a reflex, you git push… Hopefully it has never happened, but still. That's like working on a production server. That's why I like to work on master (so that I don't checkout outdated branches and have long builds), but with git apply as a first step. Jehan > Zbyszek > >> This is a very common git issue, you can look it up. :-) >> There are workarounds. The best one is to create a second working tree >> attached to the same local repository (git help worktree), to do the >> rebase there without touching the main working tree (the one you >> build). Then when you are done, you can checkout the rebased branch. >> This is possible and not too bad if you have to do it often, actually. >> Though it's still going through a lot of hoops. -- ZeMarmot open animation film http://film.zemarmot.net Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, 2017-05-17 at 10:06 -0400, Pat Suwalski wrote: > On 2017-05-16 07:10 PM, Mattias Bengtsson wrote: > > How did you install GitLab? We use the omnibus RPM package for > > CentOS > > and have had no dependency problems while upgrading from some 7.x > > release all the way to 9.1.x over the last few years. A lot come > > bundled in the omnibus package and the rest gets installed from the > > host operating system repositories. > > There's the difference. I don't trust the current omnibus package, so > I install from source. That decision is old, but at the time we > installed, there wasn't an omnibus package. There lies your problem I believe. I'm pretty sure this doesn't apply to GNOME. > A proper package would rely on system libraries only. Shipping software, targeting multiple Linux distributions is hard. > Anyway, this is getting off-topic. Using the only appropriate > install method for this package takes considerable effort. It is. I don't agree that a manual installation from source is "the only appropriate install method". That is a rather extreme position to take and one I'm sure our sysadmins doesn't hold. In short, I don't consider this an issue. Regards, Mattias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 04:25:09PM +0200, Jehan Pagès wrote: > Hi, > > On Wed, May 17, 2017 at 2:44 PM, Carlos Soriano > wrote: > > Ah, I see what you mean now. But then you can rebase yourself in master > > right? And the build time would be exactly the same no? > > Not sure what you mean. You don't want to rebase master under any > circumstances (unless you rebase over origin/master to be able to push > new commits of course). Anyway you usually won't be able to, since > force push should be forbidden in master. And in any cases, this does > not solve the issue I was talking about. > > What I want is rebasing a patch branch over master. And no, you cannot > do it *from* master. You have to first checkout the branch so that you > can rebase. Once you checked out, it's too late. Timestamps of various > files are changed even though they didn't change between master and > the rebased branch (but they changed in the in-between step). 'git cherry-pick ..branch' ? Zbyszek > This is a very common git issue, you can look it up. :-) > There are workarounds. The best one is to create a second working tree > attached to the same local repository (git help worktree), to do the > rebase there without touching the main working tree (the one you > build). Then when you are done, you can checkout the rebased branch. > This is possible and not too bad if you have to do it often, actually. > Though it's still going through a lot of hoops. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hi, On Wed, May 17, 2017 at 2:44 PM, Carlos Soriano wrote: > Ah, I see what you mean now. But then you can rebase yourself in master > right? And the build time would be exactly the same no? Not sure what you mean. You don't want to rebase master under any circumstances (unless you rebase over origin/master to be able to push new commits of course). Anyway you usually won't be able to, since force push should be forbidden in master. And in any cases, this does not solve the issue I was talking about. What I want is rebasing a patch branch over master. And no, you cannot do it *from* master. You have to first checkout the branch so that you can rebase. Once you checked out, it's too late. Timestamps of various files are changed even though they didn't change between master and the rebased branch (but they changed in the in-between step). This is a very common git issue, you can look it up. :-) There are workarounds. The best one is to create a second working tree attached to the same local repository (git help worktree), to do the rebase there without touching the main working tree (the one you build). Then when you are done, you can checkout the rebased branch. This is possible and not too bad if you have to do it often, actually. Though it's still going through a lot of hoops. Jehan > > Best regards, > Carlos Soriano > > Original Message -------- > Subject: Re: Proposal to deploy GitLab on gnome.org > Local Time: May 17, 2017 2:03 PM > UTC Time: May 17, 2017 12:03 PM > From: jehan.marmott...@gmail.com > To: Carlos Soriano > desktop-devel-list > > Hi, > > On Wed, May 17, 2017 at 1:50 PM, Carlos Soriano > wrote: >> So the main problem is autotools rebuilds everything when switching >> branches, even if the files didn't change? >> That's sounds very strange, autotools builds based on mtime of the files, >> and I checked this personally. > > Yes that's how autotools works. > >> Are you sure of the reason of this situation? Could it be because the >> branch >> is not rebased properly on top of the master branch (and the UI in GitLab >> will say so, so the contributor will need to do it because otherwise there >> is no fast forward merge anyway)? > > As I said in the email you answer, that's the most obvious reason, yes. :-) > Quoting myself: > >> actually for good reasons sometimes; for instance often the branch would >> be based on older commits than master HEAD > > The contributor will usually work on master and when one pushes, it > would be usually properly rebased (though while one worked, there > would usually be commits). Then patches are rarely immediately > reviewed the next few minutes! It may be days until we make time to do > so. You cannot ask a contributor to rebase the branch constantly and > immediately at the second when you want to review (they also have > their own schedules and not at our orders!). Even more if you review > it in several steps accross several days (which could happen for > complicated patch). > So no, we are usually the ones to rebase the contributor's branch. > That means, when we do rebase, it's too late. We already checked out > the branch, file timestamps changed and are not going to be reverted. > So the next `make` will be long, even if we rebased. > > GIMP has commits nearly every day, and very often many commits a day. > You cannot expect the contributor branches to be always up to date > with master. They will always be at least a few commits late. And even > more since we don't review straight away. > > Jehan > >> Best regards, >> Carlos Soriano >> >> Original Message >> Subject: Re: Proposal to deploy GitLab on gnome.org >> Local Time: May 17, 2017 1:41 PM >> UTC Time: May 17, 2017 11:41 AM >> From: jehan.marmott...@gmail.com >> To: Carlos Soriano >> desktop-devel-list >> >> Hi, >> >> On Wed, May 17, 2017 at 1:05 PM, Carlos Soriano >> wrote: >>> Hey Jehan, >>> >>> Knowing that core contributors like you and GIMP maintainers will have >>> access to the repo, are the sporadic contributions still many enough >>> enough >> >> Yes we still have regular one-time contributions. If anything, we are >> the ones who don't review them fast enough, though we have been >> getting better now and try to review external patches in a more timely >> fashion. >> >>> for fetching a remote being inconvenient? Is it because it takes >>> considerably more time to fetch a repo than download and applying a >>> patch? >> >> It does take more time indeed. But the most a
Re: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 01:49:21PM +0200, Sébastien Wilmet wrote: > By attaching a patch to a bugtracker ticket, we loose the information of > the parent commit: where the commit has been initially created in the > git history. If the patch is created by git format-patch, it contains the hash of the parent, so git knows the original parent. > I've already had the problem that git-bz apply fails (there was a > conflict), while git was able to resolve automatically the conflict when > rebasing the branch. 'git am -3' is the same as a rebase. Zbyszek ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, 2017-05-17 at 15:55 +0200, Bastien Nocera wrote: > If I'm a registered developer for the GNOME org, or that particular > module, I'd create my merge requests as wip branches in the main > repo?Or as branches in a separate repo that I have the control of? That would be up to you. Choose whichever you prefer? > What about developers that don't have GNOME commit access? Do they > fork, play in their corners and then create a merge request? Yes. > Does that merge request automatically create a branch in the upstream > repo? No. However the merge requests get added as refs in the remote git repo, so you can fetch them locally: https://docs.gitlab.com/ce/user/project/merge_requests/index.html#check out-locally-by-modifying-git-config-for-a-given-repository Alternatively, you can add a remote pointing to the fork, then fetch that to get the branch to merge. > > > > - git-bz attach equals to git push origin HEAD:fix2340issue, > > > > then click create merge request. > > > > > > Does this rewrite the commit message to include the PR or bug > > > number? > > > > No, as written in the wiki you write "Closes: $number" and it will > > handle things automatically. > > Of course some addition could be done to do the rewrite. > > Right, so that's not automated, and you can't know what to put in the > commit messages until you've create the merge request. Kind of a > chicken and egg problem. The merge request gets automatically closed when you merge it. The "Closes #number" is to associate the commit to the corresponding issue (and have it closed automatically), not the pull request. > > > Do we end up with separate merge requests and bug numbers, > > > segregating users and developers? And yes, clicking a button is a > > > problem when > > > > Yes. They are different concepts in this tool, which I though it > > was an improvement. The bug is more about the discussion of what is > > wanted/motivation/reasoning/design/etc., the merge request is about > > pure code. > > Not sure I would frame it as segregating users and developers > > though. > > As Jehan mentions, it is. Users filing bugs look at open issues, most > of the time, but don't look at merge requests at all. Searching in a repo will give results both in the code, the issues, the merge requests, the wiki, ... -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On 2017-05-16 07:10 PM, Mattias Bengtsson wrote: How did you install GitLab? We use the omnibus RPM package for CentOS and have had no dependency problems while upgrading from some 7.x release all the way to 9.1.x over the last few years. A lot come bundled in the omnibus package and the rest gets installed from the host operating system repositories. There's the difference. I don't trust the current omnibus package, so I install from source. That decision is old, but at the time we installed, there wasn't an omnibus package. In general, IMO it's not appropriate to run whatever random libraries they threw into their package. It's very large, and if you don't use the host specifically for gitlab, it gets tricky using it with port 80 and 443 with Apache. A proper package would rely on system libraries only. Could it be that Debian stable is just very old? I think it's proper to expect at least a 3 year lifecycle out of software that runs on a server, no? Can you imagine if Windows Server 2012 was considered too old for a package equivalent to Gitlab? That just wouldn't happen. Anyway, this is getting off-topic. Using the only appropriate install method for this package takes considerable effort. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, 2017-05-17 at 15:55 +0200, Bastien Nocera wrote: > On Wed, 2017-05-17 at 08:50 -0400, Carlos Soriano wrote: > > > Original Message > > > Subject: Re: Proposal to deploy GitLab on gnome.org > > > Local Time: May 17, 2017 2:10 PM > > > UTC Time: May 17, 2017 12:10 PM > > > From: had...@hadess.net > > > To: Carlos Soriano > > > desktop-devel-list@gnome.org > > > > > > On Wed, 2017-05-17 at 06:36 -0400, Carlos Soriano via desktop- > > > devel- > > > list wrote: > > > > Hey Bastien, > > > > > > > > Not sure if you read the wiki and the workflow we outlined in > > > > > > there, > > > > since we mention how this works. You will realize that's not > > > > necessary for you, neither a git-bz alternative since you will > > > > > > use > > > > just git: > > > > - git-bz apply equals to git checkout remoteBranch > > > > > > No, it doesn't. git-bz apply on a master or version branch will > > > allow > > > me to amend commits. It does everything but push. The above > > > doesn't > > > allow me to apply the same set of patches to a development and a > > > stable > > > branch for example. > > > > Doesn't git rebase do precisely this? > > I don't quite understand the workflow for users to create merge > requests with patches added, compared to my experiences with GitHub > for > example, so bear with me. > > If I'm a registered developer for the GNOME org, or that particular > module, I'd create my merge requests as wip branches in the main > repo?Or as branches in a separate repo that I have the control of? > > What about developers that don't have GNOME commit access? Do they > fork, play in their corners and then create a merge request? Does > that > merge request automatically create a branch in the upstream repo? How > do we stop merge request spam, or the unbounded growth of the repo > with > all the wip branches, if that's the case? The workflow page is hidden inside the conclusion on the original page that was posted: https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/GitLabWorkflows So it's unbounded growth as the merge request branches are created in the upstream repo. > Do you have a link to the tool and its documentation? There's nothing > in the Wiki linking to it, it just says "a tool exists". The tool is also linked from that page: https://github.com/NARKOZ/gitlab/ FWIW, we should get to a point where I don't need to open my browser to manage a merge request. I do this quite often directly from my bug mail to the terminal, copying the bug URL and appending it to git-bz. I don't think that anything else should be required, and most of it should be automated. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, 2017-05-17 at 08:50 -0400, Carlos Soriano wrote: > > Original Message > > Subject: Re: Proposal to deploy GitLab on gnome.org > > Local Time: May 17, 2017 2:10 PM > > UTC Time: May 17, 2017 12:10 PM > > From: had...@hadess.net > > To: Carlos Soriano > > desktop-devel-list@gnome.org > > > > On Wed, 2017-05-17 at 06:36 -0400, Carlos Soriano via desktop- > > devel- > > list wrote: > > > Hey Bastien, > > > > > > Not sure if you read the wiki and the workflow we outlined in > > there, > > > since we mention how this works. You will realize that's not > > > necessary for you, neither a git-bz alternative since you will > > use > > > just git: > > > - git-bz apply equals to git checkout remoteBranch > > > > No, it doesn't. git-bz apply on a master or version branch will > > allow > > me to amend commits. It does everything but push. The above doesn't > > allow me to apply the same set of patches to a development and a > > stable > > branch for example. > > Doesn't git rebase do precisely this? I don't quite understand the workflow for users to create merge requests with patches added, compared to my experiences with GitHub for example, so bear with me. If I'm a registered developer for the GNOME org, or that particular module, I'd create my merge requests as wip branches in the main repo?Or as branches in a separate repo that I have the control of? What about developers that don't have GNOME commit access? Do they fork, play in their corners and then create a merge request? Does that merge request automatically create a branch in the upstream repo? How do we stop merge request spam, or the unbounded growth of the repo with all the wip branches, if that's the case? > > > - git-bz attach equals to git push origin HEAD:fix2340issue, then > > > click create merge request. > > > > Does this rewrite the commit message to include the PR or bug > > number? > > No, as written in the wiki you write "Closes: $number" and it will > handle things automatically. > Of course some addition could be done to do the rewrite. Right, so that's not automated, and you can't know what to put in the commit messages until you've create the merge request. Kind of a chicken and egg problem. > > Do we end up with separate merge requests and bug numbers, > > segregating > > users and developers? And yes, clicking a button is a problem when > > Yes. They are different concepts in this tool, which I though it was > an improvement. The bug is more about the discussion of what is > wanted/motivation/reasoning/design/etc., the merge request is about > pure code. > Not sure I would frame it as segregating users and developers though. As Jehan mentions, it is. Users filing bugs look at open issues, most of the time, but don't look at merge requests at all. > > "git-bz file" took care of all the clicky stuff on the command- > > line. > > Right, that can be improved. > > > > And since you will have access to all projects...not need for > > your > > > own repo. > > > > > > Do you mean you don't like the extra step that is clicking once > > per > > > issue the "create merge request" button? > > > > I don't like the fact that the bug report and the merge request are > > separate. > > > > > If that's the case, why is the command line tool we mention in > > the > > > wiki not good for you? (you will need some alias for adapting it > > to > > > your needs, or maybe we can modify to make the "create merge > > request" > > > more comprehensible?) > > > > The only mention of a command-line tool says: > > "There is a CLI tool which allows a wide range of actions to be > > done > > from the command line, although it isn't particularly user > > friendly." > > which is a bit low on details to allow me to comment on it. > > It's rather vague, I agree. But you can explore it yourself, the > readme of the project is quite explanation. But I'm afraid is not up > to the expectations you have as it is right now. Would be good to > improve this of course. Do you have a link to the tool and its documentation? There's nothing in the Wiki linking to it, it just says "a tool exists". ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Original Message Subject: Re: Proposal to deploy GitLab on gnome.org Local Time: May 17, 2017 2:10 PM UTC Time: May 17, 2017 12:10 PM From: had...@hadess.net To: Carlos Soriano desktop-devel-list@gnome.org On Wed, 2017-05-17 at 06:36 -0400, Carlos Soriano via desktop-devel- list wrote: > Hey Bastien, > > Not sure if you read the wiki and the workflow we outlined in there, > since we mention how this works. You will realize that's not > necessary for you, neither a git-bz alternative since you will use > just git: > - git-bz apply equals to git checkout remoteBranch No, it doesn't. git-bz apply on a master or version branch will allow me to amend commits. It does everything but push. The above doesn't allow me to apply the same set of patches to a development and a stable branch for example. Doesn't git rebase do precisely this? > - git-bz attach equals to git push origin HEAD:fix2340issue, then > click create merge request. Does this rewrite the commit message to include the PR or bug number? No, as written in the wiki you write "Closes: $number" and it will handle things automatically. Of course some addition could be done to do the rewrite. Do we end up with separate merge requests and bug numbers, segregating users and developers? And yes, clicking a button is a problem when Yes. They are different concepts in this tool, which I though it was an improvement. The bug is more about the discussion of what is wanted/motivation/reasoning/design/etc., the merge request is about pure code. Not sure I would frame it as segregating users and developers though. "git-bz file" took care of all the clicky stuff on the command-line. Right, that can be improved. > And since you will have access to all projects...not need for your > own repo. > > Do you mean you don't like the extra step that is clicking once per > issue the "create merge request" button? I don't like the fact that the bug report and the merge request are separate. > If that's the case, why is the command line tool we mention in the > wiki not good for you? (you will need some alias for adapting it to > your needs, or maybe we can modify to make the "create merge request" > more comprehensible?) The only mention of a command-line tool says: "There is a CLI tool which allows a wide range of actions to be done from the command line, although it isn't particularly user friendly." which is a bit low on details to allow me to comment on it. It's rather vague, I agree. But you can explore it yourself, the readme of the project is quite explanation. But I'm afraid is not up to the expectations you have as it is right now. Would be good to improve this of course.___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Ah, I see what you mean now. But then you can rebase yourself in master right? And the build time would be exactly the same no? Best regards, Carlos Soriano Original Message Subject: Re: Proposal to deploy GitLab on gnome.org Local Time: May 17, 2017 2:03 PM UTC Time: May 17, 2017 12:03 PM From: jehan.marmott...@gmail.com To: Carlos Soriano desktop-devel-list Hi, On Wed, May 17, 2017 at 1:50 PM, Carlos Soriano wrote: > So the main problem is autotools rebuilds everything when switching > branches, even if the files didn't change? > That's sounds very strange, autotools builds based on mtime of the files, > and I checked this personally. Yes that's how autotools works. > Are you sure of the reason of this situation? Could it be because the branch > is not rebased properly on top of the master branch (and the UI in GitLab > will say so, so the contributor will need to do it because otherwise there > is no fast forward merge anyway)? As I said in the email you answer, that's the most obvious reason, yes. :-) Quoting myself: > actually for good reasons sometimes; for instance often the branch would be > based on older commits than master HEAD The contributor will usually work on master and when one pushes, it would be usually properly rebased (though while one worked, there would usually be commits). Then patches are rarely immediately reviewed the next few minutes! It may be days until we make time to do so. You cannot ask a contributor to rebase the branch constantly and immediately at the second when you want to review (they also have their own schedules and not at our orders!). Even more if you review it in several steps accross several days (which could happen for complicated patch). So no, we are usually the ones to rebase the contributor's branch. That means, when we do rebase, it's too late. We already checked out the branch, file timestamps changed and are not going to be reverted. So the next `make` will be long, even if we rebased. GIMP has commits nearly every day, and very often many commits a day. You cannot expect the contributor branches to be always up to date with master. They will always be at least a few commits late. And even more since we don't review straight away. Jehan > Best regards, > Carlos Soriano > > ---- Original Message > Subject: Re: Proposal to deploy GitLab on gnome.org > Local Time: May 17, 2017 1:41 PM > UTC Time: May 17, 2017 11:41 AM > From: jehan.marmott...@gmail.com > To: Carlos Soriano > desktop-devel-list > > Hi, > > On Wed, May 17, 2017 at 1:05 PM, Carlos Soriano > wrote: >> Hey Jehan, >> >> Knowing that core contributors like you and GIMP maintainers will have >> access to the repo, are the sporadic contributions still many enough >> enough > > Yes we still have regular one-time contributions. If anything, we are > the ones who don't review them fast enough, though we have been > getting better now and try to review external patches in a more timely > fashion. > >> for fetching a remote being inconvenient? Is it because it takes >> considerably more time to fetch a repo than download and applying a patch? > > It does take more time indeed. But the most annoying part is having to > switch branches. When you checkout another branch, autotools gets > confused and will re-build much more than what it should have if I > just applied the patch (actually for good reasons sometimes; for > instance often the branch would be based on older commits than master > HEAD). So you transform a 10-second builds into a 10-minute build > (this is *not* exageration; if the patch is on a plugin or even on > most of the core for instance, the rebuild will be very quick; but if > it starts rebuilding libgimp*, then we are doomed!). > When it's a separate remote, I even wonder if git will still make the > link between the 2 remotes? Will it try to rebuild everything from > scratch? This would be absolutely terrible. > > What I would do to test a patch is: > - wget > - git apply (this won't make a commit so I won't push it by mistake) > - test it. If it looks good… > - git checkout -- . > - git am > - Optionally fix minor stuff and amend, edit the commit message if needed. > - git push > > If the patch looks really simple and obviously good from the basic > visual review, I would just ignore the `git apply` steps. Just git am, > test, push. This can all be done in 15 minutes. In these 15 minutes, > the procedure and rebuild could take just 2 or 3 minutes; the 10+ > additional minutes are because I do thorough tests even for small > patches. > > If I am forced to checkout another branch, the procedure + build would > be suddenly extremely long and boring. >
Re: Proposal to deploy GitLab on gnome.org
Hi, On Wed, May 17, 2017 at 2:10 PM, Bastien Nocera wrote: > On Wed, 2017-05-17 at 06:36 -0400, Carlos Soriano via desktop-devel- > list wrote: >> Do you mean you don't like the extra step that is clicking once per >> issue the "create merge request" button? > > I don't like the fact that the bug report and the merge request are > separate. I don't like this either. This just makes no sense. Very often a bug report could become a merge request (someone — either the original bug reporter or someone else — could bring a patch later) or a merge request could become a bug report (if the original patch is not right; yet the bug actually exists, we acknowledge it and don't want to just get rid of the report because we would forget about the bug). In other words, they are the same things. A "merge request" is simply a bug report where a patch has been proposed. I don't understand why they had to make 2 concepts. I didn't mention it earlier because I imagined that would never change anyway and I would just have to live with this strange separation. Gitlab just obviously tries to do the same as github here. But since you mention it. Yeah I also think this is a completely broken workflow. Jehan -- ZeMarmot open animation film http://film.zemarmot.net Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, 2017-05-17 at 06:36 -0400, Carlos Soriano via desktop-devel- list wrote: > Hey Bastien, > > Not sure if you read the wiki and the workflow we outlined in there, > since we mention how this works. You will realize that's not > necessary for you, neither a git-bz alternative since you will use > just git: > - git-bz apply equals to git checkout remoteBranch No, it doesn't. git-bz apply on a master or version branch will allow me to amend commits. It does everything but push. The above doesn't allow me to apply the same set of patches to a development and a stable branch for example. > - git-bz attach equals to git push origin HEAD:fix2340issue, then > click create merge request. Does this rewrite the commit message to include the PR or bug number? Do we end up with separate merge requests and bug numbers, segregating users and developers? And yes, clicking a button is a problem when "git-bz file" took care of all the clicky stuff on the command-line. > And since you will have access to all projects...not need for your > own repo. > > Do you mean you don't like the extra step that is clicking once per > issue the "create merge request" button? I don't like the fact that the bug report and the merge request are separate. > If that's the case, why is the command line tool we mention in the > wiki not good for you? (you will need some alias for adapting it to > your needs, or maybe we can modify to make the "create merge request" > more comprehensible?) The only mention of a command-line tool says: "There is a CLI tool which allows a wide range of actions to be done from the command line, although it isn't particularly user friendly." which is a bit low on details to allow me to comment on it. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hi, On Wed, May 17, 2017 at 1:59 PM, Bastien Nocera wrote: > On Wed, 2017-05-17 at 13:54 +0200, Jehan Pagès wrote: >> Hi, >> >> On Wed, May 17, 2017 at 1:49 PM, Sébastien Wilmet >> wrote: >> > On Wed, May 17, 2017 at 11:45:26AM +0200, Bastien Nocera wrote: >> > > On Wed, 2017-05-17 at 11:33 +0200, Sébastien Wilmet wrote: >> > > > >> > > >> > > >> > > > Most developers are more familiar with the GitHub workflow, I >> > > > think >> > > > it's >> > > > an easier workflow than attaching a patch to a bugtracker >> > > > ticket. >> > > > Once >> > > > the contributor has pushed a branch on the fork repo, all the >> > > > rest >> > > > can >> > > > be done from the web interface by clicking on some buttons. >> > > >> > > I absolutely hate this workflow, fwiw. I prefer being able to run >> > > "git- >> > > bz" to both create and apply patches, rather than keeping a clone >> > > with >> > > a bunch of patches in my own org, or remembering the commands to >> > > push a >> > > repo to my own repo from the upstream clone. >> > > >> > > I hope there will be a git-bz equivalent available. >> > >> > By attaching a patch to a bugtracker ticket, we loose the >> > information of >> > the parent commit: where the commit has been initially created in >> > the >> > git history. >> > >> > I've already had the problem that git-bz apply fails (there was a >> > conflict), while git was able to resolve automatically the conflict >> > when >> > rebasing the branch. >> >> Right. Patches are not a perfect workflow either. It's just nice and >> simple. >> >> Another problem of patches is that the email in it is not validated >> (it's just a text file). I don't think this has ever been a problem >> for us, but still theoretically: will gitlab validate contributor's >> email and make sure the email in the commit are the same as the one >> they validated in their profile? I assume it will do this, just >> checking. Because it would be good for minimal author check. > > That'd be broken. I wouldn't want to use the same email for the > bug/issue tracker and the code I commit. It also wouldn't work for > folks who want to use personal/work mail depending on the area of > contribution, or file pull requests with non-GNOME contributors. Often these kind of web software allow you to register several emails. Can't gitlab do this? Anyway that's just a detail. Previous workflows were already broken on this topic anyway. I just know that this is one of the problem (reliability of authorship and contact) of patch files on bug trackers and I was wondering if gitlab would fix it. Apparently not. Jehan -- ZeMarmot open animation film http://film.zemarmot.net Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hi, On Wed, May 17, 2017 at 1:50 PM, Carlos Soriano wrote: > So the main problem is autotools rebuilds everything when switching > branches, even if the files didn't change? > That's sounds very strange, autotools builds based on mtime of the files, > and I checked this personally. Yes that's how autotools works. > Are you sure of the reason of this situation? Could it be because the branch > is not rebased properly on top of the master branch (and the UI in GitLab > will say so, so the contributor will need to do it because otherwise there > is no fast forward merge anyway)? As I said in the email you answer, that's the most obvious reason, yes. :-) Quoting myself: > actually for good reasons sometimes; for instance often the branch would be > based on older commits than master HEAD The contributor will usually work on master and when one pushes, it would be usually properly rebased (though while one worked, there would usually be commits). Then patches are rarely immediately reviewed the next few minutes! It may be days until we make time to do so. You cannot ask a contributor to rebase the branch constantly and immediately at the second when you want to review (they also have their own schedules and not at our orders!). Even more if you review it in several steps accross several days (which could happen for complicated patch). So no, we are usually the ones to rebase the contributor's branch. That means, when we do rebase, it's too late. We already checked out the branch, file timestamps changed and are not going to be reverted. So the next `make` will be long, even if we rebased. GIMP has commits nearly every day, and very often many commits a day. You cannot expect the contributor branches to be always up to date with master. They will always be at least a few commits late. And even more since we don't review straight away. Jehan > Best regards, > Carlos Soriano > > ---- Original Message > Subject: Re: Proposal to deploy GitLab on gnome.org > Local Time: May 17, 2017 1:41 PM > UTC Time: May 17, 2017 11:41 AM > From: jehan.marmott...@gmail.com > To: Carlos Soriano > desktop-devel-list > > Hi, > > On Wed, May 17, 2017 at 1:05 PM, Carlos Soriano > wrote: >> Hey Jehan, >> >> Knowing that core contributors like you and GIMP maintainers will have >> access to the repo, are the sporadic contributions still many enough >> enough > > Yes we still have regular one-time contributions. If anything, we are > the ones who don't review them fast enough, though we have been > getting better now and try to review external patches in a more timely > fashion. > >> for fetching a remote being inconvenient? Is it because it takes >> considerably more time to fetch a repo than download and applying a patch? > > It does take more time indeed. But the most annoying part is having to > switch branches. When you checkout another branch, autotools gets > confused and will re-build much more than what it should have if I > just applied the patch (actually for good reasons sometimes; for > instance often the branch would be based on older commits than master > HEAD). So you transform a 10-second builds into a 10-minute build > (this is *not* exageration; if the patch is on a plugin or even on > most of the core for instance, the rebuild will be very quick; but if > it starts rebuilding libgimp*, then we are doomed!). > When it's a separate remote, I even wonder if git will still make the > link between the 2 remotes? Will it try to rebuild everything from > scratch? This would be absolutely terrible. > > What I would do to test a patch is: > - wget > - git apply (this won't make a commit so I won't push it by mistake) > - test it. If it looks good… > - git checkout -- . > - git am > - Optionally fix minor stuff and amend, edit the commit message if needed. > - git push > > If the patch looks really simple and obviously good from the basic > visual review, I would just ignore the `git apply` steps. Just git am, > test, push. This can all be done in 15 minutes. In these 15 minutes, > the procedure and rebuild could take just 2 or 3 minutes; the 10+ > additional minutes are because I do thorough tests even for small > patches. > > If I am forced to checkout another branch, the procedure + build would > be suddenly extremely long and boring. > > Now I don't say that there is no alternative. I guess what I would do > is: fetch the remote (don't checkout it), then cherry-pick only the > commit. This way, I avoid a stupid rebuild of useless stuff. It's > still not as good as previously since it will still take longer, and I > lose the `git apply` step, which is the step which allows me to wor
Re: Proposal to deploy GitLab on gnome.org
On Wed, 2017-05-17 at 13:54 +0200, Jehan Pagès wrote: > Hi, > > On Wed, May 17, 2017 at 1:49 PM, Sébastien Wilmet > wrote: > > On Wed, May 17, 2017 at 11:45:26AM +0200, Bastien Nocera wrote: > > > On Wed, 2017-05-17 at 11:33 +0200, Sébastien Wilmet wrote: > > > > > > > > > > > > > > Most developers are more familiar with the GitHub workflow, I > > > > think > > > > it's > > > > an easier workflow than attaching a patch to a bugtracker > > > > ticket. > > > > Once > > > > the contributor has pushed a branch on the fork repo, all the > > > > rest > > > > can > > > > be done from the web interface by clicking on some buttons. > > > > > > I absolutely hate this workflow, fwiw. I prefer being able to run > > > "git- > > > bz" to both create and apply patches, rather than keeping a clone > > > with > > > a bunch of patches in my own org, or remembering the commands to > > > push a > > > repo to my own repo from the upstream clone. > > > > > > I hope there will be a git-bz equivalent available. > > > > By attaching a patch to a bugtracker ticket, we loose the > > information of > > the parent commit: where the commit has been initially created in > > the > > git history. > > > > I've already had the problem that git-bz apply fails (there was a > > conflict), while git was able to resolve automatically the conflict > > when > > rebasing the branch. > > Right. Patches are not a perfect workflow either. It's just nice and > simple. > > Another problem of patches is that the email in it is not validated > (it's just a text file). I don't think this has ever been a problem > for us, but still theoretically: will gitlab validate contributor's > email and make sure the email in the commit are the same as the one > they validated in their profile? I assume it will do this, just > checking. Because it would be good for minimal author check. That'd be broken. I wouldn't want to use the same email for the bug/issue tracker and the code I commit. It also wouldn't work for folks who want to use personal/work mail depending on the area of contribution, or file pull requests with non-GNOME contributors. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, 2017-05-17 at 13:49 +0200, Sébastien Wilmet wrote: > On Wed, May 17, 2017 at 11:45:26AM +0200, Bastien Nocera wrote: > > On Wed, 2017-05-17 at 11:33 +0200, Sébastien Wilmet wrote: > > > > > > > > > > Most developers are more familiar with the GitHub workflow, I > > > think > > > it's > > > an easier workflow than attaching a patch to a bugtracker ticket. > > > Once > > > the contributor has pushed a branch on the fork repo, all the > > > rest > > > can > > > be done from the web interface by clicking on some buttons. > > > > I absolutely hate this workflow, fwiw. I prefer being able to run > > "git- > > bz" to both create and apply patches, rather than keeping a clone > > with > > a bunch of patches in my own org, or remembering the commands to > > push a > > repo to my own repo from the upstream clone. > > > > I hope there will be a git-bz equivalent available. > > By attaching a patch to a bugtracker ticket, we loose the information > of > the parent commit: where the commit has been initially created in the > git history. > > I've already had the problem that git-bz apply fails (there was a > conflict), while git was able to resolve automatically the conflict > when > rebasing the branch. That's unsurprising. Presumably, the patch provider can easily rebase, as one probably should in case of conflict anyway. I don't see the gain here. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hi, On Wed, May 17, 2017 at 1:49 PM, Sébastien Wilmet wrote: > On Wed, May 17, 2017 at 11:45:26AM +0200, Bastien Nocera wrote: >> On Wed, 2017-05-17 at 11:33 +0200, Sébastien Wilmet wrote: >> > >> >> > Most developers are more familiar with the GitHub workflow, I think >> > it's >> > an easier workflow than attaching a patch to a bugtracker ticket. >> > Once >> > the contributor has pushed a branch on the fork repo, all the rest >> > can >> > be done from the web interface by clicking on some buttons. >> >> I absolutely hate this workflow, fwiw. I prefer being able to run "git- >> bz" to both create and apply patches, rather than keeping a clone with >> a bunch of patches in my own org, or remembering the commands to push a >> repo to my own repo from the upstream clone. >> >> I hope there will be a git-bz equivalent available. > > By attaching a patch to a bugtracker ticket, we loose the information of > the parent commit: where the commit has been initially created in the > git history. > > I've already had the problem that git-bz apply fails (there was a > conflict), while git was able to resolve automatically the conflict when > rebasing the branch. Right. Patches are not a perfect workflow either. It's just nice and simple. Another problem of patches is that the email in it is not validated (it's just a text file). I don't think this has ever been a problem for us, but still theoretically: will gitlab validate contributor's email and make sure the email in the commit are the same as the one they validated in their profile? I assume it will do this, just checking. Because it would be good for minimal author check. Jehan > -- > Sébastien -- ZeMarmot open animation film http://film.zemarmot.net Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hi > On 17 May 2017, at 12:33, Sébastien Wilmet wrote: > > On Tue, May 16, 2017 at 11:15:51PM +0900, Tristan Van Berkom wrote: >> I don't share your optimism about gitlab bug tracking, nor do I share >> in the mentioned frustration with bugzilla. > > Me too, I like bugzilla (but not for doing code reviews). > > What would be the pain points if GitLab is used only for git and code > reviews, and we keep bugzilla for the bug tracker? Have you considered > that option? > > We would loose automatic links between bug tracker tickets and pull > requests. When a pull request is merged, we would need to close manually > the bugzilla ticket if everything is done. And when someone requests a > pull, the person would need to add a comment manually on bugzilla so > that other people know that the bug is being worked on. > in github you can setup “hooks" and make it close bugzilla bugs when referenced in a commit message ("Fixes bug #12345") merged to master, so I guess gitlab should have something similar. Not that I like bugzilla :), but it’s true the issues thing in github and, I guess, gitlab seem to be very basic compared to what you can do in bugzilla. Rodrigo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
So the main problem is autotools rebuilds everything when switching branches, even if the files didn't change? That's sounds very strange, autotools builds based on mtime of the files, and I checked this personally. Are you sure of the reason of this situation? Could it be because the branch is not rebased properly on top of the master branch (and the UI in GitLab will say so, so the contributor will need to do it because otherwise there is no fast forward merge anyway)? Best regards, Carlos Soriano Original Message Subject: Re: Proposal to deploy GitLab on gnome.org Local Time: May 17, 2017 1:41 PM UTC Time: May 17, 2017 11:41 AM From: jehan.marmott...@gmail.com To: Carlos Soriano desktop-devel-list Hi, On Wed, May 17, 2017 at 1:05 PM, Carlos Soriano wrote: > Hey Jehan, > > Knowing that core contributors like you and GIMP maintainers will have > access to the repo, are the sporadic contributions still many enough enough Yes we still have regular one-time contributions. If anything, we are the ones who don't review them fast enough, though we have been getting better now and try to review external patches in a more timely fashion. > for fetching a remote being inconvenient? Is it because it takes > considerably more time to fetch a repo than download and applying a patch? It does take more time indeed. But the most annoying part is having to switch branches. When you checkout another branch, autotools gets confused and will re-build much more than what it should have if I just applied the patch (actually for good reasons sometimes; for instance often the branch would be based on older commits than master HEAD). So you transform a 10-second builds into a 10-minute build (this is *not* exageration; if the patch is on a plugin or even on most of the core for instance, the rebuild will be very quick; but if it starts rebuilding libgimp*, then we are doomed!). When it's a separate remote, I even wonder if git will still make the link between the 2 remotes? Will it try to rebuild everything from scratch? This would be absolutely terrible. What I would do to test a patch is: - wget - git apply (this won't make a commit so I won't push it by mistake) - test it. If it looks good… - git checkout -- . - git am - Optionally fix minor stuff and amend, edit the commit message if needed. - git push If the patch looks really simple and obviously good from the basic visual review, I would just ignore the `git apply` steps. Just git am, test, push. This can all be done in 15 minutes. In these 15 minutes, the procedure and rebuild could take just 2 or 3 minutes; the 10+ additional minutes are because I do thorough tests even for small patches. If I am forced to checkout another branch, the procedure + build would be suddenly extremely long and boring. Now I don't say that there is no alternative. I guess what I would do is: fetch the remote (don't checkout it), then cherry-pick only the commit. This way, I avoid a stupid rebuild of useless stuff. It's still not as good as previously since it will still take longer, and I lose the `git apply` step, which is the step which allows me to work and test patches on master without fearing making a stupid push mistake. Now here too there are workarounds, like I could git reset immediately to get rid of the commit (still keeping the code), but that makes a lot of workarounds now! ;P So yeah, that's not as bright and simple as it could be. Jehan > Cheers, > Carlos Soriano > > Original Message > Subject: Re: Proposal to deploy GitLab on gnome.org > Local Time: May 17, 2017 12:47 PM > UTC Time: May 17, 2017 10:47 AM > From: jehan.marmott...@gmail.com > To: Tristan Van Berkom , > desktop-devel-list > > Hi, > > On Wed, May 17, 2017 at 12:33 PM, Sébastien Wilmet > wrote: >> On Tue, May 16, 2017 at 11:15:51PM +0900, Tristan Van Berkom wrote: >>> I don't share your optimism about gitlab bug tracking, nor do I share >>> in the mentioned frustration with bugzilla. >> >> Me too, I like bugzilla (but not for doing code reviews). >> >> What would be the pain points if GitLab is used only for git and code >> reviews, and we keep bugzilla for the bug tracker? Have you considered >> that option? >> >> We would loose automatic links between bug tracker tickets and pull >> requests. When a pull request is merged, we would need to close manually >> the bugzilla ticket if everything is done. And when someone requests a >> pull, the person would need to add a comment manually on bugzilla so >> that other people know that the bug is being worked on. >> >> Mmh I think that's not practical if the links must be done manually. >> >> Maintaining the bugzilla instance would also require sysadmin time, and >
Re: Proposal to deploy GitLab on gnome.org
Hi, On Wed, May 17, 2017 at 1:23 PM, Christoph Reiter wrote: > On Wed, May 17, 2017 at 12:47 PM, Jehan Pagès > wrote: >> The only thing I am annoyed at is this forking workflow. Both as a >> contributor, and as a code committer/reviewer. Having to fetch a new >> remote for every single-commit contribution out there is terrible. > > In case you didn't know, just like with github you can fetch the PRs > from the main remote if you adjust the git config accordingly: > https://docs.gitlab.com/ce/user/project/merge_requests/#checkout-merge-requests-locally > > $ git fetch > $ git branch -a # look for PR branch > $ git checkout origin/merge-requests/42 > $ git checkout master I didn't know about this. That is indeed not too bad. I would still cherry-pick the merge-requests commits into my current branch so that the next make does not try to rebuild too much and for me not to waste 20 minutes. But that's still a good feature. Jehan -- ZeMarmot open animation film http://film.zemarmot.net Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 11:45:26AM +0200, Bastien Nocera wrote: > On Wed, 2017-05-17 at 11:33 +0200, Sébastien Wilmet wrote: > > > > > Most developers are more familiar with the GitHub workflow, I think > > it's > > an easier workflow than attaching a patch to a bugtracker ticket. > > Once > > the contributor has pushed a branch on the fork repo, all the rest > > can > > be done from the web interface by clicking on some buttons. > > I absolutely hate this workflow, fwiw. I prefer being able to run "git- > bz" to both create and apply patches, rather than keeping a clone with > a bunch of patches in my own org, or remembering the commands to push a > repo to my own repo from the upstream clone. > > I hope there will be a git-bz equivalent available. By attaching a patch to a bugtracker ticket, we loose the information of the parent commit: where the commit has been initially created in the git history. I've already had the problem that git-bz apply fails (there was a conflict), while git was able to resolve automatically the conflict when rebasing the branch. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hi, On Wed, May 17, 2017 at 1:05 PM, Carlos Soriano wrote: > Hey Jehan, > > Knowing that core contributors like you and GIMP maintainers will have > access to the repo, are the sporadic contributions still many enough enough Yes we still have regular one-time contributions. If anything, we are the ones who don't review them fast enough, though we have been getting better now and try to review external patches in a more timely fashion. > for fetching a remote being inconvenient? Is it because it takes > considerably more time to fetch a repo than download and applying a patch? It does take more time indeed. But the most annoying part is having to switch branches. When you checkout another branch, autotools gets confused and will re-build much more than what it should have if I just applied the patch (actually for good reasons sometimes; for instance often the branch would be based on older commits than master HEAD). So you transform a 10-second builds into a 10-minute build (this is *not* exageration; if the patch is on a plugin or even on most of the core for instance, the rebuild will be very quick; but if it starts rebuilding libgimp*, then we are doomed!). When it's a separate remote, I even wonder if git will still make the link between the 2 remotes? Will it try to rebuild everything from scratch? This would be absolutely terrible. What I would do to test a patch is: - wget - git apply (this won't make a commit so I won't push it by mistake) - test it. If it looks good… - git checkout -- . - git am - Optionally fix minor stuff and amend, edit the commit message if needed. - git push If the patch looks really simple and obviously good from the basic visual review, I would just ignore the `git apply` steps. Just git am, test, push. This can all be done in 15 minutes. In these 15 minutes, the procedure and rebuild could take just 2 or 3 minutes; the 10+ additional minutes are because I do thorough tests even for small patches. If I am forced to checkout another branch, the procedure + build would be suddenly extremely long and boring. Now I don't say that there is no alternative. I guess what I would do is: fetch the remote (don't checkout it), then cherry-pick only the commit. This way, I avoid a stupid rebuild of useless stuff. It's still not as good as previously since it will still take longer, and I lose the `git apply` step, which is the step which allows me to work and test patches on master without fearing making a stupid push mistake. Now here too there are workarounds, like I could git reset immediately to get rid of the commit (still keeping the code), but that makes a lot of workarounds now! ;P So yeah, that's not as bright and simple as it could be. Jehan > Cheers, > Carlos Soriano > > ---- Original Message > Subject: Re: Proposal to deploy GitLab on gnome.org > Local Time: May 17, 2017 12:47 PM > UTC Time: May 17, 2017 10:47 AM > From: jehan.marmott...@gmail.com > To: Tristan Van Berkom , > desktop-devel-list > > Hi, > > On Wed, May 17, 2017 at 12:33 PM, Sébastien Wilmet > wrote: >> On Tue, May 16, 2017 at 11:15:51PM +0900, Tristan Van Berkom wrote: >>> I don't share your optimism about gitlab bug tracking, nor do I share >>> in the mentioned frustration with bugzilla. >> >> Me too, I like bugzilla (but not for doing code reviews). >> >> What would be the pain points if GitLab is used only for git and code >> reviews, and we keep bugzilla for the bug tracker? Have you considered >> that option? >> >> We would loose automatic links between bug tracker tickets and pull >> requests. When a pull request is merged, we would need to close manually >> the bugzilla ticket if everything is done. And when someone requests a >> pull, the person would need to add a comment manually on bugzilla so >> that other people know that the bug is being worked on. >> >> Mmh I think that's not practical if the links must be done manually. >> >> Maintaining the bugzilla instance would also require sysadmin time, and >> development efforts to rebase the patches to new bugzilla versions. >> >> I don't know, I'm excited about the idea to use a similar contribution >> workflow as in GitHub, but less excited about having a bug tracker >> similar to the GitHub one. (I've never used GitLab, but I'm familiar >> with GitHub, and after seeing some screenshots it seems that the GitLab >> bug tracker is similar to GitHub's). > > I like bugzilla too and guess it probably does more than github/lab > bug trackers. But I also know there are annoying parts. Like someone > noted that searching projects in the long list of GNOME projects is > terrible experience (I even have a browser keyword so
Re: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 12:47 PM, Jehan Pagès wrote: > The only thing I am annoyed at is this forking workflow. Both as a > contributor, and as a code committer/reviewer. Having to fetch a new > remote for every single-commit contribution out there is terrible. In case you didn't know, just like with github you can fetch the PRs from the main remote if you adjust the git config accordingly: https://docs.gitlab.com/ce/user/project/merge_requests/#checkout-merge-requests-locally $ git fetch $ git branch -a # look for PR branch $ git checkout origin/merge-requests/42 $ git checkout master ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hey Jehan, Knowing that core contributors like you and GIMP maintainers will have access to the repo, are the sporadic contributions still many enough enough for fetching a remote being inconvenient? Is it because it takes considerably more time to fetch a repo than download and applying a patch? Cheers, Carlos Soriano Original Message Subject: Re: Proposal to deploy GitLab on gnome.org Local Time: May 17, 2017 12:47 PM UTC Time: May 17, 2017 10:47 AM From: jehan.marmott...@gmail.com To: Tristan Van Berkom , desktop-devel-list Hi, On Wed, May 17, 2017 at 12:33 PM, Sébastien Wilmet wrote: > On Tue, May 16, 2017 at 11:15:51PM +0900, Tristan Van Berkom wrote: >> I don't share your optimism about gitlab bug tracking, nor do I share >> in the mentioned frustration with bugzilla. > > Me too, I like bugzilla (but not for doing code reviews). > > What would be the pain points if GitLab is used only for git and code > reviews, and we keep bugzilla for the bug tracker? Have you considered > that option? > > We would loose automatic links between bug tracker tickets and pull > requests. When a pull request is merged, we would need to close manually > the bugzilla ticket if everything is done. And when someone requests a > pull, the person would need to add a comment manually on bugzilla so > that other people know that the bug is being worked on. > > Mmh I think that's not practical if the links must be done manually. > > Maintaining the bugzilla instance would also require sysadmin time, and > development efforts to rebase the patches to new bugzilla versions. > > I don't know, I'm excited about the idea to use a similar contribution > workflow as in GitHub, but less excited about having a bug tracker > similar to the GitHub one. (I've never used GitLab, but I'm familiar > with GitHub, and after seeing some screenshots it seems that the GitLab > bug tracker is similar to GitHub's). I like bugzilla too and guess it probably does more than github/lab bug trackers. But I also know there are annoying parts. Like someone noted that searching projects in the long list of GNOME projects is terrible experience (I even have a browser keyword so that I don't have to do this anymore, because it was so annoying; but obviously new contributors would not have such shortcuts). Also the fact that the reports actually have less options is not bad IMO. One gets lost in all these bz options. Simplicity is good sometimes. :-) gitlab has cool features too, like it's much easier to mention someone to have them take a look at a report, for instance. And finally, as you say, code review is much better. I like that you can annotate line per line (easier for the reviewee in particular to understand our review). Bottom line: I definitely don't think we should keep both bz and gitlab in the end. The only thing I am annoyed at is this forking workflow. Both as a contributor, and as a code committer/reviewer. Having to fetch a new remote for every single-commit contribution out there is terrible. Jehan > -- > Sébastien > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- ZeMarmot open animation film http://film.zemarmot.net Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hi, On Wed, May 17, 2017 at 12:33 PM, Sébastien Wilmet wrote: > On Tue, May 16, 2017 at 11:15:51PM +0900, Tristan Van Berkom wrote: >> I don't share your optimism about gitlab bug tracking, nor do I share >> in the mentioned frustration with bugzilla. > > Me too, I like bugzilla (but not for doing code reviews). > > What would be the pain points if GitLab is used only for git and code > reviews, and we keep bugzilla for the bug tracker? Have you considered > that option? > > We would loose automatic links between bug tracker tickets and pull > requests. When a pull request is merged, we would need to close manually > the bugzilla ticket if everything is done. And when someone requests a > pull, the person would need to add a comment manually on bugzilla so > that other people know that the bug is being worked on. > > Mmh I think that's not practical if the links must be done manually. > > Maintaining the bugzilla instance would also require sysadmin time, and > development efforts to rebase the patches to new bugzilla versions. > > I don't know, I'm excited about the idea to use a similar contribution > workflow as in GitHub, but less excited about having a bug tracker > similar to the GitHub one. (I've never used GitLab, but I'm familiar > with GitHub, and after seeing some screenshots it seems that the GitLab > bug tracker is similar to GitHub's). I like bugzilla too and guess it probably does more than github/lab bug trackers. But I also know there are annoying parts. Like someone noted that searching projects in the long list of GNOME projects is terrible experience (I even have a browser keyword so that I don't have to do this anymore, because it was so annoying; but obviously new contributors would not have such shortcuts). Also the fact that the reports actually have less options is not bad IMO. One gets lost in all these bz options. Simplicity is good sometimes. :-) gitlab has cool features too, like it's much easier to mention someone to have them take a look at a report, for instance. And finally, as you say, code review is much better. I like that you can annotate line per line (easier for the reviewee in particular to understand our review). Bottom line: I definitely don't think we should keep both bz and gitlab in the end. The only thing I am annoyed at is this forking workflow. Both as a contributor, and as a code committer/reviewer. Having to fetch a new remote for every single-commit contribution out there is terrible. Jehan > -- > Sébastien > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- ZeMarmot open animation film http://film.zemarmot.net Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hey Bastien, Not sure if you read the wiki and the workflow we outlined in there, since we mention how this works. You will realize that's not necessary for you, neither a git-bz alternative since you will use just git: - git-bz apply equals to git checkout remoteBranch - git-bz attach equals to git push origin HEAD:fix2340issue, then click create merge request. And since you will have access to all projects...not need for your own repo. Do you mean you don't like the extra step that is clicking once per issue the "create merge request" button? If that's the case, why is the command line tool we mention in the wiki not good for you? (you will need some alias for adapting it to your needs, or maybe we can modify to make the "create merge request" more comprehensible?) Best regards, Carlos Soriano Original Message ---- Subject: Re: Proposal to deploy GitLab on gnome.org Local Time: May 17, 2017 11:45 AM UTC Time: May 17, 2017 9:45 AM From: had...@hadess.net To: Sébastien Wilmet , Jehan Pagès desktop-devel-list@gnome.org On Wed, 2017-05-17 at 11:33 +0200, Sébastien Wilmet wrote: > > Most developers are more familiar with the GitHub workflow, I think > it's > an easier workflow than attaching a patch to a bugtracker ticket. > Once > the contributor has pushed a branch on the fork repo, all the rest > can > be done from the web interface by clicking on some buttons. I absolutely hate this workflow, fwiw. I prefer being able to run "git- bz" to both create and apply patches, rather than keeping a clone with a bunch of patches in my own org, or remembering the commands to push a repo to my own repo from the upstream clone. I hope there will be a git-bz equivalent available. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hi, On Wed, May 17, 2017 at 11:33 AM, Sébastien Wilmet wrote: > On Wed, May 17, 2017 at 01:42:15AM +0200, Jehan Pagès wrote: >> Github/gitlab wants to force you to fork the project into a public >> repository on your private account so that you can make a pull >> request. This is seriously stupid IMO and very poor workflow. That's >> the reason why github/gitlab is absolutely littered with useless >> repositories containing absolutely no difference with the upstream >> repository (except they are outdated since the person didn't touch it >> for months). I'm sure trash "fork" repositories are the majority of >> github/gitlab contents. > > Once your commit is merged upstream, you can delete your fork repo (but > yes, maybe the majority of people don't do it). And I perfectly understand why they don't. They think that maybe they will finish their patch some day and be able to make a pull request (since they would usually fork first before actually make their first commit). They think that they may do another patch some day; so when this day come, why bother forking again? I would do the same. After all, it's not my own disk space! Well if GNOME is fine with hosting thousands of clones of all their repositories for every one-time committer which comes, I guess it's ok. > On GitHub at least it's easy to see if a repo is a fork, with a link to > the upstream repo. > > Most developers are more familiar with the GitHub workflow, I think it's Most developers who are on github because they discovered public project contribution there, maybe. So they got used to the only thing they know. I am absolutely not sure that they are actually more than all the developers who used saner workflows for years! But I don't have statistics, so who knows! I may be wrong. ;-) Now don't take me wrong. I am not fully against the migration. I think a lot of things would be nice on gitlab. But the workflow part is horrible IMO. This whole public forking business. I am not asking for the gitlab dev to change it (or for GNOME to patch gitlab) as a default. I know that won't happen. I am only asking if we can have "alternative" support for patches so that the ones who don't want to fork can go the alternative route. Basically a bug report with a patch should be considered same as a "merge request". Also obviously having a git-bz equivalent, as others pointed, would be very nice. > an easier workflow than attaching a patch to a bugtracker ticket. Once > the contributor has pushed a branch on the fork repo, all the rest can > be done from the web interface by clicking on some buttons. Assuming you consider than pushing on buttons on a web GUI is "easier" workflow, you may be right. As a developer, I spent most of my time in my terminal. The less I get out of the terminal, the better I feel. I don't want some actions which didn't need web browser interaction to suddenly need it. Jehan > -- > Sébastien -- ZeMarmot open animation film http://film.zemarmot.net Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, May 16, 2017 at 11:15:51PM +0900, Tristan Van Berkom wrote: > I don't share your optimism about gitlab bug tracking, nor do I share > in the mentioned frustration with bugzilla. Me too, I like bugzilla (but not for doing code reviews). What would be the pain points if GitLab is used only for git and code reviews, and we keep bugzilla for the bug tracker? Have you considered that option? We would loose automatic links between bug tracker tickets and pull requests. When a pull request is merged, we would need to close manually the bugzilla ticket if everything is done. And when someone requests a pull, the person would need to add a comment manually on bugzilla so that other people know that the bug is being worked on. Mmh I think that's not practical if the links must be done manually. Maintaining the bugzilla instance would also require sysadmin time, and development efforts to rebase the patches to new bugzilla versions. I don't know, I'm excited about the idea to use a similar contribution workflow as in GitHub, but less excited about having a bug tracker similar to the GitHub one. (I've never used GitLab, but I'm familiar with GitHub, and after seeing some screenshots it seems that the GitLab bug tracker is similar to GitHub's). -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On 17 May 2017 at 13:56, Carlos Soriano wrote: > Hey Arun, > > Glad to hear you are positive about the proposal! > > Let me answer your points: > > Original Message ---- > Subject: Re: Proposal to deploy GitLab on gnome.org > Local Time: May 17, 2017 7:32 AM > UTC Time: May 17, 2017 5:32 AM > From: a...@accosted.net > To: Carlos Soriano > desktop-devel-list@gnome.org > > On 17 May 2017 at 03:57, Carlos Soriano via desktop-devel-list > wrote: >> Hello Mattias, >> >> Thanks for sharing your thoughs! >> >> Your concern is about using fast forward merge. Yes, we raised this >> concern >> as the top most important for us, and as we mention in the wiki we have >> good >> news, GitLab team is willing to strongly consider making fast forward >> merge >> to CE if GNOME decides to switch to GitLab. >> >> Don't worry much about this one :) > > Thank you for taking this up. While I share some concerns voiced on > this thread, overall, I think it is a good thing for us to be trying > to move to tools that make our lives easier as well as lower the bar > for new contributors who are used to the Github-esque workflow. > > My first note to folks who are concerned about GitLab being an evil > semi-closed project would be to look at the repository at > https://gitlab.com/gitlab-org/gitlab-ce -- having shared these > concerns in the past, I feel a lot more positive looking at degree to > which external contributions are encouraged. > > > Yes, as mentioned in a different thread, more than 50% is by community. > Of course we had the same concerns in the past But then we explored the tool > and the team more, realized that in the CE repo there ara quite a lot of > non-gitlab contributions, read more about them and their actions in the past > (like moving EE features to CE based on user input), and talked with them. > Now we are pretty confident about it. > > > The things I worry about are the features that are in the EE and not > in CE that I think will be important for us either now, or down the > line: > > * Git hooks -- either admins with file system access need to manage > these for projects because the web interface to do this is EE-only > > > This is not a problem really. We were doing it already with Bugzilla/cgit. > > > * Automatic rebase for fast forward commits -- Carlos mentioned that > this might be something that'll just be part of the CE > > > Yes, no worries about this one. > > > * Single-sign-on with the remaining GNOME account infra -- maybe this > will just be something we'll have to maintain ourselves > > > Care to expand? You mean using the gnome account to login? If so, that's > already possible. I looked at the LDAP support item in the CE vs. EE page, but if it's solved already, that's awesome. > * Issue templates -- again, this seems like a basic feature for this > kind of platform so we can get more meaningful bug reports to start > with > > > This is on CE. > https://docs.gitlab.com/ce/user/project/description_templates.html > You might remembered from the past, before 8.1, when it was EE. > Test our gitlab test instance as outlined in the wiki so you know what's the > current status of the tool, since it changed and added quite a few things in > the last months that otherwise we would have ponder much more if it makes > sense for us. I was looking at the CE vs. EE page -- I guess that needs to be updated. > * Multiple issue boards per project -- I haven't used the issue > boards yet, but this seemed like a rather artificial limitation rather > than an actual feature differentiated in EE > > > Not sure how this is necessary for us, compared to what we have in Bugzilla. > Of course this would be useful, but the frame of the problem is more about > what we have now vs what we could have. > > > Other than the hooks which might be an immediate concern, I guess the > rest of these aren't a step down from where we are, so if we have an > idea of how to deal with these in the future, that's good enough. > > > Template issues and ff merge would have been a step down. Not sure template > issues would have been extremely important, but still. But as mentioned, > template issues in is CE since a few months ago, and fast forward merge > shouldn't worry you :) Well, that's two more thumbs up from me, then. :-) -- Arun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 3:15 PM, Bastien Nocera wrote: > On Wed, 2017-05-17 at 11:33 +0200, Sébastien Wilmet wrote: >> > >> Most developers are more familiar with the GitHub workflow, I think >> it's >> an easier workflow than attaching a patch to a bugtracker ticket. >> Once >> the contributor has pushed a branch on the fork repo, all the rest >> can >> be done from the web interface by clicking on some buttons. > > I absolutely hate this workflow, fwiw. I prefer being able to run "git- > bz" to both create and apply patches, rather than keeping a clone with > a bunch of patches in my own org, or remembering the commands to push a > repo to my own repo from the upstream clone. > > I hope there will be a git-bz equivalent available. I would love a git-bz equivalent for this so I can use it for the projects I contribute to on GitHub ;) This reminds me, does GitLab allow you to review the commit message of a patch or series of patches or does it hide it away like GitHub does? I often forget to review the syntax and content of the commit message because of this on GitHub, and this is probably quite important for GNOME projects. Cheers, Nirbheek ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, 2017-05-17 at 11:33 +0200, Sébastien Wilmet wrote: > > Most developers are more familiar with the GitHub workflow, I think > it's > an easier workflow than attaching a patch to a bugtracker ticket. > Once > the contributor has pushed a branch on the fork repo, all the rest > can > be done from the web interface by clicking on some buttons. I absolutely hate this workflow, fwiw. I prefer being able to run "git- bz" to both create and apply patches, rather than keeping a clone with a bunch of patches in my own org, or remembering the commands to push a repo to my own repo from the upstream clone. I hope there will be a git-bz equivalent available. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 01:42:15AM +0200, Jehan Pagès wrote: > Github/gitlab wants to force you to fork the project into a public > repository on your private account so that you can make a pull > request. This is seriously stupid IMO and very poor workflow. That's > the reason why github/gitlab is absolutely littered with useless > repositories containing absolutely no difference with the upstream > repository (except they are outdated since the person didn't touch it > for months). I'm sure trash "fork" repositories are the majority of > github/gitlab contents. Once your commit is merged upstream, you can delete your fork repo (but yes, maybe the majority of people don't do it). On GitHub at least it's easy to see if a repo is a fork, with a link to the upstream repo. Most developers are more familiar with the GitHub workflow, I think it's an easier workflow than attaching a patch to a bugtracker ticket. Once the contributor has pushed a branch on the fork repo, all the rest can be done from the web interface by clicking on some buttons. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hey Arun, Glad to hear you are positive about the proposal! Let me answer your points: Original Message Subject: Re: Proposal to deploy GitLab on gnome.org Local Time: May 17, 2017 7:32 AM UTC Time: May 17, 2017 5:32 AM From: a...@accosted.net To: Carlos Soriano desktop-devel-list@gnome.org On 17 May 2017 at 03:57, Carlos Soriano via desktop-devel-list wrote: > Hello Mattias, > > Thanks for sharing your thoughs! > > Your concern is about using fast forward merge. Yes, we raised this concern > as the top most important for us, and as we mention in the wiki we have good > news, GitLab team is willing to strongly consider making fast forward merge > to CE if GNOME decides to switch to GitLab. > > Don't worry much about this one :) Thank you for taking this up. While I share some concerns voiced on this thread, overall, I think it is a good thing for us to be trying to move to tools that make our lives easier as well as lower the bar for new contributors who are used to the Github-esque workflow. My first note to folks who are concerned about GitLab being an evil semi-closed project would be to look at the repository at https://gitlab.com/gitlab-org/gitlab-ce -- having shared these concerns in the past, I feel a lot more positive looking at degree to which external contributions are encouraged. Yes, as mentioned in a different thread, more than 50% is by community. Of course we had the same concerns in the past But then we explored the tool and the team more, realized that in the CE repo there ara quite a lot of non-gitlab contributions, read more about them and their actions in the past (like moving EE features to CE based on user input), and talked with them. Now we are pretty confident about it. The things I worry about are the features that are in the EE and not in CE that I think will be important for us either now, or down the line: * Git hooks -- either admins with file system access need to manage these for projects because the web interface to do this is EE-only This is not a problem really. We were doing it already with Bugzilla/cgit. * Automatic rebase for fast forward commits -- Carlos mentioned that this might be something that'll just be part of the CE Yes, no worries about this one. * Single-sign-on with the remaining GNOME account infra -- maybe this will just be something we'll have to maintain ourselves Care to expand? You mean using the gnome account to login? If so, that's already possible. * Issue templates -- again, this seems like a basic feature for this kind of platform so we can get more meaningful bug reports to start with This is on CE. https://docs.gitlab.com/ce/user/project/description_templates.html You might remembered from the past, before 8.1, when it was EE. Test our gitlab test instance as outlined in the wiki so you know what's the current status of the tool, since it changed and added quite a few things in the last months that otherwise we would have ponder much more if it makes sense for us. * Multiple issue boards per project -- I haven't used the issue boards yet, but this seemed like a rather artificial limitation rather than an actual feature differentiated in EE Not sure how this is necessary for us, compared to what we have in Bugzilla. Of course this would be useful, but the frame of the problem is more about what we have now vs what we could have. Other than the hooks which might be an immediate concern, I guess the rest of these aren't a step down from where we are, so if we have an idea of how to deal with these in the future, that's good enough. Template issues and ff merge would have been a step down. Not sure template issues would have been extremely important, but still. But as mentioned, template issues in is CE since a few months ago, and fast forward merge shouldn't worry you :) Thanks again to everyone helping with this, Arun p.s.: I do think Bugzilla allows for more complexity in tracking/management but that might just be because of my familiarity with it. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 12:04 AM, Mattias Bengtsson wrote: > At my work we keep a semi-linear git history: > - we only allow merges based on the tip of master > - we always merge with --no-ff (which is what GitLab's merge >button does) > > This gives us grouping of commits into features, while still > making sure our history is reasonably easy to follow. Do you have a public repo online to see what this looks like? -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
From the migration plan in the wiki: "Our contention is that copying/moving every existing GNOME issue to a new issue tracker is impractical and, in many situations, undesirable." May you expand in which many situations is undesirable? I have tickets in Shotwell that have migrated three times now. From Trac to Redmine to bgo. Most of them are unreadable, are missing attachments or other viable information. Also, all references to older tickets in code are hard or even impossible to find. So in my opinion, either all information has to be transferred properly, INCLUDING a possibility to find the old bgo number, or better nothing. But I would be perfectly happy with a r/o bgo instance for reference. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On 17 May 2017 at 03:57, Carlos Soriano via desktop-devel-list wrote: > Hello Mattias, > > Thanks for sharing your thoughs! > > Your concern is about using fast forward merge. Yes, we raised this concern > as the top most important for us, and as we mention in the wiki we have good > news, GitLab team is willing to strongly consider making fast forward merge > to CE if GNOME decides to switch to GitLab. > > Don't worry much about this one :) Thank you for taking this up. While I share some concerns voiced on this thread, overall, I think it is a good thing for us to be trying to move to tools that make our lives easier as well as lower the bar for new contributors who are used to the Github-esque workflow. My first note to folks who are concerned about GitLab being an evil semi-closed project would be to look at the repository at https://gitlab.com/gitlab-org/gitlab-ce -- having shared these concerns in the past, I feel a lot more positive looking at degree to which external contributions are encouraged. The things I worry about are the features that are in the EE and not in CE that I think will be important for us either now, or down the line: * Git hooks -- either admins with file system access need to manage these for projects because the web interface to do this is EE-only * Automatic rebase for fast forward commits -- Carlos mentioned that this might be something that'll just be part of the CE * Single-sign-on with the remaining GNOME account infra -- maybe this will just be something we'll have to maintain ourselves * Issue templates -- again, this seems like a basic feature for this kind of platform so we can get more meaningful bug reports to start with * Multiple issue boards per project -- I haven't used the issue boards yet, but this seemed like a rather artificial limitation rather than an actual feature differentiated in EE Other than the hooks which might be an immediate concern, I guess the rest of these aren't a step down from where we are, so if we have an idea of how to deal with these in the future, that's good enough. Thanks again to everyone helping with this, Arun p.s.: I do think Bugzilla allows for more complexity in tracking/management but that might just be because of my familiarity with it. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hi! On Wed, May 17, 2017 at 12:27 AM, Carlos Soriano via desktop-devel-list wrote: > Hello Mattias, > > Thanks for sharing your thoughs! > > Your concern is about using fast forward merge. Yes, we raised this concern > as the top most important for us, and as we mention in the wiki we have good > news, GitLab team is willing to strongly consider making fast forward merge > to CE if GNOME decides to switch to GitLab. > > Don't worry much about this one :) Good to read! This would also be a big problem for GIMP. We are trying to keep up master commit log as linear as possible, without any merge commits (it failed sometimes, errors were made!). One of my other main issues with github/lab is the way it forces you to fork a project on your personal account so that you can contribute. Many of my contributions to various projects are one-liners or small commits (as is the case for many developers). When I do this, I want to just upload a git formatted patch file (which will also be easy for the reviewer to test with a `git apply|am`). Unfortunately gitlab does not allow simple .patch files.If I recall, you can still upload one but there is no support of it. That's just considered as a text file. So you don't get the UI for review, etc. It is not handled the same as there "merge requests". Well last time I tried. Correct me if I am wrong. Github/gitlab wants to force you to fork the project into a public repository on your private account so that you can make a pull request. This is seriously stupid IMO and very poor workflow. That's the reason why github/gitlab is absolutely littered with useless repositories containing absolutely no difference with the upstream repository (except they are outdated since the person didn't touch it for months). I'm sure trash "fork" repositories are the majority of github/gitlab contents. Could GNOME's gitlab instance make sure that patch files are properly handled so that contributors are still allowed to upload patches? Will GNOME's gitlab instance have the same politics on "everything should be forked one thousand times"? Jehan P.S.: apart from this, I am happy that things go forward and I think gitlab has some great tools for code reviewing, and simpler UI for bug reporters. But there are some things which really make things complicated each time I have to contribute to a github or gitlab project (since gitlab is apparently trying to mimic github on many core features). This made me not contribute sometimes on some projects when I thought that the annoyance was worse than the usefulness of my patch (whereas if I could have just git-formatted a patch, I would have done it). > Best regards, > Carlos Soriano > > Original Message > Subject: Re: Proposal to deploy GitLab on gnome.org > Local Time: May 17, 2017 12:04 AM > UTC Time: May 16, 2017 10:04 PM > From: mattias.jc.bengts...@gmail.com > To: desktop-devel-list@gnome.org > > Hi all! > > On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote: >> The outcome of this evaluation process is that we are recommending >> that GNOME sets up its own GitLab instance, as a replacement for >> Bugzilla and cgit. > > This is very exciting! I've been following the plans on the wiki and > the discussions in #sysadmin and have been waiting impatiently for you > to reveal the plans to the public. > > As part of my responsibilities at my current work I help maintaining > our internal GitLab CE instance and from my limited experience, > updating and maintaining it has been rather easy. > > One exciting thing about GitLab is its fast pace of development. New > releases with new features are coming often. > > One question though regarding the GitLab CE merge button: > > The merge button in GitLab CE produces (non-ff) merge-commits > which might be undesirable (the history gets really hard to read > IMHO). GitLab EE allows you to rebase and/or perform --ff merges > instead. > > At my work we keep a semi-linear git history: > - we only allow merges based on the tip of master > - we always merge with --no-ff (which is what GitLab's merge >button does) > > This gives us grouping of commits into features, while still > making sure our history is reasonably easy to follow. > > To enforce this with GitLab CE we use a pre-merge CI test that > tries to perform a fast forward merge, and fails if it can't. We > then set the merge setting for the repo in question to not allow > merging MR's with failing CI pipelines. > > In GNOME, the most common workflow has been to use a straight > history without merge-commits + release-branches. This implies making > a fast-forward merge or a rebase, which means that the above mentioned > trick won't work wit
Re: Proposal to deploy GitLab on gnome.org
Hi Pat! On Tue, 2017-05-16 at 10:41 -0400, Pat Suwalski wrote: > I only lurk here, so I don't often offer an opinion, but I do > maintain the GitLab install at my medium-sized company. I do the same, but our experiences seems to be pretty different. > My problem with GitLab is how fluid it is. The underlying > technologies keep changing, and it's a real pain staying up to date. > If you get behind at all with the updates, it's quite a chore to > upgrade, and half way through you find out you need a new Ruby, need > to upgrade through a couple of packaging systems for node, and > really, you should just upgrade to Debian unstable (that last one is > a bit of an exaggeration). > Expect a new user interface experience every four months. > That's not to say that it's fragile. It's been rock-solid for us. How did you install GitLab? We use the omnibus RPM package for CentOS and have had no dependency problems while upgrading from some 7.x release all the way to 9.1.x over the last few years. A lot come bundled in the omnibus package and the rest gets installed from the host operating system repositories. Could it be that Debian stable is just very old? > It's just hard to recommend something you can't predict, running > ever-changing technologies that no sysadmin can comfortably stay on > top of. Since everything has been working super smooth for us I can't say that I agree (not implying that the pain you've experienced isn't real of course). Regards, Mattias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
First off, thank you so much for all your contributions as a user and contributor. I think all of us appreciate that. On Tue, May 16, 2017 at 1:27 PM Mirko Crowther via desktop-devel-list < desktop-devel-list@gnome.org> wrote: > I'm *AGAINST* any initiative about moving GNOME to either GitLab or > Phabricator. > > > > In recent months we have got together to examine the possibilities for > > GNOME’s development infrastructure. We’ve spent a lot of time on this, > > because we want the community to have faith in our conclusions. > > > Available alternatives to cgit and Bugzilla include GOGS, gitea and > Pagure. However, these were rejected early on in this evaluation, due to > their contributor levels and sustainability. > > > Perhaps you spent a lot of time on this, but clearly not enough. You are > basically suggesting that GNOME should rely for its infrastructure, which > is a very important component, on a company whose business model is to sell > proprietary features for its "enterprise" edition, and whose > Which we already do for other infrastructure tools like puppet. > I'm outraged to read that you're questioning the sustainability of > projects such as gitea and pagure, while you see no problem with GitLab's > own sustainability. As far as I can see, gitea has its own community and > development is going strong. Pagure is developed (supported?) by Red Hat > and the Fedora community is already using it (the now defunct FedoraHosted > has migrated to pagure). Gogs > These tools were rejected because it didn't have the feature set that evaluators were looking for and clearly we have reached the end of what can be done with the current situation. > > Anyway, I'm not a GNOME developer, so the decision is not on me. But I'm a > GNOME user, I try to contribute by helping users, or submitting bug > reports. I also donated to the project, and I want to know that when I > support a free project, it will in turn support other free projects. That's > why if this wicked proposal will be accepted, I'll stop being an active > GNOME user and also invite everybody to stop donating to the GNOME project. > > I respect that you are an ally in Free Software, but in general, it is very impolite to threaten the community because they decided on something that you personally oppose or against your values. If there is a solution that was Free Software that met the needs of what the GNOME Project was looking for, you can be assured we would have seriously evaluated it. Approving GitLab should be considered something very prestigious to Gitlab Inc and it will be our fondest wish that they respect the relationship we have with sufficient gravitas. You might consider reading this post hosted on Gitlab regarding software freedom - https://about.gitlab.com/2015/05/20/gitlab-gitorious-free-software/. If you have any further questionspr comments, please direct your replies to me personally rather than continuing it here so that we can continue to gather feedback from the community without distracting side conversations. sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hello Mattias, Thanks for sharing your thoughs! Your concern is about using fast forward merge. Yes, we raised this concern as the top most important for us, and as we mention in the wiki we have good news, GitLab team is willing to strongly consider making fast forward merge to CE if GNOME decides to switch to GitLab. Don't worry much about this one :) Best regards, Carlos Soriano Original Message Subject: Re: Proposal to deploy GitLab on gnome.org Local Time: May 17, 2017 12:04 AM UTC Time: May 16, 2017 10:04 PM From: mattias.jc.bengts...@gmail.com To: desktop-devel-list@gnome.org Hi all! On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote: > The outcome of this evaluation process is that we are recommending > that GNOME sets up its own GitLab instance, as a replacement for > Bugzilla and cgit. This is very exciting! I've been following the plans on the wiki and the discussions in #sysadmin and have been waiting impatiently for you to reveal the plans to the public. As part of my responsibilities at my current work I help maintaining our internal GitLab CE instance and from my limited experience, updating and maintaining it has been rather easy. One exciting thing about GitLab is its fast pace of development. New releases with new features are coming often. One question though regarding the GitLab CE merge button: The merge button in GitLab CE produces (non-ff) merge-commits which might be undesirable (the history gets really hard to read IMHO). GitLab EE allows you to rebase and/or perform --ff merges instead. At my work we keep a semi-linear git history: - we only allow merges based on the tip of master - we always merge with --no-ff (which is what GitLab's merge button does) This gives us grouping of commits into features, while still making sure our history is reasonably easy to follow. To enforce this with GitLab CE we use a pre-merge CI test that tries to perform a fast forward merge, and fails if it can't. We then set the merge setting for the repo in question to not allow merging MR's with failing CI pipelines. In GNOME, the most common workflow has been to use a straight history without merge-commits + release-branches. This implies making a fast-forward merge or a rebase, which means that the above mentioned trick won't work with our model. From my understanding (after reading the workflow description), the plan is to just not use the merge-button if you want to keep the current merging model. This is /definitely/ fine by me, the net gain from moving to GitLab is still *huge*. But I'm wondering, has there been any further discussion around this? Has anyone reached out to GitLab asking if this feature could be moved to CE for us? Regards, A very excited Mattias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hi all! On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote: > The outcome of this evaluation process is that we are recommending > that GNOME sets up its own GitLab instance, as a replacement for > Bugzilla and cgit. This is very exciting! I've been following the plans on the wiki and the discussions in #sysadmin and have been waiting impatiently for you to reveal the plans to the public. As part of my responsibilities at my current work I help maintaining our internal GitLab CE instance and from my limited experience, updating and maintaining it has been rather easy. One exciting thing about GitLab is its fast pace of development. New releases with new features are coming often. One question though regarding the GitLab CE merge button: The merge button in GitLab CE produces (non-ff) merge-commits which might be undesirable (the history gets really hard to read IMHO). GitLab EE allows you to rebase and/or perform --ff merges instead. At my work we keep a semi-linear git history: - we only allow merges based on the tip of master - we always merge with --no-ff (which is what GitLab's merge button does) This gives us grouping of commits into features, while still making sure our history is reasonably easy to follow. To enforce this with GitLab CE we use a pre-merge CI test that tries to perform a fast forward merge, and fails if it can't. We then set the merge setting for the repo in question to not allow merging MR's with failing CI pipelines. In GNOME, the most common workflow has been to use a straight history without merge-commits + release-branches. This implies making a fast-forward merge or a rebase, which means that the above mentioned trick won't work with our model. From my understanding (after reading the workflow description), the plan is to just not use the merge-button if you want to keep the current merging model. This is /definitely/ fine by me, the net gain from moving to GitLab is still *huge*. But I'm wondering, has there been any further discussion around this? Has anyone reached out to GitLab asking if this feature could be moved to CE for us? Regards, A very excited Mattias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
I'm *AGAINST* any initiative about moving GNOME to either GitLab or Phabricator. > In recent months we have got together to examine the possibilities for > GNOME’s development infrastructure. We’ve spent a lot of time on this, > because we want the community to have faith in our conclusions. > Available alternatives to cgit and Bugzilla include GOGS, gitea and Pagure. > However, these were rejected early on in this evaluation, due to their > contributor levels and sustainability. Perhaps you spent a lot of time on this, but clearly not enough. You are basically suggesting that GNOME should rely for its infrastructure, which is a very important component, on a company whose business model is to sell proprietary features for its "enterprise" edition, and whose interest therefore is to work against the "community" edition as much as possible to maximize their profits on the "enterprise" edition. Bear in mind that this is the same company that shut down Gitorious. Remember? Don't get me wrong though, I think the fact that they even have a free edition is noble on their part. But this "community" edition is no more than a bait, or a free trial, and it's only good for small teams if they really need to share some code. But it certainly is *not* a valid long-term solution for a project the size of GNOME. The interests of GitLab Inc. and GNOME are *not* aligned (or the interests of GitLab and any other free software for what matters). Remember this when you'll hit the wall with GitLab. I'm outraged to read that you're questioning the sustainability of projects such as gitea and pagure, while you see no problem with GitLab's own sustainability. As far as I can see, gitea has its own community and development is going strong. Pagure is developed (supported?) by Red Hat and the Fedora community is already using it (the now defunct FedoraHosted has migrated to pagure). Gogs development instead seems to have slowed down, but this is likely because there is only 1 developer. Other people are still using it though, see notabug.org, so I don't know... Then there is Savannah. GNOME is a GNU project, right? Then use Savannah, that would be the right place. Maybe they suck a little bit, but instead of supporting other free software communities you're falling for some eye candy. Anyway, I'm not a GNOME developer, so the decision is not on me. But I'm a GNOME user, I try to contribute by helping users, or submitting bug reports. I also donated to the project, and I want to know that when I support a free project, it will in turn support other free projects. That's why if this wicked proposal will be accepted, I'll stop being an active GNOME user and also invite everybody to stop donating to the GNOME project.___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, May 16, 2017 at 2:38 PM Carlos Soriano wrote: > That's a nice discussion to have, but a goal on the initiative was to try > to match what we have now (with the inherited niceties for those > workflow/use cases), with the less disruption possible, while keeping the > "nice things we could do" for a later case-by-case evaluation. > Right, to be clear, what i'm proposing is to keep status quo for access control, but on the new system. here's what I proposed mapped to the existing system: Can report issues and propose fixes → anyone can currently report bugs to bugzilla, and attach patches Can triage issues → those with editbugs can triage issues Can fix issues → those with commit access can fix issues. So if we keep that level of access control without adding additional ACLs and such I'm a happy camper --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Michael, Ray, That's a nice discussion to have, but a goal on the initiative was to try to match what we have now (with the inherited niceties for those workflow/use cases), with the less disruption possible, while keeping the "nice things we could do" for a later case-by-case evaluation. My motivation is to not derive the discussion into details of what we could do, but rather keep on the big change and what blockers/concerns/disruptions could cause. Best regards, Carlos Soriano Original Message ---- Subject: Re: Proposal to deploy GitLab on gnome.org Local Time: May 16, 2017 8:21 PM UTC Time: May 16, 2017 6:21 PM From: halfl...@gmail.com To: Christoph Reiter Michael Catanzaro , Allan Day , desktop-devel-list Hi, It's quite hard to get commit access atm because you have to be trusted initially. If a maintainer can give commit access to one repo he/she watches anyway there is less trust needed in the beginning. Or if a new contributor wants to take over an abandoned project. is that true? I mean you have to have someone with commit access vouch for you but that's a pretty low bar. I don't think it should be any lower than that, but I also wouldn't want to see it higher than that. GNOME has had open ACLs from the beginning and it's a good thing! There's no evidence of abuse, we shouldn't go locking everything down just because we can. IMO, there should be three access tiers: 1) Can report issues and propose fixes 2) Can triage issues 3) Can fix issues Anything more granular than that is a bad idea. It just introduces artificial barriers that people will run into. (What happens when a maintainer goes AWOL ?) Let's keep things open like we always have! --Ray___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
I agree with Ray. Open ACLs is a big + for GNOME and there are no significant evidence of abuse of that. Big NO for the artificial barriers by fine grained ACLs On 16 May 2017 at 23:51, Ray Strode wrote: > Hi, >> >> It's quite hard to get commit access atm because you have to be >> trusted initially. If a maintainer can give commit access to one repo >> he/she watches anyway there is less trust needed in the beginning. Or >> if a new contributor wants to take over an abandoned project. > > is that true? I mean you have to have someone with commit access vouch for > you but that's a pretty low bar. I don't think it should be any lower than > that, but I also wouldn't want to see it higher than that. GNOME has had > open ACLs from the beginning and it's a good thing! There's no evidence of > abuse, we shouldn't go locking everything down just because we can. > > IMO, there should be three access tiers: > > 1) Can report issues and propose fixes > 2) Can triage issues > 3) Can fix issues > > Anything more granular than that is a bad idea. It just introduces > artificial barriers that people will run into. (What happens when a > maintainer goes AWOL ?) > > Let's keep things open like we always have! > > --Ray > > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Kind Regards, Kunal ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hi, > It's quite hard to get commit access atm because you have to be > trusted initially. If a maintainer can give commit access to one repo > he/she watches anyway there is less trust needed in the beginning. Or > if a new contributor wants to take over an abandoned project. > is that true? I mean you have to have someone with commit access vouch for you but that's a pretty low bar. I don't think it should be any lower than that, but I also wouldn't want to see it higher than that. GNOME has had open ACLs from the beginning and it's a good thing! There's no evidence of abuse, we shouldn't go locking everything down just because we can. IMO, there should be three access tiers: 1) Can report issues and propose fixes 2) Can triage issues 3) Can fix issues Anything more granular than that is a bad idea. It just introduces artificial barriers that people will run into. (What happens when a maintainer goes AWOL ?) Let's keep things open like we always have! --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, May 16, 2017 at 7:03 PM, Ray Strode wrote: > Hi, > > On Tue, May 16, 2017 at 12:20 PM wrote: >> >> Another issue we haven't discussed yet is commit permissions. Right >> now, everyone can commit anything to every repository, but with GitLab >> we'll probably eventually want something more fine-grained where >> *active* maintainers have more control over who is allowed to commit. > > uhh, why? I think the lack of fine grained ACLs is an extremely useful > feature of our current setup. Are you concerned we might grow abusers at > some point? It's quite hard to get commit access atm because you have to be trusted initially. If a maintainer can give commit access to one repo he/she watches anyway there is less trust needed in the beginning. Or if a new contributor wants to take over an abandoned project. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, May 16, 2017 at 12:23 PM, mcatanz...@gnome.org wrote: Some maintainers want this, and I think that will be fine in the future. I don't really care much either way, because I've never seen any intentional abuse, and if someone commits something wrong to one of my projects I can simply revert it... which is very rare. But GitLab makes it easy to lock down permissions, and I hope we don't do that right away, when our build system is still very fragile and waiting for maintainers to approve build fixes is undesirable. And we do need some tier of permissions, since we want everyone to be able to use the issue tracker, but we surely do not want everyone to be able to close and reopen issues, or to commit to our projects. Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, May 16, 2017 at 12:03 PM, Ray Strode wrote: Hi, On Tue, May 16, 2017 at 12:20 PM wrote: Another issue we haven't discussed yet is commit permissions. Right now, everyone can commit anything to every repository, but with GitLab we'll probably eventually want something more fine-grained where *active* maintainers have more control over who is allowed to commit. uhh, why? I think the lack of fine grained ACLs is an extremely useful feature of our current setup. Are you concerned we might grow abusers at some point? --Ray Some maintainers want this, and I think that will be fine in the future. I don't really care much either way, because I've never seen any intentional abuse, and if someone commits something wrong to one of my projects I can simply revert it... which is very rare. But GitLab makes it easy to lock down permissions, and I hope we don't do that right away, when our build system is still very fragile and waiting for maintainers to approve build fixes is undesirable. Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hi, On Tue, May 16, 2017 at 12:20 PM wrote: > Another issue we haven't discussed yet is commit permissions. Right > now, everyone can commit anything to every repository, but with GitLab > we'll probably eventually want something more fine-grained where > *active* maintainers have more control over who is allowed to commit. > uhh, why? I think the lack of fine grained ACLs is an extremely useful feature of our current setup. Are you concerned we might grow abusers at some point? --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, May 16, 2017 at 5:36 PM, wrote: ... > We need a much better migration plan than that. If we don't have a script > to migrate Bugzilla issues, comments, and attachments to our new GitLab > instance, then we should not be considering using GitLab's issue tracker at > all. > We're committed to creating the necessary migration tooling; I think that Alberto already has something in the works. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
mcatanz...@gnome.org wrote: > > Does the plan consider a tool like bugzilla2gitlab, but removing > > the part that copy the accounts? > > We need a much better migration plan than that. If we don't have a > script to migrate Bugzilla issues, comments, and attachments to our > new GitLab instance, then we should not be considering using GitLab's > issue tracker at all. I suspect that scripting it at an high level using web APIs or even a local ORM would take an inordinate amount of time, but I glanced at the Bugzilla and GitLab database schema definitions and I think that a simple SQL migration of projects/bugs/comments/attachments may be doable, if we don't mind screwing up text formatting a bit. :) https://github.com/bugzilla/bugzilla/blob/master/Bugzilla/DB/Schema.pm https://github.com/gitlabhq/gitlabhq/blob/master/db/schema.rb (By the way, huge kudos to the people pushing for this switch) -- Emanuele Aina www.collabora.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On 16 May 2017 at 15:23, Carlos Soriano wrote: > Glad to hear that. Could you mention what projects relevant for GNOME > (either part of GNOME already or not) that you are maintainer of would > benefit of a transition to GitLab? Of immediate benefit would be gnome-software as we have lots of different teams from lots of different companies all working together. I'd ideally want the same workflow for my other projects, which would probably include odrs-web, gnome-color-manager, gnome-packagekit, and gnome-multi-writer. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, May 16, 2017 at 11:12 AM, Germán Poo-Caamaño wrote: From the migration plan in the wiki: "Our contention is that copying/moving every existing GNOME issue to a new issue tracker is impractical and, in many situations, undesirable." May you expand in which many situations is undesirable? I can foresee unmaintained projects, but I clearly am missing more cases. For (semi-)maintained projects bugzilla is a database of "wisdom", which is practical to find duplicated reports, for example, repetitive bugs, and more importantly, the rationale behind WONTFIX issues because of design decisions. Does the plan consider a tool like bugzilla2gitlab, but removing the part that copy the accounts? We need a much better migration plan than that. If we don't have a script to migrate Bugzilla issues, comments, and attachments to our new GitLab instance, then we should not be considering using GitLab's issue tracker at all. I would rather continue to use Bugzilla forever than switch to GitLab without a proper migration of existing issues. We could still switch from cgit to GitLab and use it for merge requests, but turn off the issue tracker for now and reevaluate in the future when we have a better migration story in place. (Of course, we do not need to migrate anything except for actively-maintained projects currently hosted on git.gnome.org.) We might even decide to never migrate the issue tracker. I would be surprised (and, of course, pleased) if the GitLab issue tracker ever becomes anywhere near as good as Bugzilla (or Phabricator's issue tracker, Maniphest). That said, some of the comments in this thread have made me more comfortable with switching, especially Emmanuele's comment that it's now possible to move issues from one project to another. Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Another issue we haven't discussed yet is commit permissions. Right now, everyone can commit anything to every repository, but with GitLab we'll probably eventually want something more fine-grained where *active* maintainers have more control over who is allowed to commit. Currently we still need the ability to commit build fixes when a project is broken in JHBuild (or Continuous), so that means everyone (or at least release team) still needs commit access to everything for the time being. But I bet if we replace JHBuild with BuildStream and integrate it with GitLab CI, then build failures will become much easier to track than they are right now, and this won't be necessary anymore. Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, May 16, 2017 at 6:23 AM Allan Day wrote: > > We are confident that GitLab is a good choice for GNOME, and we can’t wait > for GNOME to modernise our developer experience with it. It will provide us > with vastly more effective tools, an easier landing for newcomers, and lots > of opportunities to improve the way that we work. We're ready to start > working on the migration. > > > I want to thank everyone who put the effort into putting this together and doing a thorough job of considering our options. This welcome news, and at last we infrastructure that can provide a similar experience to Github while staying true to our values and improving the way we work. Just another great change for the future! I've not had some time to spend on gitlab that much, but I can see that we have an opportunity to change how we do developer flows that takes advantage of the capabilities of Gitlab. So a big +1 from me! sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, 2017-05-16 at 10:28 -0400, Carlos Soriano via desktop-devel- list wrote: > Hello Hubert, > > [...] > 2- what are the migration plans for bugzilla: bugzilla URL, bug > numbers and the actual content > In the wiki we outline what our plans are. However this is a moving > target based on the input we receive here. > We have to find a balance between how much reasonable effort would > one way to migrate or the other vs the benefits. Also, different > projects might have different needs for migration. > [...] From the migration plan in the wiki: "Our contention is that copying/moving every existing GNOME issue to a new issue tracker is impractical and, in many situations, undesirable." May you expand in which many situations is undesirable? I can foresee unmaintained projects, but I clearly am missing more cases. For (semi-)maintained projects bugzilla is a database of "wisdom", which is practical to find duplicated reports, for example, repetitive bugs, and more importantly, the rationale behind WONTFIX issues because of design decisions. Does the plan consider a tool like bugzilla2gitlab, but removing the part that copy the accounts? -- Germán Poo-Caamaño http://calcifer.org/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list