Re: GitLab update: Moving to the next step

[Andre Klapper]

On Wed, 2017-12-13 at 08:34 +0100, Milan Crha wrote:
> By the way, what were/are your main issues with Bugzilla?

See https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure

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

Re: GitLab update: Moving to the next step

[Carlos Soriano]

Oh haha

Carlos Soriano
GNOME Board of Directors

On Wed, Dec 13, 2017 at 10:12 AM, Florian Müllner 
wrote:

>
> On Wed, 13 Dec 2017, 09:36 Carlos Soriano,  wrote:
>
>> The shortcuts for example, would be good to have a shortcuts window as we
>> implemented recently at GNOME
>>
> The problem with those is of course that they are often not very
> discoverable themselves. Case in point, GitLab already has that somewhat
> hidden behind a '?' shortcut.
>
___
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 Wed, 13 Dec 2017, 09:36 Carlos Soriano,  wrote:

> The shortcuts for example, would be good to have a shortcuts window as we
> implemented recently at GNOME
>
The problem with those is of course that they are often not very
discoverable themselves. Case in point, GitLab already has that somewhat
hidden behind a '?' shortcut.
___
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]

GitLab is definitely intended to be compehensible withouth consulting a
manual, and just by the UI. If the UI is unclear, it's probably a bug or a
missing feature, and they have a design team for these. The shortcuts for
example, would be good to have a shortcuts window as we implemented
recently at GNOME (and that we didn't have for 14 years, so maybe give
GitLab some breath :) ).

I'm planning to do similar with newcomers experience, which has some gaps
because it assumes GitHub workflow alike knowledge at some points.

If someone proposes a bug upstream, put a comment in issue #8.

Regarding  "what are your issues with Bugzilla" you can also check out the
list in the wiki when we proposed the transition few months ago.Integrating
project repo and issue tracker was one of the main broad advantages, so
Bugzilla already falls down on that and it shows clearly with the common
git-bz, splinter and all the tricks we had in place for trying to make
integration between both repo and issue tracker work.

On Wed., 13 Dec. 2017, 08:51 Milan Crha,  wrote:

> On Thu, 2017-12-07 at 17:50 +, Emmanuele Bassi wrote:
> > I seriously doubt you were born with innate knowledge of Bugzilla -
>
> Hi,
> it sounds like you consider an intuitive interface something obscure.
> Well, it's intuitive at least for me.
>
> > even though Bugzilla's feature set is basically limited to what you
> > see in the page.
>
> Yes, that's basically the main part of it. I definitely do not know all
> the features bugzilla can do, but the basic parts I use I didn't need
> to search for in a manual, they were just there, on the screen.
>
> Like with the shortcuts in the interface of GitLab. I definitely know
> how to click on [reply] in bugzilla, but I do not know how to press 'r'
> (or any key to be considered a shortcut of this kind) on a tablet. I
> didn't try it and it probably doesn't matter.
>
> If you let me to make a side note, maybe it's similar to the reason why
> I never got to use Blender. It's a very powerful tool, but it requires
> to know so many shortcuts to be able to use it (I didn't try to use it
> for a long time, thus my information can be outdated). It can be great
> for professionals and people using it every day, but when it comes to
> newbies like me, then I'm completely lost. What I need are basic
> things. I can compare it with Rhino3D, I can do most of those basic
> things with a mouse, everything is in the interface, I do not need to
> know special shortcuts and when I open the software half year later I
> still can do it without refreshing my memory too much. I do not want to
> change subject, that's just an analogy I recalled and it is possibly
> highly inaccurate, thus forgive me if you consider it as such, please.
> 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

[Milan Crha]

On Thu, 2017-12-07 at 17:50 +, Emmanuele Bassi wrote:
> I seriously doubt you were born with innate knowledge of Bugzilla -

Hi,
it sounds like you consider an intuitive interface something obscure.
Well, it's intuitive at least for me.

> even though Bugzilla's feature set is basically limited to what you
> see in the page.

