Re: Matrix IRC bridge considered harmful

[Carlos Soriano via desktop-devel-list]

Matthew,

On April 19th 2020 we completed the server set up configured as agreed.
After that, we though everything was done and ready, and as you probably
remember we did actually informed the community about the improved services
[0]. That the previous answer to this thread make it sound like it has been
on hold because of us since then is not correct and I believe it has more
drama on it than it needs to be.

We do truly appreciate the services, because you are right that it's
beneficial for both organizations and we want GNOME contributors to have
the best experience regardless of the service they are using. However, I
hope you understand our careful consideration on what steps we follow here,
as we care about not putting the community in a position that would be
difficult to go back from. This is specially true around branding, external
services and official recommendations.

I don't see a reason why we couldn't make the IRC bridge performance ok
with this requirements in place, so let's continue working on making that
happen as we have been doing.

Thanks,
Carlos

[0]
https://mail.gnome.org/archives/desktop-devel-list/2019-March/msg00015.html

On Fri, 14 Feb 2020 at 01:00, Matthew Hodgson via desktop-devel-list <
desktop-devel-list@gnome.org> wrote:

> Hi folks,
>
> Sorry for the delay in response here - the last 24 hours have not been fun.
>
> Trying to address the main bits of feedback here:
>
> 1. The original issue that Michael Catanzaro reported (Matrix->IRC PM
> going missing) was a legitimate bug in the bridge.  The bridge is meant to
> display an error if you try to talk to an absent IRC user; this was fixed
> today and will be deployed tomorrow:
> https://github.com/matrix-org/matrix-appservice-irc/pull/978.  Sorry that
> you got bitten by this :(
>
> 2. In terms of: "We currently have loads of garbage IRC users in the
> channels after the bridge hosted at matrix.org was replaced with one
> hosted at the gnome.org homeserver." - I thought we'd cleared this up in
> the days following the migration, and this is the first I've heard of it
> still being a problem.  It sounds like the old bridge created IRC users on
> the Matrix side, and then the new bridge bridged them back over to IRC.  It
> should be trivial to kick out the old bridge's IRC users - please can you
> give me an example channel/room where this is happening to look at?
>
> 3. In terms of bridge performance: we set up a dedicated bridge and server
> for gnome.org powered by modular.im back in April 2019.  The bridge got
> put live, but the server was never publicised because we never got a
> greenlight to announce its existence (plus the go-live was eclipsed by some
> unrelated security dramas on the matrix.org homeserver).  As a result,
> the majority of users have been using the bridge via the public matrix.org
> server, which is (unfortunately) often overloaded thanks to the exponential
> growth we've been dealing with.  However, if folks were actually using the
> dedicated GNOME server, then it would be an *excellent* experience - much
> like the one that Mozilla is enjoying currently.  It's worth noting that we
> provided the GNOME server for free because we want to support the project,
> but the running costs are significant - it's been very frustrating that the
> server has not been used.  (It seems that some people have found it anyway
> over the course of today, to quote someone in #general:gnome.org: "OMG
> the IRC bridge is SO much faster on this instance.").  I'm hoping that we
> can get a greenlight to point people at the Gnome.org server, as right now
> the situation is indeed terrible and it's hurting Matrix's reputation as
> well as hurting GNOME :((
>
> 4. Mozilla *are* running their homeserver federated (as of this week) -
> c.f. https://twitter.com/littledan/status/1227603567722319873. They're
> countering abuse by using the arsenal of anti-abuse tooling we've been
> working on over the last year as per
> https://matrix.org/docs/guides/moderation/ and
> https://github.com/matrix-org/matrix-doc/blob/msc2313/proposals/2313-moderation-policy-rooms.md
> etc.
>
> You may also be interested that the core Matrix team is starting to look
> seriously at the work going on around Fractal, particularly around E2E
> encryption, to accelerate E2E encryption for Rust clients in general.
> Specifically, we're porting pantalaimon (the Matrix daemon which offloads
> E2E encryption) from Python to Rust, and we hope that the resulting
> official E2EE-capable Matrix Rust SDK will be directly usable by Fractal
> and help the project along massively as a first class native Matrix GTK
> client (assuming they want to use it! :)
>
> So, TL;DR: we've had a solution to much of the Matrix<->IRC problems since
> April 2019, w

Re: Matrix IRC bridge considered harmful

[Carlos Soriano via desktop-devel-list]

Hi folks,

We been in contact with Matthew from Matrix for some time already. I lately
didn't have much time to invest on this, so we had have some delays on
answering. However, it's our expectation that with the set up that we have
right now the IRC bridge should perform as its best, as we are using
servers from modular.im, the company that maintains paid severs with matrix
services on them. We believe our set up is correct, but there might be some
miss configuration somewhere, or the current situation it's already the
best that can be offered.

We'll update you as soon as we have more information.

Cheers,
Carlos

On Thu, 13 Feb 2020 at 17:16, Michael Catanzaro 
wrote:

> On Wed, Feb 12, 2020 at 4:15 pm, Britt Yazel  wrote:
> > Attached is an image of the compact mode + dark theme. Just for the
> > record.
>
> The thing is, it really comes down to personal preference. I suspect we
> have a lot of people who like web clients, and a lot of people who just
> don't. With open protocols like IRC, XMPP, or Matrix, where lots of
> client choice exists, you can use whatever you prefer. It's no problem
> if you don't like any particular client because you can just use a
> different one.
>
> Myself, I like to see GNOME clients: polari, dino, fractal, chatty.
> They look good next to our other apps, and vindicate the potential of
> our desktop platform. But if we're going to have a web client, at the
> very least do it using WebKitGTK, like Revolt does, to stick with GNOME
> technologies and avoid bundling Electron.
>
> I'll also suggest: whatever we use, it'd be nice to select something
> with the potential to become a widely-accepted standard, like IRC used
> to be. Chat has become a failed disaster area of fragmented walled
> gardens, and when we have a choice between an emerging standard and yet
> another silo, I think there's tremendous value in choosing the standard.
>
> Michael
>
>
> ___
> 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: Windows runner for CI now generally available!

[Carlos Soriano via desktop-devel-list]

On Tue, 19 Nov 2019 at 10:48, Carlos Soriano  wrote:

> Hi everyone,
>
> Good news! Thanks to OpenAtMicrosoft and our staff we have set up a
> Windows runner for the GNOME/ group. Right now it's a single runner with
> the "windows" tag attached, feel free to use it as you see fit.
>
> *How to use it*
> Here's is an example on how to use a specific runner with a tag:
> https://gitlab.gnome.org/GNOME/gtk/blob/master/.gitlab-ci.yml#L43
>
> For the new Windows runner, the CI configuration would be something like:
> windows job:
>   stage:
> - build
>   tags:
> - windows
>
> More documentation about tags:
> https://docs.gitlab.com/ee/ci/yaml/README.html#tags
>
> *A report to Microsoft*
> Part of the the deal for getting the keys is that we will write a report
> to Microsoft. If you start using the runner regularly, could you write to
> me in an email a short summary about how are you using the Windows runner
> and how that benefits us and our users using Windows or Microsoft platforms?
>
> *+ other Microsoft product keys*
> Additional good news is that we also got some Microsoft product keys such
> as Visual Studio Ultimate, Office 365, Office Professional, Outlook, .Net,
> Windows 10, Visio Professional, Visual Basic, Exchange, etc. If you have a
> strong use case that would be of benefit for the GNOME project and
> community please reach out to me so we can discuss it.
>

FYI I didn't receive many requests about these, maybe we can lower the bar
and remove the "strong" from "strong use case" here :) Seriously, don't
hesitate to let me know if any of these would be of interest for you, we
can discuss whether that usage is appropriate or not.


>
> Lastly, let Bartłomiej, Andrea or me know if the runner is working well
> for you.
>
> Cheers,
> Carlos
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Windows runner for CI now generally available!

[Carlos Soriano via desktop-devel-list]

Hi everyone,

Good news! Thanks to OpenAtMicrosoft and our staff we have set up a Windows
runner for the GNOME/ group. Right now it's a single runner with the
"windows" tag attached, feel free to use it as you see fit.

*How to use it*
Here's is an example on how to use a specific runner with a tag:
https://gitlab.gnome.org/GNOME/gtk/blob/master/.gitlab-ci.yml#L43

For the new Windows runner, the CI configuration would be something like:
windows job:
  stage:
- build
  tags:
- windows

More documentation about tags:
https://docs.gitlab.com/ee/ci/yaml/README.html#tags

*A report to Microsoft*
Part of the the deal for getting the keys is that we will write a report to
Microsoft. If you start using the runner regularly, could you write to me
in an email a short summary about how are you using the Windows runner and
how that benefits us and our users using Windows or Microsoft platforms?

*+ other Microsoft product keys*
Additional good news is that we also got some Microsoft product keys such
as Visual Studio Ultimate, Office 365, Office Professional, Outlook, .Net,
Windows 10, Visio Professional, Visual Basic, Exchange, etc. If you have a
strong use case that would be of benefit for the GNOME project and
community please reach out to me so we can discuss it.

Lastly, let Bartłomiej, Andrea or me know if the runner is working well for
you.

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

Re: Please run for the board!

[Carlos Soriano via desktop-devel-list]

And in case you missed it in planet.gnome.org, I made a write up on how the
board works nowadays, why you should and why you definitely can run for the
board, read it!
https://csoriano.pages.gitlab.gnome.org/csoriano-blog/post/2019-05-27-why-you-can-and-should-apply-for-the-board/

On Wed, 29 May 2019 at 11:13, Allan Day  wrote:

> Hi everyone,
>
> In case you didn't notice, we've had to extend the deadline for the GNOME
> Foundation Board of Directors elections, because not enough candidates put
> themselves forward.
>
> Please consider running in the elections. Being on the board is actually
> quite nice. It's also a great way to see the project from a high level, and
> to develop new skills and expertise.
>
> The revised deadline for candidates is 2nd June, and instructions on how
> to put yourself forward can be found here [1].
>
> Thanks,
>
> Allan
> --
> [1]
> https://mail.gnome.org/archives/foundation-announce/2019-April/msg2.html
> ___
> 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: Relicensing Nautilus to GPLv3+

[Carlos Soriano via desktop-devel-list]

This is done now in 
https://git.gnome.org/browse/nautilus/commit/?id=365ec7f7ac1cec51dc0248dd05b17cb78252a788
Thanks all for the input!

Best,
Carlos Soriano

>  Original Message 
> Subject: Re: Relicensing Nautilus to GPLv3+
> Local Time: May 28, 2017 3:30 PM
> UTC Time: May 28, 2017 1:30 PM
> From: swil...@gnome.org
> To: Bastien Nocera 
> desktop-devel-list@gnome.org 
> On Sun, May 28, 2017 at 03:20:49PM +0200, Bastien Nocera wrote:
>> On Thu, 2017-05-25 at 12:08 +0200, Sébastien Wilmet wrote:
>> > For LGPL -> GPL, you need the explicit approval of all copyright
>> > holders.
>>
>> No, you don't. It says right in the license that you can use LGPL
>> sources as GPL if you so wish:
>> "you may convey a copy of the modified version [...] under the GNU GPL,
>> with none of the additional permissions of this License applicable to
>> that copy."
>>
>> Meaning that you can strip the additional permissions in the LGPL to
>> make it GPL without asking anyone.
> Oh, thanks for correcting me. Good to know.
> I confused with GPL -> LGPL.
> --
> Sébastien
> ___
> 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

[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: Relicensing Nautilus to GPLv3+

[Carlos Soriano via desktop-devel-list]

Ah thanks Luis, I'll take that into account

Sent from ProtonMail mobile

 Original Message 
On 28 May 2017, 13:01, Luis Menina wrote:
Hi,

Le 25/05/2017 à 14:48, Carlos Soriano via desktop-devel-list a écrit :
> Thanks Michael, looks interesting and seems there are enough reasons to
> upgrade files too.
> We can take a look after we "assume" the project license is gpl3+ and no
> problem arises.

in any case, if you choose to change each file's license, please use
SPDX tags instead or in addition to the license header. This helps to
automate license detection by license-related tools.

https://spdx.org
https://spdx.org/using-spdx#identifiers
https://spdx.linuxfound.info/sites/cpstandard/files/pages/files/using_spdx_license_list_short_identifiers.pdf

Thanks
___
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: Relicensing Nautilus to GPLv3+

[Carlos Soriano via desktop-devel-list]

Thanks Michael, looks interesting and seems there are enough reasons to upgrade 
files too.
We can take a look after we "assume" the project license is gpl3+ and no 
problem arises.

Best,
Carlos Soriano

 Original Message 
Subject: Re: Relicensing Nautilus to GPLv3+
Local Time: May 25, 2017 2:07 PM
UTC Time: May 25, 2017 12:07 PM
From: mike.catanz...@gmail.com
To: Carlos Soriano <csori...@protonmail.com>
Sébastien Wilmet <swil...@gnome.org>, desktop-devel-list@gnome.org 
<desktop-devel-list@gnome.org>

On Thu, May 25, 2017 at 5:10 AM, Carlos Soriano via desktop-devel-list
<desktop-devel-list@gnome.org> wrote:
> Aha!
> I still get different opinions from different people on that. But
> that makes sense to me. Probably makes sense to relicense the files
> too at some point, but that would be a later decision.
> Do you know any advantage of relicensing the files themselves?
>
> Best,
> Carlos Soriano

The advantages of relicensing are:

* Easier to copy code into Nautilus from other GNOME projects. You
cannot currently copy code into Nautilus from the handful of projects
that have already transitioned to GPLv3+.
* Less confusion. It's confusing for the project license to be GPLv3+
while nearly all of the source code is licensed GPLv2+.
* Promote stronger, more effective copyleft. Many people believe GPLv3
is a better license than GPLv2. See [1].

This is why I've relicensed all the source files in Epiphany.

The disadvantage is that after relicensing, it will become harder to
copy code from Nautilus into other GNOME projects. You cannot copy into
GPLv2+ projects unless you relicense the other project to GPLv3+ or go
back in the commit history to before the relicensing. This is only a
transition problem, because it can be solved by upgrading the license
of the other project.

Michael

[1] https://www.gnu.org/licenses/rms-why-gplv3.en.html___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Relicensing Nautilus to GPLv3+

[Carlos Soriano via desktop-devel-list]

The project, not everyfile. It's more like accepting that Nautilus is gpl3+ now 
since some files are gpl3+ already. That's what I mean by re licensing.

Best,
Carlos Soriano

 Original Message 
Subject: Re: Relicensing Nautilus to GPLv3+
Local Time: May 25, 2017 12:36 PM
UTC Time: May 25, 2017 10:36 AM
From: swil...@gnome.org
To: Carlos Soriano 
desktop-devel-list@gnome.org 

On Thu, May 25, 2017 at 06:10:56AM -0400, Carlos Soriano wrote:
> I still get different opinions from different people on that. But that
> makes sense to me. Probably makes sense to relicense the files too at
> some point, but that would be a later decision.
> Do you know any advantage of relicensing the files themselves?

Well, I thought you wanted to license Nautilus as GPLv3+, that's the
topic of this thread…

See:
https://www.gnu.org/licenses/gpl-faq.html#v3HowToUpgrade

--
Sébastien___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Relicensing Nautilus to GPLv3+

[Carlos Soriano via desktop-devel-list]

Aha!
I still get different opinions from different people on that. But that makes 
sense to me. Probably makes sense to relicense the files too at some point, but 
that would be a later decision.
Do you know any advantage of relicensing the files themselves?

Best,
Carlos Soriano

 Original Message 
Subject: Re: Relicensing Nautilus to GPLv3+
Local Time: May 25, 2017 12:08 PM
UTC Time: May 25, 2017 10:08 AM
From: swil...@gnome.org
To: Carlos Soriano 
desktop-devel-list@gnome.org 

On Thu, May 25, 2017 at 05:59:02AM -0400, Carlos Soriano wrote:
> For now we won't relicense the files, since that would require
> copyright holders to agree (iiuc). Instead is the project that will
> become GPL3+, since the combination of GPL2+ + GPL3+ files results in
> a project that is GPL3+.

For the files licensed as GPLv2+, the copyright holders have already
agreed with "any later version", so you can directly relicense to GPLv3+
without asking the permission to each copyright holder.

For LGPL -> GPL, you need the explicit approval of all copyright
holders.

--
Sébastien
___
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: Relicensing Nautilus to GPLv3+

[Carlos Soriano via desktop-devel-list]

Thanks Sebastien!

For now we won't relicense the files, since that would require copyright 
holders to agree (iiuc). Instead is the project that will become GPL3+, since 
the combination of GPL2+ + GPL3+ files results in a project that is GPL3+.

Best,
Carlos Soriano

 Original Message 
Subject: Re: Relicensing Nautilus to GPLv3+
Local Time: May 25, 2017 11:55 AM
UTC Time: May 25, 2017 9:55 AM
From: swil...@gnome.org
To: desktop-devel-list@gnome.org

Hi,

Just to mention that I've written two scripts that ease changing license
headers:
- gcu-multi-line-substitution
- gcu-smart-c-comment-substitution

available at:
https://github.com/swilmet/gnome-c-utils

Cheers,
Sébastien
___
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: Relicensing Nautilus to GPLv3+

[Carlos Soriano via desktop-devel-list]

Hey A. Walton,

Relicensing from gpl2+ (supposed current nautilus) to lgpl2+ (current gtk+) 
requires agreement of all copyright holders, and the software license is free 
software one.
Relicensing from gpl3+ requires ecxactly the same process, and both are still 
free software licenses.

Do you mean something in particular by "more difficult"?

Best regards,
Carlos Soriano

 Original Message 
Subject: Re: Relicensing Nautilus to GPLv3+
Local Time: May 19, 2017 6:29 AM
UTC Time: May 19, 2017 4:29 AM
From: awal...@gnome.org
To: Ernestas Kulik 
Gnome Release Team , nautilus-list 
, desktop-devel-list 

On Wed, May 17, 2017 at 7:01 AM, Ernestas Kulik  wrote:
> (Attempt no. 2, since Geary hates me)
>
> Hi,
>
> As the current licensing situation in Nautilus is quite complicated, I
> and Carlos are planning a move to relicense the entire codebase to
> GPLv3+.
>
> The codebase has files under several licenses: LGPLv2+, GPLv2+ and
> GPLv3+, the latter implicitly making the project be licensed under its
> terms, so our options are quite limited here.
>
> The situation wrt extensions is also not entirely clear, as the
> extension library is LGPLv2+ with Nautilus being GPLv2+, which in turn
> disallows loading non-free extensions. Given the fact that it is not
> meant to be a generic mechanism for loading extensions, I feel like
> relicensing it without much consideration is reasonable.
>
> If there are no objections, we will make the switch in the following
> week, most likely.

My primary objection is not ideological, but practical - relicensing
Nautilus GPLv3+ means that it becomes more difficult to promote code
from Nautilus to Gtk+, which has happened a significant number of
times in the past and I expect it will continue some into the future.

Stacked with the other reasons (plugins, etc), it just doesn't seem
like a very good idea.

-Andrew Walton.

> Regards,
> Ernestas
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
--
nautilus-list mailing list
nautilus-l...@gnome.org
https://mail.gnome.org/mailman/listinfo/nautilus-list___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Relicensing Nautilus to GPLv3+

[Carlos Soriano via desktop-devel-list]

Ah yes, my bad. For some reason my mind didn't accept the "GPL2-only is 
compatible with GPL2+". All clear now.
 Original Message 
Subject: Re: Relicensing Nautilus to GPLv3+
Local Time: May 19, 2017 12:05 AM
UTC Time: May 18, 2017 10:05 PM
From: had...@hadess.net
To: Carlos Soriano 
release-t...@gnome.org , nautilus-l...@gnome.org 
, Emilio Pozuelo Monfort , Frederic 
Crozat , desktop-devel-list@gnome.org 


On Thu, 2017-05-18 at 15:47 -0400, Carlos Soriano wrote:
> Maybe I didn't explain well. Emilio points out there could one one of
> those extensions that say GPL2+ to link to a GPL2-only library. But
> that would make the extension itself GPL2 anyway, and it's License
> file would have to reflect that initially.

Again, it wouldn't. The combined work would be GPLv2-only, but each one
of the items keeps its own license. The licenses are compatible.

You don't have to have an piece of code depending on the exact same
version of the license if those licenses are compatible. GPLv2-only is
compatible with GPLv2+, as the license mentions for that dependency
says:
"either version 2 of the License, or (at your option) any later
version."

The selection is "made" automatically when you run those 2 items in the
same memory address space (eg. when you "link" them).

> It's just a hipotetical case, I checked the extensions dependencies
> in a quick look and look fine (>= GPL+2).
--
nautilus-list mailing list
nautilus-l...@gnome.org
https://mail.gnome.org/mailman/listinfo/nautilus-list___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Relicensing Nautilus to GPLv3+

[Carlos Soriano via desktop-devel-list]

Maybe I didn't explain well. Emilio points out there could one one of those 
extensions that say GPL2+ to link to a GPL2-only library. But that would make 
the extension itself GPL2 anyway, and it's License file would have to reflect 
that initially.
It's just a hipotetical case, I checked the extensions dependencies in a quick 
look and look fine (>= GPL+2).

 Original Message 
Subject: Re: Relicensing Nautilus to GPLv3+
Local Time: May 18, 2017 9:29 PM
UTC Time: May 18, 2017 7:29 PM
From: had...@hadess.net
To: Carlos Soriano <csori...@protonmail.com>, Emilio Pozuelo Monfort 
<poch...@gmail.com>
release-t...@gnome.org <release-t...@gnome.org>, nautilus-l...@gnome.org 
<nautilus-l...@gnome.org>, desktop-devel-list@gnome.org 
<desktop-devel-list@gnome.org>, Frederic Crozat <f...@crozat.net>

On Thu, 2017-05-18 at 13:50 -0400, Carlos Soriano via desktop-devel-
list wrote:
> Wouldn't that make the actual extension GPL2-but-not-GPL3 comaptible
> since the start, and therefore cannot be GPL2+ project and therefore
> its License file would need to reflect that?

No. nautilus' license says "GPLv2 or later". The extension's license
says "GPLv2 only".

When you combine both licenses into the final product/memory address
space (the "linking" mentioned in the GPL license) you end up with a
"combined work" license of GPLv2.

So it was compatible, but wouldn't be any more.

As mentioned on IRC, I think that the original intent of using the LGPL
for the libnautilus-extensions library was to allow non-GPL-compatible
extensions to link into nautilus, at will. It's not like you could link
to the extensions library without also eventually linking to nautilus
itself...

If that were the case, and that might require some digging to talk to
the original authors, then you might be able to mention this in the
extensions document that was recently (and erroneously) removed.

HTH
___
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: Relicensing Nautilus to GPLv3+

[Carlos Soriano via desktop-devel-list]

Wouldn't that make the actual extension GPL2-but-not-GPL3 comaptible since the 
start, and therefore cannot be GPL2+ project and therefore its License file 
would need to reflect that?

 Original Message 
Subject: Re: Relicensing Nautilus to GPLv3+
Local Time: May 18, 2017 7:02 PM
UTC Time: May 18, 2017 5:02 PM
From: poch...@gmail.com
To: Carlos Soriano <csori...@protonmail.com>, Nicolas Dufresne 
<nico...@ndufresne.ca>
release-t...@gnome.org <release-t...@gnome.org>, nautilus-l...@gnome.org 
<nautilus-l...@gnome.org>, desktop-devel-list@gnome.org 
<desktop-devel-list@gnome.org>, Frederic Crozat <f...@crozat.net>

On 18/05/17 18:22, Carlos Soriano via desktop-devel-list wrote:
> Hello,
>
> After asking some authors of the current code that we have as GPL3+ inside
> nautilus, and pondering for a while, I realized the practicity of moving away
> from that code or convince those authors to relicense as GPL2+ is more a 
> burden
> than the real benefit.
>
> The only problem that arises if Nautilus becomes GPL3+ as per yesteday
> discussion in IRC at #gnome-hackers is that extensions that are GPL2-only 
> cannot
> be used anymore.
> Keep in mind GPL2+ are fine.
>
> Said this, I took a look at extensions which are not retired from distros and
> that have seen a release in at least the last 3 years. So far they are:
> nautilus-dropbox - GPL3+
> nautilus-image-converter - GPL2+
> nautilus-pastebin - GPL2+
> nautilus-python - GPL2+
> nautilus-search-tool - GPL2+
> nautilus-sendto - GPL2+
> nautilus-terminal - GPL2+
>
> Which is completely fine.

As someone already mentioned, if any of those extensions links to a
non-GPL3-compatible library, then they won't be compatible with a GPL3+
nautilus. In other words, extensions are now forbidden from linking to
GPL2-but-not-GPL3-compatible libraries. I don't know whether there are any
examples of extensions that do this. Just thought I'd point this out so the
final decision is an informed one.

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

Re: Relicensing Nautilus to GPLv3+

[Carlos Soriano via desktop-devel-list]

Ah good catch, thanks!

The copyright is holded by only one person, so he can freely change it the 
plugin is still maintained.

Best regards,
Carlos Soriano

 Original Message 
Subject: Re: Relicensing Nautilus to GPLv3+
Local Time: May 18, 2017 6:54 PM
UTC Time: May 18, 2017 4:54 PM
From: mbi...@gmail.com
To: Carlos Soriano <csori...@protonmail.com>
release-t...@gnome.org <release-t...@gnome.org>, nautilus-l...@gnome.org 
<nautilus-l...@gnome.org>, Frederic Crozat <f...@crozat.net>, 
desktop-devel-list@gnome.org <desktop-devel-list@gnome.org>

017-05-18 18:22 GMT+02:00 Carlos Soriano via desktop-devel-list
<desktop-devel-list@gnome.org>:

> The only problem that arises if Nautilus becomes GPL3+ as per yesteday
> discussion in IRC at #gnome-hackers is that extensions that are GPL2-only
> cannot be used anymore.
> Keep in mind GPL2+ are fine.
>
> Said this, I took a look at extensions which are not retired from distros
> and that have seen a release in at least the last 3 years. So far they are:
> nautilus-dropbox - GPL3+
> nautilus-image-converter - GPL2+
> nautilus-pastebin - GPL2+
> nautilus-python - GPL2+
> nautilus-search-tool - GPL2+
> nautilus-sendto - GPL2+
> nautilus-terminal - GPL2+

I found the tortoise-hg plugin in the Debian archive, which seems to
be GPL2 only
https://sources.debian.net/src/tortoisehg/4.0-1/contrib/nautilus-thg.py/

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
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: Relicensing Nautilus to GPLv3+

[Carlos Soriano via desktop-devel-list]

Hello,

After asking some authors of the current code that we have as GPL3+ inside 
nautilus, and pondering for a while, I realized the practicity of moving away 
from that code or convince those authors to relicense as GPL2+ is more a burden 
than the real benefit.

The only problem that arises if Nautilus becomes GPL3+ as per yesteday 
discussion in IRC at #gnome-hackers is that extensions that are GPL2-only 
cannot be used anymore.
Keep in mind GPL2+ are fine.

Said this, I took a look at extensions which are not retired from distros and 
that have seen a release in at least the last 3 years. So far they are:
nautilus-dropbox - GPL3+
nautilus-image-converter - GPL2+
nautilus-pastebin - GPL2+
nautilus-python - GPL2+
nautilus-search-tool - GPL2+
nautilus-sendto - GPL2+
nautilus-terminal - GPL2+

Which is completely fine.

Now, there is an issue with Totem plugin for Nautilus which adds a custom page 
to the properties page, since Totem is GPL2+ with a special clause for 
propietary gstreamer plugins.
However, that was already an unnoticed issue.
I don't want to get much deeper into all of this, given that being unnoticed 
for so long time probably means in practicity it doesn't matter much.
We will work on a workaround for this though, making this feature available 
through DBUS where this doesn't apply.

Given this, we will continue to our plan to relicense Nautilus project to GPL3+ 
next week if nothing serious gets noticed.

Best regards,
Carlos Soriano

 Original Message 
Subject: Re: Relicensing Nautilus to GPLv3+
Local Time: May 17, 2017 6:49 PM
UTC Time: May 17, 2017 4:49 PM
From: nico...@ndufresne.ca
To: Frederic Crozat , nautilus-l...@gnome.org
release-t...@gnome.org, desktop-devel-list@gnome.org

Le mercredi 17 mai 2017 à 14:55 +, Frederic Crozat a écrit :
> Le mer. 17 mai 2017 à 16:02, Ernestas Kulik  a
> écrit :
> > (Attempt no. 2, since Geary hates me)
> >
> > Hi,
> >
> > As the current licensing situation in Nautilus is quite
> > complicated, I
> > and Carlos are planning a move to relicense the entire codebase to
> > GPLv3+.
> >
> > The codebase has files under several licenses: LGPLv2+, GPLv2+ and
> > GPLv3+, the latter implicitly making the project be licensed under
> > its
> > terms, so our options are quite limited here.
> >
> > The situation wrt extensions is also not entirely clear, as the
> > extension library is LGPLv2+ with Nautilus being GPLv2+, which in
> > turn
> > disallows loading non-free extensions. Given the fact that it is
> > not
> > meant to be a generic mechanism for loading extensions, I feel like
> > relicensing it without much consideration is reasonable.
>
> I know at least one proprietary extension for Nautilus (integration
> with Synology NAS product) and I'm not sure we should prevent
> proprietary extensions to be used for Nautilus.

You can just mimic Totem exception clause. This is used to allow
proprietary GStreamer plugins.

https://git.gnome.org/browse/totem/tree/COPYING#n345

regards,
Nicolas___
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

[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 
Carlos Soriano , desktop-devel-list@gnome.org 
, Bastien Nocera 

Hi,

On Wed, May 17, 2017 at 5:59 PM, Mathieu Bridon  wrote:
> On Wed, 2017-05-17 at 17:44 +0200, Jehan Pagès wrote:
>> On Wed, May 17, 2017 at 5:01 PM, Mathieu Bridon > > wrote:
>> > On Wed, 2017-05-17 at 16:47 +0200, Jehan Pagès wrote:
>> > > IMO this is a completely broken and over-complicated workflow.
>> > > For
>> > > long term contributors, having their own remote can be
>> > > understandable.
>> > > But for one-time contribs?
>> >
>> > One-time contributions can be done entirely in the web UI, for
>> > example:
>>
>> Ok. Sorry but no.
>> I code in my text editor, not in my browser.
>
> That's fine, me too.
>
> But you're not a one-time contributor to GNOME, are you?

GNOME is a lot of projects. I have been a one-time contributor to
several GNOME projects and will likely continue to do so for the same
or other projects. Even though I have a GNOME git account, I
(obviously) don't push to random projects which never heard of me. I
am still going through the normal bugzilla procedure and will continue
to go through the normal gitlab procedure if the migration is done.

> Remember that I'm responding to your thread about how the fork+merge-
> request workflow is too complex for trivial one-time contributions.
>
>> > For one-time contributions, this is a **much** simpler workflow
>> > than cloning the repository, making the changes, committing the
>> > change, making a patch, then sending the patch by email/bugzilla.
>> > It even enables non-technical people to contribute!
>>
>> Well much simpler for developers who like to push buttons. We are
>> many who don't like this. Let's not generalize!
>>
>> Also such patches are acceptable for very simple stuff. For instance
>> typo fixes, or string fixes, or similar.
>
> Well yes, that's exactly what this thread was about: simple one-time
> contribution that are so trivial that they make the fork+merge-request
> workflow prohibitive.

Since I kind of started the discussion on this topic, it's good to
assume I know what it is about. I never discussed about trivial
contributions, and I don't think to remember anyone else discussing on
this topic as an answer to my emails.

So no, the discussion was on the contribution workflow (for people who
don't push directly, but will make bug reports/merge
requests/patches/etc. Most of them being one-time contributors).

>> But other than this, even
>> one-liners of actual code, I don't want to encourage people who do
>> things without actually testing (and expecting us to test for them).
>
> That's why you have a CI that runs before merging.
>
>> > And if I send you a patch, you might find it easier to test it
>> > locally. But that completely bypasses your pre-merge CI.
>>
>> CI test basic stuff like "it builds", and "the tests don't fail". But
>> there is much more in a patch than this.
>
> A CI can do pretty much anything you want it to, it's not limited to
> "basic stuff" at all.

Yes you can do tests for a lot of things. Anything is scriptable. It
doesn't mean that everything is scripted in tests. Otherwise software
who succeed all the tests would have no bugs by definition.
So we still need to test many things manually.

>> Of course, you could say that the tests should include every case.
>> But the fact is that if there is a bug that was not seen before, that
>> probably means there is no tests for it (otherwise we'd have seen
>> it!). Even if we add a test, then we have to check first that the
>> test is fine by building locally. Back to square 1.
>
> And the person doing that is not the one-time contributor, but you, the
> maintainer.

Yes, which is why I say that I still test the patches locally before
pushing and don't rely only on CI.

> Seriously, you started complaining that the fork+clone is too 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 

Re: Relicensing Nautilus to GPLv3+

[Carlos Soriano via desktop-devel-list]

There are few by error.
The important cases are lineup-parameters used for uncrustify, and the 
threatics part from gnome-builder.
However, we already spent time on implementing our own thing in the past with 
git-archive-all (GPLv3+) when meson couldn't handle it, so I would like to 
prevent this from happening again and avoid us the work with asking few 
upstreams to relicense based on our needs, and rather switch to GPL3+ where 
most of the tools are.

Best regards,
Carlos Soriano

 Original Message 
Subject: Re: Relicensing Nautilus to GPLv3+
Local Time: May 17, 2017 4:59 PM
UTC Time: May 17, 2017 2:59 PM
From: had...@hadess.net
To: Michael Catanzaro 
Ernestas Kulik , nautilus-l...@gnome.org, 
desktop-devel-list@gnome.org, release-t...@gnome.org

On Wed, 2017-05-17 at 09:45 -0500, Michael Catanzaro wrote:
> On Wed, May 17, 2017 at 9:20 AM, Bastien Nocera 
> wrote:
> > If nautilus is GPLv3+, that means we can't link it against GPLv2-
> > only
> > or LGPLv2-only libraries in the extensions. I'm also not opening
> > the
> > can of worms that is non-GPL-compatible dependencies of extensions
> > (such as proprietary, or patent-encumbered GStreamer plugins),
> > because
> > that's an existing problem.
> >
> > What's the end goal for relicensing? What problems do the current
> > license cause that require a relicense?
> >
> > Cheers
>
> Sounds like the license is already GPLv3+, since it uses GPLv3+
> source
> files, and the existing GPLv2+ notices are incorrect or misleading.

Were those licenses applied in error, or imported from projects that
were GPLv3 themselves?
--
nautilus-list mailing list
nautilus-l...@gnome.org
https://mail.gnome.org/mailman/listinfo/nautilus-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

[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 
desktop-devel-list 

Hi,

On Wed, May 17, 2017 at 1:50 PM, Carlos Soriano  wrote:
> So the main problem is autotools rebuilds everything when switching
> branches, even if the files didn't change?
> That's sounds very strange, autotools builds based on mtime of the files,
> and I checked this personally.

Yes that's how autotools works.

> Are you sure of the reason of this situation? Could it be because the branch
> is not rebased properly on top of the master branch (and the UI in GitLab
> will say so, so the contributor will need to do it because otherwise there
> is no fast forward merge anyway)?

As I said in the email you answer, that's the most obvious reason, yes. :-)
Quoting myself:

> actually for good reasons sometimes; for instance often the branch would be 
> based on older commits than master HEAD

The contributor will usually work on master and when one pushes, it
would be usually properly rebased (though while one worked, there
would usually be commits). Then patches are rarely immediately
reviewed the next few minutes! It may be days until we make time to do
so. You cannot ask a contributor to rebase the branch constantly and
immediately at the second when you want to review (they also have
their own schedules and not at our orders!). Even more if you review
it in several steps accross several days (which could happen for
complicated patch).
So no, we are usually the ones to rebase the contributor's branch.
That means, when we do rebase, it's too late. We already checked out
the branch, file timestamps changed and are not going to be reverted.
So the next `make` will be long, even if we rebased.

GIMP has commits nearly every day, and very often many commits a day.
You cannot expect the contributor branches to be always up to date
with master. They will always be at least a few commits late. And even
more since we don't review straight away.

Jehan

> Best regards,
> Carlos Soriano
>
>  Original Message 
> Subject: Re: Proposal to deploy GitLab on gnome.org
> Local Time: May 17, 2017 1:41 PM
> UTC Time: May 17, 2017 11:41 AM
> From: jehan.marmott...@gmail.com
> To: Carlos Soriano 
> desktop-devel-list 
>
> Hi,
>
> On Wed, May 17, 2017 at 1:05 PM, Carlos Soriano 
> wrote:
>> Hey Jehan,
>>
>> Knowing that core contributors like you and GIMP maintainers will have
>> access to the repo, are the sporadic contributions still many enough
>> enough
>
> Yes we still have regular one-time contributions. If anything, we are
> the ones who don't review them fast enough, though we have been
> getting better now and try to review external patches in a more timely
> fashion.
>
>> for fetching a remote being inconvenient? Is it because it takes
>> considerably more time to fetch a repo than download and applying a patch?
>
> It does take more time indeed. But the most annoying part is having to
> switch branches. When you checkout another branch, autotools gets
> confused and will re-build much more than what it should have if I
> just applied the patch (actually for good reasons sometimes; for
> instance often the branch would be based on older commits than master
> HEAD). So you transform a 10-second builds into a 10-minute build
> (this is *not* exageration; if the patch is on a plugin or even on
> most of the core for instance, the rebuild will be very quick; but if
> it starts rebuilding libgimp*, then we are doomed!).
> When it's a separate remote, I even wonder if git will still make the
> link between the 2 remotes? Will it try to rebuild everything from
> scratch? This would be absolutely terrible.
>
> What I would do to test a patch is:
> - wget
> - git apply (this won't make a commit so I won't push it by mistake)
> - test it. If it looks good…
> - git checkout -- .
> - git am
> - Optionally fix minor stuff and amend, edit the commit message if needed.
> - git push
>
> If the patch looks really simple and obviously good from the basic
> visual review, I would just ignore the `git apply` steps. Just git am,
> test, push. This can all be done in 15 minutes. In these 15 minutes,
> the procedure and rebuild could take just 2 or 3 minutes; the 10+
> additional minutes are because I do thorough tests even for small
> patches.
>
> If I am forced to checkout another branch, the procedure + build would
> be suddenly extremely long and boring.
>
> 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 

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 
desktop-devel-list 

Hi,

On Wed, May 17, 2017 at 1:05 PM, Carlos Soriano  wrote:
> Hey Jehan,
>
> Knowing that core contributors like you and GIMP maintainers will have
> access to the repo, are the sporadic contributions still many enough enough

Yes we still have regular one-time contributions. If anything, we are
the ones who don't review them fast enough, though we have been
getting better now and try to review external patches in a more timely
fashion.

> for fetching a remote being inconvenient? Is it because it takes
> considerably more time to fetch a repo than download and applying a patch?

It does take more time indeed. But the most annoying part is having to
switch branches. When you checkout another branch, autotools gets
confused and will re-build much more than what it should have if I
just applied the patch (actually for good reasons sometimes; for
instance often the branch would be based on older commits than master
HEAD). So you transform a 10-second builds into a 10-minute build
(this is *not* exageration; if the patch is on a plugin or even on
most of the core for instance, the rebuild will be very quick; but if
it starts rebuilding libgimp*, then we are doomed!).
When it's a separate remote, I even wonder if git will still make the
link between the 2 remotes? Will it try to rebuild everything from
scratch? This would be absolutely terrible.

What I would do to test a patch is:
- wget
- git apply (this won't make a commit so I won't push it by mistake)
- test it. If it looks good…
- git checkout -- .
- git am
- Optionally fix minor stuff and amend, edit the commit message if needed.
- git push

If the patch looks really simple and obviously good from the basic
visual review, I would just ignore the `git apply` steps. Just git am,
test, push. This can all be done in 15 minutes. In these 15 minutes,
the procedure and rebuild could take just 2 or 3 minutes; the 10+
additional minutes are because I do thorough tests even for small
patches.

If I am forced to checkout another branch, the procedure + build would
be suddenly extremely long and boring.

Now I don't say that there is no alternative. I guess what I would do
is: fetch the remote (don't checkout it), then cherry-pick only the
commit. This way, I avoid a stupid rebuild of useless stuff. It's
still not as good as previously since it will still take longer, and I
lose the `git apply` step, which is the step which allows me to work
and test patches on master without fearing making a stupid push
mistake. Now here too there are workarounds, like I could git reset
immediately to get rid of the commit (still keeping the code), but
that makes a lot of workarounds now! ;P

So yeah, that's not as bright and simple as it could be.

Jehan

> Cheers,
> Carlos Soriano
>
>  Original Message 
> Subject: Re: Proposal to deploy GitLab on gnome.org
> Local Time: May 17, 2017 12:47 PM
> UTC Time: May 17, 2017 10:47 AM
> From: jehan.marmott...@gmail.com
> To: Tristan Van Berkom ,
> desktop-devel-list 
>
> Hi,
>
> On Wed, May 17, 2017 at 12:33 PM, Sébastien Wilmet 
> wrote:
>> On Tue, May 16, 2017 at 11:15:51PM +0900, Tristan Van Berkom wrote:
>>> I don't share your optimism about gitlab bug tracking, nor do I share
>>> in the mentioned frustration with bugzilla.
>>
>> Me too, I like bugzilla (but not for doing code reviews).
>>
>> What would be the pain points if GitLab is used only for git and code
>> reviews, and we keep bugzilla for the bug tracker? Have you considered
>> that option?
>>
>> We would loose automatic links between bug tracker tickets and pull
>> requests. When a pull request is merged, we would need to close manually
>> the bugzilla ticket if everything is done. And when someone requests a
>> pull, the person would need to add a comment manually on bugzilla so
>> that other people know that the bug is being worked on.
>>
>> Mmh I think that's not practical if the links must be done manually.
>>
>> Maintaining the bugzilla instance would also require sysadmin time, and
>> development efforts to rebase the patches to new bugzilla versions.
>>
>> I don't 

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 , desktop-devel-list 


Hi,

On Wed, May 17, 2017 at 12:33 PM, Sébastien Wilmet  wrote:
> On Tue, May 16, 2017 at 11:15:51PM +0900, Tristan Van Berkom wrote:
>> I don't share your optimism about gitlab bug tracking, nor do I share
>> in the mentioned frustration with bugzilla.
>
> Me too, I like bugzilla (but not for doing code reviews).
>
> What would be the pain points if GitLab is used only for git and code
> reviews, and we keep bugzilla for the bug tracker? Have you considered
> that option?
>
> We would loose automatic links between bug tracker tickets and pull
> requests. When a pull request is merged, we would need to close manually
> the bugzilla ticket if everything is done. And when someone requests a
> pull, the person would need to add a comment manually on bugzilla so
> that other people know that the bug is being worked on.
>
> Mmh I think that's not practical if the links must be done manually.
>
> Maintaining the bugzilla instance would also require sysadmin time, and
> development efforts to rebase the patches to new bugzilla versions.
>
> I don't know, I'm excited about the idea to use a similar contribution
> workflow as in GitHub, but less excited about having a bug tracker
> similar to the GitHub one. (I've never used GitLab, but I'm familiar
> with GitHub, and after seeing some screenshots it seems that the GitLab
> bug tracker is similar to GitHub's).

I like bugzilla too and guess it probably does more than github/lab
bug trackers. But I also know there are annoying parts. Like someone
noted that searching projects in the long list of GNOME projects is
terrible experience (I even have a browser keyword so that I don't
have to do this anymore, because it was so annoying; but obviously new
contributors would not have such shortcuts).

Also the fact that the reports actually have less options is not bad
IMO. One gets lost in all these bz options. Simplicity is good
sometimes. :-)
gitlab has cool features too, like it's much easier to mention someone
to have them take a look at a report, for instance.
And finally, as you say, code review is much better. I like that you
can annotate line per line (easier for the reviewee in particular to
understand our review).

Bottom line: I definitely don't think we should keep both bz and
gitlab in the end.

The only thing I am annoyed at is this forking workflow. Both as a
contributor, and as a code committer/reviewer. Having to fetch a new
remote for every single-commit contribution out there is terrible.

Jehan

> --
> Sébastien
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list

--
ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal to deploy GitLab on gnome.org

[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 , Jehan Pagès 

desktop-devel-list@gnome.org

On Wed, 2017-05-17 at 11:33 +0200, Sébastien Wilmet wrote:
>

> Most developers are more familiar with the GitHub workflow, I think
> it's
> an easier workflow than attaching a patch to a bugtracker ticket.
> Once
> the contributor has pushed a branch on the fork repo, all the rest
> can
> be done from the web interface by clicking on some buttons.

I absolutely hate this workflow, fwiw. I prefer being able to run "git-
bz" to both create and apply patches, rather than keeping a clone with
a bunch of patches in my own org, or remembering the commands to push a
repo to my own repo from the upstream clone.

I hope there will be a git-bz equivalent available.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal to deploy GitLab on gnome.org

[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

[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

[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 
Michael Catanzaro , Allan Day , 
desktop-devel-list 

Hi,

It's quite hard to get commit access atm because you have to be
trusted initially. If a maintainer can give commit access to one repo
he/she watches anyway there is less trust needed in the beginning. Or
if a new contributor wants to take over an abandoned project.

is that true? I mean you have to have someone with commit access vouch for you 
but that's a pretty low bar. I don't think it should be any lower than that, 
but I also wouldn't want to see it higher than that. GNOME has had open ACLs 
from the beginning and it's a good thing! There's no evidence of abuse, we 
shouldn't go locking everything down just because we can.

IMO, there should be three access tiers:
1) Can report issues and propose fixes
2) Can triage issues
3) Can fix issues

Anything more granular than that is a bad idea. It just introduces artificial 
barriers that people will run into. (What happens when a maintainer goes AWOL ?)

Let's keep things open like we always have!
--Ray___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal to deploy GitLab on gnome.org

[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 

On Tue, May 16, 2017 at 3:22 PM, 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].

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

Re: Proposal to deploy GitLab on gnome.org

[Carlos Soriano via desktop-devel-list]

Hello Tristan,

Glad to hear you are positive about the change!

Regarding your concerns, all of them are currently being work by GitLab. A good 
example to know whether GitLab can handle big projects it's to look at GitLab 
itself as we mention in the wiki, here: 
https://gitlab.com/gitlab-org/gitlab-ce/issues where they have in a single 
project 30.000 bugs, which is hardly 1/3 of our whole Bugzilla instance at 
GNOME.
Needless to say the first interested in GitLab issues working well are 
themselves.

Said that, over these 3 months of testing, what I saw is that every single 
concern or proposal I though GitLab Issues could manage better was either 
implemented or in the works. Their developing pace is actually quite 
impressive. So I expect more polishing in this part.
You can take a look at their "changelogs" between releases (one each month). 
For example this last release, you can overview how many features they do in a 
month of work 
https://about.gitlab.com/2017/04/22/gitlab-9-1-released/#protected-tags-ce-ees-eep

Cheers,
Carlos Soriano

 Original Message 
Subject: Re: Proposal to deploy GitLab on gnome.org
Local Time: May 16, 2017 4:15 PM
UTC Time: May 16, 2017 2:15 PM
From: tristan.vanber...@codethink.co.uk
To: Allan Day , desktop-devel-list 


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

Hi !

I'd first like to say that I would love it that we embrace gitlab and
run our own gitlab instance to manage GNOME's gits.

There are some great features we can leverage, the ones I'm most
interested in are:

o Pre merge CI pipelines manageable on a per-project basis, this
is really great

o Merge requests (need I say more ?)

o Pages are also a great feature, if we could have that to allow
projects to setup their own pages deployments from their
.gitlab-ci.yml, that would be a bonus.

However I'm not sure if that would be too much of a radical change
from the experience we have now with developer.gnome.org and the
wiki.

I don't share your optimism about gitlab bug tracking, nor do I share
in the mentioned frustration with bugzilla. However if I need to trade
what I believe to be a far superior bug tracking infrastructure for a
weaker one provided by gitlab, the other benefits far outweigh the
loss.

Regarding bug tracking, these are some things I think are important,
some of which gitlab already handles fine, others not so much:

o For a relatively "stable" software, I want to keep hundreds of
bugs open at all times, and I want to ideally view them and sort
them, and not have to click through this annoying "pagination"

A bug tracker holds a _lot_ of importance to me in how I like
to manage and document the development of a project, arguably
as much as the source itself; even if an enhancement requests
lays dormant in bugzilla for years, It's always great to have
a full documentation of what you could potentially be doing
better.

o Dependencies, I like that with bugzilla we can make one bug
depend on another, with this we achieve interesting things,
like graphing out the dependencies which lead to a symbolic
milestone.

Yes, I can track milestones on a wiki page or with another
moving part, but then I tend to lose posterity; documenting
as much as possible in your bug tracker helps you to track
the whole project history in one place.

o Real attachments, and a good view of them if possible with
syntax highlighting is great.

I dont like to accept bug reports which contain links out to
external resources if and when at all possible, this makes it
difficult to have good posterity.

If I want to go back in time and remember why this bug was
reproducing last year, I need to have a real attachment (for
example a glade file) and be sure that I'm not stuck with a
link to a resource which may have changed since last year (i.e.
a link to someone's git branch) or disappeared altogether.

o Good email notifications, and hopefully some granularity on
what events I want to listen and be notified for.

Again, gitlab does *some* of this stuff well, but I feel that it's just
good enough for the typically small jquery plugin like projects that
you tend to find hosted on github.

I could not imagine what it might be like to track all the bugs of the
linux kernel, GTK+ bug history, or mozilla, any serious project with
gitlab, the throughput seems to be much too high, while the main
benefits I can see are:

o Automatic integration with the rest of gitlab for free (nice
to have merge requests notify the issues automatically without
having to reference in bug comments, etc). Of course this also
means you have one account for both your git and your bug tracking.

o A bootstrapy JS user interface instead of a more old fashioned UI
(I dont think this is a reasonable argument to trade away a
powerful bug tracker for this alone, though).

All of that said, I am 

Re: Proposal to deploy GitLab on gnome.org

[Carlos Soriano via desktop-devel-list]

Hello Hubert,

Glad to hear you are supportive of the idea.
Regarding your questions:
1- will URL to cgit be remapped to the gitlab instance?
Last time I checked with Andrea and Alberto that was the plan.
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.
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.

Best regards,
Carlos Soriano

 Original Message 
Subject: Re: Proposal to deploy GitLab on gnome.org
Local Time: May 16, 2017 4:09 PM
UTC Time: May 16, 2017 2:09 PM
From: h...@figuiere.net
To: desktop-devel-list 

On 16/05/17 09:22 AM, 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'm totally supportive of the idea. While it is a proposal, I just have
a couple of questions about the migration:

1. will URL to cgit be remapped to the gitlab instance so that any link
to any specific commmit still point to the proper place? Commit sha1 are
immutable so it is a matter of having a proper redirector where cgit
lives... unless the cgit instance is kept alive.

2. what are the migration plans for bugzilla: bugzilla URL, bug numbers
and the actual content?

I know none of these are easy to implement. Let me know how I can help.

Cheers,

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

[Carlos Soriano via desktop-devel-list]

Hello Richard,

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?

In this way we can evaluate the positive impact this initiative would have.

Cheers,
Carlos Soriano

 Original Message 
Subject: Re: Proposal to deploy GitLab on gnome.org
Local Time: May 16, 2017 3:48 PM
UTC Time: May 16, 2017 1:48 PM
From: hughsi...@gmail.com
To: Allan Day 
desktop-devel-list 

On 16 May 2017 at 14:22, 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 great news. Over the last few years I've started most of my
new projects on GitHub and then had to begrudgingly move them to
git.gnome.org for the translator teams and so that other people can do
drive-by fixes. GitLab would make this unnecessary and make it easier
for me to work with other people easily on reviews and PRs without all
the bugzilla spam. Certainly a huge +1 from me.

Richard.
___
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: Stackexchange community for GNOME/GTK+

[Carlos Soriano via desktop-devel-list]

Is there some public place that offer something similar as AskFedora to create 
a community for GNOME?
I think one requirement for us is to not host it ourselves, and still be 
relevant.
I guess that's why Sri choose Stackexchange. But I don't know other 
alternatives.

Carlos Soriano

 Original Message 
Subject: Re: Stackexchange community for GNOME/GTK+
Local Time: May 10, 2017 3:04 PM
UTC Time: May 10, 2017 1:04 PM
From: mike.catanz...@gmail.com
To: liberfo...@freeside.fr
newcomers-l...@gnome.org, gtk-devel-list , 
desktop-devel-list 

And it's already closed as a duplicate of Stack Overflow.

Looks like if you want to do this, we'd have to host it using free
software like Ask Fedora does.

Michael

___
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: For projects switching to Meson *only*

[Carlos Soriano via desktop-devel-list]

Hello Emmanuele,

Would be fine if the maintainer does the patch for continuous instead of doing 
the build-API?

Carlos Soriano

 Original Message 
Subject: For projects switching to Meson *only*
Local Time: 27 April 2017 10:45 AM
UTC Time: 27 April 2017 08:45
From: eba...@gmail.com
To: Desktop Development List 

Hi everyone;

since maintainers have started switching to Meson for the development
cycle (awesome!) I'd like to ask for a favour: if you're dropping
autotools entirely, could you please add a `configure` wrapper script
that conforms to the build-api[1] that GNOME Continuous uses?

A simple script is available here[2], and it has nice properties, like
being able to work with a simple:

./configure
make
sudo make install

which makes distributors and integrators happy.

Before you ask: yes, I'm looking at adding Meson support to
Continuous, as part of a larger rework of the manifest file to adapt
to the Flatpak builder manifest format; that will take time, though,
so in the interim it'd be great if we didn't have to ship a patch for
every project, when the alternative is simply dropping a script into
the project's top-level.

Ciao,
Emmanuele.

[1]: https://github.com/cgwalters/build-api
[2]: https://github.com/ebassi/graphene/blob/master/configure

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

Re: GitHub Development Platform for GNOME

[Carlos Soriano via desktop-devel-list]

Hello Walter,

Yes, using non-free software for something as important as our infraestructure 
is problematic for most of the GNOME community. GitHub is not a feasible option 
for the time being. Other alternatives that are free software can be and are 
being taken into account, and that's the path we should lead.

Best regards,
Carlos Soriano

 Original Message 
Subject: GitHub Development Platform for GNOME
Local Time: April 9, 2017 9:44 PM
UTC Time: April 9, 2017 7:44 PM
From: waltervar...@linux.com
To: desktop-devel-list@gnome.org

I want to share my humble opinion and thoughts about GitHub/GitLab:

I get worried about the long-term viability of the GNOME project after running
an iteration over OODA Loop (observe, orient, decide, act)[1].

Canonical's recent decision about not maintaining unity for Ubuntu makes it
quite clear that Desktop is not the priority anymore, IoT and Mobile are the
priority now, and now GitHub is the world leading development platform.

Since the primary goal is to provide a developer experience that does not act as
a barrier to new contributors, Should we be more pragmatic about that and
reconsider GitHub as an option?

Is it a dogmatic foundational decision not to evaluate GitHub because it is not
Free Software?

Kind Regards

[1] https://en.wikipedia.org/wiki/OODA_loop___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GSoC student introduction

[Carlos Soriano via desktop-devel-list]

Hello Armin,

I'm Carlos Soriano, one of the mentors in GNOME.
This project idea looks like a key project for GNOME and I'm sure all of us are 
looking forward to see it happen!

I read your proposal and the points outlined and goals looks good. I understand 
the complexity of Mutter + Wayland prevents you to have a clear idea and 
timeline of it, but I think it will be better if you dig a little more in the 
code and have a clearer idea of it, so a rough timeline can be done. I think 
it's important to know how much time every goal will take and what do you think 
you are capable of, and it's also important for us. But again, I completely 
understand this is going to be difficult for this project.

Also put a link to your previous GSoC and a link to your contributions in other 
FOSS projects so it's easier to evaluate your proposal (this is part of the 
GNOME template, would be nice to have it already since it's an important point 
for the evaluation and it can help the GNOME community to get excited about the 
you and the project :) )

In any case, your potential mentors will help you more on the details. Feel 
free to share with us the final proposal again when it's done.

Looking forward to see your contributions!
Carlos Soriano

 Original Message 
Subject: GSoC student introduction
Local Time: March 24, 2017 9:22 PM
UTC Time: March 24, 2017 8:22 PM
From: krezovic.ar...@gmail.com
To: desktop-devel-list@gnome.org, gnome-shell-l...@gnome.org
kat.g...@gmail.com

Hello everyone,

I am Armin Krezović, and I've decided to apply to Google Summer
of Code to work on Mutter.

I have completed all the necessary steps outlined in [1], and
also written a proposal (can be still considered as a draft),
which can be found at [2]. The proposal was written trying to
answer as many questions outlined in [1], but not all of them
could be answered (at this point, or at all).

I'd like to know if that would pose a problem, and if it could
be improved somehow. I would be thankful to anyone who could
take the time to quickly review the proposal.

Looking forward to working with you.

TIA, Armin.

[1] https://wiki.gnome.org/Outreach/SummerOfCode/Students
[2] 
https://docs.google.com/document/d/1C7iCqTdCZR4aLSHfACfleRFqfKRzojBHKI8C30XHs9k/edit?usp=sharing
___
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: Searching mentor for GSoC Proposal on GNOME Disks

[Carlos Soriano via desktop-devel-list]

Hello Kai!

I'm Carlos Soriano, one of the mentors in GNOME.
It's great you came up with this proposal, and you seem to have a decent 
understanding of the technologies involved, it's great to see you would like to 
tackle this part of the stack. Everyone will love seeing work on this!

Did you try to mention this to Michael or the udisks maintainer?
https://github.com/storaged-project/udisks/blob/master/AUTHORS
And maybe an email to
https://lists.freedesktop.org/mailman/listinfo/devkit-devel?

On possibility is Michael/GNOME can mentor you, or, a co-mentor project could 
arise, the gtk+ part by someone from GNOME/Michael and the udisk part from 
someone from udisks sharing the work.

To be fair is a little late in the GSoC timeline to find a mentor, but I think 
it's possible if your contributions are great!
In case we cannot find a mentor, would you be interested in continue your 
contribution during the year and try again for Outreachy[0] if you are eligible 
or for next year GSoC?

Looking forward to see your contributions!
Carlos Soriano

[0] https://www.gnome.org/outreachy/

 Original Message 
Subject: Searching mentor for GSoC Proposal on GNOME Disks
Local Time: March 24, 2017 3:30 PM
UTC Time: March 24, 2017 2:30 PM
From: kailu...@riseup.net
To: desktop-devel-list@gnome.org

Hello,

after going through many of the listed ideas from organizations in the
Google Summer of Code program, I came to the conclusion that I would
like to propose working on GNOME Disks.

Why?
I use it very often and it mostly does a good job. But recently I had to
use GParted again for resizing and moving partitions and realized that
it can't work in a Wayland session (because it runs as root).
Since the storaged/UDisks transition also might give the chance to work
on related features in UDisks, I think working on GNOME Disks would make
up a good GSoc project in order to provide functionality which was
offered GParted.

What?
The suggestion is to first accurately list available filesystem choices
(needs some UDisk work) and then support resizing and checking. As
moving partitions is not so essential and may be out of scope for UDisk,
this would be at most a stretch goal.
On the way there are other maintenance tasks and the whole project also
reachs out to UDisks/libblockdev for resizing and fixing filesystems.

Is there anyone who would like to be a mentor for me?
https://wiki.gnome.org/Outreach/SummerOfCode/Mentors
I'm in the process of reading code and open bugs reports and have
started working on a new feature with guidance from Michael Catanzaro:
https://github.com/pothos/gnome-disk-utility/tree/create-disk-image

Some words on myself: I'm in the computer science master program at TU
Berlin and finished my bachelor last year at FU Berlin. Up to now I'm
not a great contributor :/ but was at GUADEC in Strasbourg and follow
the planet.gnome.org since many years.

Thank you for reading!
Regards,
Kai

___
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: irc.gimp.org is now available via Matrix (was: Re: Thoughs about communication)

[Carlos Soriano via desktop-devel-list]

Oh I actually talked with Matthew today about this and opened a new bug:

https://github.com/matrix-org/matrix-appservice-irc/issues/390 . In this case 
this is for disabling the spam filter they have so any non-registered user can 
talk with matrix users.

Also regarding Michael advice of not talking to [m] users, that's semi true, 
most of us already change the IRC handler to be our regular IRC nickname, so 
for example I'm csoriano even from Matrix. Which might be an issue if we are 
missing pm's



Best regards,
Carlos Soriano


 Original Message 
Subject: Re: irc.gimp.org is now available via Matrix (was: Re: Thoughs about 
communication)
Local Time: March 14, 2017 5:50 PM
UTC Time: March 14, 2017 4:50 PM
From: mcatanz...@gnome.org
To: Alexandre Franke , Matthew Hodgson 
Desktop Development List 

On Wed, 2017-03-08 at 12:15 +0100, Alexandre Franke wrote:
> Heads up on a quite important issue: some private messages from IRC
> users to Matrix users are not delivered. The IRC user won’t get
> notified and so will never know the messages were lost.
>
> https://github.com/matrix-org/matrix-appservice-irc/issues/382

Hi,

I hit this yesterday and was planning to send a warning to this list,
but I see you've already done so. Here is a reminder. Do not attempt to
send private messages to Matrix users (people with [m] behind their
names) until this is fixed! Your messages will be *silently* dropped
without any notice to you or the intended recipient!

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

GNOME accepted for GSoC

[Carlos Soriano via desktop-devel-list]

Hello all,

GNOME was again accepted for GSoC! \\o//

Thanks to the mentors who've already listed GSoC project ideas! We currently 
have only around 16 GSoC ideas, it would be excellent to have at least four 
more mentors with new ideas for this round, as we are used to be one of the 
biggest organisations and would be awesome to keep it this way :)
If you are interested please add your idea in the wiki [0]. If you are 
interested but don't have any ideas, please contact us at soc-adm...@gnome.org 
or one of the admins [1] on IRC and we will help you find some.

For mentors whose ideas are triaged, it's time to register with us!
Please fill the form [2] and we will invite you to the GSoC program in Google's 
website.
Also, please subscribe to the mentors list [3] if you haven't done so yet. We 
will send required information for mentors in that list.

If you have any question, please don't hesitate to contact us at 
soc-adm...@gnome.org or any of us on IRC [1].

[0] https://wiki.gnome.org/Outreach/SummerOfCode/2017/Ideas
[1] https://wiki.gnome.org/Outreach/SummerOfCode/admins
[2] 
https://docs.google.com/forms/d/e/1FAIpQLSeCuIH2mY7D6aMvQs0jFymTc_7AwEC5lX54NYa24a6bI1pvOw/viewform?usp=sf_link
[3] https://mail.gnome.org/mailman/listinfo/soc-mentors-list

Have a nice day,
GSOC admins___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: irc.gimp.org is now available via Matrix (was: Re: Thoughs about communication)

[Carlos Soriano via desktop-devel-list]

oh excellent, thanks!



Best regards,
Carlos Soriano

 Original Message 

Subject: Re: irc.gimp.org is now available via Matrix (was: Re: Thoughs about 
communication)
Local Time: March 3, 2017 12:02 AM
UTC Time: March 2, 2017 11:02 PM
From: afra...@gnome.org
To: Carlos Soriano <csori...@protonmail.com>
Matthew Hodgson <matt...@matrix.org>, Desktop Development List 
<desktop-devel-list@gnome.org>

On Thu, Mar 2, 2017 at 11:56 PM, Carlos Soriano via desktop-devel-list
<desktop-devel-list@gnome.org> wrote:
> I'm missing some rooms though, like #nautilus or #gnome-photos etc. Are they
> on the bridge and the search is having problems to find them or are they out
> for some reason?

The bridge is for a whole network, not per room. The rooms that appear
in the directory are just the ones for which at least one Matrix user
already joined (so they are “known”). You can join any room as Matthew
described with #_gimpnet_#ircchannelname:matrix.org

--
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: irc.gimp.org is now available via Matrix (was: Re: Thoughs about communication)

[Carlos Soriano via desktop-devel-list]

Excellent news we have matrix bridge, thanks Matthew!

I'm missing some rooms though, like #nautilus or #gnome-photos etc. Are they on 
the bridge and the search is having problems to find them or are they out for 
some reason?



Best regards,
Carlos Soriano


 Original Message 
Subject: Re: irc.gimp.org is now available via Matrix (was: Re: Thoughs about 
communication)
Local Time: March 2, 2017 11:05 PM
UTC Time: March 2, 2017 10:05 PM
From: matt...@matrix.org
To: Alberto Ruiz 
Carlos Soriano , Desktop Development List 



We deliberately don't implement gravatar support as it's a bit of a privacy 
issue, given it lets gravatar track and correlate users across a wide range of 
services. I guess we could provide it as an option though :)

--
Matthew Hodgson
Matrix.org


On 2 Mar 2017, at 22:02, Alberto Ruiz  wrote:


Yeah I just did, the web app went well. I was on the train while trying. This 
is really neat stuff, will gather a bunch of feedback. So far the lack of 
automatic gravatar support comes to mind.



2017-03-02 22:00 GMT+00:00 Sriram Ramkrishna :





On Thu, Mar 2, 2017 at 1:53 PM Alberto Ruiz  wrote:

Tried to register through the Riot mobile app... the register request timed out.



Try the web app version - http://riot.im/

sri






2017-03-02 19:32 GMT+00:00 Matthew Hodgson :

On 03/02/2017 15:57, Matthew Hodgson wrote:


On 3 Feb 2017, at 13:00, Alexandre Franke 
Matthew, anything blocking the bridging on our side?

Nothing blocking at all; it's all on our side, which has ended up
blocked on FOSDEM - we've had to prioritise a sprint to ship new
releases for FOSDEM and are currently all on trains to Brussels. It's
top of the IRC bridging backlog and we should get to it early next
week. Sorry for the delay...


Hi all,

We've finally set up a bridge hosted by matrix.org that links GIMPNet into 
Matrix (as per the earlier bits of this thread). Sorry that it took so long to 
happen: FOSDEM ended up being even crazier than we expected, and we've spent 
the last month handling the traffic increases and operational excitements that 
came off the back of it.

The bridge has been set up to provide access to all of GIMPNet through matrix 
room aliases of form:

#_gimpnet_${channelname}:matrix.org

e.g.

#_gimpnet_#gtk+:matrix.org

The easiest way to use the new bridge is probably through Riot, the current 
flagship Matrix client: URLs for direct access to a room via riot-web are of 
the form:

[https://riot.im/app/#/room/#_gimpnet_#gtk+:matrix.org](https://riot.im/app/#/room/%23_gimpnet_%23gtk+:matrix.org)

You can also join using "/join #_gimpnet_#gtk+:matrix.org" style syntax, or 
using the graphical room directory (button linked from the bottom left).

We haven't turned on guest access on the bridge, so users are forced to 
register an account (and go through a captcha) before joining channels.

You can spot folks connecting via Matrix as by default they have a [m] suffix 
on their nickname.

Feedback very welcome! We are still in beta, and very interested in making sure 
it fits the bill for communities like GNOME :)

Matthew

--
Matthew Hodgson
Matrix.org
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list




--

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



--

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

Re: GNOME goal candidates

[Carlos Soriano via desktop-devel-list]

I think installed test etc it's not going to happen or be maintained if we 
don't enable coverage with it too. I think that's the actual trick that will 
keep us up with the initiative.

So I would go with both since the start, and together.



Best regards,
Carlos Soriano
 Original Message 

Subject: Re: GNOME goal candidates
Local Time: March 1, 2017 8:05 PM
UTC Time: March 1, 2017 7:05 PM
From: swil...@gnome.org
To: desktop-devel-list@gnome.org

On Wed, Mar 01, 2017 at 08:31:24AM -0600, Michael Catanzaro wrote:
> OK, you all have changed my mind. I guess installed tests should be a
> goal.
>
> Do we want to do this for coverage as well...?

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

The page needs to be updated for AX_CODE_COVERAGE. But I would keep it,
at least to have a list of best-practices as Emmanuele said.

--
Sébastien
___
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: GNOME goal candidates

[Carlos Soriano via desktop-devel-list]

Hey,

Good initiative, I agree with the approvals and rejections, except:
For installed tests an coverage... I think we should aim to provide some 
minimum quality, and continuous integration and installed tests is something 
that really help with this and it's pretty common now for every project. You 
are right when you commented about coverage that this highly depends on the 
project, so maybe the goal should apply just to the core modules and apps?

FWIW Nautilus has an internship that is going to be precisely this, installed 
tests and coverage. IMHO we should aim for this in the core, where we are 
really present and the quality of the project is reflected.

Also adding tests is a good newcomers task, so it doesn't necessarily mean a 
lot of work for the maintainer, it can be a good entry point for getting new 
contributors for the module.



Best regards,
Carlos Soriano


 Original Message 
Subject: GNOME goal candidates
Local Time: March 1, 2017 12:12 AM
UTC Time: February 28, 2017 11:12 PM
From: mcatanz...@gnome.org
To: desktop-devel-list@gnome.org

Hi,

One of my action items from the release team meeting at GUADEC was to
go through the GNOME goals page to deal with the backlog of unapproved
goals. (I never said *when* I would do it. ;) Please review this list
and complain if you don't agree with my choices.

It's worth mentioning that some of these goals are VERY old.

I want to immediately approve the following three goals, provided that
their sponsors are willing to update the (now very stale) lists of
affected modules:

https://wiki.gnome.org/Initiatives/GnomeGoals/UseTimeoutAddSeconds
(Javier Jardon)
https://wiki.gnome.org/Initiatives/GnomeGoals/HeaderBars (Allan Day)
https://wiki.gnome.org/Initiatives/GnomeGoals/DBusActivatable (Matthias
Clasen)

I want to punt on the following goals and keep them in the unapproved
candidate list for now:

https://wiki.gnome.org/Initiatives/GnomeGoals/DistCheck
https://wiki.gnome.org/Initiatives/GnomeGoals/ModernAutotools
https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests

I want to reject the following goals:

https://wiki.gnome.org/Initiatives/GnomeGoals/UpdateInfoFiles
https://wiki.gnome.org/Initiatives/GnomeGoals/NicerBuilds
https://wiki.gnome.org/Initiatives/GnomeGoals/AddCodeCoverage
https://wiki.gnome.org/Initiatives/GnomeGoals/ValidateGtkBuilderFiles
https://wiki.gnome.org/Initiatives/GnomeGoals/CorrectIconNames

In order:

Passing distcheck is obviously good, but not useful to spend time on
this now if we wind up creating a Meson goal, which seems likely. We
have enough goals right now as it is. Moreover, this is really
something to be expected of module maintainers rather than a project-
wide goal where everyone would be encouraged to help with different
modules. And our maintainers are not stupid; if they're releasing
modules that don't pass distcheck (vte <_<), something is very
seriously wrong.

The ModernAutotools goal needs to be updated, because best practices
have changed since it was written. We'll need to look this one over
closely before approving it. Additionally, it's not useful to approve
it if we wind up creating a Meson goal instead.

As for the installed test goal, I'm really not convinced that tests
should be installed. The QA team that was enthusiastic about installed
tests seems to have disappeared, so nobody is driving this anymore. I'd
like to see further discussion on this before approving or rejecting
it. Also, I'd like to see if people are still interested in . I kinda
think that traditional make check style testing is still the way to
go

UpdateInfoFiles includes some weirdness like updating FSF address in
all source files, and changing all applications to not use ranges to
indicate copyright years. This is not related to updating info files
and needs to be split out at the very least. But I'm also not sure this
is an appropriate goal candidate anyway. We can update all our README
files now, but they're just going to become stale again in a few years,
and we don't want to re-run this goal every couple of years. That's not
to say we shouldn't update our info files anyway -- of course we
should! -- but that I'm not convinced this should be a project-wide
GNOME goal. (P.S. This goal turns 10 at the end of the March! We should
probably handle goals a bit sooner in the future. ;)

NicerBuilds is just using silent rules. That's already complete for all
GNOME modules, so there's zero reason to approve it as a new goal.

Code coverage would be wonderful, but there is no point in adding
coverage to modules unless the modules' maintainers plan to work on
adding new tests to raise the coverage. We just don't have enough
developers to do this project-wide. Accordingly, coverage should be
pursued on a per-module rather than project-wide basis.

GtkBuilder validation looks like more gook to add to our Automake
files, when we really want less gook there. Even if it's only a small
amount of code, I'd rather 

Re: Thoughs about communication

[Carlos Soriano via desktop-devel-list]

A clarification:
By "moving more channels to it" I mean "implement the bridge in more channels" 
if we see it is successful and we like the outcome. I didn't mean to retire IRC 
channels at all.



Best regards,
Carlos Soriano

 Original Message 
Subject: Re: Thoughs about communication
Local Time: February 3, 2017 1:43 PM
UTC Time: February 3, 2017 12:43 PM
From: desktop-devel-list@gnome.org
To: Sriram Ramkrishna 
Desktop Development List 

Heya,

Should we go ahead then? Sri, let's go with #gnome and #engagement for now? If 
the bridge works out well, we can move more channels to it soon.

I believe only thing needed is Matthew to set it up in matrix.org and gimpe.net 
opers set it up the bridge right?



Best regards,
Carlos Soriano


 Original Message 
Subject: Re: Thoughs about communication
Local Time: January 27, 2017 7:03 PM
UTC Time: January 27, 2017 6:03 PM
From: s...@ramkrishna.me
To: Allan Day 
Desktop Development List 





On Fri, Jan 27, 2017 at 8:55 AM Allan Day  wrote:




On Thu, Jan 26, 2017 at 8:56 PM, Sriram Ramkrishna  wrote:
...






My two cents, and bear with me on my slight rant - I really hate the idea of 
depending on a web app like riot. It's like admitting that we've lost the whole 
application space and that we're going browser. I know that is not what is 
intended, but that will be the perception.

I'd like to do this, but I'd like to start putting resources into creating a 
viable chat client that works and is designed as a competition to a web app. 
Maybe that means some kind of contest or something. I'm not really worried 
about actually writing one after all matrix is an open standard, but the design 
one that shows the advantage of running something native should be a challenge 
that we need to meet head on.




...

While a native chat application would be nice, making it a requirement would be 
a real mistake in my opinion. A couple of reasons for that:

It isn't that I want to make it a requirement. It's more of a challenge given 
the prevalence of web based applications. I just want to make sure that we are 
aware that we are doing that in this particular instance.







First, chat is fragmented. There's no common standard, and whatever we choose 
is going to be one player among many. That puts it in a different category from 
many of our core applications.

A good point. I suppose in this case, nobody will be happy because potential 
contributors would be unhappy that we didn't pick the chat program they are 
using. I know a number of us are using telegram since last GUADEC on occasion.






Second, the GNOME developer community is already spread too thin. One of the 
most pressing questions we have right now is how we can focus our efforts on 
critical areas. In order to do that, we need to leverage other projects and 
initiatives when it benefits us. Because when we try to do everything in house, 
it hurts us, whether it's maintaining our own infrastructure, writing our own 
tools, or implementing every app ourselves. We end up being stuck behind the 
curve.

Yes, I am aware of that and I will always rush first to champion the leveraging 
of other groups and organizations. The social aspects of that is that we also 
become insular when we need to be forging relationships with the groups around 
us.







Obviously we're a community project and people will work on whatever itch they 
want to scratch. I wouldn't discourage someone from working on something if 
that's what they want to do. But that's different from making native apps a 
hard requirement in cases like this.

Just to be clear, I'm not trying to make it a hard requirement, at the moment, 
I just want to get it working and we'll figure out the client part at a later 
date. Today, most people are used to using chat applications either from phone 
or from their desktop using a web browser so I see no pressing need to put 
resources into a client unless it's just a fun project.







We need to learn to tread lightly, embrace new things, and recognise that we 
can't do everything ourselves. If we do that, I think we could find ourselves 
in a pretty exciting place.

I agree completely.

sri






Allan___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Thoughs about communication

[Carlos Soriano via desktop-devel-list]

Heya,

Should we go ahead then? Sri, let's go with #gnome and #engagement for now? If 
the bridge works out well, we can move more channels to it soon.

I believe only thing needed is Matthew to set it up in matrix.org and gimpe.net 
opers set it up the bridge right?



Best regards,
Carlos Soriano


 Original Message 
Subject: Re: Thoughs about communication
Local Time: January 27, 2017 7:03 PM
UTC Time: January 27, 2017 6:03 PM
From: s...@ramkrishna.me
To: Allan Day 
Desktop Development List 





On Fri, Jan 27, 2017 at 8:55 AM Allan Day  wrote:




On Thu, Jan 26, 2017 at 8:56 PM, Sriram Ramkrishna  wrote:
...






My two cents, and bear with me on my slight rant - I really hate the idea of 
depending on a web app like riot. It's like admitting that we've lost the whole 
application space and that we're going browser. I know that is not what is 
intended, but that will be the perception.

I'd like to do this, but I'd like to start putting resources into creating a 
viable chat client that works and is designed as a competition to a web app. 
Maybe that means some kind of contest or something. I'm not really worried 
about actually writing one after all matrix is an open standard, but the design 
one that shows the advantage of running something native should be a challenge 
that we need to meet head on.




...

While a native chat application would be nice, making it a requirement would be 
a real mistake in my opinion. A couple of reasons for that:

It isn't that I want to make it a requirement. It's more of a challenge given 
the prevalence of web based applications. I just want to make sure that we are 
aware that we are doing that in this particular instance.







First, chat is fragmented. There's no common standard, and whatever we choose 
is going to be one player among many. That puts it in a different category from 
many of our core applications.

A good point. I suppose in this case, nobody will be happy because potential 
contributors would be unhappy that we didn't pick the chat program they are 
using. I know a number of us are using telegram since last GUADEC on occasion.






Second, the GNOME developer community is already spread too thin. One of the 
most pressing questions we have right now is how we can focus our efforts on 
critical areas. In order to do that, we need to leverage other projects and 
initiatives when it benefits us. Because when we try to do everything in house, 
it hurts us, whether it's maintaining our own infrastructure, writing our own 
tools, or implementing every app ourselves. We end up being stuck behind the 
curve.

Yes, I am aware of that and I will always rush first to champion the leveraging 
of other groups and organizations. The social aspects of that is that we also 
become insular when we need to be forging relationships with the groups around 
us.







Obviously we're a community project and people will work on whatever itch they 
want to scratch. I wouldn't discourage someone from working on something if 
that's what they want to do. But that's different from making native apps a 
hard requirement in cases like this.

Just to be clear, I'm not trying to make it a hard requirement, at the moment, 
I just want to get it working and we'll figure out the client part at a later 
date. Today, most people are used to using chat applications either from phone 
or from their desktop using a web browser so I see no pressing need to put 
resources into a client unless it's just a fun project.







We need to learn to tread lightly, embrace new things, and recognise that we 
can't do everything ourselves. If we do that, I think we could find ourselves 
in a pretty exciting place.

I agree completely.

sri






Allan___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Thoughs about communication

[Carlos Soriano via desktop-devel-list]

Hey Sri,

I want to see this happen too and I encouraged Alberto to start this thread, he 
proposed the same as you, using #newcomers channel as one of the precursors, 
since is one of the first channels for new people.

However, I think #newcomers is not the best place to experiment, things are 
alteady all confusing and hard (from a newcomer perspective) and adding two 
ways of communication and in the experiment phase is going to make it worse.

Instead we can add #gnome-hackers or so, where there are quite a few people (I 
would love to have #nautilus too, regular contributors agreed on 
experimenting), and once we agree on matrix or whatever then switch #newcomers 
to matrix or whatever as single documented way of comunication.

Just my 2 cents :)

Carlos Soriano
 Original Message 
On 26 Jan 2017, 21:56, Sriram Ramkrishna wrote:




On Fri, Jan 13, 2017 at 7:47 AM Allan Day < allanp...@gmail.com> wrote:





Attracting and retaining contributors has to be the most important 
consideration. It's worth noting that IRC cuts in a few different directions 
here: on the one hand, IRC means there's no barrier between us and all the 
existing Free Software contributors/projects who are also using IRC. On the 
other hand, for contributors who are used to modern tools, IRC probably feels 
like a huge step backwards - it isn't user friendly, isn't attractive, and it 
doesn't work well if you're not in one of the time zones that are popular with 
our community.


In some ways, GNOME has the worst of both worlds - we're using poor tech which 
has the advantage of adoption, and then we go and use a relatively isolated 
server, so we miss out on the additional traffic we might get on Freenode.


Let me add my two cents here. I've been wanting to do something like this for 
some time and as Allan has alluded to, there has been discussions amongst 
engagement team people around this.

My two cents, and bear with me on my slight rant - I really hate the idea of 
depending on a web app like riot. It's like admitting that we've lost the whole 
application space and that we're going browser. I know that is not what is 
intended, but that will be the perception.

I'd like to do this, but I'd like to start putting resources into creating a 
viable chat client that works and is designed as a competition to a web app. 
Maybe that means some kind of contest or something. I'm not really worried 
about actually writing one after all matrix is an open standard, but the design 
one that shows the advantage of running something native should be a challenge 
that we need to meet head on.

That said, we'll table that bit for now. I have talked to Andrea Veri, they are 
kind of low on sysadmin resources and probably can't help in the immediate 
future in implementing something.

Seeing as I have some free time; I asked Andrea if it was okay if I could 
spearhead this particular project. A good way introduce myself back to devops 
after a long hiatus. He seemed to agree, so I can start looking into at least 
creating the irc bridge between matrix and some specific rooms - #engagement, 
#newcomers, and #docs. I've picked these as the kind of contributors we have 
tend to be quite varied, but also there are differences in culture and 
etiquette between irc and these other technologies that can be disruptive.

sri___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Sick day today

[Carlos Soriano via desktop-devel-list]

omg sorry all



 Original Message 
On 25 Jan 2017, 11:56, Bastien Nocera wrote:

On Wed, 2017-01-25 at 05:55 -0500, Carlos Soriano Sanchez wrote:
> Got down again

At least it's a sick note, not a rant like Behdad sent to the wrong
list ;)
___
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: Github's pull requests and GNOME

