Re: Suggestions for librsvg's COMPILING.md

[Federico Mena Quintero]

On Sat, 2017-12-02 at 13:51 -0500, David Michael wrote:
> 
> In librsvg's COMPILING.md, there are two inconsistencies around
> cross-compiling.
> 
>   * The option --target=TRIPLE is passed to cargo, not --host.
>   * RUST_TARGET_PATH should be set for make, not configure.

Ah, thanks for noticing!  I've pushed this fix.

> An alternative to writing a target JSON file could be to override
> CARGO_TARGET_ARGS and RUST_TARGET_SUBDIR (if RUST_LIB used the
> variable) when a compatible builtin target is available.  For
> example:
> 
> ./configure --host=x86_64-redhat-linux-gnu ...
> make CARGO_TARGET_ARGS=--target=x86_64-unknown-linux-gnu ...

You mean, in Makefile.am instead of

RUST_LIB=@abs_top_builddir@/rust/target/@RUST_TARGET_SUBDIR@/librsvg_internals.a

Something like

RUST_TARGET_SUBDIR=@RUST_TARGET_SUBDIR@
RUST_LIB=@abs_top_builddir@/rust/target/$(RUST_TARGET_SUBDIR)/librsvg_internals.a

?

(I haven't even tested this; just trying to see if we are thinking of
the same thing.)

> Is that worth maybe adding a --with-rust-target option to configure
> that defaults to $host when cross-compiling?  (I didn't think of that
> for the cross-compiling patch since I was only building for a new
> target with no builtin support.)

Hm, I'm not sure.  Would these be the two cases then?

1. Rust supports the same --host=TRIPLE out of the box, in the form of 
"cargo --target=TRIPLE".

2. Rust doesn't know the --host=TRIPLE.  You'd like an easier way to
pass the json file, or a compatible triple, and that would be the 
--with-rust-target option?

I haven't played with cross compilation at all, so if you want to own
this bit and patch the build infrastructure, feel free to do it :)

> As a side note, here is one way to generate a JSON spec from a
> similar
> builtin target.  It may not be helpful including this in
> documentation
> since it uses unstable options, so I'm just throwing it out there.
> 
> RUSTC_BOOTSTRAP=1 rustc -Z unstable-options \
> --print=target-spec-json \
> --target=x86_64-unknown-linux-gnu |
> sed -e /is-builtin/d -e s/unknown/redhat/g \
> > "${RUST_TARGET_PATH%%:*}/x86_64-redhat-linux-gnu.json"

Interesting.  For now I want to keep librsvg compiling on rust stable,
although I have implicitly updated what "stable" means in the past :) 
No nightly features, I guess.


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

Re: GitLab update: Moving to the next step

[Carlos Soriano]

Sorry, I meant this link https://gitlab-test.gnome.org/mcrha/test/labels.
What you were missing is that labels are entities, and you can create,
delete, rename, add a description, subscribe to them (for example for
components of a project) etc.

What I did to do what you see is left sidebar -> labels -> click button
"generate default labels".


Best
--
Carlos Soriano
GNOME Foundation
Treasurer, Board of Directors

On Fri, Dec 8, 2017 at 12:27 AM, Carlos Soriano  wrote:

> Hey Milan,
>
> I just took a look at your issue. You couldn't add a label because you
> didn't created any label in the project. I create some for you so you can
> play with them. https://gitlab-test.gnome.org/mcrha/test/issues/2
>
>
> Best
> --
> Carlos Soriano
> GNOME Foundation
> Treasurer, Board of Directors
>
> On Thu, Dec 7, 2017 at 10:21 AM, Milan Crha  wrote:
>
>> On Thu, 2017-12-07 at 10:03 +0100, Milan Crha wrote:
>> > I filled https://gitlab.com/gitlab-org/gitlab-ce/issues/40903 there.
>>
>> Hi again,
>> and also https://gitlab.com/gitlab-org/gitlab-ce/issues/40904
>>
>> I do not see how to add labels to the issue, and the test instance
>> doesn't do anything with "/label ~something" (literally, without
>> quotes) in the comment.
>>
>> I added both to your issue at:
>> https://gitlab.gnome.org/GNOME-Community/GitLab-Infrastructure/issues/8
>> I do not know how to add it to the proper section, I thought it's a
>> wiki page hidden under your link.
>>
>> Bye,
>> Milan
>> ___
>> 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: GitLab update: Moving to the next step

