Re: Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)
On Sat, 2019-05-04 at 11:33 +0200, Bastien Nocera wrote: > > I don't have a good answer for this. I didn't find an explanation one > way or the other, but there are uses of "slave copies" that aren't > "copied from master" in Google, but usually not in > recording/publishing > fields. > > I just don't know whether "slave copy" is implied in "master copy" or > whether it's completely disconnected from the term. If it's > completely > disconnected, where does "mastering" come from? > > Let me know if you find good etymologies for the verb "master". I > couldn't think of any way that it wouldn't be related to a master > copy > and its "slave" copies. I’m not willing to do research on this, but if you take a look at https://en.wikipedia.org/wiki/Mastering_(audio), it mentions that it’s the process of preparing and transferring the final audio to a master (canonical, original) storage device, which will serve as a template for all future copies. I don’t understand the obsession with pairing master-anything with slaves. In this concrete example, the better analogy would be cloning - the copies are, for all intents and purposes, identical to the one true original. ___ 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
On Wed, May 1, 2019, 15:24 Michael Gratton wrote: > On Wed, May 1, 2019 at 14:32, Ernestas Kulik > wrote: > > On Wed, 2019-05-01 at 21:38 +1000, Michael Gratton wrote: > >> > >> After deliberately setting out to make the project more inclusive, > >> Python has reversed a five-year-long trend of declining number of > >> core > >> devs and it has been increasing ever since. They have for example, > >> in > >> the last three years gone from having 0 to 4 women who are core > >> devs. > >> > >> They have also been successful in getting other projects to use more > >> inclusive language. For example, MongoDB initially refused to stop > >> using the term "master", but then relented after Python did so. > >> GNOME > >> could be in a similar position of leadership here, since it's pretty > >> clear /someone/ needs to be the first to do the right thing to get > >> others moving as well. > > > > To make a counterpoint: The GNOME Foundation straight up hired women > > to > > hold positions of leadership, and I don’t remember seeing a big > > effort > > to become inclusive. Rather, there was “just” someone generous > > enough > > to donate big money that allowed to get people onboard and pay them > > for > > their time. > > You may have missed then that Outreachy started off as the GNOME > Outreach Program for Women: <https://en.wikipedia.org/wiki/Outreachy> :) > > The Impact section there is a particularly good read about the positive > impact of inclusivity programs, in this case, for women. > That is absolutely true, it slipped my mind completely. > ___ 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
On Wed, 2019-05-01 at 15:03 +0300, Alberts Muktupāvels via desktop- devel-list wrote: > > Numbers please? For example how many contributors GNOME has lost last > year? > Do you speak about one or two people? Hundreds people? More? To be fair, I think that even losing one or two could have a ripple effect - word of mouth can be really powerful. An anecdote is my closest friends being indirectly involved, as I just don’t stop yapping about things I’m passionate about. ___ 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
On Wed, 2019-05-01 at 21:38 +1000, Michael Gratton wrote: > > After deliberately setting out to make the project more inclusive, > Python has reversed a five-year-long trend of declining number of > core > devs and it has been increasing ever since. They have for example, > in > the last three years gone from having 0 to 4 women who are core devs. > > They have also been successful in getting other projects to use more > inclusive language. For example, MongoDB initially refused to stop > using the term "master", but then relented after Python did so. > GNOME > could be in a similar position of leadership here, since it's pretty > clear /someone/ needs to be the first to do the right thing to get > others moving as well. To make a counterpoint: The GNOME Foundation straight up hired women to hold positions of leadership, and I don’t remember seeing a big effort to become inclusive. Rather, there was “just” someone generous enough to donate big money that allowed to get people onboard and pay them for their time. I still, however, see what we’re doing right now as moral grandstanding that is rather disconnected from the people in the community. ___ 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
On Wed, 2019-05-01 at 21:08 +1000, Michael Gratton wrote: > In the end, as the experience Python has had clearly shows, we will > gain much, much more by being inclusive than we lose by entertaining > a > small minority who would rather we aren't. Excuse me if I missed this, but can you elaborate on what has clearly been shown? ___ 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
On Thu, 2019-04-25 at 13:24 +0200, David Woodhouse wrote: > On Thu, 2019-04-25 at 13:04 +0200, Bastien Nocera wrote: > > > Besides, we can't use "mainline" anyway, as that is a reference > > > to > > > intravenous drug taking and since we can't be expected tell > > > homonyms > > > apart or pass basic primary school comprehension exercises by > > > applying our knowledge of context to the words we see, we'll > > > *obviously* > > > interpret all instances of the word "mainline" as references to > > > drugs... right? > > > > This is a "slippery slope" logical fallacy. Are you going to argue > > that > > we can't use "trunk" either because of its link to deforestation? > > ;) > > Why not? It makes just as much sense as eschewing "master" and > "mainline". > > I see it more as "proof by contradiction". > > The logic in this request appears to be of the form: > • Word X has bad connotations > • Word X' is a homonym of word X > • Therefore we must avoid all uses of word X and its >homonyms like X' with related etymology. > > The logic is just fundamentally flawed, which is quite clear to see > as > soon as you try to apply it to the general case. If we’re going to bring formality into the logic, then maybe I’ll butt in as well. I believe that the premise is all wrong to begin with. The claim is that this change will make GNOME somehow more inclusive, but do we have anything more than white Americans writing opinion essays, trying to absolve themselves of white guilt? Other projects being mentioned only makes everything sound more important, but is there concrete evidence of individuals being affected to the point of not contributing? Is it just so that we could give ourselves a good pat on the back and tell everyone that we are post- inclusive? For whatever it’s worth, I realize that I don’t truly care about using a different branch name in the end, but I get super annoyed by these innitiatives when they have no measurable outcomes. > And if you want to claim that I'm making the logic excessively broad, > and that the case of master¹ vs. master⁶ is somehow different to the > case of mainline¹ vs. mainline², or trunk¹ vs. trunk², then I would > happily listen to your explanation of what makes them different. > > As a software engineer, I much prefer to fix bugs rather than paper > over them with workarounds. And if the bug here is that some people > wouldn't pass a high school comprehension test because they can't > tell > the difference between different words that happen to be spelled the > same, then changing a small handful of examples doesn't really > address > the real problem. It's a workaround, not a fix. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.32 applications still missing icon changes
On Sat, Mar 30, 2019, 17:32 Leslie S Satenstein via desktop-devel-list < desktop-devel-list@gnome.org> wrote: > Monday April 4th??? Is your desktop calendar set to February? > Doesn’t really matter what calendar Michael uses, since it’s easy enough to cross-reference with the official schedule: https://wiki.gnome.org/ThreePointThirtythree#Schedule ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Check your default window size!
On Tue, 2018-03-20 at 18:29 +0100, Alexandre Franke wrote: > > Somewhat related, since not too long ago (I’d say 3.26, maybe 3.24) > Nautilus randomly forgets it’s size and will open a very small window > (with the sidebar displayed, the content area fits slightly less than > a row in height and than 2 icons in width). Hmm, we’ve actually received reports of a different issue - restoring window *position* in multi-head environments was unreliable. I’ve fixed it up a little, but removed that feature altogether from the development branch. Any issues with restoring sizes are unexpected and I’d appreciate a ticket. :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.25.90 will probably be delayed
On Sat, 2017-08-12 at 15:40 -0500, mcatanz...@gnome.org wrote: > Hi developers, > > I'm still struggling to get buildable release modulesets for > 3.25.90. > As you know, tarballs for that release were due Monday and the > release > was due Wednesday, but it's Saturday now and I haven't delivered it > yet. Normally I spend about one day working on a release and it's not > a > big deal, but this time around there have been such a huge number of > failures that it's taken all week. I can't understate how much worse > this release has been than any I've ever worked on before. > > I was hoping to finish up today, but it's just not going to happen. > Normally all releases have an app or two that fails to build and we > just mark them as skipped in the jhbuildrc that we release and roll > with it. But right now, we have tricky outstanding build failures in > low-level components [1][2] that I don't understand and which I have > spent *far* too much time on already. This is a judgment call, but I > think we're just not in a state to make our .90 beta release right > now, > since if we can't build it ourselves, distros probably won't be able > to > either. Please help fix these tricky issues and then we can see > where > we're at and decide how to adjust our schedule when they're fixed. > I've > uploaded tentative jhbuild modulesets [3] for smoketesting, so you > can > build with the exact same tarball versions and build flags that we > release. You can use a command like this: > > $ jhbuild -f sample-tarball.jhbuildrc -m gnome-apps-3.25.90.modules > build > > The good news is that a huge number of other build failures have > already been fixed. In 80% of these cases the problem was already > fixed > in git and just needed a new tarball release. It's becoming too much > effort to track down maintainers when releases are needed. When you > make incompatible changes to your module or commit build fixes, it's > important to follow the GNOME release cycle as otherwise it creates > a > big problem on release day when we can't build our tarballs against > each other. > > Michael > > [1] https://github.com/hughsie/colord/issues/54 > [2] https://github.com/hughsie/PackageKit/issues/212 > [3] I've uploaded tentative jhbuild modulesets [3] for smoketesting, > so > you can build with the exact same tarball versions and build flags > that > we release. > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list I’ve created a pull request for the colord issue. That, along with the commit you referenced, fixes the build for me. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Relicensing Nautilus to GPLv3+
On Wed, 2017-05-17 at 16:20 +0200, Bastien Nocera wrote: > > If nautilus is GPLv3+, that means we can't link it against GPLv2-only > or LGPLv2-only libraries in the extensions. That’s fair. > I'm also not opening the > can of worms that is non-GPL-compatible dependencies of extensions > (such as proprietary, or patent-encumbered GStreamer plugins), because > that's an existing problem. Loading GPL-incompatibly-licensed extensions is already a problem. For all I know, it always was. > What's the end goal for relicensing? What problems do the current > license cause that require a relicense? The end goal here is to announce what has been the case since at least two years ago (sans libnautilus-extension). We’ve got code that is licensed under GPLv3+ and we’ve wanted to use code licensed under GPLv3+, but, ironically, didn’t, because of these issues. Having libnautilus-extension licensed under LGPL makes no sense if the extensions have to be compatible with GPL when loaded. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Relicensing Nautilus to GPLv3+
(Attempt no. 2, since Geary hates me) Hi, As the current licensing situation in Nautilus is quite complicated, I and Carlos are planning a move to relicense the entire codebase to GPLv3+. The codebase has files under several licenses: LGPLv2+, GPLv2+ and GPLv3+, the latter implicitly making the project be licensed under its terms, so our options are quite limited here. The situation wrt extensions is also not entirely clear, as the extension library is LGPLv2+ with Nautilus being GPLv2+, which in turn disallows loading non-free extensions. Given the fact that it is not meant to be a generic mechanism for loading extensions, I feel like relicensing it without much consideration is reasonable. If there are no objections, we will make the switch in the following week, most likely. Regards, Ernestas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Relicensing Nautilus as GPLv3+
Hi, Nautilus has been implicitly licensed under GPLv3 for the last couple of years, since some sources ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
