Re: Porting applications to meson

2017-05-23 Thread Iñigo Martínez
I don't know where libgepub does belong in that list (core-deps
maybe?), but it's done[0]. I will try to get totem done.

Best regards,

[0] https://bugzilla.gnome.org/show_bug.cgi?id=782994#c1

2017-05-23 16:09 GMT+02:00 Javier Jardón :
> On 23 May 2017 at 10:14, Milan Crha  wrote:
>> On Tue, 2017-05-23 at 09:55 +0100, Javier Jardón wrote:
>>> I've been thinking on doing this for a while, so here you go:
>>>
>>> https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting
>>
>> Hi,
>> do not count with evolution* for now, please. I'm not willing to change
>> their build system again, that soon after the change to CMake. I'm
>> quite happy with CMake, to be honest.
>>
>> And as long as its dependencies like WebKitGTK+ or libical use CMake,
>> thus it's needed for Continuous, jhbuild, and what-so-ever-other
>> consumers, there's really not much need to change to Meson for these,
>> from my point of view.
>>
>> I know each has its parts which can do better than the other, that's
>> pretty common. The suggested effort may work for Meson as an advertise
>> and to popularize it, which can be also good for Meson, no doubt.
>
> Sure, this is more to coordinate effort and avoid duplicating effort
>
> Also help people that are interested to port and need some examples to
> get started
>
>
> Cheers,
> Javier Jardón
> ___
> 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: Porting applications to meson

2017-05-23 Thread Javier Jardón
On 23 May 2017 at 10:14, Milan Crha  wrote:
> On Tue, 2017-05-23 at 09:55 +0100, Javier Jardón wrote:
>> I've been thinking on doing this for a while, so here you go:
>>
>> https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting
>
> Hi,
> do not count with evolution* for now, please. I'm not willing to change
> their build system again, that soon after the change to CMake. I'm
> quite happy with CMake, to be honest.
>
> And as long as its dependencies like WebKitGTK+ or libical use CMake,
> thus it's needed for Continuous, jhbuild, and what-so-ever-other
> consumers, there's really not much need to change to Meson for these,
> from my point of view.
>
> I know each has its parts which can do better than the other, that's
> pretty common. The suggested effort may work for Meson as an advertise
> and to popularize it, which can be also good for Meson, no doubt.

Sure, this is more to coordinate effort and avoid duplicating effort

Also help people that are interested to port and need some examples to
get started


Cheers,
Javier Jardón
___
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

2017-05-23 Thread 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

2017-05-23 Thread 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

2017-05-23 Thread 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

2017-05-23 Thread 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

2017-05-23 Thread 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

2017-05-23 Thread 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: Porting applications to meson

2017-05-23 Thread Milan Crha
On Tue, 2017-05-23 at 09:55 +0100, Javier Jardón wrote:
> I've been thinking on doing this for a while, so here you go:
> 
> https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting

Hi,
do not count with evolution* for now, please. I'm not willing to change
their build system again, that soon after the change to CMake. I'm
quite happy with CMake, to be honest.

And as long as its dependencies like WebKitGTK+ or libical use CMake,
thus it's needed for Continuous, jhbuild, and what-so-ever-other
consumers, there's really not much need to change to Meson for these,
from my point of view.

I know each has its parts which can do better than the other, that's
pretty common. The suggested effort may work for Meson as an advertise
and to popularize it, which can be also good for Meson, no doubt.

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

2017-05-23 Thread 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: Porting applications to meson

2017-05-23 Thread Javier Jardón
Hi,

On 22 May 2017 at 20:37, Jeremy Bicha  wrote:
> On Mon, May 22, 2017 at 3:29 PM, Iñigo Martínez  
> wrote:
>> Is there any application that no one is working on and that it would
>> be interesting to port it to meson?
>
> Why don't we set up a candidate GNOME Goal to track progress on
> converting modules to meson?
>
> https://wiki.gnome.org/Initiatives/GnomeGoals

I've been thinking on doing this for a while, so here you go:

https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting

Please help filling the missing info

Cheers,
Javier
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list