[Carlos Soriano]

Hey Milan,

I just took a look at your issue. You couldn't add a label because you
didn't created any label in the project. I create some for you so you can
play with them. https://gitlab-test.gnome.org/mcrha/test/issues/2


Best
--
Carlos Soriano
GNOME Foundation
Treasurer, Board of Directors

On Thu, Dec 7, 2017 at 10:21 AM, Milan Crha  wrote:

> On Thu, 2017-12-07 at 10:03 +0100, Milan Crha wrote:
> > I filled https://gitlab.com/gitlab-org/gitlab-ce/issues/40903 there.
>
> Hi again,
> and also https://gitlab.com/gitlab-org/gitlab-ce/issues/40904
>
> I do not see how to add labels to the issue, and the test instance
> doesn't do anything with "/label ~something" (literally, without
> quotes) in the comment.
>
> I added both to your issue at:
> https://gitlab.gnome.org/GNOME-Community/GitLab-Infrastructure/issues/8
> I do not know how to add it to the proper section, I thought it's a
> wiki page hidden under your link.
>
> Bye,
> Milan
> ___
> 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: GitLab update: Moving to the next step

[Carlos Soriano]

Hey Michael,

On Thu, Dec 7, 2017 at 9:04 PM, Michael Catanzaro 
wrote:

> I've been rewriting this email again and again to try not to be too
> impolitic... and I don't think I've succeeded, but I want to try to express
> the importance to me of some of the missing issue tracker features.
>
>
I'm pretty sure you succeed, appreciated you spent the time to not be over
the top.


> On 12/07/2017 12:07 PM, Carlos Soriano wrote:
>
>> Said that, add your comments about specific improvements to issue #8
>> too in a new comment so we can track them.
>>
>
> It looks like everything I care about is actually already tracked there in
> issue #8. (Except that the quote button needs to work like 'r'... good to
> know about the 'r' shortcut, I can live with that.) Looking over #8, I
> think duplicate issues, canned replies, and dependencies between issues
> should all be considered blockers to issue tracker migration.


> I assume I don't need to explain why tracking duplicate issues is
> important. Just look at the state of the closed issues in gnome-calendar's
> issue tracker right now.
>


I understand the importance of this, and we discussed them in the past. We
have discussed also with the people trying GitLab, and the balance keep
being positive. I agree better UI experience for duplicates is something we
should see in the near future, but I think the general consensus is that we
can move forward without it and eventually have a better experience.


