Re: Relicensing Nautilus to GPLv3+

[A. Walton]

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

[Bastien Nocera]

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).
___
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 , Emilio Pozuelo Monfort 

release-t...@gnome.org , nautilus-l...@gnome.org 
, desktop-devel-list@gnome.org 
, Frederic Crozat 

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+

[Bastien Nocera]

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

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 , Nicolas Dufresne 

release-t...@gnome.org , nautilus-l...@gnome.org 
, desktop-devel-list@gnome.org 
, Frederic Crozat 

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: gnome-settings-daemon/gnome-control-center under new ownership

[Matthias Clasen]

On Thu, May 18, 2017 at 10:49 AM, Bastien Nocera  wrote:

> Hey,
>
> At GUADEC 2010, Matthias asked Richard Hughes and I to help with gnome-
> control-center's port to GTK+ 3.x and update all the panels to the new
> control-center shell that Jon McCann had been polishing.
>
> Skip forward 7 years later, and I'm mostly doing patch reviews for
> features and redesigns done by others, along with being the person that
> rejects adding new options.
>

You've been doing it for along time. Thanks for your service!
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Relicensing Nautilus to GPLv3+

[Emilio Pozuelo Monfort]

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 
release-t...@gnome.org , nautilus-l...@gnome.org 
, Frederic Crozat , 
desktop-devel-list@gnome.org 

017-05-18 18:22 GMT+02:00 Carlos Soriano via desktop-devel-list
:

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

[Michael Biebl]

017-05-18 18:22 GMT+02:00 Carlos Soriano via desktop-devel-list
:

> 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

Re: Proposal to deploy GitLab on gnome.org

[Andre Klapper]

On Thu, 2017-05-18 at 12:17 +0200, Milan Crha wrote:
> please, do not forget of Bugzilla integration with backtraces. It can
> colorize them, it can show possible duplicates with score when the
> backtrace is opened in its own window, and it can even notify the
> reporter that the backtrace matches some other bugs and it offers the
> reporter to eventually join an existing bug, instead of filling a new
> bug report. Of course, an average user cannot decipher backtrace of
> random projects, thus it's fine he/she files a new bug report, but my
> main point for Bugzilla is that it knows what to do with inline
> backtraces. Does gitlab issue tracker know it too?

The Traceparser is another (basically) unmaintained custom extension we
have in our Bugzilla, with some confusing bugs (e.g. bug 744491). 

GNOME Bugzilla does not receive gazillions of crasher bug reports
anymore (like after the 2.16 release, which was the reason to write
this extension if I remember correctly) and most distributions nowadays
ship their own tools (and own backends) for automatic crasher analysis.

The Traceparser is convenient but I would not strongly miss it if there
was nothing similar in GitLab. I'd say a regression we could live with?

> I've seen a screenshot of the gitlab issue tracker in an early stage of
> the wiki page [1], which I cannot find right now. It was full of
> colored tags, which effectively hid the main purpose, the information
> which had been meant to be shared. The page looked like a rainbow, not
> like a clean interface to share information between the reporter and
> the developer.

I do not know GitLab much but I'd expect functionality to set a color
when creating a label. So color rules could be established if wanted /
needed [4]. I'd call GitLab a way cleaner interface than Bugzilla. :)

andre

[4] notorious Wikimedia example for project/tag/label coloring rules: 
https://www.mediawiki.org/wiki/Phabricator/Project_management#Types_of_Projects

-- 
Andre Klapper  |  ak...@gmx.net
http://blogs.gnome.org/aklapper/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Andre Klapper]

On Tue, 2017-05-16 at 10:51 -0400, Shaun McCance wrote:
> That said, here's a potential pain point: in Bugzilla, you can have
> different components auto-assign to different accounts, and we made
> these @gnome.bugs fake accounts for teams. The docs team uses this to
> make it easy to follow docs bugs across products. I don't think GitLab
> has any sense of components, preferring the more casual labels for
> categorization.

When all that overcategorization in a ticket (Bugzilla: 1 "product" per
ticket, 1 "component" per ticket, 0-∞ "keywords" per ticket, random
freetext in a "whiteboard" entry, upstream's "tags" fields that GNOME
hides via custom CSS) is turned into a single "Labels" field, with 0-∞
labels associated to a ticket, and everybody tries to remember adding
that #user-docs label, and if a GitLab user can receive notifications
for certain labels (so docs team members could follow activity), I
don't see a real problem? :)

