Re: Moving final mailman lists over to discourse

[Daniel Mustieles García via desktop-devel-list]

Hi all,

Yes, please, give us a chance to re-organize translation teams workflow
since most teams use mailing lists to distribute work, review translations
and welcome new members.

Also Damned Lies integration with Discourse is a critical part (I hope we
don't lose email notifications about new PO files uploaded waiting for
review)

Thanks in advance

Regards

El jue, 29 sept 2022 a las 19:25, Guillaume Bernard ()
escribió:

> Hi all,
>
> Rafael is right and Claude just opened an issue on Damned Lies project to
> track
> the implementation of Discourse in Damned Lies.
>
> https://gitlab.gnome.org/Infrastructure/damned-lies/-/issues/325
>
> For localized mailing list, some are used to notify translators about
> changes in
> the modules of their respective teams.
>
> Regards,
> --
> Guillaume Bernard
>
> Le jeudi 29 septembre 2022 à 14:18 -0300, Rafael Fontenelle a écrit :
> > Hi Neil,
> >
> > Reading your list-of-lists.txt attachment I noticed that some mailing
> > lists used by language teams in Damned Lies are in the "Lists to
> > close" category. These mailing lists are used by Damned Lies to send
> > notifications of translation activities. If closed there's a chance it
> > could break Damned Lies notifications, and I don't think Damned Lies
> > is not able to notify Discourse.
> >
> > I recommend double-checking that with GTP coordinators.
> >
> > The language team lists I found in the text file are:
> >
> > gnome-cs-l...@gnome.org
> > gnome...@gnome.org
> > gnome-el-l...@gnome.org
> > gnome-es-l...@gnome.org
> > gnome-et-l...@gnome.org
> > gnome-fy-l...@gnome.org
> > gnome-gl-l...@gnome.org
> > gnome-hu-l...@gnome.org
> > gnome-latin-l...@gnome.org
> > gnome-nl-l...@gnome.org
> > gnome-pt_br-l...@gnome.org
> > gnome-...@gnome.org
> > gnome-sk-l...@gnome.org
> > gnome-se-l...@gnome.org
> >
> > Best regards,
> > Rafael
> >
> > On Thu, Sep 29, 2022 at 12:49 PM Neil McGovern  wrote:
> > >
> > > Hi folks,
> > >
> > > On Mon, 2022-08-22 at 14:36 +0100, Neil McGovern wrote:
> > > > > As mentioned about three years ago, there's a desire to retire
> > > > > mailman
> > > > > and its dependencies on python2. Discussion is now happening on
> > > > > discourse.gnome.org.
> > > > >
> > > > > Over the coming month, I'll be going through each list that
> > > > > remains,
> > > > > seeing if they're still alive and moving them over [0]
> > > > >
> > >
> > > I've gone through every mailing list that we host, and broadly split
> > > them into two categories - lists that can be closed and ones that
> > > should be migrated to discourse.
> > >
> > > For those which should close, they've had very low activity (in some
> > > cases, zero...). For those that should move, I've made sure that
> > > there's tags in place so people can filter for a specific subject if
> > > they want. Please see the attached.
> > >
> > > For both, the archives will be preserved, but they won't accept or
> > > distribute any new mail after the end of October.
> > >
> > > Again, as a reminder, if you have any automation that's posting to
> > > mailing lists, let me know (Thanks to the release team for having
> > > already done so :P).
> > >
> > > Thanks,
> > > Neil
> > > --
> > > Neil McGovern
> > > Executive Director, The GNOME Foundation
> > > ___
> > > foundation-list mailing list
> > > foundation-l...@gnome.org
> > > https://mail.gnome.org/mailman/listinfo/foundation-list
> > ___
> > foundation-list mailing list
> > foundation-l...@gnome.org
> > https://mail.gnome.org/mailman/listinfo/foundation-list
> ___
> foundation-list mailing list
> foundation-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/foundation-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: sorry if this is the wrong place

[Daniel Mustieles García via desktop-devel-list]

This feature is called "Fractional Scaling". There are several articles
related to his explaining how to set different scaling for two displays in
the same system.

Don't want to give you concrete example webpages because I've not tested
them and I don't want to confuse you, but a quick search in Google might
help.

Regards

El lun., 14 sept. 2020 a las 14:52, Francis Grizzly Smit (<
griz...@smit.id.au>) escribió:

> I wish to make a feature request for the gnome desktop, and I cannot find
> anyway on the gnome.org sites to do this
>
> basically I have a problem with desktop font scaling I have a new 27" hi
> resolution (3840 x 2160 (16:9)) monitor and a older 27" with lesser
> resolution (1920 x 1200 (16:10)), now the fonts on the hi-res monitor were
> too small for my eyes, the lower res one was fine, now the  display options
> would let me scale the monitor, but I only need the fonts to be bigger not
> anything else (so this is a total waste), so I scale the fonts in
> gnome-tweak, this works fine on on the hi res monitor at 1.40 but it also
> scales the lower res monitor, which is a total waste, but is better than
> the other.
>
>
> so my feature request is that the font scaling be  split per monitor so I
> can have font scaling on the hi-res monitor to 1.40 and leave the other one
> at 1.00
>
>
> Hope this is not too hard to do, yours sincerely Francis Grizzly Smit.
> --
>
>.~. In my life God comes first
>/V\ but Linux is pretty high after that :-D
>   /( )\Francis (Grizzly) Smit
>   ^^-^^http://www.smit.id.au/
>
> ___
> 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: A humble concern about keyboard abilities of GNOME