>
> I use a long canned reply to close probably half the bugs I receive ("here
> is how you report a WebKit bug..."), and bug management would be extremely
> frustrating without it. I could keep it in a text file and copy/paste for a
> couple months, as long as upstream has promised the feature is on the way.
> But I really would rather stay on Bugzilla forever rather than give up
> canned replies forever. I am going to be thinking "I hate GitLab" every
> other time I close a bug... we don't want that.
>

Like everything, it's a balance. I hope you see as you hate GitLab there
are others that hate Bugzilla, including most of new contributors. It's
impossible to make everyone happy with such a change, but I hope you trust
me when I say that I didn't take any steps on this lightly, and that I
tried to take a representation of the whole community. In no moment I
though about myself when taking these decisions, and I went far beyond the
possible to try to make sure we are taking the best decision for GNOME and
that our community agrees with that decision.


>
> And I would also insist on a schedule for open sourcing dependencies
> between issues. That such an important feature is being kept closed source
> indicates we are going to have further problems collaborating with upstream
> down the road. We should be prepared to stay with Bugzilla indefinitely if
> GitLab remains unwilling to open source basic issue tracker functionality.
>
>
We cannot rely on that, and to be honest, with the UI and markdown of
GitLab I didn't miss it so far. Probably others can chime in, but even if
it will be preferred to have, we can do fine without.

Note that I also explained few times this and it's written in our
transition wiki: We evaluated the current state and we defined our blockers
based on that. To be honest I'm more than happy if over time half of the
issues we have in that list are improved/fixed, and some of them have
people working on them already.


> The big picture that I see is that GitLab has some cool features, and some
> people really want merge requests... I don't really care either way, but
> OK, fine by me. But I spend a *lot* of time working with Bugzilla, and
> losing basic issue tracking features is going to make my job as a GNOME
> maintainer harder. So when it comes time for all the remaining projects to
> move to GitLab, if the above deficiencies are not resolved, then I hope
> that we'll be allowed to turn off GitLab's issue tracker and stick with
> Bugzilla. Maybe it would be better to make that the default transition, in
> fact.


Again, it's very difficult to make everyone happy, and of course there are
always trade offs that we have taken into account on the whole path until
today. But I hope you understand, eventually we will have to move forward,
we cannot indefinitely stay with two issue trackers, and it's also going to
be quite impractical even for you.

What I can do here is trying to push for some changes to make your utter
unhappiness to "it's okaish", because I believe it will be hard for you to
be happy with GitLab, at least until you get used to it. In the same way
lot of us feel with Bugzilla or any other tool that we could have evaluated.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitLab update: Moving to the next step

[Michael Catanzaro]

I've been rewriting this email again and again to try not to be too 
impolitic... and I don't think I've succeeded, but I want to try to 
express the importance to me of some of the missing issue tracker 
features.


On 12/07/2017 12:07 PM, Carlos Soriano wrote:

Said that, add your comments about specific improvements to issue #8
too in a new comment so we can track them.


It looks like everything I care about is actually already tracked there 
in issue #8. (Except that the quote button needs to work like 'r'... 
good to know about the 'r' shortcut, I can live with that.) Looking over 
#8, I think duplicate issues, canned replies, and dependencies between 
issues should all be considered blockers to issue tracker migration.


I assume I don't need to explain why tracking duplicate issues is 
important. Just look at the state of the closed issues in 
gnome-calendar's issue tracker right now.


I use a long canned reply to close probably half the bugs I receive 
("here is how you report a WebKit bug..."), and bug management would be 
extremely frustrating without it. I could keep it in a text file and 
copy/paste for a couple months, as long as upstream has promised the 
feature is on the way. But I really would rather stay on Bugzilla 
forever rather than give up canned replies forever. I am going to be 
thinking "I hate GitLab" every other time I close a bug... we don't want 
that.


And I would also insist on a schedule for open sourcing dependencies 
between issues. That such an important feature is being kept closed 
source indicates we are going to have further problems collaborating 
with upstream down the road. We should be prepared to stay with Bugzilla 
indefinitely if GitLab remains unwilling to open source basic issue 
tracker functionality.


The big picture that I see is that GitLab has some cool features, and 
some people really want merge requests... I don't really care either 
way, but OK, fine by me. But I spend a *lot* of time working with 
Bugzilla, and losing basic issue tracking features is going to make my 
job as a GNOME maintainer harder. So when it comes time for all the 
remaining projects to move to GitLab, if the above deficiencies are not 
resolved, then I hope that we'll be allowed to turn off GitLab's issue 
tracker and stick with Bugzilla. Maybe it would be better to make that 
the default transition, in fact.


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

Re: GitLab update: Moving to the next step

[Carlos Soriano]

And I agree, I also want a reply button!

On Thu., 7 Dec. 2017, 19:07 Carlos Soriano,  wrote:

