Re: Making a phone call with GNOME

[Matthew Hodgson]

On 19/03/2018 13:27, Simon McVittie wrote:

There's no way we could have designed this correctly in Telepathy
without being aware of protocol quirks like these, and indeed this
API wasn't present in our first attempts (initially we could only
represent one-to-one conversations and named chatrooms, like in XMPP
and IRC).


Just to illustrate Simon's point further - Matrix doesn't currently have 
a first-class concept for 1:1 conversations; instead a 1:1 conversation 
is just a room which happens to have two people in it (although we do 
track whether the intent for that room is to use it for DMing a given 
user).  The reason is in part because it's incredibly common and useful 
to be able to invite 3rd parties into 1:1s - especially bots or 
assistants (human or machine)... and also to keep the API simpler and 
less special-casey.


M

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

Re: [GitLab] IMPORTANT: Mass migration plan

[Carlos Soriano]

Oh got it Phillip, apologies for the noise, I'm starting to forget the
details here and there...

On 21 March 2018 at 22:49, Alexandre Franke  wrote:

> On Wed, Mar 21, 2018 at 10:37 PM, Shaun McCance  wrote:
> > And in constructing this example for this email, I discovered that this
> > redirect ALREADY WORKS. Nevermind me. Carry on being awesome.
>
> And https://git.gnome.org/browse/nautilus/commit/?id=
> 99fa9e298b289b643aab14286479676ec85dfd24
> redirects to https://gitlab.gnome.org/GNOME/nautilus/commit/
> 99fa9e298b289b643aab14286479676ec85dfd24
> which is even more awesome. ☺
>
> --
> Alexandre Franke
> GNOME Hacker & Foundation Director
> ___
> 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: Migration of non-core apps Was: Re: [GitLab] IMPORTANT: Mass migration plan

[Carlos Soriano]

Whops sorry, your comment in the issue slipped my inbox.

gnome-commander is not migrated. bugzilla-migration is an admin user that
is used for testing migrations. My comment
https://gitlab.gnome.org/Infrastructure/GitLab/issues/83#note_24426 still
stands, there is a bug that needs fixing before a migration can happen.

Cheers

On 21 March 2018 at 22:49, Uwe Scholz  wrote:

> Hi Carlos and all the others,
>
> you migrated *Gnome Commander* to Gitlab some time ago, which isn't a
> core app of Gnome. I am the maintainer of this software and I see that
> the GitLab link to the project currently is:
>
> https://gitlab.gnome.org/bugzilla-migration/gnome-commander
>
> I am not sure about it, so I am asking it here: Will this be the final
> link? Or is there the possibility to change "bugzilla-migration" to
> something like my user name or a group, i.e. "non-core" or whatever? As
> I don't know how non-core apps will be handled in the future I am asking
> this here. I am not so deeply informed about the plans about the Gnome
> infrastructure. Maybe the answer you give is of interest for others.
>
> And I still have a problem in pushing commits to the new repository,
> I think because I am not set to the maintainer of the repository. See my
> last comment at issue #83:
> https://gitlab.gnome.org/Infrastructure/GitLab/issues/83
>
> Do I have to apply for becoming the maintainer of the Gnome Commander
> repo at GitLab somewhere?
>
> Best wishes and thank you for all your efforts so far!
> Uwe
>
> Am Tue, 20 Mar 2018 18:01:35 +0100 schrieb Carlos Soriano:
> > Hello community,
> >
> > After a few months of manually migrating projects we have moved
> > already over 60, most of them were core modules to make sure the most
> > important projects were migrated before the mass migration happens.
> > We are now at the point where a mass migration makes more sense than
> > continuing handling migrations one by one, in part also because of
> > the increasing amount of requests.
> >
> > [...]
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Migration of non-core apps Was: Re: [GitLab] IMPORTANT: Mass migration plan

[Uwe Scholz]

Hi Carlos and all the others,

you migrated *Gnome Commander* to Gitlab some time ago, which isn't a
core app of Gnome. I am the maintainer of this software and I see that
the GitLab link to the project currently is:

https://gitlab.gnome.org/bugzilla-migration/gnome-commander

I am not sure about it, so I am asking it here: Will this be the final
link? Or is there the possibility to change "bugzilla-migration" to
something like my user name or a group, i.e. "non-core" or whatever? As
I don't know how non-core apps will be handled in the future I am asking
this here. I am not so deeply informed about the plans about the Gnome
infrastructure. Maybe the answer you give is of interest for others.

And I still have a problem in pushing commits to the new repository,
I think because I am not set to the maintainer of the repository. See my
last comment at issue #83:
https://gitlab.gnome.org/Infrastructure/GitLab/issues/83

Do I have to apply for becoming the maintainer of the Gnome Commander
repo at GitLab somewhere?

Best wishes and thank you for all your efforts so far!
Uwe

Am Tue, 20 Mar 2018 18:01:35 +0100 schrieb Carlos Soriano:
> Hello community,
> 
> After a few months of manually migrating projects we have moved
> already over 60, most of them were core modules to make sure the most
> important projects were migrated before the mass migration happens.
> We are now at the point where a mass migration makes more sense than
> continuing handling migrations one by one, in part also because of
> the increasing amount of requests.
> 
> [...]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] IMPORTANT: Mass migration plan

[Alexandre Franke]

On Wed, Mar 21, 2018 at 10:37 PM, Shaun McCance  wrote:
> And in constructing this example for this email, I discovered that this
> redirect ALREADY WORKS. Nevermind me. Carry on being awesome.

And 
https://git.gnome.org/browse/nautilus/commit/?id=99fa9e298b289b643aab14286479676ec85dfd24
redirects to 
https://gitlab.gnome.org/GNOME/nautilus/commit/99fa9e298b289b643aab14286479676ec85dfd24
which is even more awesome. ☺