Our "@gnome.bugs virtual assignee" setup in Bugzilla is a horrible
hack, due to unavailability of an "allow me to receive notifications
for these products / components" functionality for ages [1].

andre

[1] To be fair, a downstream bgo extension got upstreamed at
https://github.com/bugzilla/extensions-ComponentWatching
but that's not shipped /by default/ which makes following anything that
is neither a ticket nor a user to stalk rather complicated/cumbersome.
-- 
Andre Klapper  |  ak...@gmx.net
http://blogs.gnome.org/aklapper/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal to deploy GitLab on gnome.org

[Andre Klapper]

On Tue, 2017-05-16 at 10:28 -0400, Carlos Soriano wrote:

> 2- what are the migration plans for bugzilla: bugzilla URL, bug numbers and 
> the actual content
[...]
> Also, different projects might have different needs for migration.

While that is true, it is more confusing if I can find all the Bugzilla
tickets I created about project X now in GitLab while I cannot find all
Bugzilla tickets I created about project Y now in GitLab but you expect
me to find out myself what to find where (some BZ, some GitLab?).
 
> For example, for Nautilus we could migrate just specific important
> bugs or just file new bugs in GitLab while preserving the old ones in
> Bugzilla, where I can still follow/fix/comment them. 
[...]
> As I'm the one maintaining it, I prefer a slow and smooth transition
> rather than a hard one and take the opportunity to focus on the
> priority ones.

If I interpret "slow" and "hard" correctly and if "old ones" means
"older unresolved tickets", you propose running two task tracking
systems in parallel with some tickets or some projects here and some
there and I (simple user) may have no idea where to do or find what.

When Wikimedia killed their Bugzilla instance they made a hard cut
(first migration step was turning Bugzilla entirely read-only [1]).
https://xkcd.com/927/ also applies.

andre

[1] https://phabricator.wikimedia.org/T1234
-- 
Andre Klapper  |  ak...@gmx.net
http://blogs.gnome.org/aklapper/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal to deploy GitLab on gnome.org

[Andre Klapper]

On Tue, 2017-05-16 at 17:54 +0100, Allan Day wrote:
> On Tue, May 16, 2017 at 5:36 PM,  wrote:
> ...
> > We need a much better migration plan than that. If we don't have a
> > script to migrate Bugzilla issues, comments, and attachments to our
> > new GitLab instance, then we should not be considering using
> > GitLab's issue tracker at all.
> 
> We're committed to creating the necessary migration tooling; I think
> that Alberto already has something in the works.

The "Release often, release early" mantra makes me reply by "Please
show me the code."

andre
-- 
Andre Klapper  |  ak...@gmx.net
http://blogs.gnome.org/aklapper/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

gnome-settings-daemon/gnome-control-center under new ownership

[Bastien Nocera]

Hey,

At GUADEC 2010, Matthias asked Richard Hughes and I to help with gnome-
control-center's port to GTK+ 3.x and update all the panels to the new
control-center shell that Jon McCann had been polishing.

Skip forward 7 years later, and I'm mostly doing patch reviews for
features and redesigns done by others, along with being the person that
rejects adding new options.

I'm writing this mail because I want to be able to focus on writing
code again, implementing new features desktop-wide such as integrating
OOM handling into the desktop, porting our session handling to systemd,
dealing with kernel bugs and, finally, spending some time on my old
friend Videos.

Rui will be taking over handling of day-to-day operations for gnome-
control-center and gnome-settings-daemon. I'll still be around to
handle bugs in my own area of expertise (such as the Bluetooth panel or
the fingerprint integration).

If you have long-standing bugs still opened because the maintainer got
jaded, or because your patches didn't get reviewed, please connect with
Rui to get a fresh look.

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

Re: Proposal to deploy GitLab on gnome.org

[Bastien Nocera]

Hey,

On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote:
> [Written on behalf of Alberto Ruiz, Carlos Soriano, Andrea Veri,
> Emmanuele Bassi and myself.]
> 
> Please bear in mind that this is just a recommendation! We are not
> claiming to have complete knowledge and we would like to hear
> questions and comments. At the same time, we do ask that members of
> the community approach this proposal with an open mind: please read
> the wiki pages and try to resist making assumptions about GitLab
> without familiarising yourself with it.