> If you read my email fully and clicked the links, you would have seen the
> specific date the rebase before merge is coming to our instance.
>
> I'm surprised that copy&pasting a comment and clicking the button "quote"
> vs pressing a button should be considered a blocker for migrating more
> projects. If that's the level of details we should block this for moving
> on, where everyone of us (included me) has its own detail that wants to be
> improved, I'm confident we would never move to anything.
>
> So please, take into consideration the big picture.
>
> Said that, add your comments about specific improvements to issue #8 too
> in a new comment so we can track them.
>
> On Thu., 7 Dec. 2017, 18:52 Florian Müllner,  wrote:
>
>> On Thu, Dec 7, 2017 at 6:19 PM, Michael Catanzaro 
>> wrote:
>> > I'll add two more to Milan's list:
>> >
>> > (1) Canned replies. I would rather stay with Bugzilla forever than give
>> up
>> > canned replies.
>>
>> That is being tracked:
>> https://gitlab.gnome.org/GNOME-Community/GitLab-Infrastructure/issues/33
>>
>> There are some links to upstream discussions there, so I'd expect some
>> comparable functionality in gitlab eventually.
>>
>>
>> > (2) Still waiting for rebase merge requests. Ditto.
>>
>> And this actually *has* been considered a blocker the entire time. So
>> seeing the migration going forward, I suspect that there has been
>> movement in that area ...
>> ___
>> 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: GitLab update: Moving to the next step

[Carlos Soriano]

If you read my email fully and clicked the links, you would have seen the
specific date the rebase before merge is coming to our instance.

I'm surprised that copy&pasting a comment and clicking the button "quote"
vs pressing a button should be considered a blocker for migrating more
projects. If that's the level of details we should block this for moving
on, where everyone of us (included me) has its own detail that wants to be
improved, I'm confident we would never move to anything.

So please, take into consideration the big picture.

Said that, add your comments about specific improvements to issue #8 too in
a new comment so we can track them.

On Thu., 7 Dec. 2017, 18:52 Florian Müllner,  wrote:

> On Thu, Dec 7, 2017 at 6:19 PM, Michael Catanzaro 
> wrote:
> > I'll add two more to Milan's list:
> >
> > (1) Canned replies. I would rather stay with Bugzilla forever than give
> up
> > canned replies.
>
> That is being tracked:
> https://gitlab.gnome.org/GNOME-Community/GitLab-Infrastructure/issues/33
>
> There are some links to upstream discussions there, so I'd expect some
> comparable functionality in gitlab eventually.
>
>
> > (2) Still waiting for rebase merge requests. Ditto.
>
> And this actually *has* been considered a blocker the entire time. So
> seeing the migration going forward, I suspect that there has been
> movement in that area ...
> ___
> 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: GitLab update: Moving to the next step

[Florian Müllner]

On Thu, Dec 7, 2017 at 6:19 PM, Michael Catanzaro  wrote:
> I'll add two more to Milan's list:
>
> (1) Canned replies. I would rather stay with Bugzilla forever than give up
> canned replies.

That is being tracked:
https://gitlab.gnome.org/GNOME-Community/GitLab-Infrastructure/issues/33

There are some links to upstream discussions there, so I'd expect some
comparable functionality in gitlab eventually.


> (2) Still waiting for rebase merge requests. Ditto.

And this actually *has* been considered a blocker the entire time. So
seeing the migration going forward, I suspect that there has been
movement in that area ...
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitLab update: Moving to the next step

[Emmanuele Bassi]

On 7 December 2017 at 17:01, Milan Crha  wrote:
> On Wed, 2017-12-06 at 18:49 +0100, Carlos Soriano wrote:

> a) See the second comment of
>https://gitlab-test.gnome.org/mcrha/test/issues/2
>It shows like three lines of text (one line, then empty line, then
>third line). When you edit that comment you'll see I made it
>several lines, not only three - the interface is ignoring my
>Enter-s. Am I supposed to use some crazy tag when I want to divide
>paragraphs and/or write simple lines?

The comment format is Markdown; you break paragraph by adding an empty line.

> b) How do I reply to a comment?

Select the text in the comment you wish to reply to, hit 'r'; it'll
put the selection, already quoted, in the comment area.

> c) my current work flow with bugzilla involves having opened *one* tab
>in the browser with a search which contains a list of bugs changed
>since some date for four different products. I refresh it in the
>morning to see newly added bugs and eventually react to them (I
>know, that's a silly idea to take care of newly added bugs where
>reporters are active the most). How do I do the same in
>gitlab, while: 1) the space will not be wasted, because I dislike
>scrolling when it's unnecessary (and here it is); 2) it will not
>be four different tabs in the browser?