-- 
Alexandre Franke
GNOME Hacker & Foundation Director
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] IMPORTANT: Mass migration plan

[Shaun McCance]

Hi Carlos,

I think we might be talking about two different things. I was just
referring to CGit links, not anything with bugs/issues and users. For
example, redirecting this:

https://git.gnome.org/browse/nautilus/tree/README.md

to this:

https://gitlab.gnome.org/GNOME/nautilus/blob/master/README.md

And in constructing this example for this email, I discovered that this
redirect ALREADY WORKS. Nevermind me. Carry on being awesome.

On Wed, 2018-03-21 at 22:14 +0100, Carlos Soriano wrote:
> Regarding the impersonation, it was me being cautious, I didn't do
> any
> consultation or something like that.
> 
> My take is that the consequences of X threshold of people complaining
> about
> that would be a major issue, including possible requests for deleting
> all
> the issues migrated that contain the impersonation, and I don't want
> to
> find myself in that situation. If that surprises you, I suggest to
> take a
> moment and think again about how many different people our community
> have
> :). On the other hand, less legible text of migrated issues doesn't
> strike
> me as a major problem.
> 
> For practical reason I personally prefer the result of the migration
> with
> impersonation too.
> 
> Anyway, Philip let's go with impersonation, would you be able to take
> care
> of that?
> 
> On 21 March 2018 at 21:52, Carlos Soriano  wrote:
> 
> > Hey Shaun,
> > 
> > It wouldn't be a problem per se, actually we were doing it before.
> > However, if we do that GitLab hooks are not triggered, and we rely
> > on them.
> > So the only way forward is for everyone to start using the new
> > repos.
> > 
> > Sorry!
> > 
> > On 21 March 2018 at 21:44, Shaun McCance  wrote:
> > 
> > > On Tue, 2018-03-20 at 18:01 +0100, Carlos Soriano wrote:
> > > > - Cgit will be phased out and removed by June 1st 2018.
> > > 
> > > How tremendously difficult would it be to set up 302 redirects so
> > > that
> > > links to commits/branches/etc go to the right place in GitLab? I
> > > don't
> > > want to add to your workload. You all are already doing
> > > incredible work
> > > with a very big job. But it would be kind of nice.
> > > 
> > > --
> > > Shaun
> > > 
> > > 
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] IMPORTANT: Mass migration plan

[philip . chimento]

On Wed, Mar 21, 2018 at 2:15 PM Carlos Soriano  wrote:

> Regarding the impersonation, it was me being cautious, I didn't do any
> consultation or something like that.
>
> My take is that the consequences of X threshold of people complaining
> about that would be a major issue, including possible requests for deleting
> all the issues migrated that contain the impersonation, and I don't want to
> find myself in that situation. If that surprises you, I suggest to take a
> moment and think again about how many different people our community have
> :). On the other hand, less legible text of migrated issues doesn't strike
> me as a major problem.
>
> For practical reason I personally prefer the result of the migration with
> impersonation too.
>
> Anyway, Philip let's go with impersonation, would you be able to take care
> of that?
>

See my earlier mail, due to a GitLab bug you can either preserve the user
account, or the timestamp, but not both. While this bug is still not fixed,
doing the impersonation would make things much less legible overall because
the timestamps will be messed up, potentially posting messages out of order.

Check https://gitlab.gnome.org/Incubator/bztogl/issues/7 for more
information.

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

Re: [GitLab] IMPORTANT: Mass migration plan

[Carlos Soriano]

Regarding the impersonation, it was me being cautious, I didn't do any
consultation or something like that.

My take is that the consequences of X threshold of people complaining about
that would be a major issue, including possible requests for deleting all
the issues migrated that contain the impersonation, and I don't want to
find myself in that situation. If that surprises you, I suggest to take a
moment and think again about how many different people our community have
:). On the other hand, less legible text of migrated issues doesn't strike
me as a major problem.

For practical reason I personally prefer the result of the migration with
impersonation too.

Anyway, Philip let's go with impersonation, would you be able to take care
of that?

On 21 March 2018 at 21:52, Carlos Soriano  wrote:

> Hey Shaun,
>
> It wouldn't be a problem per se, actually we were doing it before.
> However, if we do that GitLab hooks are not triggered, and we rely on them.
> So the only way forward is for everyone to start using the new repos.
>
> Sorry!
>
> On 21 March 2018 at 21:44, Shaun McCance  wrote:
>
>> On Tue, 2018-03-20 at 18:01 +0100, Carlos Soriano wrote:
>> > - Cgit will be phased out and removed by June 1st 2018.
>>
>> How tremendously difficult would it be to set up 302 redirects so that
>> links to commits/branches/etc go to the right place in GitLab? I don't
>> want to add to your workload. You all are already doing incredible work
>> with a very big job. But it would be kind of nice.
>>
>> --
>> Shaun
>>
>>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] IMPORTANT: Mass migration plan

[Carlos Soriano]

Hey Shaun,

It wouldn't be a problem per se, actually we were doing it before. However,
if we do that GitLab hooks are not triggered, and we rely on them. So the
only way forward is for everyone to start using the new repos.

Sorry!

On 21 March 2018 at 21:44, Shaun McCance  wrote:

> On Tue, 2018-03-20 at 18:01 +0100, Carlos Soriano wrote:
> > - Cgit will be phased out and removed by June 1st 2018.
>
> How tremendously difficult would it be to set up 302 redirects so that
> links to commits/branches/etc go to the right place in GitLab? I don't
> want to add to your workload. You all are already doing incredible work
> with a very big job. But it would be kind of nice.
>
> --
> Shaun
>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] IMPORTANT: Mass migration plan

[Shaun McCance]

On Tue, 2018-03-20 at 18:01 +0100, Carlos Soriano wrote:
> - Cgit will be phased out and removed by June 1st 2018.