[Daniel Mustieles García via desktop-devel-list]

Ok, I'm going to add a warning message to wiki's page, informing it's
deprecated and and link to the Initiatives gitlab's page.

Thanks!

El mié., 29 ene. 2020 a las 16:53, Michael Catanzaro ()
escribió:

> On Wed, Jan 29, 2020 at 8:37 am, Daniel Mustieles García
>  wrote:
> > This sounds like a new GNOME Goal, but Gitlab's format seems to be
> > more useful than wiki's one. What do you think about moving wiki's
> > goals to Gitlab (and also review status of current goals to update
> > it, if needed)?
>
> The GNOME Goals wiki page has been obsolete for as long as I remember.
> Even after the last update attempt, there are still obsolete goals like
> "PortToGMenu" (shell app menus), "HeaderBars" is listed as an
> unapproved future goal that apps should not yet implement, etc.
>
> GitLab is certainly a much better place for tracking initiatives and
> keeping things up-to-date.
>
>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: A humble concern about keyboard abilities of GNOME

[Daniel Mustieles García via desktop-devel-list]

Hi!

This sounds like a new GNOME Goal, but Gitlab's format seems to be more
useful than wiki's one .
What do you think about moving wiki's goals to Gitlab (and also review
status of current goals to update it, if needed)?

Regards

El mar., 28 ene. 2020 a las 22:36, Michael Catanzaro ()
escribió:

>
> Thanks for starting
> https://gitlab.gnome.org/GNOME/Initiatives/issues/14. It's going to
> really help ensure the consistency of our keyboard shortcuts.
>
> Michael
>
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Let's update our doaps!

[Daniel Mustieles García via desktop-devel-list]

Taken from gnome-documents, for example ;-)

 

  Christopher Davis
  mailto:christopherda...@gnome.org; />
  christopherdavis

  

  

  Alessandro Bono
  mailto:ab...@gnome.org; />
  abono

  

Regards

El mié., 16 oct. 2019 a las 11:40, Alberto Fanjul Alonso via
desktop-devel-list () escribió:

> Is there any example already done for this?
>
> I looked into doap spec http://usefulinc.com/ns/doap# and didn't find any
> author tag available.
>
> El lun., 14 oct. 2019 a las 17:40,  escribió:
>
>> Hi,
>>
>> Please take a moment to look through your .doap files and remove any
>> old/inactive maintainers, or switch them from  tags to 
>> tags. There seem to be many projects just adding new maintainers but never
>> removing old ones, as if in fear of perhaps offending the former
>> maintainers. But it would be helpful for release team to keep the doap
>> updated.
>>
>> Thanks,
>>
>> Michael
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal: Replace all references to master/slave in GNOME modules

[Daniel Mustieles García via desktop-devel-list]

El mié., 1 may. 2019 a las 14:39, Michael Gratton () escribió:

> On Wed, May 1, 2019 at 14:30, Carmen Bianca Bakker
>  wrote:
> >
> > I think the problem is that, when prompted why we should make this
> > change, you said that we need only look at Python to see why this
> > change is good. But Python did NOT change the name of their master
> > branch, so it's a disingenuous example.
>
> I never claimed that, so I'm actually the one being mis-represented
> here. :)
>

YOU DID. You've argued we should change master branch name because Python,
Django, Rust did it. You've mixed two concepts: the use of master/slave
terms in source code and the name of the master branch. Please don't fall
in victimism, you have done wrong and you should fix it.

You are completely free to change every "master" appearance in your source
code if you want so, but you shouldn't change master branch's name, we have
explained why several times.


> I did however point out that Python has replaced uses of the term
> "master", and we should do the same.
>
> //Mike
>
> --
> ⊨ Michael Gratton, Percept Wrangler.
> ⚙ 
>
>
> ___
> 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: Proposal: Replace all references to master/slave in GNOME modules

[Daniel Mustieles García via desktop-devel-list]

El mié., 1 may. 2019 a las 3:49, Ask Hjorth Larsen ()
escribió:

> Am Mi., 1. Mai 2019 um 01:07 Uhr schrieb Michael Gratton :
> >
> > On Tue, Apr 30, 2019 at 17:53, Daniel Mustieles García
> >  wrote:
> > > What has happened with this? We have a repo with a non-standard
> > > branch name and no consensus for a global change, do we?
> >
> > Just trying to find the time to write up a summary of where we are at
> > and a draft plan to move forward.
>
> But the argument that a master branch would imply slavery was not
> convincing to me and many others.  Why, then, is work in this
> direction apparently continuing?
>

Not only is continuing, we have left an open door for other maintainers to
do this same change (okay, having a symlink named master poiting to the new
branch name).