I cannot help you, there. If you expect the workflow to be exactly the
same, I strongly suggest you never switch away from Bugzilla.

> d) I cannot set labels on my test project for some reason.

You need to have the appropriate permissions to do so; it's probably a
test instance issue.

> I know you can easily RTFM me, but do you know what? I didn't read any
> single word of the bugzilla manual and I've been able to work with it
> with no problem.

I seriously doubt you were born with innate knowledge of Bugzilla -
even though Bugzilla's feature set is basically limited to what you
see in the page.

Ciao,
 Emmanuele.

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

Re: GitLab update: Moving to the next step

[Emmanuele Bassi]

On 7 December 2017 at 17:19, Michael Catanzaro  wrote:
> On 12/07/2017 11:01 AM, Milan Crha wrote:
>>
>> b) How do I reply to a comment?
>
>
> This one should be a blocker to migrating any more projects.

> (1) Canned replies. I would rather stay with Bugzilla forever than give up
> canned replies.

Can we please drop this hyperbolic tone of "oh my god this new
platform doesn't work exactly like Bugzilla so we need to stop
everything until we replicated the subset of Bugzilla I like",
repeated for a bunch of maintainers with different subsets?

This is entirely not constructive.

You were not born with innate knowledge of Bugzilla, and even
Bugzilla's features that we use (the ones that survived the various
rebases) have been implemented over the years. I'm sure we can
re-implement stuff while we migrate, instead of expecting everything
to be as it was as a precondition for the migration.

Ciao,
 Emmanuele.

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

Re: GitLab update: Moving to the next step

[Michael Catanzaro]

On 12/07/2017 11:01 AM, Milan Crha wrote:

b) How do I reply to a comment?


This one should be a blocker to migrating any more projects. Lack of 
quoting is sufficiently annoying that it discourages me from 
participating in bug report for other maintainer's modules that have 
moved to GitLab.


I'll add two more to Milan's list:

(1) Canned replies. I would rather stay with Bugzilla forever than give 
up canned replies.


(2) Still waiting for rebase merge requests. Ditto.

Still, I think GitLab is looking pretty nice

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

Re: GitLab update: Moving to the next step

[philip . chimento]

On Thu, Dec 7, 2017 at 4:18 AM Germán Poo-Caamaño  wrote:

> On Thu, 2017-12-07 at 12:10 +, Emmanuele Bassi wrote:
> > On 7 December 2017 at 11:57, Germán Poo-Caamaño 
> > wrote:
> >
> >
> > > Have you considered the backlash to GNOME that it may cause?
> > > https://twitter.com/Amorelandra/status/938444347506180096
> > >
> > > I just learned about it.
> >
> > You should probably read the whole thread.
> >
> > https://twitter.com/puppetmasterd/status/938577068803088384
> >
> > And, yes: diversity is still an issue that we need to tackle [insert
> > subtle reminder here about the code of conduct rework that the board
> > is still working on and that I hope I'll see in my lifetime].
>
> I did read it, and I found it unfortunate. The reason to remove
> GamerGate was because of spam(!).
>
> And the wording did not help that much either:
>
> "The worst thing is that there seems to be systematic harassment of
> people (especially women) by this campaign. If so this is terrible and
> something that we absolutely condone."
>
> They absolute "condone" harassment? I think the right word was
> "condemn". But not clarification either.
>

If you scroll down in the thread past all the BS, Sijbrandij does
explicitly clarify that "we absolutely condone" was a typo, and meant to
say "absolutely can't condone".

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

Re: GitLab update: Moving to the next step

[Milan Crha]

On Wed, 2017-12-06 at 18:49 +0100, Carlos Soriano wrote:
> I have good news, after few meetings and discussions with GitLab we
> reached an agreement on a way to bring the features we need and to
> fix our most important blockers in a reasonable time and in a way
> that are synced with us.

Hi,
couple other things I faced when I touched gitlab. How is the test
instance different from the one GNOME is maybe going to use? Though I
do not see basic things even in gitlab.com interface, thus maybe
doesn't matter.

Let's start with easy things:

a) See the second comment of
   https://gitlab-test.gnome.org/mcrha/test/issues/2
   It shows like three lines of text (one line, then empty line, then
   third line). When you edit that comment you'll see I made it
   several lines, not only three - the interface is ignoring my
   Enter-s. Am I supposed to use some crazy tag when I want to divide
   paragraphs and/or write simple lines?