How tremendously difficult would it be to set up 302 redirects so that
links to commits/branches/etc go to the right place in GitLab? I don't
want to add to your workload. You all are already doing incredible work
with a very big job. But it would be kind of nice.

--
Shaun

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

Re: [GitLab] IMPORTANT: Mass migration plan

[Carlos Soriano]

Just a very quick thing, please don't rename projects :D

We have git management on disk, not only in GitLab. Not sure if our hooks
would protect against that, but better to not test them for now...

On Wed., 21 Mar. 2018, 17:57 Mathieu Bridon via desktop-devel-list, <
desktop-devel-list@gnome.org> wrote:

> On Wed, 2018-03-21 at 11:22 +0100, Arnaud Bonatti wrote:
> > Hi Milan,
> >
> > 2018-03-21 8:53 UTC+01:00, Milan Crha :
> > > Your module rename may mean also renaming in distributions, thus it
> > > should not be done in a rush and "just because we can". At least
> > > from my point of view. You also lose some kind of mind share with
> > > the rename, because existing users know what it is called now, but
> > > will be lost when you rename the module […]
> >
> > I completely agree with you, the renaming of an old and known
> > application is always a hard thing to decide and to do, and that’s
> > why it definitively needs discussions. Note that I don’t feel any
> > hurry here (in fact, I’m talking here and there about this renaming
> > since two years…), but depending on how hard it looks like to do the
> > renaming *after* the Gitlab migration,
>
> Renaming in Gitlab is trivial: in the project settings you can just
> rename the project, and Gitlab will set up redirections so that old
> URLs keep working. (at least that happened on other Gitlab instances, I
> see no reason why that wouldn't work on GNOME's)
>
>
> --
> Mathieu
> ___
> 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] IMPORTANT: Mass migration plan

[Mathieu Bridon via desktop-devel-list]

On Wed, 2018-03-21 at 11:22 +0100, Arnaud Bonatti wrote:
> Hi Milan,
> 
> 2018-03-21 8:53 UTC+01:00, Milan Crha :
> > Your module rename may mean also renaming in distributions, thus it
> > should not be done in a rush and "just because we can". At least
> > from my point of view. You also lose some kind of mind share with
> > the rename, because existing users know what it is called now, but
> > will be lost when you rename the module […]
> 
> I completely agree with you, the renaming of an old and known
> application is always a hard thing to decide and to do, and that’s
> why it definitively needs discussions. Note that I don’t feel any
> hurry here (in fact, I’m talking here and there about this renaming
> since two years…), but depending on how hard it looks like to do the
> renaming *after* the Gitlab migration,

Renaming in Gitlab is trivial: in the project settings you can just
rename the project, and Gitlab will set up redirections so that old
URLs keep working. (at least that happened on other Gitlab instances, I
see no reason why that wouldn't work on GNOME's)


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

Re: [GitLab] IMPORTANT: Mass migration plan

[Mathieu Bridon via desktop-devel-list]

On Wed, 2018-03-21 at 06:28 -0400, Carlos Soriano wrote:
> > Any chance of getting
> https://gitlab.gnome.org/Incubator/bztogl/issues/7 fixed before then?
> 
> Not sure, I think impersonating is still something some people don't
> agree with.

It's what the Gitlab "Import from Github" feature does, automatically,
by default.

I've never met anybody complaining about this, and on the contrary have
always seen people being extremely positively surprised that Gitlab
managed to preserve authorship of everything (tickets, pull requests,
etc… i.e not just commits)

Of course, that's just anecdata…

Have you actually had anyone complaining about it?


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

Re: [GitLab] IMPORTANT: Mass migration plan

[philip . chimento]

On Wed, Mar 21, 2018 at 6:50 AM Carlos Soriano  wrote:

> It could be that's a solution, could someone check?
>
> For context, my plan is to modify the migration tool as soon as possible
> to not require admin access for running it (but admin access will still be
> required for the actual migration) so everyone can help me with the whole
> thing by testing their own modules and reporting issues.
>
> On 21 March 2018 at 09:27, Germán Poo-Caamaño  wrote:
>
>> On Wed, 2018-03-21 at 08:53 -0400, Carlos Soriano wrote:
>> > > I really don’t think it is a big deal, especially if this is
>> > publicly
>> > announced
>> >
>> > It's not about if admins have powers or not, is about the fact of
>> > impersonating a user in comments. It's true that publicly announcing
>> > could
>> > be enough.
>>
>> AFAIU, it is only data migration, you are not doing anything extra that
>> was not in the user's intention.
>>
>> > However the other big issue is that notifications would be send
>> > massively, and I don't know how to prevent that. So that's basically
>> > a no-no from the start. Maybe some trick can be done, but no idea.
>>
>> Cannot you disable the email notifications during the migration?
>>
>> I mean, when you create a project, set the notification to 'disabled',
>> and enable them after the migration finishes.
>>
>> https://docs.gitlab.com/ee/api/notification_settings.html#doc-nav
>
>
The reason https://gitlab.gnome.org/Incubator/bztogl/issues/7 wasn't fixed
yet is because of a bug in GitLab. We already determined from an informal
poll that people weren't bothered by the impersonation.

You can either set the user account, or the creation time, but not both,
and I found the creation time to be more important. If anyone wants to
either fix this upstream or advocate for it, feel free. It would be trivial
to make the change in the migration tool, but it depends on how the bug is
resolved in GitLab.

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

Re: [GitLab] IMPORTANT: Mass migration plan

[Carlos Soriano]

It could be that's a solution, could someone check?

For context, my plan is to modify the migration tool as soon as possible to
not require admin access for running it (but admin access will still be
required for the actual migration) so everyone can help me with the whole
thing by testing their own modules and reporting issues.

On 21 March 2018 at 09:27, Germán Poo-Caamaño  wrote:

