Re: Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)

[Matthias Klumpp]

Am Fr., 3. Mai 2019 um 15:36 Uhr schrieb Carmen Bianca Bakker
:
>
> Je ven, 2019-05-03 je 14:45 +0200, Bastien Nocera skribis:
> > [...]
> > If we agree that the "master" in the git branch name is the same
> > "master" that's used in "master copy" meaning "the original", "the one
> > medium that other copies are made from", then it's probably a
> > "master/slave" relationship.
> >
> > There are still existing mentions of "slave copies". In short, "master
> > copies" could have been called that because the copies made from it
> > were "slave copies".
>
> This logic makes sense to me, thank you. That was the missing bit of
> logic for me. I can get on board with that.
> [...]

Is this really true though? I never once heard of a "slave copy", so I
just googled the word combination, yielding only 7.130 results, none
of which that I skimmed through relate to an actual "slave copy" as in
"copied from master". All seem to deal with copying to
slave(-machines) or copies that slaves hold.
For comparison, "master copy" yields >> 542.000.000 results. So either
the term slave copy does not exist at all, or it is very fringe and
has never been widely used or used recently.
Thinking about it, a 1:1 copy from master is still a master in its own
right and completely identical to the pristine data it was copied
from. So there is really do dependency relationship here, as you would
normally have in a traditional master<->slave pattern. All master
copies are equal in their "master-ness". So, having a slave copy makes
no logical sense to me.
tl;dr: Is there some further reading on the usage of slave copy in
projects and its common etymology with master copy?

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/
___
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

[Matthias Klumpp]

Am Fr., 26. Apr. 2019 um 18:12 Uhr schrieb :
> I'm a little surprised that nobody has yet mentioned the elephant in
> the room. The definition of "git" is not very inclusive:
>
> [...]

I really did not want to comment on this thread initially, but I would
like to add a thought to this afterall:

While I think a reasonable effort should be made to keep language
inclusive and especially not explicitly exclusive, I think that we
also must expect a level of tolerance from people joining any
community (especially a multicultural one), just because cultures are
so vastly different, like interpretation of languages is, and one will
inevitably be in a position where certain word choices or
communication threads feel strange to them.
If one approaches a situation not assuming that the other party is
after you or has bad intent, one may learn about how words are used
differently in different contexts and communities. My association with
"git" is primarily the revision control system, "master" is primarily
associated with the pristine branch in a Git repository or a
controlling process/procedure, etc. This is because I learned about
what these words mean in a computer context. If I was reading a
history book on slavery, "master" would of course be charged with a
different meaning in that particular context.
Language is in constant flux, and we, just by using a word, will add a
different meaning to it, eventually displacing whatever connotations
the word had previously, or adding new meaning to it in a new context.
E.g. I would never have thought about "master" being gender-specific
at all, simply because I hadn't yet seen the word used in a context
where it explicitly meant that.
I am not in favor of banning a word just because it has negative
connotations in one context, because it creates a lot of additional
work as well as mental barriers ("what am I allowed to say?") or
derails discussions.
E.g. as a German, I find the word "euthanize" to be a bit strange due
to our history, yet, it is a commonly used word in medical texts and
scientific publications. I know what the word means in this context,
so I am perfectly fine with its usage, because due to that I also know
the intent of the people using the word and that there are no bad
connotations at all.

Another example would be the "weboob" package that we removed from
Debian because of its sexist name(s) and images. There was a really
large discussion about it, as "weboob" as a pure name on its own,
standing for "web outside of browsers" isn't actually considered to be
sexist by everyone. However, the package was eventually (and very
rightfully so) removed because in accumulation, given how upstream
acted and how modules of the software were named and illustrated, it
was beyond any doubt clear that the intention behind the name was
indeed to deliberately be sexist and to explicitly provoke, which is
not something we would want in our community. (Please note that I
simplified the incident a lot here)

Master/slave used in conjunction is somewhat of a gray area, because
here it really is an analogy to slavery, sort of (the master fully
controls the slave which is acting on their behalf, executing any
requested task). Of course, the context is different here as well (IT
vs. history), and nobody should really think the author of code
containing the analogy is supporting slavery, or that the community
makes any statement about slavery. Since this word pair is an
intentional direct analogy to very dark history though, personally I
think that if it can be replaced, it should be.