b) How do I reply to a comment? I really do not see it (call it
   usability issue, because this is quite unintuitive comparing to
   bugzilla, where I see beside each comment a [reply] link which
   does fancy things and saves me time). Oh, I've received an answer
   from the upstream, there's a keyboard shortcut for it, which
   involves selection on the page. I really cannot get such things
   when opening the interface (not the manual).

c) my current work flow with bugzilla involves having opened *one* tab
   in the browser with a search which contains a list of bugs changed
   since some date for four different products. I refresh it in the
   morning to see newly added bugs and eventually react to them (I
   know, that's a silly idea to take care of newly added bugs where
   reporters are active the most). How do I do the same in
   gitlab, while: 1) the space will not be wasted, because I dislike
   scrolling when it's unnecessary (and here it is); 2) it will not
   be four different tabs in the browser?

d) I cannot set labels on my test project for some reason. They are
   probably good for searching, I don't know, but trying "/label ~xxx"
   in the comment just doesn't do anything (is that the right and only
   way to set label on an issue by commenting with a code-like tags?).
   I opened an issue in gitlab.com (see my previous mail in this
   thread), maybe I do not have permission for it, in my own project?
   The test instance also doesn't auto-complete any label, which may
   or may not be related (per-project labels disabled/impossible?).

I know you can easily RTFM me, but do you know what? I didn't read any
single word of the bugzilla manual and I've been able to work with it
with no problem. Weird, I know. While there is expected some
difference, I think I should not be hunting for basic usage hints.

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

Re: GitLab update: Moving to the next step

[Emmanuele Bassi]

On 7 December 2017 at 14:17, Allan Day  wrote:
> Emmanuele Bassi  wrote:
> ...
>> This raises the question of who is going to review the currently
>> insufficient-bordering-on-useless code of conduct that we have for
>> GNOME online services and, more generally, for the community?
> ...
>
> As you know, I'm also on the Foundation Board of Directors. I'd like
> to reassure you that the board takes these issues very seriously and
> has recently been discussing the best way forward.

Thanks, Allan.

> I'm also currently chairing the Code of Conduct Working Group. While I
> can't speak for that group, from a personal point of view I think it
> makes sense to try and wrap up the Events Code of Conduct before
> looking at the one for online behaviour. Thankfully we're on the cusp
> of having that done, and much of the work that we've done in that area
> may well be transferable to online conduct, so we should hopefully be
> in a good position to move forward.

That's good to know, and I look forward to see the conclusion of the
code of conduct work for GNOME events.

Ciao,
 Emmanuele.

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

Re: GitLab update: Moving to the next step

[Allan Day]

Emmanuele Bassi  wrote:
...
> This raises the question of who is going to review the currently
> insufficient-bordering-on-useless code of conduct that we have for
> GNOME online services and, more generally, for the community?
...

As you know, I'm also on the Foundation Board of Directors. I'd like
to reassure you that the board takes these issues very seriously and
has recently been discussing the best way forward.

I'm also currently chairing the Code of Conduct Working Group. While I
can't speak for that group, from a personal point of view I think it
makes sense to try and wrap up the Events Code of Conduct before
looking at the one for online behaviour. Thankfully we're on the cusp
of having that done, and much of the work that we've done in that area
may well be transferable to online conduct, so we should hopefully be
in a good position to move forward.

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

Re: GitLab update: Moving to the next step

[Emmanuele Bassi]