> On Wed, 2018-03-21 at 08:53 -0400, Carlos Soriano wrote:
> > > Should issues be filed against Infrastructure/GitLab?
> >
> > Yeah please
> >
> > > which Andre already raised. His proposal to send the announcement
> >
> > Maybe yeah, I have no idea how to do that or extract this information
> > though. Feel free to send me the list of projects/contacts and I can
> > definitely can send an email.
> >
> > > I really don’t think it is a big deal, especially if this is
> > publicly
> > announced
> >
> > It's not about if admins have powers or not, is about the fact of
> > impersonating a user in comments. It's true that publicly announcing
> > could
> > be enough.
>
> AFAIU, it is only data migration, you are not doing anything extra that
> was not in the user's intention.
>
> > However the other big issue is that notifications would be send
> > massively, and I don't know how to prevent that. So that's basically
> > a no-no from the start. Maybe some trick can be done, but no idea.
>
> Cannot you disable the email notifications during the migration?
>
> I mean, when you create a project, set the notification to 'disabled',
> and enable them after the migration finishes.
>
> https://docs.gitlab.com/ee/api/notification_settings.html#doc-nav
>
> --
> Germán Poo-Caamaño
> http://calcifer.org/
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] IMPORTANT: Mass migration plan

[Germán Poo-Caamaño]

On Wed, 2018-03-21 at 08:53 -0400, Carlos Soriano wrote:
> > Should issues be filed against Infrastructure/GitLab?
> 
> Yeah please
> 
> > which Andre already raised. His proposal to send the announcement
> 
> Maybe yeah, I have no idea how to do that or extract this information
> though. Feel free to send me the list of projects/contacts and I can
> definitely can send an email.
> 
> > I really don’t think it is a big deal, especially if this is
> publicly
> announced
> 
> It's not about if admins have powers or not, is about the fact of
> impersonating a user in comments. It's true that publicly announcing
> could
> be enough.

AFAIU, it is only data migration, you are not doing anything extra that
was not in the user's intention.

> However the other big issue is that notifications would be send
> massively, and I don't know how to prevent that. So that's basically
> a no-no from the start. Maybe some trick can be done, but no idea.

Cannot you disable the email notifications during the migration?

I mean, when you create a project, set the notification to 'disabled',
and enable them after the migration finishes.

https://docs.gitlab.com/ee/api/notification_settings.html#doc-nav

-- 
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: Making a phone call with GNOME

[Simon McVittie]

On Wed, 21 Mar 2018 at 11:43:09 +, Bob Ham wrote:
> On 19/03/18 13:27, Simon McVittie wrote:
> > There's no way we could have designed this correctly in Telepathy without
> > being aware of protocol quirks like these, and indeed this API wasn't
> > present in our first attempts (initially we could only represent
> > one-to-one conversations and named chatrooms, like in XMPP and IRC).
> 
> Can I ask how this was eventually exposed in the API?  Was there a
> boolean property on some interface, or separate interfaces for the
> different semantics, or something else?

Named chatroom: TargetHandleType = ROOM, TargetID = room's unique ID,
and the Channel has the Group interface to list its members
(including whether we are there or merely invited, members who we
invited, members who were invited by others (if we can know that), etc.)

Strictly one-to-one conversation: TargetHandleType = CONTACT,
TargetID = peer's unique ID

MSNP-style unnamed chatroom: TargetHandleType = NONE, TargetID = "",
and the Channel has the Group interface to list its members
(including whether we are there or merely invited, members who we
invited, members who were invited by others (if we can know that), etc.)

... but even that isn't enough, because XMPP chatrooms
have a unique ID that is human-readable except for when it
isn't, and Skype chatrooms have a unique identifier that
can be rejoined later but is not human-readable; so we added
https://telepathy.freedesktop.org/spec/Channel_Interface_Room.html
later on.

The complexity of Telepathy might look ridiculous, but everything is
there for a reason. If you are trying to put a UX-agnostic abstraction
layer across as many protocols as Telepathy, make sure you are aware of
what you're letting yourself in for.

libpurple is simpler than Telepathy, but it achieves that by having a
UI-centric rather than protocol-centric design, or at least it did last
time I worked with it: it's easy to use it to implement a UX that looks
a lot like Pidgin (or Pidgin with macOS widgets, i.e. Adium, or Pidgin
in a TUI, i.e. Finch), but hard to use it to implement any other UX.

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

Re: [GitLab] IMPORTANT: Mass migration plan

[Carlos Soriano]

> Should issues be filed against Infrastructure/GitLab?

Yeah please

> which Andre already raised. His proposal to send the announcement

Maybe yeah, I have no idea how to do that or extract this information
though. Feel free to send me the list of projects/contacts and I can
definitely can send an email.

> I really don’t think it is a big deal, especially if this is publicly
announced

It's not about if admins have powers or not, is about the fact of
impersonating a user in comments. It's true that publicly announcing could
be enough.

However the other big issue is that notifications would be send massively,
and I don't know how to prevent that. So that's basically a no-no from the
start. Maybe some trick can be done, but no idea.


On 21 March 2018 at 07:07, Alexandre Franke  wrote:

