Re: Proposal to deploy GitLab on gnome.org

2017-05-28 Thread Sébastien Wilmet 
On Wed, May 17, 2017 at 02:21:55PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, May 17, 2017 at 01:49:21PM +0200, Sébastien Wilmet wrote:
> > By attaching a patch to a bugtracker ticket, we loose the information of
> > the parent commit: where the commit has been initially created in the
> > git history.
> If the patch is created by git format-patch, it contains the hash of
> the parent, so git knows the original parent.
> 
> > I've already had the problem that git-bz apply fails (there was a
> > conflict), while git was able to resolve automatically the conflict when
> > rebasing the branch.
> 'git am -3' is the same as a rebase.

Thanks for correcting me. Indeed a patch created with `git format-patch`
includes the hashes of the parent objects. When using git-bz it hides a
little the use of git am, so I was not aware of all the possiblities of
git am. It's possible to configure the am.threeWay setting in git, by
default it's false.

But it doesn't seem easy (or even possible) with git am to create a
branch at the original place in the git history where the patches were
created. The parent *commit* is not known, only the parent objects. I
think it can be useful to know where the contributor has created the
commits. With a pull request workflow like in GitHub and GitLab, when we
fetch the branch we know the parent commit.

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

Re: Relicensing Nautilus to GPLv3+

2017-05-28 Thread Sébastien Wilmet 
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

Re: Relicensing Nautilus to GPLv3+

2017-05-28 Thread Bastien Nocera 
On Thu, 2017-05-25 at 12:08 +0200, Sébastien Wilmet wrote:
> 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.

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

Re: Proposal to deploy GitLab on gnome.org

2017-05-28 Thread 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+

2017-05-28 Thread 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+

2017-05-28 Thread Luis Menina 

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