Re: Proposal to deploy GitLab on gnome.org

[Zbigniew Jędrzejewski-Szmek]

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

[Sébastien Wilmet]

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

[Tobias Mueller]

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

[Florian Müllner]

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

[Florian Müllner]

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

[Michael Catanzaro]

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

[Sébastien Wilmet]

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

[Carlos Soriano via desktop-devel-list]

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

[Felipe Borges]

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

[Mathieu Bridon]

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

[Adrian Perez de Castro]

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

[Bastien Nocera]

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

[Bastien Nocera]

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

[Felipe Borges]

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

[Milan Crha]

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

[Philip Withnall]

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

[Florian Müllner]

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

[Shaun McCance]

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

[mcatanzaro]

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

[Tom Tryfonidis]

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=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

[Andre Klapper]

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

[Andre Klapper]

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

[Andre Klapper]

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

[Andre Klapper]

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

[Bastien Nocera]

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

[Carlos Soriano via desktop-devel-list]

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 <boche...@daitauha.fr>
Carlos Soriano <csori...@protonmail.com>, desktop-devel-list@gnome.org 
<desktop-devel-list@gnome.org>, Bastien Nocera <had...@hadess.net>

Hi,

On Wed, May 17, 2017 at 5:59 PM, Mathieu Bridon <boche...@daitauha.fr> 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 <boche...@daitauha.fr
>> > 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 d

Re: Proposal to deploy GitLab on gnome.org

[Milan Crha]

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

[Milan Crha]

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

[Tristan Van Berkom]

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

[Jehan Pagès]

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 

Re: Proposal to deploy GitLab on gnome.org

[Alexandre Franke]

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

[Mathieu Bridon]

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

[Jehan Pagès]

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

[Mattias Bengtsson]

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

[Zbigniew Jędrzejewski-Szmek]

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

[Mathieu Bridon]

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

[Florian Müllner]

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

[Jehan Pagès]

Hi,

On Wed, May 17, 2017 at 3:55 PM, Bastien Nocera <had...@hadess.net> 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 <csori...@protonmail.com>
>> > desktop-devel-list@gnome.org <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 segregat

Re: Proposal to deploy GitLab on gnome.org

[Zbigniew Jędrzejewski-Szmek]

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

[Florian Müllner]

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

[Jehan Pagès]

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

[Mattias Bengtsson]

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

[Zbigniew Jędrzejewski-Szmek]

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

[Jehan Pagès]

Hi,

On Wed, May 17, 2017 at 2:44 PM, Carlos Soriano <csori...@protonmail.com> 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 <csori...@protonmail.com>
> desktop-devel-list <desktop-devel-list@gnome.org>
>
> Hi,
>
> On Wed, May 17, 2017 at 1:50 PM, Carlos Soriano <csori...@protonmail.com>
> 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 <csori...@protonmail.com>
>> desktop-devel-list <desktop-devel-list@gnome.org>
>>
>> Hi,
>>
>> On Wed, May 17, 2017 at 1:05 PM, Carlos Soriano <csori...@protonmail.com>
>> 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
>

Re: Proposal to deploy GitLab on gnome.org

[Zbigniew Jędrzejewski-Szmek]

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

[Mathieu Bridon]

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

[Pat Suwalski]

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

[Bastien Nocera]

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 <csori...@protonmail.com>
> > > desktop-devel-list@gnome.org <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

[Bastien Nocera]

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 <csori...@protonmail.com>
> > desktop-devel-list@gnome.org <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

[Carlos Soriano via desktop-devel-list]

 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 <csori...@protonmail.com>
desktop-devel-list@gnome.org <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

[Carlos Soriano via desktop-devel-list]

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 <csori...@protonmail.com>
desktop-devel-list <desktop-devel-list@gnome.org>

Hi,

On Wed, May 17, 2017 at 1:50 PM, Carlos Soriano <csori...@protonmail.com> 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 <csori...@protonmail.com>
> desktop-devel-list <desktop-devel-list@gnome.org>
>
> Hi,
>
> On Wed, May 17, 2017 at 1:05 PM, Carlos Soriano <csori...@protonmail.com>
> 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
&

Re: Proposal to deploy GitLab on gnome.org

[Jehan Pagès]

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

[Bastien Nocera]

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

[Jehan Pagès]

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

[Jehan Pagès]

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

[Rodrigo Moya]

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

[Carlos Soriano via desktop-devel-list]

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 <csori...@protonmail.com>
desktop-devel-list <desktop-devel-list@gnome.org>

Hi,

On Wed, May 17, 2017 at 1:05 PM, Carlos Soriano <csori...@protonmail.com> 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 <tristan.vanber...@codethink.co.uk>,
> desktop-devel-list <desktop-devel-list@gnome.org>
>
> Hi,
>
> On Wed, May 17, 2017 at 12:33 PM, Sébastien Wilmet <swil...@gnome.org>
> 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 p