> On Wed, Mar 21, 2018 at 11:28 AM, Carlos Soriano 
> wrote:
> > Could you create an issue for those you know so I can evaluate them one
> by one?
> > Ideally with a way to contact their maintainers.
>
> I don’t know of other projects from the top of my head and reviewing
> the list at https://bugzilla.gnome.org/page.cgi?id=browse.html;
> classification=__all
> is probably the only way, but that would require quite an investment
> of time. I can’t take on that task right now and would appreciate
> anyone volunteering to do it. This could be split amongst several
> people.
>
> Should issues be filed against Infrastructure/GitLab?
>
> > In general I think these projects should decide themselves where they
> want
> > to live, and move either to one place or the other altogether.
>
> Sure, but they are unlikely to read d-d-l and similar lists as they
> have little interaction with our community, which Andre already
> raised. His proposal to send the announcement (amended with a note for
> non-GNOME project that they can elect to migrate outside of the GNOME
> infrastructure) sounds like a great idea.
>
> >> Any chance of getting https://gitlab.gnome.org/
> Incubator/bztogl/issues/7
> >> fixed before then?
> >
> > Not sure, I think impersonating is still something some people don't
> agree
> > with.
>
> With the kinds of power admins already have, I really don’t think it
> is a big deal, especially if this is publicly announced. Did you
> actually have people express concerns or are you just assuming like
> you were in the first place? You already got positive feedback when
> that was discussed last time.
>
> The legibility gain on the other hand *is* a big deal.
>
> >> Can we make a pass of archiving before that?
> >
> > That was my desire too, but the agreement seems to be on the opposite and
> > have all the projects even for historical reasons. We could have a
> subgroup
> > for those though.
>
> Yes, a GNOME/Archives/ subgroup sounds good.
>
> > The work load for migrating git repositories is not an issue, on the
> other
> > hand migrating bugs is a big work load.
>
> Fair enough, archiving before migration and then moving them to the
> GNOME/Archives/ subgroup would still make it easier to find stuff once
> on Gitlab. Also archiving helps with translations and bugzilla.
>
> --
> Alexandre Franke
> GNOME Hacker & Foundation Director
> ___
> 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] IMPORTANT: Mass migration plan

[Benjamin Berg]

On Wed, 2018-03-21 at 12:07 +0100, Alexandre Franke wrote:
> > > Any chance of getting https://gitlab.gnome.org/Incubator/bztogl/issues/7
> > > fixed before then?
> > 
> > Not sure, I think impersonating is still something some people
> > don't agree
> > with.
> 
> With the kinds of power admins already have, I really don’t think it
> is a big deal, especially if this is publicly announced. Did you
> actually have people express concerns or are you just assuming like
> you were in the first place? You already got positive feedback when
> that was discussed last time.
> 
> The legibility gain on the other hand *is* a big deal.

The likelyhood of complaints seems rather low. But if there are any
complaints, couldn't you effectively disable that specific user
account, deleting any private information attached to the account
itself (but leaving all the comments/bug reports intact)?

Benjamin

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] IMPORTANT: Mass migration plan

[Milan Crha]

On Wed, 2018-03-21 at 09:18 -0300, Germán Poo-Caamaño wrote:
> FWIW, he can type Epiphany, and filter it, right?. It is faster.

Hi,
yes, he can and I do it too, but he didn't and doesn't for some reason.
The set of things which can be done and which are actually used (and
which are obvious) differ for different parties, even when they all use
the same software for years.
Bye,
Milan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] IMPORTANT: Mass migration plan

[Germán Poo-Caamaño]

On Wed, 2018-03-21 at 08:53 +0100, Milan Crha wrote:
> 
> A good example is Epiphany. I asked a user to test something with it
> recently. He installed it, but he could not find it in the
> Applications. It's not "Epiphany" there, it's just "Web". I know it,
> but for him it was a surprise and a source of confusion.

It has many advantages for newcomers, although sometimes generic names
of common use may end like "Who's on first" routine by Abbott &
Costello. https://www.youtube.com/watch?v=kTcRRaXV-fg

FWIW, he can type Epiphany, and filter it, right?. It is faster.

-- 
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: Making a phone call with GNOME

[Bob Ham]

On 19/03/18 13:27, Simon McVittie wrote:

> You can't[1]
> have an XMPP conversation with two peers without joining a (named)
> chatroom. Even if *you* send every message to both of those peers,
> their clients won't know that they should send replies to both you and
> the other peer.
> 
> In contrast, on MSNP, you could start a two-party conversation and later
> decide to invite a third person.

Reflecting on this, it does seem like a subtle but pernicious problem.

> There's no way we could have designed this correctly in Telepathy without
> being aware of protocol quirks like these, and indeed this API wasn't
> present in our first attempts (initially we could only represent
> one-to-one conversations and named chatrooms, like in XMPP and IRC).

Can I ask how this was eventually exposed in the API?  Was there a
boolean property on some interface, or separate interfaces for the
different semantics, or something else?

Thanks,

Bob



signature.asc
Description: OpenPGP digital signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] IMPORTANT: Mass migration plan

[Milan Crha]

On Wed, 2018-03-21 at 11:22 +0100, Arnaud Bonatti wrote:
> Do you now understand more why I want to rename?

Hi,
yes, sure, thanks for explaining it. The reason to rename it, because
it doesn't work for DConf only, makes perfect sense. The other names do
not look good to me, but I'm not a decision maker here, neither good in
wording/naming myself, thus I'm afraid I cannot help here. Let's see
what it'll evolve to (in the next several weeks I guess).
Thanks again and bye,
Milan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] IMPORTANT: Mass migration plan

[Alexandre Franke]

On Wed, Mar 21, 2018 at 11:28 AM, Carlos Soriano  wrote:
> Could you create an issue for those you know so I can evaluate them one by 
> one?
> Ideally with a way to contact their maintainers.

I don’t know of other projects from the top of my head and reviewing
the list at 
https://bugzilla.gnome.org/page.cgi?id=browse.html=__all
is probably the only way, but that would require quite an investment
of time. I can’t take on that task right now and would appreciate
anyone volunteering to do it. This could be split amongst several
people.

Should issues be filed against Infrastructure/GitLab?

> In general I think these projects should decide themselves where they want
> to live, and move either to one place or the other altogether.

Sure, but they are unlikely to read d-d-l and similar lists as they
have little interaction with our community, which Andre already
raised. His proposal to send the announcement (amended with a note for
non-GNOME project that they can elect to migrate outside of the GNOME
infrastructure) sounds like a great idea.

>> Any chance of getting https://gitlab.gnome.org/Incubator/bztogl/issues/7
>> fixed before then?
>
> Not sure, I think impersonating is still something some people don't agree
> with.