Yes, that's basically the main part of it. I definitely do not know all
the features bugzilla can do, but the basic parts I use I didn't need
to search for in a manual, they were just there, on the screen.

Like with the shortcuts in the interface of GitLab. I definitely know
how to click on [reply] in bugzilla, but I do not know how to press 'r'
(or any key to be considered a shortcut of this kind) on a tablet. I
didn't try it and it probably doesn't matter.

If you let me to make a side note, maybe it's similar to the reason why
I never got to use Blender. It's a very powerful tool, but it requires
to know so many shortcuts to be able to use it (I didn't try to use it
for a long time, thus my information can be outdated). It can be great
for professionals and people using it every day, but when it comes to
newbies like me, then I'm completely lost. What I need are basic
things. I can compare it with Rhino3D, I can do most of those basic
things with a mouse, everything is in the interface, I do not need to
know special shortcuts and when I open the software half year later I
still can do it without refreshing my memory too much. I do not want to
change subject, that's just an analogy I recalled and it is possibly
highly inaccurate, thus forgive me if you consider it as such, please.
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 Fri, 2017-12-08 at 16:50 +, philip.chime...@gmail.com wrote:
> Coming from GitHub, Bugzilla was like regressing to the stone age. If
> I were to insist that my opinion take precedence in the same way that
> has happened multiple times on this thread, I'd demand that all
> activity on Bugzilla cease immediately. I don't think that would be
> very fair for me to do either.

Hi,
yes, that makes sense and I'm also not thinking to be "better than
anybody else" (I do not know how to say it better), I'm only trying to
keep close to my current workflow, which makes me efficient in certain
way. It's understood it cannot be the same, those are different tools,
but I expect some basic stuff to work.

By the way, what were/are your main issues with Bugzilla? If it's about
pull requests, then, well, I've been told on IRC that issues and pull
requests are two different things and if you check what I'm
questioning, then you'll see it is all about tracking issues, not
proposed changes from contributors. Bugzilla is an issue tracker and
from my point of view quite powerful in many ways. Definitely much more
than issue tracker by GitLab. I really do not want markup, the less
images for smileys and emoticons, those add exactly 0 Sh to the issue
itself (just like "me too" comments in bugzilla). Bugzilla doesn't know
anything about cvs/svn/git and it (I believe) never had too, it's a
tool to maintain issues, not the code repository. That's GitLab and
some other for, if you really want a web interface for it.
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

[Carlos Soriano]

On Mon, Dec 11, 2017 at 9:17 PM, Sriram Ramkrishna 
wrote:

>
>
> On Mon, Dec 11, 2017 at 12:57 PM  wrote:
>
>> On Thu, Dec 7, 2017 at 2:04 PM, Michael Catanzaro
>>  wrote:
>> > Looking over #8, I think duplicate issues, canned replies, and
>> > dependencies between issues should all be considered blockers to
>> > issue tracker migration.
>>
>> Carlos has pointed out that there is rudimentary (not very good)
>> support for duplicates:
>>
>> https://wiki.gnome.org/GitLab#Issues
>>
>> I think it suffices for now... you just have to remember the magic
>> words /duplicate #number. Lack of duplicates was my biggest concern. I
>> trust this will be improved in the future.
>>
>> Canned replies are WIP upstream. I can live without for a short while,
>> as I trust they will be implemented sooner rather than later.
>>
>> Emmanuele and Carlos both proposed various workarounds to lack of issue
>> dependencies. One option is to use labels to track a group of related
>> issues. The other option is to manually maintain a task list issue,
>> which is a bit of manual effort, but not really a big deal.
>>
>> No further objections from me.
>>
>
> Has feedback for this particular feedback  been given to Gitlab?
>