Re: Proposal to deploy GitLab on gnome.org

[Jehan Pagès]

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

[Sébastien Wilmet]

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

[Jehan Pagès]

Hi,

On Wed, May 17, 2017 at 1:05 PM, Carlos Soriano <csori...@protonmail.com> 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 <tristan.vanber...@codethink.co.uk>,
> desktop-devel-list <desktop-devel-list@gnome.org>
>
> Hi,
>
> On Wed, May 17, 2017 at 12:33 PM, Sébastien Wilmet <swil...@gnome.org>
> 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

Re: Proposal to deploy GitLab on gnome.org

[Christoph Reiter]

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

[Carlos Soriano via desktop-devel-list]

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 <tristan.vanber...@codethink.co.uk>, desktop-devel-list 
<desktop-devel-list@gnome.org>

Hi,

On Wed, May 17, 2017 at 12:33 PM, Sébastien Wilmet <swil...@gnome.org> 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

[Jehan Pagès]

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

[Carlos Soriano via desktop-devel-list]

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 <swil...@gnome.org>, Jehan Pagès 
<jehan.marmott...@gmail.com>
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

[Jehan Pagès]

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

[Sébastien Wilmet]

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

[Arun Raghavan]

On 17 May 2017 at 13:56, Carlos Soriano <csori...@protonmail.com> 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 <csori...@protonmail.com>
> desktop-devel-list@gnome.org <desktop-devel-list@gnome.org>
>
> On 17 May 2017 at 03:57, Carlos Soriano via desktop-devel-list
> <desktop-devel-list@gnome.org> 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

[Nirbheek Chauhan]

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

[Bastien Nocera]

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

[Sébastien Wilmet]

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

[Carlos Soriano via desktop-devel-list]

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 <csori...@protonmail.com>
desktop-devel-list@gnome.org <desktop-devel-list@gnome.org>

On 17 May 2017 at 03:57, Carlos Soriano via desktop-devel-list
<desktop-devel-list@gnome.org> 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

[Alexandre Franke]

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

[Jens Georg]

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

[Jehan Pagès]

Hi!

On Wed, May 17, 2017 at 12:27 AM, Carlos Soriano via
desktop-devel-list <desktop-devel-list@gnome.org> 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 with our model.
>
> From 

Re: Proposal to deploy GitLab on gnome.org

[Mattias Bengtsson]

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

[Sriram Ramkrishna]

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

[Carlos Soriano via desktop-devel-list]

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

[Mattias Bengtsson]

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

[Mirko Crowther via desktop-devel-list]

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

[Ray Strode]

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

[Carlos Soriano via desktop-devel-list]

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 <reiter.christ...@gmail.com>
Michael Catanzaro <mcatanz...@gnome.org>, Allan Day <a...@gnome.org>, 
desktop-devel-list <desktop-devel-list@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

[Kunal Jain]

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

[Ray Strode]

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

[Christoph Reiter]

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

[mcatanzaro]

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

[mcatanzaro]

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

[Ray Strode]

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

[Allan Day]

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

[Emanuele Aina]

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

[Richard Hughes]

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

[mcatanzaro]

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

[mcatanzaro]

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

[Sriram Ramkrishna]

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

[Germán Poo-Caamaño]

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

Re: Proposal to deploy GitLab on gnome.org

[Michael Catanzaro]

On Tue, May 16, 2017 at 9:49 AM, Tobias Mueller  
wrote:

Hi.

I welcome the proposal to modernise our development infrastructure.

On Di, 2017-05-16 at 10:38 -0400, Carlos Soriano via 
desktop-devel-list

wrote:
 You can take a look at their "changelogs" between releases (one 
each month).

This seems to be the most risky part about moving to GitLab: Having to
maintain it.  Maintaining Bugzilla is not an easy task, but they don't
release every month.  Also, we have learnt (more or less...) how to
block bots DoSing or spamming us.


I think the main problem with maintaining Bugzilla is the fairly large 
number of downstream changes we have that makes upgrades difficult, 
right? We should consider not making downstream changes to our GitLab 
instance to prevent this from becoming a problem.


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

[Germán Poo-Caamaño]

On Tue, 2017-05-16 at 16:24 +0100, Emmanuele Bassi wrote:
> On 16 May 2017 at 16:17, Germán Poo-Caamaño  wrote:
> 
> > Another potential pain point: in Bugzilla, one can move bugs
> > between
> > products. This happen when the bug has been reported to the wrong
> > product, or when triaging the bugs the developers know the bug is
> > somewhere else in the stack.
> > 
> > Gitlab does not allow moving bugs between products. It is expected
> > to
> > be in 8.6 [1], but that is not for sure.
> 
> You can move issues between projects on the same instance, even with
> the community edition.
> 
> The issue you link was closed a year ago after the merge. Release
> 8.6.0 of the community edition was released around the same time.