With the kinds of power admins already have, I really don’t think it
is a big deal, especially if this is publicly announced. Did you
actually have people express concerns or are you just assuming like
you were in the first place? You already got positive feedback when
that was discussed last time.

The legibility gain on the other hand *is* a big deal.

>> Can we make a pass of archiving before that?
>
> That was my desire too, but the agreement seems to be on the opposite and
> have all the projects even for historical reasons. We could have a subgroup
> for those though.

Yes, a GNOME/Archives/ subgroup sounds good.

> The work load for migrating git repositories is not an issue, on the other
> hand migrating bugs is a big work load.

Fair enough, archiving before migration and then moving them to the
GNOME/Archives/ subgroup would still make it easier to find stuff once
on Gitlab. Also archiving helps with translations and bugzilla.

-- 
Alexandre Franke
GNOME Hacker & Foundation Director
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] IMPORTANT: Mass migration plan

[Carlos Soriano]

> What will happen to non-GNOME/third party products that we have on
Bugzilla?

Yeah, not knowing these special cases make me anxious. Could you create an
issue for those you know so I can evaluate them one by one? Ideally with a
way to contact their maintainers.

In general I think these projects should decide themselves where they want
to live, and move either to one place or the other altogether.

> Any chance of getting https://gitlab.gnome.org/Incubator/bztogl/issues/7
fixed before then?

Not sure, I think impersonating is still something some people don't agree
with.

> Can we make a pass of archiving before that?

That was my desire too, but the agreement seems to be on the opposite and
have all the projects even for historical reasons. We could have a subgroup
for those though.

The work load for migrating git repositories is not an issue, on the other
hand migrating bugs is a big work load.

On 21 March 2018 at 05:50, Alexandre Franke  wrote:

> On Tue, Mar 20, 2018 at 6:01 PM, Carlos Soriano 
> wrote:
> > Hello community,
>
> Hi,
>
> > After a few months of manually migrating projects we have moved already
> over
> > 60, most of them were core modules to make sure the most important
> projects
> > were migrated before the mass migration happens.
>
> Congratulations on that achievement.
>
> > Proposed plan and timeline for mass migration
>
> What will happen to non-GNOME/third party products that we have on
> Bugzilla? The example that comes to mind is Doxygen as it’s quite
> visible (in the top 10 when looking at weekly reports). They use
> Bugzilla but not git.gnome.org. For this specific case, they could
> move their issues to Github where their repository already is
>
> There are probably other similar cases, I seem to remember some
> projects using Launchpad for code but our Bugzilla for bug reports.
>
> In any case those probably shouldn’t be moved to the GNOME group on
> Gitlab, right?
>
> > - Projects that want their bugs migrated will create an issue in our
> > infrastructure similar to this over the next two months. These project
> bugs
> > will be migrated to GitLab issues between June 1st and June 15th 2018.
> [0]
>
> Any chance of getting
> https://gitlab.gnome.org/Incubator/bztogl/issues/7 fixed before then?
> It was supposedly blocked because you thought people would be against
> the script impersonating them, but it turned out not to be an issue so
> I guess nothing is blocking it anymore. That would vastly improve
> legibility and usefulness of migrating issues.
>
> > - Projects that doesn't create an issue for bug migration will migrate
> only
> > the repository, also by June 1st 2018.
>
> Can we make a pass of archiving before that? Several repos haven’t had
> any activity at all (not even translations) for 2, 3, … up to
> 8 years. There’s not much sense migrating those. A cleanup would
> reduce the work load.
>
> Cheers,
>
> --
> Alexandre Franke
> GNOME Hacker & Foundation Director
> ___
> 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] IMPORTANT: Mass migration plan

[Arnaud Bonatti]

Hi Milan,

2018-03-21 8:53 UTC+01:00, Milan Crha :
> Your module rename may mean also renaming in distributions, thus it
> should not be done in a rush and "just because we can". At least from
> my point of view. You also lose some kind of mind share with the
> rename, because existing users know what it is called now, but will be
> lost when you rename the module […]

I completely agree with you, the renaming of an old and known
application is always a hard thing to decide and to do, and that’s why
it definitively needs discussions. Note that I don’t feel any hurry
here (in fact, I’m talking here and there about this renaming since
two years…), but depending on how hard it looks like to do the
renaming *after* the Gitlab migration, it could be good to do it
*during* the move. That’s the only reason of my mail, asking if it’d
be better to do it at the same time.

But as you asked, let’s explain a little the reasoning anyway.

> On Wed, 2018-03-21 at 07:56 +0100, Arnaud Bonatti wrote:
>> the future name of ‘dconf-editor’ needs discussions (‘Registry’ and
>> ‘Tinkerings’ are the best I came with
>
> […] Does dconf-editor talk only to DConf, or it's
> available for any GSettings backend? If the later, then the most
> accurate (but maybe not the nicest) name would be "gsettings-editor".

The main problem really is here: `dconf-editor` doesn’t do any dconf
edition in an usual GNOME installation. Yes, it’s confusing.

To explain a little to everybody what we’re talking about: “gsettings”
is the settings part of the GLib API, used by all Gtk+/GNOME
applications; “dconf” is an underlying system, that should not be used
directly by applications developpers (it is used by the GLib library,
and could be replaced by something else at one point); “gconf” is the
previous configuration system, that has been replaced by “dconf”.

“dconf-editor” has been designed as a way to edit directly dconf keys
first (copying the UI of “gconf-editor”, that was used similarly for
gconf). Since 3.20 dconf-editor is gsettings-based for usual cases;
there has been some usual corner cases that needed dconf edits. Since
the last release, 3.28, the usual corner cases are using gsettings
calls, so in an usual GNOME installation, you shouldn’t do any dconf
edits (dconf reads are always needed, but that’s because the GLib API
needs improvements).

I’m not done with dconf edits, there are some other corner cases
(Flatpaks, I’m looking at you…). But dconf-editor might start in a not
so long future to ask the user to “remove keys without schemas”, and
that means removing keys defined by dconf but not by gsettings… here
the terminology starts to be really uncomfortable if the app name
remains “dconf-editor”.

So, yes, “gsettings-editor” would already be a real improvement on
“dconf-editor”, and it would even follow the same naming convention
(and I understand how that would be good). It’s not an excluded option
for a rename, but I have two/three problems with it:
 – first, it doesn’t follow GNOME 3 naming conventions of centering on
the objects instead of the actions (my English here is bad, but “Web”
is for viewing the _Web_, “Files” for browsing _files_, “Tweaks” are
for editing _tweaks_, and “dconf-editor” is not for editing
_dconf-editors_), and
 – I’d like to have some sort of continuity between Settings
(installed by default) < Tweaks (recommanded for usual configurations
change) < ?? (other changes not recommanded);
 – secondly, in a long-term future, there might be some other
configurations system added (QSettings, etc.), and I’d like to not
have to rename/fork every three years, for obvious reasons. :·)