Read my email and click the links please :( At least just the blockers and
the GitLab documentation I prepared


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

Re: GitLab update: Moving to the next step

[Sriram Ramkrishna]

On Mon, Dec 11, 2017 at 12:57 PM  wrote:

> On Thu, Dec 7, 2017 at 2:04 PM, Michael Catanzaro
>  wrote:
> > Looking over #8, I think duplicate issues, canned replies, and
> > dependencies between issues should all be considered blockers to
> > issue tracker migration.
>
> Carlos has pointed out that there is rudimentary (not very good)
> support for duplicates:
>
> https://wiki.gnome.org/GitLab#Issues
>
> I think it suffices for now... you just have to remember the magic
> words /duplicate #number. Lack of duplicates was my biggest concern. I
> trust this will be improved in the future.
>
> Canned replies are WIP upstream. I can live without for a short while,
> as I trust they will be implemented sooner rather than later.
>
> Emmanuele and Carlos both proposed various workarounds to lack of issue
> dependencies. One option is to use labels to track a group of related
> issues. The other option is to manually maintain a task list issue,
> which is a bit of manual effort, but not really a big deal.
>
> No further objections from me.
>

Has feedback for this particular feedback  been given to Gitlab?

sri


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

Re: GitLab update: Moving to the next step

[mcatanzaro]

On Thu, Dec 7, 2017 at 2:04 PM, Michael Catanzaro 
 wrote:
Looking over #8, I think duplicate issues, canned replies, and 
dependencies between issues should all be considered blockers to 
issue tracker migration.


Carlos has pointed out that there is rudimentary (not very good) 
support for duplicates:


https://wiki.gnome.org/GitLab#Issues

I think it suffices for now... you just have to remember the magic 
words /duplicate #number. Lack of duplicates was my biggest concern. I 
trust this will be improved in the future.


Canned replies are WIP upstream. I can live without for a short while, 
as I trust they will be implemented sooner rather than later.


Emmanuele and Carlos both proposed various workarounds to lack of issue 
dependencies. One option is to use labels to track a group of related 
issues. The other option is to manually maintain a task list issue, 
which is a bit of manual effort, but not really a big deal.


No further objections from me.

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

[Michael Catanzaro]

On 12/11/2017 10:15 AM, Emmanuele Bassi wrote:

That's what tags are for, given that "dependencies" and "blockers" in
Bugzilla are flat lists of bug numbers — unlike, say, Phabricator's
trees of issues.


Fair enough, actually. That does work to replace tracker bugs, which is 
my main use case for issue dependencies. I guess I don't really need 
those, then.



The BZ migration script will take the "depends_on" and "blocks"
fields, and will list them with links to the original Bugzilla bug, as
part of the issue description, to avoid hitting the database too often
during the migration, but it should be easy to check if the bug was
already moved, and replace the link to the equivalent issue on GitLab.


OK.

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

[Emmanuele Bassi]

On 11 December 2017 at 15:51,   wrote:
> On Sun, Dec 10, 2017 at 10:04 AM, Michael Catanzaro 
> wrote:
>>
>> I was providing my opinions on which issues should be blockers for GNOME.
>> I'm not issuing demands here... Carlos is running this show.
>
>
> I updated a tracker bug today:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=776514
>
> How will that be migrated?
>
> Without issue dependencies, keeping track of related tasks is going to be a
> lot harder

That's what tags are for, given that "dependencies" and "blockers" in
Bugzilla are flat lists of bug numbers — unlike, say, Phabricator's
trees of issues.

The BZ migration script will take the "depends_on" and "blocks"
fields, and will list them with links to the original Bugzilla bug, as
part of the issue description, to avoid hitting the database too often
during the migration, but it should be easy to check if the bug was
already moved, and replace the link to the equivalent issue on GitLab.

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

[mcatanzaro]

On Sun, Dec 10, 2017 at 10:04 AM, Michael Catanzaro 
 wrote:
I was providing my opinions on which issues should be blockers for 
GNOME. I'm not issuing demands here... Carlos is running this show.


I updated a tracker bug today:

https://bugzilla.gnome.org/show_bug.cgi?id=776514

How will that be migrated?

Without issue dependencies, keeping track of related tasks is going to 
be a lot harder


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

[Michael Catanzaro]

On 12/08/2017 10:50 AM, philip.chime...@gmail.com wrote:

I admire Carlos' restraint here but I'm going to say it more bluntly:
in my opinion, it is unfair to expect that any individual person's
opinion on their preferred must-haves should be able to block the
migration from moving forward. This is part of the monumental job
Carlos has been doing: gathering everyone's requirements, evaluating
them, checking the feasibility with GitLab, and deciding which ones
are blockers for GNOME _as a whole_ before we move the migration
forward. By demanding that your personal blockers take precedence, you
are undermining Carlos' hard work and the balancing act he has to
perform to get this to happen at all. It's impossible for him to make
everyone happy and I think he's done a fine job of representing
different perspectives, I dare say even ones that he doesn't agree
with. We need to trust that he is including all the factors and making
the right decision.


I was providing my opinions on which issues should be blockers for 
GNOME. I'm not issuing demands here... Carlos is running this show.


That said, if GitLab doesn't at least have real support for duplicate 
issues (its #1 problem IMO), then I will be quite displeased to lose 
Bugzilla. I still think the compromise here is to allow modules to turn 
off GitLab's issue tracker. Setting aside the rest of GitLab's features, 
surely we can agree its issue tracker is clearly inferior to what we 
have right now.


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

[Hashem Nasarat]

On Thu, Dec 7, 2017 at 12:01 PM, Milan Crha  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?
>

I was confused but figured out how to insert line breaks using Markdown:
just end the line with two spaces then a newline

For example this is on
a new line.

http://markdown-guide.readthedocs.io/en/latest/basics.html#line-return
___
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 2:36 PM Carlos Soriano  wrote:

> 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 admire Carlos' restraint here but I'm going to say it more bluntly: in my
opinion, it is unfair to expect that any individual person's opinion on
their preferred must-haves should be able to block the migration from
moving forward. This is part of the monumental job Carlos has been doing:
gathering everyone's requirements, evaluating them, checking the
feasibility with GitLab, and deciding which ones are blockers for GNOME _as
a whole_ before we move the migration forward. By demanding that your
personal blockers take precedence, you are undermining Carlos' hard work
and the balancing act he has to perform to get this to happen at all. It's
impossible for him to make everyone happy and I think he's done a fine job
of representing different perspectives, I dare say even ones that he
doesn't agree with. We need to trust that he is including all the factors
and making the right decision.

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

I have to think "I hate Bugzilla" every time I use Bugzilla, but that
didn't seem to bother anybody. I became a GNOME maintainer 395 days ago and
have had to deal with Bugzilla for most of those days, so let's say 500
times I SMHd including patches that I filed before I became a maintainer. I
even _used Google Chrome as my primary browser_ because it was the only
browser that had an extension that would turn Bugzilla bugs into Trello
cards which I found easier to deal with. Michael, I don't mean to single
you out, this is just an example, but If you think "I hate GitLab" every
other time you close a bug, then you will have to close 1000 bugs before
you approach my level of Bugzilla-rage.

Coming from GitHub, Bugzilla was like regressing to the stone age. If I
were to insist that my opinion take precedence in the same way that has
happened multiple times on this thread, I'd demand that all activity on
Bugzilla cease immediately. I don't think that would be very fair for me to
do either.


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

Re: GitLab update: Moving to the next step

[mcatanzaro]

On Fri, Dec 8, 2017 at 3:40 AM, Emilio Pozuelo Monfort 
 wrote:
Can't you write a simple greasemonkey script to add canned replies to 
gitlab, until they are implemented upstream?


No, because our web browser does not support Greasemonkey yet. (Should 
be possible to do using WebKitUserContentManager, if anyone has an itch 
to scratch.)


But thanks for your suggestion, because it reminded be that our custom 
CSS feature (which is under the hood implemented in the same way that 
user scripts would have to be) is broken under flatpak... it works by 
launching gedit to edit a text file, and that's hard to do under 
flatpak. I will fix that


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

[Emilio Pozuelo Monfort]

On 07/12/17 21:04, Michael Catanzaro wrote:
> 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.

Can't you write a simple greasemonkey script to add canned replies to gitlab,
until they are implemented upstream?

Cheers,
Emilio
___
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 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 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

Re: GitLab update: Moving to the next step

[philip . chimento]

On Wed, Dec 6, 2017 at 9:49 AM 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
> 
> 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.
>

Sounds like fantastic news!

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.
>
> With this change comes other news: We did our first batch migration of 8
> projects today, totaling 21 projects that have moved by now. Also, the
> Engagement team has started using GitLab for better tracking and
> collaboration with the rest of the community, don't hesitate to check it
> out  if you want to
> make publicity of some feature or if you want to collaborate!
>
> To make the transition easier, I created a general documentation for using
> GitLab for GNOMER's, check it out here  (feel
> free to edit).
> If you want to help, get in touch with me or check out our task list
> 
> .
> If you want your project to be moved, get in touch with me or create an
> issue like this one
> 
> .
>
> As always, I'm there for your questions and feedback. You can do so in
> this mail chain, in irc, in private messages to me or by filling issues in
> the GNOME infrastructure project
> . I just
> want to ask, please keep in mind that I'm doing this entirely in my free
> time, so be considerate, I don't have unlimited energy :)
>

Thank you for all the coordination and work you have done so far.

Also thanks to all that helped so far, specially Phillip, Emmanuele and
> Alberto.
>
> Hope you enjoy the news and the work we have done.
>

I am already getting a lot more contributions to GJS in GitLab, without
even asking for them, than I did in Bugzilla. It's fantastic!

Philip
___
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,

To explain it better, my discussions with them are for high impact changes.
My bandwidth is fully in there.

We however maintain our own list
 in
a way for us to keep an eye for improvements we want to see and also
because there are GitLab people looking at it, but I want to keep the focus
on our major issues for the direct discussions, and leave everything else
for a more regular flow discussion with upstream issues, etc.

For your issue, could you please create an issue upstream
 and add it in a comment to our
list? You are the best person to explain why you need that option.


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

On Wed, Dec 6, 2017 at 7:05 PM, Milan Crha  wrote:

> 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,
> I only recently noticed that there is no option to send mail
> notifications from Gitlab as text/plain only, while this could be
> changed in bugzilla. I agree it's no blocker, it's just nice to have.
> For me personally, I do not care of fancy fonts and whatever in
> text/plain+text/html messages they send, I prefer text/plain for
> bugzilla mail, because I care of the information, not the form (and
> less data being transferred and stored as well). In case I didn't
> overlook the option in the Gitlab preferences, could you ask them/add
> it to the list, please?
> Thanks and 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

[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,
I only recently noticed that there is no option to send mail
notifications from Gitlab as text/plain only, while this could be
changed in bugzilla. I agree it's no blocker, it's just nice to have.
For me personally, I do not care of fancy fonts and whatever in
text/plain+text/html messages they send, I prefer text/plain for
bugzilla mail, because I care of the information, not the form (and
less data being transferred and stored as well). In case I didn't
overlook the option in the Gitlab preferences, could you ask them/add
it to the list, please?
Thanks and bye,
Milan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

GitLab update: Moving to the next step

[Carlos Soriano]

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

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.

With this change comes other news: We did our first batch migration of 8
projects today, totaling 21 projects that have moved by now. Also, the
Engagement team has started using GitLab for better tracking and
collaboration with the rest of the community, don't hesitate to check it out
 if you want to make
publicity of some feature or if you want to collaborate!

To make the transition easier, I created a general documentation for using
GitLab for GNOMER's, check it out here  (feel
free to edit).
If you want to help, get in touch with me or check out our task list
.
If you want your project to be moved, get in touch with me or create an
issue like this one
.

As always, I'm there for your questions and feedback. You can do so in this
mail chain, in irc, in private messages to me or by filling issues in the GNOME
infrastructure project
. I just
want to ask, please keep in mind that I'm doing this entirely in my free
time, so be considerate, I don't have unlimited energy :)

Also thanks to all that helped so far, specially Phillip, Emmanuele and
Alberto.

Hope you enjoy the news and the work we have done.

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