Glad to know about it. I looked for the status at the bottom, clearly I
was looking at the wrong place (everyday I learn something new :-)

-- 
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

Re: Proposal to deploy GitLab on gnome.org

[Emmanuele Bassi]

On 16 May 2017 at 16:17, Germán Poo-Caamaño  wrote:

> Another potential pain point: in Bugzilla, one can move bugs between
> products. This happen when the bug has been reported to the wrong
> product, or when triaging the bugs the developers know the bug is
> somewhere else in the stack.
>
> Gitlab does not allow moving bugs between products. It is expected to
> be in 8.6 [1], but that is not for sure.

You can move issues between projects on the same instance, even with
the community edition.

The issue you link was closed a year ago after the merge. Release
8.6.0 of the community edition was released around the same time.

The latest 8.x release is 8.17.6, and the latest 9.x release is 9.1.6,
with 9.2.0 being in release candidate stretch.

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

[Germán Poo-Caamaño]

On Tue, 2017-05-16 at 10:51 -0400, Shaun McCance wrote:
> 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.
> 
> I 100% support this move. There are inevitably going to be some pain
> points, but the end result will be worth it.
> 
> 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.

Another potential pain point: in Bugzilla, one can move bugs between
products. This happen when the bug has been reported to the wrong
product, or when triaging the bugs the developers know the bug is
somewhere else in the stack.

Gitlab does not allow moving bugs between products. It is expected to
be in 8.6 [1], but that is not for sure.

[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/3024

-- 
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

Re: Proposal to deploy GitLab on gnome.org

[Allan Day]

On Tue, May 16, 2017 at 3:51 PM, Shaun McCance  wrote:

> 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.
>
> I 100% support this move. There are inevitably going to be some pain
> points, but the end result will be worth it.
>
> 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.
>

That's a good point. There have been a number of pertinent issues and
concerns raised already in this thread. We'll make sure that we review them
and provide some feedback.

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

[Carlos Soriano via desktop-devel-list]

Hello Alexandre (I got your name right :P),

The team was composed by people with no previous bias, except Alberto who 
initially approached us towards GitLab, and me liking Phab more.
Said that, over the testing period of more than 3 months we evaluated both 
options as extensively as possible, and all members of the original team tended 
more and more towards GitLab with as a clear choice, and more people like 
Alberto Alfan, Mathias Bengston, Javier Jardon and others raised their willing 
to help with GitLab and started prototyping parts of the eventual integration 
(CI, etc.).

When this happened, we decided we needed to calibrate this again, although we 
started with a balanced team and always doing as neutral as possible.
This is when we approached specifically people that currently are using Phab 
and prefer Phab on their work. Those are Emmanuelle Bassi (this proposal is 
written on behalf of him too) and Daniels, both from Endless where they use 
Phabricator extensively.
After some time of discussions, videocalls, and testing, we all, together with 
Emmanuel and Daniels, decided GitLab was the best choice for the GNOME project 
for the reasons stated in the wiki (and all the details we have been seeing for 
this time of course).

Summarizing, we didn't look just to GitLab and though it's good enough, rather, 
we took a look at all the options we could, evaluated them through this months, 
contacted people that could help from those tools, and then evaluated again.
Then we polished and minimized the wiki with the final decision in mind for 
helping on getting an overview, so that's probably why you see the wiki is 
written in that way.

Hope is clear now :)

Cheers,
Carlos Soriano

 Original Message 
Subject: Re: Proposal to deploy GitLab on gnome.org
Local Time: May 16, 2017 4:38 PM
UTC Time: May 16, 2017 2:38 PM
From: afra...@gnome.org
To: desktop-devel-list <desktop-devel-list@gnome.org>

On Tue, May 16, 2017 at 3:22 PM, Allan Day <a...@gnome.org> 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].

Excellent. I think most will agree it’s time we implement such changes.

> 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 mail mentions Gitlab as the only alternative. I know some people
suggested to consider Phabricator, yet your proposal doesn’t mention
it and by the looks of the wiki pages your research has been focused
around Gitlab. Now I know very little about both Gitlab and
Phabricator so I won’t push or block anything, but I’m a bit worried
that this wasn’t given enough scrutiny. In particular, I saw that
Phabricator has a tool for mockups/design (Pholio [0]) that really
looked like something we’d make good use of. It would allow our
designers to stop using Github, Dropbox, and such non free,
not-on-our-infrastructure tools.

So did you just look at Gitlab and think it’s good enough, or did you
actually consider Phabricator (and maybe other alternatives) and pick
Gitlab as the best fit?

[0] https://www.phacility.com/phabricator/pholio/

--
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___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list