On 7 December 2017 at 13:28, Allan Day  wrote:
> Emmanuele Bassi  wrote:
> ...
>> And, yes: diversity is still an issue that we need to tackle [insert
>> subtle reminder here about the code of conduct rework that the board
>> is still working on and that I hope I'll see in my lifetime].
> ...
>
> Small clarification - it's the working group [1] that's working on the
> code of conduct, not the board. Also, it's an events code of conduct,
> not one for online behaviour.

Thanks for the clarification about the scope — even though this is not
what I was led to believe the *many* times I raised this issue with
the board. Well, clearly my fault.

This raises the question of who is going to review the currently
insufficient-bordering-on-useless code of conduct that we have for
GNOME online services and, more generally, for the community?

I want to have something like the freedesktop.org code of conduct[0]
apply to all the services we have in GNOME — mailing list, IRC, Git
repositories, and issue tracking. Since two of those services are now
being coalesced into a single platform, I think we should be
exceedingly clear about what we support and, especially, what we don't
condone.

The "Bill & Ted" code of conduct we currently have is woefully
inadequate to the modern realities of what the Internet is.

Ciao,
 Emmanuele.

[0]: https://www.freedesktop.org/wiki/CodeOfConduct/

Ciao,
 Emmanuele.

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

Re: GitLab update: Moving to the next step

[Allan Day]

Emmanuele Bassi  wrote:
...
> And, yes: diversity is still an issue that we need to tackle [insert
> subtle reminder here about the code of conduct rework that the board
> is still working on and that I hope I'll see in my lifetime].
...

Small clarification - it's the working group [1] that's working on the
code of conduct, not the board. Also, it's an events code of conduct,
not one for online behaviour.

Allan
-- 
[1] https://wiki.gnome.org/Diversity/CoCWorkingGroup/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitLab update: Moving to the next step

[Emmanuele Bassi]

On 7 December 2017 at 12:18, Germán Poo-Caamaño  wrote:

>> And, yes: diversity is still an issue that we need to tackle [insert
>> subtle reminder here about the code of conduct rework that the board
>> is still working on and that I hope I'll see in my lifetime].
>
> I did read it, and I found it unfortunate. The reason to remove
> GamerGate was because of spam(!).

Well, the repository *was* in violation of the ToS for gitlab.com.

> And the wording did not help that much either:
>
> "The worst thing is that there seems to be systematic harassment of
> people (especially women) by this campaign. If so this is terrible and
> something that we absolutely condone."
>
> They absolute "condone" harassment? I think the right word was
> "condemn". But not clarification either.

Or, possibly, "we do not condone". In any case, have you thought about
reaching out to GitLab?

We should definitely raise this as a point with them — but, again:
this is *our* hosting, and we decide *our* rules.

I don't want to dismiss this at all, but the context here is
important. We are using their software, but we have our own servers
and our own code of conduct — as lightweight as it is.

>> On the other hand: we're self-hosting our own GitLab instance, so we
>> get to be as inclusive as we can, without necessarily depending on
>> some other project to make the rules.
>
> It may backlash GNOME either way, unfortunately.

I don't think so — any more that the fact that we don't get backlash
when the FSF does something dumb, or when Linus insults people — and
yet we still release our software under a FSF license, and run our
software on Linux.

Ciao,
 Emmanuele.

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

Re: GitLab update: Moving to the next step

[Germán Poo-Caamaño]

On Thu, 2017-12-07 at 12:10 +, Emmanuele Bassi wrote:
> On 7 December 2017 at 11:57, Germán Poo-Caamaño 
> wrote:
> 
> 
> > Have you considered the backlash to GNOME that it may cause?
> > https://twitter.com/Amorelandra/status/938444347506180096
> > 
> > I just learned about it.
> 
> You should probably read the whole thread.
> 
> https://twitter.com/puppetmasterd/status/938577068803088384
> 
> And, yes: diversity is still an issue that we need to tackle [insert
> subtle reminder here about the code of conduct rework that the board
> is still working on and that I hope I'll see in my lifetime].

I did read it, and I found it unfortunate. The reason to remove
GamerGate was because of spam(!).

And the wording did not help that much either:

"The worst thing is that there seems to be systematic harassment of
people (especially women) by this campaign. If so this is terrible and
something that we absolutely condone."

They absolute "condone" harassment? I think the right word was
"condemn". But not clarification either.

> On the other hand: we're self-hosting our own GitLab instance, so we
> get to be as inclusive as we can, without necessarily depending on
> some other project to make the rules.

It may backlash GNOME either way, unfortunately.

-- 
Germán Poo-Caamaño
http://calcifer.org/

signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitLab update: Moving to the next step

[Emmanuele Bassi]

On 7 December 2017 at 11:57, Germán Poo-Caamaño  wrote:


> Have you considered the backlash to GNOME that it may cause?
> https://twitter.com/Amorelandra/status/938444347506180096
>
> I just learned about it.

You should probably read the whole thread.

https://twitter.com/puppetmasterd/status/938577068803088384

And, yes: diversity is still an issue that we need to tackle [insert
subtle reminder here about the code of conduct rework that the board
is still working on and that I hope I'll see in my lifetime].

On the other hand: we're self-hosting our own GitLab instance, so we
get to be as inclusive as we can, without necessarily depending on
some other project to make the rules.

Ciao,
 Emmanuele.

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

Re: GitLab update: Moving to the next step

[Germán Poo-Caamaño]

On Wed, 2017-12-06 at 18:49 +0100, Carlos Soriano wrote:
> Hello community,
> 
> I have good news, after few meetings and discussions with GitLab we
> reached
> an agreement on a way to bring the features we need and to fix our
> most
> important blockers
>  s/8>
> in a reasonable time and in a way that are synced with us. Their team
> will
> fix our blockers in the next 1-2 months, most of them will be fix in
> the
> release of 22th of December and the rest if everything goes well in
> the
> release of 22th of January. The one left that will be an ongoing
> effort out
> of those 2 months is a richer UI experience for duplicates, which is
> going
> to be an ongoing effort.
> 
> Apologies for the blockage for those that regularly asked to migrate
> their
> project, I wanted to make sure we are doing things in the right
> steps. I
> also wanted to make sure that I get feedback and comments about the
> initiative all around in my effort to make a representation of the
> community for taking these decisions. Now it's the point where I'm
> confident, the feedback and comments both inside and outside of our
> core
> community has been largely that we should start our path to fully
> migrate
> to GitLab.
> 
> So starting today we move forward to the next step, this means that
> all
> projects that want to migrate are free to migrate. I'm also
> coordinating
> with some core apps for a migration in the upcoming month (e.g.
> Documents,
> Photos, Boxes), with other core projects to be migrated once we have
> in
> GitLab the features we need (i.e. Software, Shell, Mutter), and more
> platform-ish core projects like gtk+, glib etc. to be taken their
> time to
> ensure their migration is smooth. All depends individually of the
> project
> and the maintainer, of course.
> [...]

Have you considered the backlash to GNOME that it may cause?
https://twitter.com/Amorelandra/status/938444347506180096

I just learned about it.

-- 
Germán Poo-Caamaño
http://calcifer.org/

signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitLab update: Moving to the next step

[Milan Crha]

On Thu, 2017-12-07 at 10:03 +0100, Milan Crha wrote:
> I filled https://gitlab.com/gitlab-org/gitlab-ce/issues/40903 there.

Hi again,
and also https://gitlab.com/gitlab-org/gitlab-ce/issues/40904

I do not see how to add labels to the issue, and the test instance
doesn't do anything with "/label ~something" (literally, without
quotes) in the comment.

I added both to your issue at:
https://gitlab.gnome.org/GNOME-Community/GitLab-Infrastructure/issues/8
I do not know how to add it to the proper section, I thought it's a
wiki page hidden under your link.

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

Re: GitLab update: Moving to the next step

[Milan Crha]

On Wed, 2017-12-06 at 19:31 +0100, Carlos Soriano wrote:
> To explain it better, my discussions with them are for high impact
> changes. My bandwidth is fully in there.

Hi,
that's understood and a reason why I made it "nice to have" and nothing
more.

I filled https://gitlab.com/gitlab-org/gitlab-ce/issues/40903 there.
Bye,
Milan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list