Please don't ready any of the statements above as an attempt to be
super-objective - I don't think that is possible, and I don't even
think objectivity can be the goal here, as the issue is so deeply tied
to individual opinions and experiences as well as cultural histories
and the languages one knows. That's why IMHO the "right" solution here
is actually ultimately what the community comes up with collectively,
and what feels right for us.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/
___
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

[Matthias Klumpp]

Am Mo., 25. März 2019 um 19:39 Uhr schrieb Emmanuele Bassi via
desktop-devel-list :
>
>
>
> On Mon, 25 Mar 2019 at 18:27, Florian Müllner  wrote:
>>
>> On Mon, Mar 25, 2019 at 6:50 PM Emmanuele Bassi  wrote:
>> >
>> > You cut the part where I said the appindicator implementation should be 
>> > changed. :-)
>>
>> I thought you were referring to the client library, not the underlying spec 
>> :-)
>
> AFAIK the spec still assumes X11 like:
> ```
> org.freedesktop.StatusNotifierItem.WindowId
>
> UINT32 org.freedesktop.StatusNotifierItem.WindowId ();
>
> It's the windowing-system dependent identifier for a window, the application 
> can chose one of its windows to be available through this property or just 
> set 0 if it's not interested.
>
> ```
> or DBus-Menu:
> ```
> org.freedesktop.StatusNotifierItem.Menu
> OBJECT PATH: DBus path to an object which should implement the 
> com.canonical.dbusmenu interface
> ```

Urgh...

> on top of the whole wishy-washy "don't implement this if you don't like it, 
> Mercury is retrograde, or it's Thursday", so it's definitely needs to be 
> changed as well.

Just assume people are willing to constructively work on this. The
StatusNotifier spec is quite old now and has gone through many hands,
and I am quite confident that people from KDE and other interested
parties would have an interest in working on improving its flaws or
creating a new unified specification that GNOME also adopts. On all
sides, there might be new people now and existing perspectives can be
changed.

This all doesn't matter though if GNOME does not want to adopt
something like the StatusNotifier spec in the first place, so any
discussion about its quality and whether adopting it is a good idea or
not comes second to answering the question of whether GNOME actually
*wants* to have a solution for this.
Some more methodical usability testing would actually be nice here, I guess.
Personally, I think a desktop like GNOME has to keep at least a base
level of compatibility for existing apps, and since tray icons are
such a widespread concept still used by so many apps despite a push
from GNOME to remove them, it's fair to ask the question of whether
having some solution for displaying their information again would be
good. People don't care about GNOME as much as they care about using
their apps on it, and if a change in the desktop suddenly "breaks" a
bunch of them, it actually *is* the desktop's fault.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Gravatar vs libravatar

[Matthias Klumpp]

Am Do., 20. Sep. 2018 um 15:48 Uhr schrieb Carlos Soriano :
>
> And... we are reverting the change.
>
> The service is shutting down and actually any call to their servers is 
> redirecting to Gravatar, which is quite shady
>
> If someone wants to help with that and contact libravatar developers feel 
> free to do so.

The service actually isn't shutting down, see the very first and bold
message on the blogpost ;-)

https://blog.libravatar.org/posts/Libravatar.org_is_not_going_away/

> On Thu, 20 Sep 2018 at 15:33, Carlos Soriano  wrote:
>>
>> Done, enjoy!
>>
>> On Thu, 6 Sep 2018 at 10:03, Carlos Soriano  wrote:
>>>
>>> There has been indeed many things I didn't realize back then!
>>>
>>> This has got an overwhelming positive outcome, so seems replacing Gravatar 
>>> by libravatar is the way forward. We will replace it in two weeks if no 
>>> blocker appears.
>>>
>>> Thanks all!
>>>
>>> On Tue, 4 Sep 2018 at 18:00, Tobias Mueller  wrote:

 Hi,

 On Tue, 2018-09-04 at 11:24 -0400, Nicolas Dufresne wrote:
 > I'm surely not
 > the only one that isn't going that extreme in keeping control over
 > couple of my pictures flying around and won't go that far.
 This is much less about you than it is about other people visiting our
 Web site.  AFAIU, we trick those people into telling a third party (i.e.
 Gravatar) that they are visiting our Web site.  While people can patch
 their browsers to disable such behaviour, we might feel better when not
 doing that by default. Because.. you know.. we claim to value their
 privacy.

 Someone was going wild about the GPDR and claimed that GNOME would be
 affected. If that's the case then we better not make ship code to our
 visitors that exposes them to third parties.

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



