Re: Making a phone call with GNOME
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
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
Re: [GitLab] IMPORTANT: Mass migration plan
> 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
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
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
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
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
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&product=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