Let’s talk now of my (currently) preferred propositions.

> With 'Registry', well, it's too generic and I'd say "Hello Windows"
> when I see it anywhere on Linux.

Yes. Because the app can become generic; and because this way, it’d be
clear what the application is about, as everybody knows what the
“Windows Registry” (aka “regedit”) is, while most people don’t know
what “dconf” is, nor what “gsettings” is. And I also understand
completely why desrt vetoed this option, as gsettings is designed to
avoid all the problems the Windows Registry has had. I wouldn’t be
surprised that the community doesn’t retain that name, but I like it
anyway, just for clarity reasons. :·)

The last name I came with is “Tinkerings”. Note that I’m not natively
speaking English, so I may miss something, but I came with
“Bidouillages” in French, and they etymologically look similar. It’s
generic enough for whatever evolution the application could have
(clearly), it also highlights that the user has the complete
responsibility of his/her edits, and that editing that way is clearly
not recommanded if you don’t exactly know what you’re doing. All these
things are important for a good name.

> Just my thoughts.
>   Bye,
>   Milan

Thanks for sharing. :·) Do you now understand more why I want to rename?

Regards,
Arnaud

-- 
Arnaud Bonatti

Re: [GitLab] IMPORTANT: Mass migration plan

[Alexandre Franke]

On Tue, Mar 20, 2018 at 6:01 PM, Carlos Soriano  wrote:
> Hello community,

Hi,

> After a few months of manually migrating projects we have moved already over
> 60, most of them were core modules to make sure the most important projects
> were migrated before the mass migration happens.

Congratulations on that achievement.

> Proposed plan and timeline for mass migration

What will happen to non-GNOME/third party products that we have on
Bugzilla? The example that comes to mind is Doxygen as it’s quite
visible (in the top 10 when looking at weekly reports). They use
Bugzilla but not git.gnome.org. For this specific case, they could
move their issues to Github where their repository already is

There are probably other similar cases, I seem to remember some
projects using Launchpad for code but our Bugzilla for bug reports.

In any case those probably shouldn’t be moved to the GNOME group on
Gitlab, right?

> - Projects that want their bugs migrated will create an issue in our
> infrastructure similar to this over the next two months. These project bugs
> will be migrated to GitLab issues between June 1st and June 15th 2018. [0]

Any chance of getting
https://gitlab.gnome.org/Incubator/bztogl/issues/7 fixed before then?
It was supposedly blocked because you thought people would be against
the script impersonating them, but it turned out not to be an issue so
I guess nothing is blocking it anymore. That would vastly improve
legibility and usefulness of migrating issues.

> - Projects that doesn't create an issue for bug migration will migrate only
> the repository, also by June 1st 2018.

Can we make a pass of archiving before that? Several repos haven’t had
any activity at all (not even translations) for 2, 3, … up to
8 years. There’s not much sense migrating those. A cleanup would
reduce the work load.

Cheers,

-- 
Alexandre Franke
GNOME Hacker & Foundation Director
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] IMPORTANT: Mass migration plan

[Carlos Soriano]

Hey all,