>
> I think everyone is willing to go to reasonable lengths to avoid
> direct references to actual offensive terms.  But there were many
> objections to this change.  Some are practical and will persist even
> if the change does not cause errors (non-conformity to a reasonable
> default, learning/tutorials, ...).  Another reason why a lot of us
> don't like this change, I think, is that we are also users of the
> English language and don't much appreciate being told how to think:
> Using the word 'inclusive' all the while steamrolling extremely
> specific and far-fetched ideas of some US movement upon a broad
> international community is frankly not a prime example of
> inclusiveness in my book.  What distinguishes this from the direct
> 'slavery' case is that you actually need to point to a long list of
> meanings in the Dictionary, then pick and choose.  This is outside the
> scope of 'going to reasonable lengths'.
>
> I nominate the simplest plan for 'moving forward'.
>
> Best regards
> Ask
>
> >
> > Oh that though, Daniel, I asked you back on the i18n thread when the
> > last time you had a problem working on Geary's translations with
> > Damned-Lies, but you never got back to me. Can you say when that was?
> > If you have a specific date that would be super helpful.
> >
> > Cheers,
> > //Mike
> >
> > --
> > ⊨ Michael Gratton, Percept Wrangler.
> > ⚙ 
> >
> >
> > ___
> > 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: Proposal: Replace all references to master/slave in GNOME modules

[Daniel Mustieles García via desktop-devel-list]

El mié., 1 may. 2019 a las 1:06, Michael Gratton () escribió:

> On Tue, Apr 30, 2019 at 17:53, Daniel Mustieles García
>  wrote:
> > What has happened with this? We have a repo with a non-standard
> > branch name and no consensus for a global change, do we?
>
> Just trying to find the time to write up a summary of where we are at
> and a draft plan to move forward.
>
> Oh that though, Daniel, I asked you back on the i18n thread when the
> last time you had a problem working on Geary's translations with
> Damned-Lies, but you never got back to me. Can you say when that was?
> If you have a specific date that would be super helpful.
>

Didn't see that message, sorry. Don't remember the specific day it failed.

>
> Cheers,
> //Mike
>
> --
> ⊨ Michael Gratton, Percept Wrangler.
> ⚙ 
>
>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal: Replace all references to master/slave in GNOME modules

[Daniel Mustieles García via desktop-devel-list]

El mié., 1 may. 2019 a las 4:58, Germán Poo-Caamaño ()
escribió:

> On Wed, 2019-05-01 at 03:49 +0200, Ask Hjorth Larsen via desktop-devel-
> list wrote:
> > Am Mi., 1. Mai 2019 um 01:07 Uhr schrieb Michael Gratton <
> > m...@vee.net>:
> > > On Tue, Apr 30, 2019 at 17:53, Daniel Mustieles García
> > >  wrote:
> > > > What has happened with this? We have a repo with a non-standard
> > > > branch name and no consensus for a global change, do we?
> > >
> > > Just trying to find the time to write up a summary of where we are
> > > at
> > > and a draft plan to move forward.
> >
> > But the argument that a master branch would imply slavery was not
> > convincing to me and many others.  Why, then, is work in this
> > direction apparently continuing?
>
> Michael is free to write a summary of the thread when he pleases, as
> well as he is free to write a proposal draft to move forward as he
> pleases. He does not need to convince you or me. He is a free person.
>

The problem is that he is not only writting a summary. He has renamed
master branch in GitLab, he has noticed people in Ubuntu about this change,
he has ignored us when we have said his arguments about Python, Django, etc
were not valid, he has ignored what most of the people in this thread has
said... that's not just a summary and that's not just a proposal. The
change was done before opening this thread.

>
> --
> Germán Poo-Caamaño
> https://calcifer.org/
>
>
> ___
> 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: Proposal: Replace all references to master/slave in GNOME modules

[Daniel Mustieles García via desktop-devel-list]

What has happened with this? We have a repo with a non-standard branch name
and no consensus for a global change, do we?

El sáb., 27 abr. 2019 a las 15:19, Bastien Nocera ()
escribió:

> On Sat, 2019-04-27 at 14:13 +0200, Ask Hjorth Larsen via desktop-devel-
> list wrote:
> >
> 
> > This sounds beautiful, but mindless prescriptivism like this won't
> > help any of the peoples you mention.  Want to help?  Donate money
> > where it matters.  Vote for someone good.  Avoid buying smartphones
> > produced in sweatshops - that actually reduces real-life
> > slavery.  You
> > know, /real/ things.
>
> What tells you that this isn't what Michael or anybody else already
> does, and why would it matter? In this community, you don't really get
> a say in what people think is important, or how they spend their time,
> as responsibilities are volunteered.
>
> Michael mentioned that the change is only likely to happen once it's
> possible to make it seamless, so this wouldn't take anyone's time, so
> contributors can focus on what's important to them.
>
> As mentioned *many* times on this list, we're talking about one thing,
> and one thing only. Bringing up other cases where changes might be
> needed is probably best done separately, in their own thread, and in
> their own time.
>
> ___
> 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: Proposal: Replace all references to master/slave in GNOME modules

[Daniel Mustieles García via desktop-devel-list]

El jue., 25 abr. 2019 a las 16:40, Andre Klapper () escribió:

> On Thu, 2019-04-25 at 16:24 +0200, Daniel Mustieles García wrote:
> > The next change we could discuss is about to remove daemons, parents
> > killing child process, zombies...
>
> Feel free to start that discussion if daemons and zombies bother you.
>

They don't bother me, it was just a joke... maybe I forgot to include an
emoji at the end of the phrase

>
> Trying to create a more welcoming environment by choosing your words
> more carefully is not a "change everything or nothing" debate. I don't
> see a need for a "But how far should this go?!" straw argument.
>

Sure, and I completely agree with this sentence, but I belive we should fix
the issue with Geary and later comment the language-related topics we
consider we could apply into GNOME's code.

>
> Phrases like "Kill process or sacrifice child" bother me. They can be
> rephrased and still be accurate (even if it's only "child process").
> Of course you are also free to not be bothered by such phrases.
>
> andre
> --
> Andre Klapper  |  ak...@gmx.net
> https://blogs.gnome.org/aklapper/
>
>
> ___
> 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: Proposal: Replace all references to master/slave in GNOME modules

[Daniel Mustieles García via desktop-devel-list]

Emmanuele, that was only a joke, to try to calm things down ;-)

My main target is to talk about the current change in Geary's master
branch. Once fixed or resolved that point, we can discuss the next step

El jue., 25 abr. 2019 a las 16:27, Emmanuele Bassi ()
escribió:

>
>
> On Thu, 25 Apr 2019 at 15:24, Daniel Mustieles García via
> desktop-devel-list  wrote:
>
>> The next change we could discuss is about to remove daemons, parents
>> killing child process, zombies...
>>
>
> Let's not play the tiresome "slippery slope" fallacy, here, and try to
> stick to the topic of the naming of the default branch of the Git
> repositories.
>
> Ciao,
>  Emmanuele.
>
> El jue., 25 abr. 2019 a las 16:17, Christopher Davis via
>> desktop-devel-list () escribió:
>>
>>> It does not reflect on history, it is not a reference to it.
>>>
>>>
>>> That's not how language works. Language is years of words being assigned
>>> meaning. As you
>>> described it, master/slave terminology has the same exact meaning of a
>>> relationship between a
>>> real master and slave. That connection is the problematic bit, because
>>> in some countries slavery
>>> wasn't all that long ago, and in some places it's never left or it
>>> changed forms.
>>>
>>> If we want to be an inclusive project, it would be beneficial to use
>>> language that do esn't scratch at scars
>>> when we have other metaphors we can use.
>>>
>>> Regards,
>>> Chris
>>>
>>> On Thu, Apr 25, 2019 at 10:12 AM, Pat Suwalski  wrote:
>>>
>>> On 2019-04-25 9:58 a.m., Emmanuele Bassi via desktop-devel-list wrote:
>>>
>>> If you cannot maintain even a semblance of a civil discourse, the door
>>> is shown to you at the bottom of every email.
>>>
>>> Fine, if you want it stated a different way, the terms being used are as
>>> accurate as possible. There is a master process. It tells a slave what to
>>> do. The slave process does it, no questions asked. This is what machines
>>> do. It is accurate. It does not reflect on history, it is not a reference
>>> to it. --Pat ___
>>> 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
>>
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal: Replace all references to master/slave in GNOME modules

[Daniel Mustieles García via desktop-devel-list]

The next change we could discuss is about to remove daemons, parents
killing child process, zombies...

I'd vote for fixing the current change in branch name first and once done
that discuss and comment about language, slavery and whatever we consider
we could apply to our project to be more less offensive, but fixing the
current issue should be the first action to take into account.

Regards

El jue., 25 abr. 2019 a las 16:17, Christopher Davis via desktop-devel-list
() escribió:

> It does not reflect on history, it is not a reference to it.
>
>
> That's not how language works. Language is years of words being assigned
> meaning. As you
> described it, master/slave terminology has the same exact meaning of a
> relationship between a
> real master and slave. That connection is the problematic bit, because in
> some countries slavery
> wasn't all that long ago, and in some places it's never left or it changed
> forms.
>
> If we want to be an inclusive project, it would be beneficial to use
> language that do esn't scratch at scars
> when we have other metaphors we can use.
>
> Regards,
> Chris
>
> On Thu, Apr 25, 2019 at 10:12 AM, Pat Suwalski  wrote:
>
> On 2019-04-25 9:58 a.m., Emmanuele Bassi via desktop-devel-list wrote:
>
> If you cannot maintain even a semblance of a civil discourse, the door is
> shown to you at the bottom of every email.
>
> Fine, if you want it stated a different way, the terms being used are as
> accurate as possible. There is a master process. It tells a slave what to
> do. The slave process does it, no questions asked. This is what machines
> do. It is accurate. It does not reflect on history, it is not a reference
> to it. --Pat ___
> 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
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal: Replace all references to master/slave in GNOME modules

[Daniel Mustieles García via desktop-devel-list]

Sure, sorry if my words sounded aggressive, that was not my intention. Only
meant to remark another one what was already been said in previous mails
(i18n list) and Gitlab issue.

Thanks!