I've now read through the documentation, and annotated my early
thoughts on the migration.

- Keep bugzilla URLs working, along with history
  This is very important for code history purposes, and has been
mentioned as an explicit goal at:
https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/#Migration_Possibilities

- Keep cgit URLs working
  Again, important for code history purposes. We often link to those in
bug reports and commit messages. This could probably be achieved
through redirections rather than keeping the cgit instance alive

- Keep git URLs working
  While not a problem for developers (you'd change your gitconfig and
update jhbuild, and done, mostly), it has the potential to break a lot
of flatpaks, possibly also upstream packaging. I know something similar
was done in the Fedora package repos when they migrated, so maybe it's
possible?

- Component bug assignment: g-c-c/g-s-d or gnome-documents/gnome-books
  This is probably the most important one for bug handling. Otherwise
managing bugs for g-c-c and g-s-d, the different components of which
require a lot of domain-specific knowledge, would be terribly unwieldy.

- Equivalent to NEEDINFO?
  This status was pretty important in terms of bug triaging, as the
reporter was allowed to remove that flag when they were done providing
the information, removing the burden from the bug triager to monitor
the bug. Is there an equivalent?

- Cross-module issue searching?
  Again, quite useful in terms of bug triaging, allowing to find a
"root cause" bug, possibly assigned to a different component than the
top level application. For example, a crash in Videos could be in about
7 different modules, being able to search the whole instance would be
useful.

- Mail for own replies (a-la bugzilla)
  - This is also a useful tool for bug triaging, as all the comments
end up in my Bugzilla folder, and I can search through them. I'm
guessing/hoping it's possible.

- Handling of private bugs?
  Bugzilla has the ability to create private bugs, for security and
community feedback management purposes. Does GitLab allow that?

- Bugzilla yearly reports
  Is there some statistics tool builtin to GitLab?

- Bugzilla points
  Will they be migrated? :)

Overall, the migration is a good idea, especially the ability to report
bugs and contribute without a GNOME specific account. I hope the
information about how different teams and bugzilla triagers use
Bugzilla, in particular, was of interest.

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

Re: Paperwork / Gnome's dos and don'ts

[jflesch]

17 mai 2017 21:58 "Sriram Ramkrishna"  a écrit:

> Howdy!
> 
> On Wed, May 17, 2017 at 2:57 AM  wrote:
> 
>> b) Commercialization of Windows portage
>> 
>> A while ago, I tried to sell the Windows version of Paperwork. It was based 
>> on a 60 days trial
>> period + activation keys (the code is still visible on GitHub, but it is 
>> disabled). It didn't have
>> much success at the time, but I still haven't forgotten my dream of being 
>> rich someday ;). I'm
>> considering re-trying later (I'm thinking of keeping the version N-1 free 
>> and making the version N
>> commercial).
>> 
>> Would that be a compatible with being hosted on gnome.org ?
>> Would that hurt the chances that Paperwork becomes an extra app of Gnome 
>> someday ?
> 
> I would reach out to the board on this particular question. My personal 
> opinion is the GPL does
> allow you to make money and you would still be compliant with the license. I 
> would do some
> investigations on a money model around GPL'd software. You might want to talk 
> with Aaron Brockover
> who wrote Banshee music player.
> 
Ok, I will do that.


> The worry I have is further down the road, and for arguments sake: suppose 
> Paperwork becomes a core
> application of GNOME there might be some misunderstanding with the community 
> and accusations of
> bait and switch[1] that we might have to defend at first. So communications 
> around this is very
> critical here. Because once that misunderstanding occurs, it stays persistent 
> for quite some time.
> As someone who usually does the defending, I've usually found it a big 
> headache. So this message is
> partially in my own self interest. :-)
> 
I understand perfectly your worry, and the last thing I want is to make a mess.
I'll ask the board what they think. If they tell me they prefer I don't 
commercialize a Windows portage, I won't.


> Finally, if you're using some of the designs from Allan or other GNOME 
> designers, you would be
> using their work, time and effort to generate income. Now they might not 
> mind, but you probably
> want to talk to them up front in regards to compensation (if any).
>
I understand. When I did my first try, I did discuss it with Paperwork's main 
contributors beforehand. While the GPL allows it, I consider it basic 
politeness.
This is also why I'm asking now, before hosting Paperwork on gnome.org.