[Carlos Soriano via desktop-devel-list]

Thanks Andrea,

I will take into account you are referencing the CodeContributionWorkflow page 
from outside the newcomers guided wiki, since we were planing a new revamp, 
this might worth to take into account.



Best regards,
Carlos Soriano

 Original Message 
Subject: Github's pull requests and GNOME
Local Time: 29 November 2016 4:00 PM
UTC Time: 29 November 2016 15:00
From: a...@gnome.org
To: desktop-devel-list 

Hello,

one of the most problematic points we've been discussing since the
GNOME Github mirror was introduced [1] (three years already!) has been
the presence of pull requests and the missing feature / functionality
to actually turn them off for specific repositories / organizations.
What many have correctly pointed out during these three years relates
to the fact pull requests and our current contributions workflow
collide in a way that has caused confusion between community members
with dozens of patches being left on Github unreviewed.

Finally the GNOME Infrastructure Team is going to introduce a daily
cronjob (first run is scheduled next week, enough time for collecting
excludes) that will close all the pull requests for each repository
hosted under the GNOME organization umbrella. The closure message will
look like this:

"""
Thank you for contributing to $project_name!

$project_name uses Bugzilla for code review.

If you have never contributed to GNOME before make sure you have read the
getting started documentation:
http://www.gnome.org/get-involved

Otherwise please visit
https://wiki.gnome.org/Newcomers/CodeContributionWorkflow
and follow the instructions there to upload your change to Bugzilla.
"""

If you don't want the script to actually run against any of your
maintained products, modules, components please drop me an e-mail and
I'll make sure proper excludes will be set.

Thanks,

[1] https://mail.gnome.org/archives/foundation-list/2013-August/msg00010.html


--
Cheers,

Andrea

Debian Developer,
Fedora / EPEL packager,
GNOME Infrastructure Team Coordinator,
GNOME Foundation Board of Directors Secretary,
GNOME Foundation Membership & Elections Committee Chairman

Homepage: http://www.gnome.org/~av
___
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