El jue., 25 abr. 2019 a las 11:46, Felipe Borges ()
escribió:

> On Thu, Apr 25, 2019 at 8:54 AM Daniel Mustieles García via
> desktop-devel-list  wrote:
> >
> > Hi Michael,
> >
> > Please stop lying about changes in Django, Rust or Python branches'
> names... they stil use «master» for the main branch. Here are the changes
> those projects are discussing:
> >
> > Djando: db configuration. The comments in the issue you've mentioned are
> an interesting reading... did you read them?
> > Rust: Like Djando, it's a change in source code, not in branch name
> > Python: Again... read above
> >
> > So no, your arguments are not valid and your change in the name of the
> branch have caused problems in Damned Lies, automated scripts, etc.
> >
> > Please revert the change, it makes no sense to keep this discussion
> alive.
>
> .
>
> On Thu, Apr 25, 2019 at 10:21 AM Daniel Mustieles García via
> desktop-devel-list  wrote:
> >
> > Do we need to remember you again the incovenients of your change? Damned
> Lies is broken in Geary's module (cherry-pick doesn't work), developers and
> contributors get confused if modules name their master branches to whatever
> maintainers decide, you have broken GNOME's standard naming for development
> branches, your arguments about Django, Rust, Linux Kernel are false, you've
> done this change without asking the community, which is clearly against
> it... do you want more reasons?
>
> Daniel, could you please be more careful about your wording here? This
> should be a civil conversation between colleagues and your choice of
> words can sound slightly aggressive to some people.
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal: Replace all references to master/slave in GNOME modules

[Daniel Mustieles García via desktop-devel-list]

Never mind André! Maybe in my previous mail I should have included the
steps in the last one sent by me, to avoid confusions.

El jue., 25 abr. 2019 a las 10:54, Andre Klapper () escribió:

> One coffee later, I guess we discuss different things in this thread:
>
> 1) Whether to replace the "master/slave" terminology. I'm slightly in
> favor if *both* terms are used in connection.
> Terms like "blacklist" and "whitelist" are similar. They have a bad
> connotation for some plus are harder to interpret than terms like
> "blocklist" and "allowlist" which actually express what they do.
>
> 2) Whether to rename the git master branch ("master" having the meaning
> of "original copy" as already pointed out) when there is no slave
> branch. Which I'm not in favor.
>
> Should have written that already in my previous email instead. Meh.
> Sorry, Daniel.
>
> andre
> --
> Andre Klapper  |  ak...@gmx.net
> https://blogs.gnome.org/aklapper/
>
>
> ___
> 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: Proposal: Replace all references to master/slave in GNOME modules

[Daniel Mustieles García via desktop-devel-list]

Hi André,

The question is that the change has been made before asking the GNOME
community (translators, developers, maintainers...).

If we finally decide to rename branches of course DL should be fixed to
consider it, but it someone does this change unilaterally might break
things.

Michael has argued changes in Django, Rust, etc to justify it's change in
GNOME, but those projects have no changed branches names (maybe because the
problems it could haul?

I belive the correct way to do this should be: revert the change, follow
this thread to hear what other GNOME members think about it, take a final
and global decission.

What dou you think about this?

El jue., 25 abr. 2019 a las 10:41, Andre Klapper () escribió:

> Daniel,
>
> On Thu, 2019-04-25 at 10:21 +0200, Daniel Mustieles García wrote:
> > Do we need to remember you again the incovenients of your change?
> > Damned Lies is broken in Geary's module (cherry-pick doesn't work),
> > developers and contributors get confused if modules name their master
> > branches to whatever maintainers decide, you have broken GNOME's
> > standard naming for development branches, your arguments about
> > Django, Rust, Linux Kernel are false, you've done this change without
> > asking the community, which is clearly against it... do you want more
> > reasons?
>
> Damned Lies should get fixed if all branches got renamed (what this
> thread is about), developers and contributors do NOT get confused if
> ALL master branches are renamed which is EXACTLY what this thread is
> about anyway, that someone has "broken standard naming" in one module
> is exactly why this thread about changing the standard naming was
> started, nobody brought up any "arguments about Django, Rust, Linux
> Kernel" but only mentioned what those other projects have done in some
> area so there are no "false" arguments as you call it, and asking "the
> community" (which one? GNOME? Geary? Something else?) is probably done
> in this very thread.
>
> No need to get personal ("Do we need to remember you again") by having
> your argumentation missing most of the points made.
>
> andre
> --
> Andre Klapper  |  ak...@gmx.net
> https://blogs.gnome.org/aklapper/
>
>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal: Replace all references to master/slave in GNOME modules

[Daniel Mustieles García via desktop-devel-list]

El jue., 25 abr. 2019 a las 10:13, Michael Gratton ()
escribió:

>
> On Thu, Apr 25, 2019 at 00:20, mcatanz...@gnome.org wrote:
> > We should go to reasonable lengths to avoid offending reasonable
> > people, but if someone is offended by innocuous phrases like Master's
> > degree, master plumber, Masterpiece Theater, or the word "masterful,"
> > then I'd suggest rethink why and consider that it's probably not
> > reasonable.
>
> This is objection 1) from the original proposal. Sadly, neither you,
> nor I, nor dictionaries get to choose what terms carry current or
> historical significance, positive or negative.
>
> > Naming your primary branch something other than the
> > universally-accepted default branch name is going to confuse and
> > irritate an awful lot of developers for almost no benefit.
>
> This is objection 2) from the proposal. How specifically will it cause
> confusion and irritation given that, as I have pointed out, the
> disruption is essentially minimal?
>

Do we need to remember you again the incovenients of your change? Damned
Lies is broken in Geary's module (cherry-pick doesn't work), developers and
contributors get confused if modules name their master branches to whatever
maintainers decide, you have broken GNOME's standard naming for development
branches, your arguments about Django, Rust, Linux Kernel are false, you've
done this change without asking the community, which is clearly against
it... do you want more reasons?

>
> In any case, there are several clear and positive benefits of doing
> this. Aside from it simply being the right thing to do, it also helps
> addresses Timm's concern about lack of developers - the whole point of
> improving social inclusivity is to widen the pool of people who would
> be interested in contributing to the project.
>
> We took a step in the right direction with the CoC, lets finish the job
> properly.
>
> //Mike
>
> --
> ⊨ Michael Gratton, Percept Wrangler.
> ⚙ 
>
>
> ___
> 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: Proposal: Replace all references to master/slave in GNOME modules

[Daniel Mustieles García via desktop-devel-list]

Hi Michael,

Please stop lying about changes in Django, Rust or Python branches'
names... they stil use «master» for the main branch. Here are the changes
those projects are discussing:

Djando: db configuration. The comments in the issue you've mentioned are an
interesting reading... did you read them?
Rust: Like Djando, it's a change in source code, not in branch name
Python: Again... read above

So no, your arguments are not valid and your change in the name of the
branch have caused problems in Damned Lies, automated scripts, etc.

Please revert the change, it makes no sense to keep this discussion alive.

Regards


El jue., 25 abr. 2019 a las 3:47, Michael Gratton () escribió:

> Hi all,
>
> I'd like to formally propose as a GNOME Goal that GNOME modules replace
> references to the terms "master" and "slave". This is a worthwhile
> thing to do for social inclusiveness[0]. Many FOSS and non-FOSS
> projects, including Django[1], Python[2], and Rust[3] and the ISC[4])
> have already implemented similar programmes and it would be good for
> GNOME to do so also. The scope would be to replace occurrences of the
> terms appearing in the user interface, web sites, documentation, APIs
> (except as deprecated symbols), and git repositories - essentially
> wherever a person using or developing software for GNOME may reasonably
> encounter them.
>
> By way of background, I recently did just this for Geary[5] after a
> request via private communication. The work was essentially trivial,
> and it has been a relatively painless transition. A number of people
> have positively commented on the change, and no one has objected to the
> UI or API changes, however some feedback has been received about
> renaming the mainline branch, broadly falling into essentially three
> categories: 1) It doesn't matter, 2) it's inconvenient, and 3) it
> should be done project-wide, not piecemeal.
>
> To respond to that feedback, which I imagine will also be raised for
> this proposal, I'd suggest that (1) is clearly not the case - yes it
> doesn't matter to many people, but it does matter to some, and that's
> the whole point of making a project more socially inclusive - to make
> it better for everyone. The issue raised by (2) is not a new problem -
> we already have to remember project names, branch names, file names,
> symbol names, and so on. To make that easier we have tooling support
> (auto-completion in both GUIs and TUIs, the ability to set things as
> defaults, code symbol lookup, etc.). Further, disruption can be
> minimised by carefully choosing replacement names. I deliberately chose
> "mainline" for Geary's mainline branch name because it has the same
> auto-complete prefix as "master", for example. Want to check out the
> mainline branch? Just type "git co m", just like you always have.
> Lastly, if adopted project-wide, then we'd all get used to the new
> names rather quicky. Finally, to respond to (3) I am proposing it
> project-wide now.
>
> To summarise, let's replace the use of these deprecated terms in our
> project as a step towards making GNOME a project that everyone wants to
> use and develop for. Who's in?
>
> //Mike
>
> [0] -
> <
> https://www.cs.cmu.edu/~mjw/Language/NonSexist/vuw.non-sexist-language-guidelines.txt>,
>
> 
> [1] - 
> [2] - 
> [3] - ,
> 
> [4] - 
> [5] - 
>
> --
> ⊨ Michael Gratton, Percept Wrangler.
> ⚙ 
>
>
> ___
> 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: Heads up: Geary mainline development branch renamed to `mainline`

[Daniel Mustieles García via desktop-devel-list]

So hardcoding the name "mainline" to the list of branches that Damned Lies'
looks up resolves the problem for you... and tomorrow another maintainer
decides to rename it's master branch to whatever_non_offensive_name and DL
breaks again until a patch is submited... no, sorry but this is not a
solution for this.

GNOME's modules follow a standard nomenclature and it might be followed by
all GNOME's modules. If you disagree with the naming policy you should open
a thread, discuss it with the community and follow the final decission.
It'ns not right to open the door to change master branches name freely,
although Gitlab allows it (technical ability to change it doesn't give you
the right to do it).