> You are also leveraging the
> GNOME brand here intentionally or not. So these are things that you must work 
> out with the Board of
> Directors.
> 
Agreed.


> If you do go down that route, I hope that some portion of the proceeds will 
> be contributed to the
> GNOME Foundation.
>
Yes, it would be fair.


> I do hope that you succeed. I think it is important for the market for
> applications if there was a model that succeeded, and that one can make money 
> from copyleft
> software directly from users.


Thank you for this very detailed answer :)


> Best,
> sri
> 
> [1] - I am not in anyway accusing you of planning a bait-n-switch - just that 
> a semblance of
> impropriety can start an internet mob going and harm our brand.
___
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: Proposal to deploy GitLab on gnome.org

[Milan Crha]

On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote:
> The outcome of this evaluation process is that we are recommending
> that GNOME sets up its own GitLab instance, as a replacement for
> Bugzilla and cgit.

Hi,
with respect of the cgit, it lets me download sources (snapshot) as
a .zip and a .tar.xz. The gitlab offers .zip, .tar.gz, .tar.bz2 and
.tar. I think there had been some good reasoning for projects to do
releases as .tar.xz (maybe it was even a GNOME Goal, I do not recall,
neither cannot find it), it's quite efficient with compression, thus it
would make sense to teach gitlab to use it beside .zip, instead of
those three not-that-useful-these-days .tar variants.

Would they do it upstream, or you'll need to patch it downstream, or
it's just some option somewhere?
Bye,
Milan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal to deploy GitLab on gnome.org

[Milan Crha]

On Tue, 2017-05-16 at 10:51 -0400, Shaun McCance wrote:
> That said, here's a potential pain point

Hi,
please, do not forget of Bugzilla integration with backtraces. It can
colorize them, it can show possible duplicates with score when the
backtrace is opened in its own window, and it can even notify the
reporter that the backtrace matches some other bugs and it offers the
reporter to eventually join an existing bug, instead of filling a new
bug report. Of course, an average user cannot decipher backtrace of
random projects, thus it's fine he/she files a new bug report, but my
main point for Bugzilla is that it knows what to do with inline
backtraces. Does gitlab issue tracker know it too?

Also, with respect of searching in Bugzilla, what some folks in this
thread call complicated, I call powerful. Bugzilla is powerful in
searching. The search UI can be complicated, that's why there is a
Simple and Advanced search page, but it allows you do many good things.

I've seen a screenshot of the gitlab issue tracker in an early stage of
the wiki page [1], which I cannot find right now. It was full of
colored tags, which effectively hid the main purpose, the information
which had been meant to be shared. The page looked like a rainbow, not
like a clean interface to share information between the reporter and
the developer.

One of the test issues [2] also looks somehow odd, but maybe if I would
get use to it, then it might not be that bad as it looks like now. How
many comments does it show? Four? One? Something in between? It looks
like there are four of them, all grey thin font (hard to read), and
wasting like 1/3 of my browser window height. Height is problem, not
width, with wide screens. I didn't try how it looks like on a cell
phone.

The issue [3] also says:

> Carlos Soriano @csoriano mentioned in issue #30668 (closed) 2 weeks ago

Should that "mentioned" be "is marked as duplicate" instead? I can
mention bugs between itself and I do it all the time (like "this is
partly related to bug #1234", or even "can be duplicate of bug #1234",
which used to do bug squad folks in the past too), but it doesn't mean
they are duplicates, neither that I want to add some possibly
misleading automated comment into the other bug report. I would mark
them as a duplicate, or add them to Depends/Blocks, if I'd be sure.

>From my point of view, it doesn't make much sense to have both Bugzilla
and gitlab issue tracker running at the same time and let the product
maintainers decide what is better for them. There should be some
consistency. You cannot tell the reporter that the issue he/she filled
belongs to other project, but that project issues are hosted elsewhere
(even still under gnome.org domain). I understand this whole initiative
to also make life easier for sysadmins, where maintaining two issue
trackers doesn't sound like less work for them.
Bye,
Milan

[1] https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/
[2] https://gitlab.gnome.org/GNOME/nautilus/issues/30668
[3] https://gitlab.gnome.org/GNOME/nautilus/issues/20958
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list