Re: Proposal to deploy GitLab on gnome.org

[Florian Müllner]

On Fri, May 19, 2017 at 9:55 PM Shaun McCance  wrote:

> I don't disagree with anything you're saying. As long as there's an
> easy way to get a list of issues with a specific label across all
> projects (and projects in different groups?), then we'll figure it out.
> And if there's not, we'll figure it out another way.


It looks like labels can be defined by either the project or the group:

https://gitlab.gnome.org/groups/GNOME/issues?label_name[]=newcomers

So as long as all the canonical GNOME repos are under that umbrella, it
should work just fine.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal to deploy GitLab on gnome.org

[Shaun McCance]

On Thu, 2017-05-18 at 18:08 +0200, Andre Klapper wrote:
> On Tue, 2017-05-16 at 10:51 -0400, Shaun McCance wrote:
> > 
> > That said, here's a potential pain point: in Bugzilla, you can have
> > different components auto-assign to different accounts, and we made
> > these @gnome.bugs fake accounts for teams. The docs team uses this
> > to
> > make it easy to follow docs bugs across products. I don't think
> > GitLab
> > has any sense of components, preferring the more casual labels for
> > categorization.
> When all that overcategorization in a ticket (Bugzilla: 1 "product"
> per
> ticket, 1 "component" per ticket, 0-∞ "keywords" per ticket, random
> freetext in a "whiteboard" entry, upstream's "tags" fields that GNOME
> hides via custom CSS) is turned into a single "Labels" field, with 0-
> ∞
> labels associated to a ticket, and everybody tries to remember adding
> that #user-docs label, and if a GitLab user can receive notifications
> for certain labels (so docs team members could follow activity), I
> don't see a real problem? :)
> 
> Our "@gnome.bugs virtual assignee" setup in Bugzilla is a horrible
> hack, due to unavailability of an "allow me to receive notifications
> for these products / components" functionality for ages [1].

I don't disagree with anything you're saying. As long as there's an
easy way to get a list of issues with a specific label across all
projects (and projects in different groups?), then we'll figure it out.
And if there's not, we'll figure it out another way.

This will likely affect other teams that work across projects, like the
translation teams or the newcomers initiative.


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

Re: Proposal to deploy GitLab on gnome.org

[mcatanzaro]

On Thu, May 18, 2017 at 11:36 AM, Andre Klapper  wrote:
The Traceparser is another (basically) unmaintained custom extension 
we

have in our Bugzilla, with some confusing bugs (e.g. bug 744491).


I think we should remove this extension immediately. It provides 
limited value, since you almost always want to skip through the pretty 
little trace to see the full backtrace anyway. And this confusing bug 
is very serious.


It will be a shame to lose the feature that notifies you if your 
backtrace is similar to a backtrace in another bug, but we can live 
without and it's not worth the cost of bug 744491.


Michael

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

Re: Proposal to deploy GitLab on gnome.org

[Tom Tryfonidis]

Hi,

One thing we missed from the translators requirements is the workflow for
tracking issues. At the moment, there's a "l10n" product [1] at Bugzilla
where users report bugs choosing a language from "Components" list.

My question here is, how things are going to work with Gitlab now that all
bug are per project?

At first thought, i'd say a repo only for reporting translations bugs could
work. Another potential solution is to use labels and assignees
(translation teams) per project. Both solutions have their pros and cons
(for project maintainers and translation maintainers), so i'd appreciate
your input on this.

Regards,

Tom

[1] https://bugzilla.gnome.org/page.cgi?id=browse.html=l10n
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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