Since this is a not only i18n-related issue I'm Ccing Release Team and
d-d-l to hear opinion from others, what I think you should have done before
appliying this change (opening an issue in Gitlab is not enough... not
every GNOME's member is subscribed to every proyect's notifications).

Really it is a big problem for you to have a branch called «master»? It's
annoying for me spending time on this instead of working on real
problems/tasks.

Regards

El mié., 24 abr. 2019 a las 13:17, Michael Gratton ()
escribió:

> Hi Daniel,
>
> On Wed, Apr 24, 2019 at 10:46, Daniel Mustieles García via gnome-i18n
>  wrote:
> > Great, but having modules with no standard name for
> > master/trunk/whatever branch might break applications like Damned
> > Lies, so this rename should be reconsidered, at least until we decide
> > to rename the whole modulesed's master branch to another one.
>
> The name of the mainline branch in git cannot be assumed to be "master"
> since git allows it to be changed, and as of Git 1.8 the server sends
> and the client looks for the name of the mainline branch when the repo
> is being fetched (e.g. via a clone). Changing the name of the mainline
> branch is easy to do, and in fact our Gitlab instance lets anyone with
> appropriate privs for a project do just that from the project settings
> UI.
>
> So, Damned-Lies' current behaviour is broken because it makes the
> assumption that the mainline branch is always named "master" (after
> trying a few other hard-coded names), and so it breaks in situations
> like this. However, I submitted a workaround that adds "mainline" to
> that list, and that MR[0] has been merged. I'm not sure if it has been
> deployed, but I think it may have been about a week ago.
>
> Of course, this should be fixed properly to just ask the repo what the
> right name is, and if there's interest in fixing it properly I'll
> happily look into it and submit another MR. I've also worked with
> Andrea to fix places in the sysadmin code (git hooks, GitLab
> integration, etc) making the same assumption[1], and that's been
> working fine for weeks.
>
> Anyway, it should be fixed for Geary now, so if you're still having
> problems with this as of this time last week, please let me know so I
> can look into a fix.
>
> > What would happen if every module maintainer decides to rename it's
> > master branch? It will be a mess... I just think we should keep names
> > homogeously, don't mind if it's called master, trunk... ;-)
> >>
>
> No, everything will work fine as long as people stop writing code that
> (wrongly) assumes git's mainline branch is necessarily called "master".
> :)
>
> //Mike
>
>
> [0] -
> 
> [1] -
> 
>
> --
> ⊨ Michael Gratton, Percept Wrangler.
> ⚙ 
>
>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: I believe we should reconsider our sys-tray removal

[Daniel Mustieles García via desktop-devel-list]

El lun., 25 mar. 2019 a las 12:19, Emmanuele Bassi ()
escribió:

> On Mon, 25 Mar 2019 at 10:39, Daniel Mustieles García via
> desktop-devel-list  wrote:
>
>> Can't GtkStatusIcon be modified to show icons in the top bar?
>>
>
> No.
>
> GtkStatusIcon encodes the XEMBED-based tray icon specification; this means
> that the application code is responsible for:
>
>  - sending icon data over the wire (no HiDPI, and transparency is a hack
> that breaks every other release)
>  - responding to pointer and keyboard events
>
> The latter part means that applications that show a menu are responsible
> for creating and managing the menu window and placing it at the right
> coordinates—which simply does not work in a compositor and in Wayland,
> respectively. The menu would also be styled by the toolkit, instead of
> being styled by the compositor.
>
> The only way to integrate "status icons" inside the shell UI is to move to
> a purely descriptive format:
>
>  - send the icon name from the theme
>  - send the description of the menu over the wire
>
> This would let the compositor display the icon using the appropriate
> resolution and transparency, and it would let the compositor build and
> display the menu. Sadly, this means a complete API change, which makes the
> point moot: applications would need to be changed.
>
> In any case, we do have API to achieve this—it's GMenu, and we used it for
> the application menu and for integration inside Unity for the global menus;
> it's also not used outside of GTK3 applications, and even then people do
> like using GtkMenu so much, so the point is still moot.
>
> The appindicator API/StatusNotifier specification comes close to this, but:
>
>  - appindicator is a deprecated and unmaintained API, which still falls
> back to the XEMBED protocol
>  - it's also a hack that takes a GtkMenu, serialises it, and sends it over
> the wire
>  - the StatusNotifier specification is all kinds of terrible, and
> basically the only implementation (appindicator and the KDE one) are
> normative because, according to the letter of the StatusNotifier
> specification, implementations that didn't do anything, or sent your status
> icons to Alpha Centauri and waited for user input there, are perfectly
> conformant
>
>
>> Permanently adding the extension code to the shell (which, if I've
>> undesrtood properly, "moves" icons from tray to topbar) will be a dirty but
>> effective solution.
>>
>
> Which would achieve nothing except, once again, shoving icons and menus
> into one of the most important pieces of screen real estate we have just
> because some application developers simply cannot live without their
> application icons being visible at all times. If you want to do that, use
> the extension. It's there for a reason.
>
> The tray icons were designed and meant for system status notifications:
> network state connectivity, volume level, battery level, IM status (when it
> was a thing). They were hijacked by application developers to have panel
> applets that would work across desktop environments. It was a bad idea
> then, and nothing has changed in that regard.
>
> Maybe we should maintain top-icons inside gnome-shell-extensions, so that
> it doesn't fall into disrepair because its maintainers are busy or bored.
>
>
>> I think, from my deep lack of knowledge about how it works, thak
>> GtkStatusIcon could be modified to show icons in the topbar, so
>> applications will keep calling to it without modifications, but icons would
>> appear in the topbar instead of in the tray.
>>
>> If this is technically impossible just forget about it :-)
>>
>
> Believe me, I would *love* if people "forgot about it"; but it seems this
> things have to be explained every six months, on every forum in existence,
> until the end of time, so here we are.
>