-- 
I welcome VSRE emails. See http://vsre.info/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Mobile, or "GNOME on Purism's Librem 5"

[Matthias Klumpp]

2017-09-05 17:46 GMT+02:00 Bastien Nocera <had...@hadess.net>:
> On Sun, 2017-09-03 at 16:29 +0200, Matthias Klumpp wrote:
>> [ Please keep the CC list for replies ]
>>
> 
>> So, is having a mobile UX something in scope for GNOME as a project
>> and the GNOME Shell?
>> Did anyone try to use GNOME on a smaller, phone-sized display
>> already?
>> Is there interest in the community in actually making a "GNOME
>> Mobile"
>> a reality (of course, Purism would help with that)?
>>
>> I am looking forward to your replies!
>
> Disregarding the fact that asking for the direction GNOME would need to
> go as a project to accommodate your use case when you've already said
> you could achieve it in 18 months seems a bit, well, like putting the
> cart before the horse. Anyway...

Fair point.

> There are plenty of things to be done on "the desktop" that would be
> useful for convertible laptops (like your own Librem 11), tablets (same
> one, but without the keyboard) and small form factor tablets, like
> cheap 7" Windows tablets you can now find for under $100.
>
> In no particular order:
> - working on a tip-top On-Screen Keyboard
> - working on more touch-enabled widgets (GtkImageView, "swipe" enabled
> listbox rows, slide-under toolbars that need scroll down to show up
> again, etc.)
> - have a go at gnome-shell's "maximising sovereign windows" problem
> (it's named exactly like that in bugzilla ;)
> - experimenting with UIs with smaller screens (build yourself a ghetto
> phone with the right size screen, and try out whether we need new
> widgets, adaptive apps or just CSS changes)
> - try integrating with (currently out-of-tree) OOM killer helpers to go
> away from application lifetime management by the users
> - implementing USB "gadget" to share the device's network access, or
> music library (requires specific hardware with the gadget capability)
>
> Tons to do! Let me know if you want to start experimenting with any of
> those, I'll gladly point you the right direction, and to the right
> people.

Alright, that is great to hear! I am not a UI developer myself, but if
we go through with this at Purism I might start working on some of
these points. In any case, it is clear we need to assemble a team for
this, and that having a GNOME Mobile would be generally welcomed by
the community. Of course, close coordination with the designers and
toolkit developers is needed first.

(by the way, just as a disclaimer: I am not in charge of making
decisions on what to do for the final phone - I do gather technical
information though, so when a decision has been made we can start
easier and with less friction)

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

Re: GNOME Mobile, or "GNOME on Purism's Librem 5"

[Matthias Klumpp]

Hi!

2017-09-03 17:27 GMT+02:00 Alberto Ruiz :
> [...]
>> Did anyone try to use GNOME on a smaller, phone-sized display already?
>
> Well, yes, Nokia did Maemo 10+ years ago and it was all Gtk+ based:
> https://en.wikipedia.org/wiki/Maemo
>
> The TL;DR of that story is... messy. They created a set of separate
> widgets, hildon, that didn't have a good story as to how they would
> make it upstream. Maemo's shell was stylus and keyboard driven and
> once the iPhone appeared everything changed...
>
> One thing they got right was making a product widely available to
> GNOME developers (N770, N800, N900...).
>
>> Is there interest in the community in actually making a "GNOME Mobile"
>> a reality (of course, Purism would help with that)?
>
> I think many of us would love to see that happening. But my take on it
> is that it will only happen if people step up to do the work.

Yeah, I remember that good old times :-) Reviving Maemo is not really
an option, fortunately ;-) GNOME is much different now, and phones are
as well.

>> I am looking forward to your replies!
>
> I am not sure what you are trying to achieve with this email. Are you
> just trying to assess if the community would welcome a GNOME Mobile
> initiative? Because the response depends a lot on the specifics of how
> you want to do things.

Yes, pretty much that was the intent. At the moment, we do not know
yet how many resources we will have (if any at all, depending on the
crowdfunding) to make the phone and GNOME Mobile a reality, but
figuring out what would need to be done and how any such effort would
be received by the community is very valuable to know in advance.