Tim-Philipp I'll discuss today with Andrea what to do here, in any case
don't worry, we will find a solution with either staying in Bugzilla or
making sure you can migrate to fdo (I'll run a migration test).

Arnaud, if you want a rename it's totally doable, several modules already
took this opportunity and requested this. The migration is done by us, so
no worries about that. Do please create issues in our GitLab infra product
stating these renames.

Andre, that's very helpful, thanks! Setting a banner in Bugzilla sounds the
best approach, could you do that?

Cheers

On 21 March 2018 at 03:53, Milan Crha  wrote:

> On Wed, 2018-03-21 at 07:56 +0100, Arnaud Bonatti wrote:
> > the future name of ‘dconf-editor’ needs discussions (‘Registry’ and
> > ‘Tinkerings’ are the best I came with
>
> Hi,
> may I ask why? What is the reasoning about changing the name of the
> dconf-editor? You want to rename a reversi game to reflect what it is
> (I had no idea what 'iagno' is until now), then you want to do
> something opposite for the dconf-editor? That looks odd. With
> 'Registry', well, it's too generic and I'd say "Hello Windows" when I
> see it anywhere on Linux. Does dconf-editor talk only to DConf, or it's
> available for any GSettings backend? If the later, then the most
> accurate (but maybe not the nicest) name would be "gsettings-editor".
> Otherwise I'd really keep the connection to DConf as obvious as it is
> now.
>
> The GConf editor currently identifies itself as "Configuration Editor"
> and the dconf-editor as "dconf Editor" in the Applications menu, both
> with the same icon. I do have both of them installed here.
>
> Your module rename may mean also renaming in distributions, thus it
> should not be done in a rush and "just because we can". At least from
> my point of view. You also lose some kind of mind share with the
> rename, because existing users know what it is called now, but will be
> lost when you rename the module (and the packages will be renamed, and
> the .desktop files will be renamed, and the application will be
> identified differently, and so on). I know that many application names
> in GNOME (and elsewhere) do not reflect what they actually do. Either
> one lives with what the decision makers decided at the beginning, or...
>
> A good example is Epiphany. I asked a user to test something with it
> recently. He installed it, but he could not find it in the
> Applications. It's not "Epiphany" there, it's just "Web". I know it,
> but for him it was a surprise and a source of confusion.
>
> Just my thoughts.
> 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] IMPORTANT: Mass migration plan

[Milan Crha]

On Wed, 2018-03-21 at 07:56 +0100, Arnaud Bonatti wrote:
> the future name of ‘dconf-editor’ needs discussions (‘Registry’ and
> ‘Tinkerings’ are the best I came with

Hi,
may I ask why? What is the reasoning about changing the name of the
dconf-editor? You want to rename a reversi game to reflect what it is
(I had no idea what 'iagno' is until now), then you want to do
something opposite for the dconf-editor? That looks odd. With
'Registry', well, it's too generic and I'd say "Hello Windows" when I
see it anywhere on Linux. Does dconf-editor talk only to DConf, or it's
available for any GSettings backend? If the later, then the most
accurate (but maybe not the nicest) name would be "gsettings-editor".
Otherwise I'd really keep the connection to DConf as obvious as it is
now.

The GConf editor currently identifies itself as "Configuration Editor"
and the dconf-editor as "dconf Editor" in the Applications menu, both
with the same icon. I do have both of them installed here.

Your module rename may mean also renaming in distributions, thus it
should not be done in a rush and "just because we can". At least from
my point of view. You also lose some kind of mind share with the
rename, because existing users know what it is called now, but will be
lost when you rename the module (and the packages will be renamed, and
the .desktop files will be renamed, and the application will be
identified differently, and so on). I know that many application names
in GNOME (and elsewhere) do not reflect what they actually do. Either
one lives with what the decision makers decided at the beginning, or...

A good example is Epiphany. I asked a user to test something with it
recently. He installed it, but he could not find it in the
Applications. It's not "Epiphany" there, it's just "Web". I know it,
but for him it was a surprise and a source of confusion.

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

Re: [GitLab] IMPORTANT: Mass migration plan

[Andre Klapper]

Thanks for coming up with a plan and working on this!

On Tue, 2018-03-20 at 18:01 +0100, Carlos Soriano wrote:
> - Bugzilla will only allow comments by June 1st 2018. Reporting new
> bugs on Bugzilla will be disabled. New issues will be reported and
> managed in GNOME's GitLab.

Reporting new tickets is easy to disable per BZ product:
editproducts.cgi offers a "Open for bug entry" checkbox.

That would still allow editing existing tickets though, like adding
comments. It is possible to make all tickets in a BZ product read-only: 
See https://phabricator.wikimedia.org/T1234 if that is wanted.

> - Bugzilla will be phased out and much likely converted into a static
> website by February 2020 (the proposed date may vary as we're still
> evaluating all the possible solutions to make sure all the bugs will
> remain available in read-only mode after Bugzilla's service
> decommission). We'll still evaluating possible ways of keeping old
> bugs available for historical reasons.

Regarding dumping BZ to static HTML pages,
https://phabricator.wikimedia.org/T1198 might come handy. You can see
the outcome at https://static-bugzilla.wikimedia.org/

> The goal is to have all GNOME projects moved to GitLab by GUADEC
> 2018; I left some time for eventual issues between 15th June and 6th
> July.

I wonder if really all project maintainers who use GNOME Bugzilla do
follow devel-announce-list / desktop-devel-list.

Has it been considered to mass-contact all email addresses listed as
"Developers" on GNOME BZ's product browse pages (e.g. bottom of
https://bugzilla.gnome.org/page.cgi?id=browse.html=Evolution )
of active BZ products, to inform them about this mailing list thread?

And/or setting up an informational banner on top of Bugzilla?
editparams.cgi offers an "announcehtml" parameter "will display
whatever is in this field at the top of every HTML page."

Cheers,
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] IMPORTANT: Mass migration plan

[Arnaud Bonatti]

tl;dr: Should I use the migration to rename my module?

2018-03-20 18:01 UTC+01:00, Carlos Soriano :
> The goal is to have all GNOME projects moved to GitLab by GUADEC 2018; I
> left some time for eventual issues between 15th June and 6th July.

First of all, I’d like to thank you and everybody who helped in making
this migration possible. Since I’m participating to the GNOME project,
I’ve been quite happy with the ‘cgit’ interface (and a little less
with the ‘bugzilla’ one, but it was ok for me), but I completely
understand how this workflow is not good enough for some modules or
some people, and the ‘gitlab’ interface seems a good solution for
solving all these problems. So let’s do a complete migration happily.
:·)

> Feel free to share your thoughts and comments about the proposal and I hope
> the timeline fits well with your activities.

The timeline and proposal look ok for me, but I have questions
regarding some of the modules I maintain.

Two of these modules –‘iagno’ and ‘dconf-editor’– need a renaming, and
I think it would be great to rename not only the application, but also
the module itself (to help finding where the development takes place);
‘iagno’ should become ‘gnome-reversi’ (with ‘org.gnome.iagno’ becoming
‘org.gnome.Reversi’), and the future name of ‘dconf-editor’ needs
discussions (‘Registry’ and ‘Tinkerings’ are the best I came with, and
there’s a veto on the first :·) ).

So the question is: should the renaming happens at the creation of the
‘gitlab’ repo, being part of the migration, or should I do it after
all has moved?

Regards,
Arnaud

-- 
Arnaud Bonatti

courriel : arnaud.bona...@gmail.com
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list