Sure, I am the first who would love to remove status icons, system-trays
and so from the desktop experience. Just considered the option of the
topbar the less bad place for them, but if it's not possible, theres
nothing to do.

Thanks for your explanation!

>
> Ciao,
>  Emmanuele.
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: I believe we should reconsider our sys-tray removal

[Daniel Mustieles García via desktop-devel-list]

Can't GtkStatusIcon be modified to show icons in the top bar? Permanently
adding the extension code to the shell (which, if I've undesrtood properly,
"moves" icons from tray to topbar) will be a dirty but effective solution.

I think, from my deep lack of knowledge about how it works, thak
GtkStatusIcon could be modified to show icons in the topbar, so
applications will keep calling to it without modifications, but icons would
appear in the topbar instead of in the tray.

If this is technically impossible just forget about it :-)

El lun., 25 mar. 2019 a las 10:28, Allan Day () escribió:

> Link Dupont  wrote:
> ...
>
>>  Is there a place
>> in the System menu (the top-right corner menu) where these application
>> icons + menus could live? The GSConnect extension adds an entry there.
>>
> ...
>
> Unfortunately, GtkStatusIcon is limited in what it allows us to do: you
> can't embed the icons in another place like this.
>
> Allan
> ___
> 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: I believe we should reconsider our sys-tray removal

[Daniel Mustieles García via desktop-devel-list]

Hi

This extension 
(Topicons) shows tray icons in the topbar so it would be possible to always
show them in the topbar instead of using the tray without touching the code
in the source applications.

Regards

El lun., 25 mar. 2019 a las 9:57, Allan Day via desktop-devel-list (<
desktop-devel-list@gnome.org>) escribió:

> Hey Britt,
>
> Britt Yazel  wrote:
>
>>
>> I want to re-poen an old argument now that we have seen the effects of
>> removing the sys-tray/app-indicator tray for well over a year. In short,
>> the users are not happy.
>>
>
> As I recently wrote on GitLab [1], I'm open to re-evaluating this from a
> design perspective. However, I think we'd need a different implementation
> from GtkStatusIcon, and to my knowledge acceptable alternative isn't
> available.
>
>
>> I believe our goals of putting pressure on application developers to
>> ditch the antiquated app-indicator model fell mostly on deaf ears
>>
>
> The goal was never to force app developers to do anything, and they can
> include a status indicator if they want. It's just that it won't be shown
> by default. If you haven't seen it, I wrote a lengthy account on my blog
> [2].
>
>
>> An example of this biting us in the arse is that with 3.32 TopIcons is
>> causing the CPU usage to run through the roof, and people are blaming the
>> Shell for the CPU usage, not the extension, leaving our users with a bad
>> taste in their mouths.
>>
>
> Can we can do a better job at sign-posting which extension people should
> use?
>
> Allan
> --
> [1] https://gitlab.gnome.org/GNOME/gnome-shell/issues/1014#note_457856
> [2] https://blogs.gnome.org/aday/2017/08/31/status-icons-and-gnome/
> ___
> 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: Anyone who could share their Perl knowledge (to make Bugzilla display a product overview page when new bug entry is disabled)?

[Daniel Mustieles García via desktop-devel-list]

Hi Andre,

I think Gtranslator's old bugs could be simply deleted or closed, since the
new version fixes most of them, and the other ones are deprecated.

Ccing Daniel García, so he can give us his opinion about this.

Thanks!

El mié., 27 feb. 2019 a las 14:35, Andre Klapper () escribió:

> On Tue, 2019-02-26 at 08:19 +0100, Andre Klapper wrote:
> > Currently GNOME Bugzilla does not show the "Browse" product page when a
> > product has been disabled for new bug entry
>
> Fixed now thanks to the help of Carlos and Olav. Pages like
> https://bugzilla.gnome.org/page.cgi?id=browse.html=gnome-shell
> work again so you can see all your old boogs and triage them! Right?
>
> If you want your project's (open) Bugzilla tasks to get copied to
> Gitlab one day in the future: A ticket at
> https://gitlab.gnome.org/Infrastructure/GitLab/issues/
> is welcome to sort out things.
> We still have 22015 open tickets in 190 Bugzilla products...
>
> Happy cleanup!
> andre
> --
> Andre Klapper  |  ak...@gmx.net
> https://blogs.gnome.org/aklapper/
>
>
> ___
> 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