> For example: are you going to be setting up a wikipage in
> wiki.gnome.org or are you going to have an in-house
> documentation/development process?
> Are you going to start writing
> mobile friendly widgets/apps in git(lab).gnome.org or are you going to
> host/bugtrack things yourselves? Are you going to start writing GNOME
> Shell extensions and patches for a mobile shell and contributing them
> upstream? Are you going to start profiling and improving GNOME Shell's
> performance on slow I/O?

If we do anything, it will be done upstream, as per Purism's vision.
So, developing an inhouse solution based on the GNOME stack wouldn't
be an option for us.

> These are a few ideas on how you might want to procede:
>
> - Communication: start communicating your vision of what a GNOME
> mobile is and document it on wiki.gnome.org and be vocal about it on
> planet.gnome.org as you make progress
> - Design: engage your designers with the design team early to see how
> we can create certain continuity between the desktop and the touch
> GNOME experiences
> - Planning: I would try to assess what are the specific technical
> challenges of the platform as of now, and start sketching a plan on
> how to overcome them
> - Iterate: I'd start trying to write a simple app (say, the messaging
> app) on a standard GNOME Shell session, look at the shortcomings, list
> them and have your developers start proposing patches and/or
> strategies to overcome those (at first, Gtk+ and GNOME Shell I'd say,
> but in the future flathub and GNOME Builder are other projects that
> you might want to engage wrt the developer experience aspect of
> things)

This is exactly the reply I was looking forward to, thank you! :-)

> There is another thing that would help Purism a lot, and it is the
> availability of the form factor itself. It would be great if we could
> have, say, a cheap (~100 USD) Intel based tablet that we could use as
> a reference and figure a way to make it available to the upstream
> developers willing to help and test. The 300 USD prototyping board is
> already expensive enough that prolly many people are not even thinking
> pledging for it (in my case, it'll be just another pile of circuits
> lying around my drawer.

Yes indeed. At this years Debconf we had a "Debian Mobile" BoF and the
inavailability of affordable boards for testing was pretty much listed
as the #1 issue to get more developer interested in mobile. The same
problem is plaguing the Plasma Mobile developers over at KDE. It would
be awesome if we could do something about that (but I can't promise
anything yet).

> Another approach could be running GNOME Shell on your laptop and
> access it remotely with an Android app, Jonas Adahl has been working
> on the GNOME Shell infrastructure for remote access and this is
> something that will certainly be feasible in the near future.

That's an interesting idea!

> Long story short, if you guys want to pull this off, you need to lead,
> with code, communicating a clear vision of what you want to achieve,
> and engaging on concrete items to start figuring out how to do this
> without conflicting with the ongoing plans of the GNOME platform.

That for sure :-) Thank you for your detailed reply!
___
desktop-devel-list mailing list

GNOME Mobile, or "GNOME on Purism's Librem 5"

[Matthias Klumpp]

[ Please keep the CC list for replies ]

Hello!

As some of you might already know from this years GUADEC or the media
coverage, we at Purism are planning to make a phone based on free
software, called the Librem 5[1] (if the crowdfunding succeeds).
We do need a UI for the phone, and using GNOME would make sense for us
since our laptops are already GNOME based.

Unfortunately, no GNOME Mobile UX exists yet, and I am not aware of
any concrete plans to change that at the moment.
I do think though that having a "GNOME Mobile" would be very
beneficial for the free software ecosystem in general, and I think it
makes sense to initiate a discussion about it, and see what actually
needs to be done to make GNOME work well on mobile.

Making a phone affects app development (we need dedicated apps for the
phone, e.g. a dialer/sms app), the toolkit (GTK+ needs a responsive
interface to adapt well to different screen sizes and form factors, as
well as maybe mobile-specific widgets), as well as the Shell and of
course a design of how a GNOME phone would look like and work in the
first place.

This is nothing a single company could just easily develop, because it
affects so many areas of GNOME, and is pretty much something the whole
project would need to be on board with.

So, is having a mobile UX something in scope for GNOME as a project
and the GNOME Shell?
Did anyone try to use GNOME on a smaller, phone-sized display already?
Is there interest in the community in actually making a "GNOME Mobile"
a reality (of course, Purism would help with that)?

I am looking forward to your replies!

Kind regards,
Matthias Klumpp (PureOS developer at Purism)


P.S: I hope this is the appropriate list for such a discussion -
putting it here seemed like a good idea to me, in case it is not we
could move this thread to another list.

[1]: https://puri.sm/shop/librem-5/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list