GNOME Modulesets migrating to BuildStream
Hi All ! Following my earlier proposals (long[0], shorter[1]), our discussions with the release team in the unconference days of GUADEC, and some followup internal release team discussion[2], I'm proud to announce (with my spiffy new release team hat on) our intent to stop maintaining the GNOME releases using JHBuild and start using BuildStream[3] for builds and releasing GNOME. Yes, this is going to be a disruptive change for many who are used to doing everything with JHBuild, but it will be for the best; refer to my opening mail in the above reffered thread[2] for a list of the immediate benefits. For the short term, we will continue to support and maintain the JHBuild modulesets, using the automated conversion system (which I previously outlined in my blog[4]), so you can continue to use JHBuild to build from upstrem maintained GNOME modulesets for a short time, but a cut off day is going to have to happen in order to unblock my work on further improvements (like conditionally using the same modulesets to generate the GNOME Flatpak SDKs, and creating bootable images which developers can use to test more integrated components like gnome session, gnome shell, GDM and gnome keyring). This cut off wont happen in 2017, but will happen before the release of GNOME 3.28 stable. From now on, we will be creating the development releases using BuildStream. You are all encouraged to try BuildStream, following the wiki page we setup[5] which will replace the official getting started wiki page[6], help us find and address any problems you might encounter before the transition is complete. In closing, we've been making a lot of promises for a year now, and I think we've delivered on a lot of them so far, I'm happy with the progress and it wont stop here ! Best Regards, -Tristan [0]: https://mail.gnome.org/archives/desktop-devel-list/2017-April/msg00071.html [1]: https://mail.gnome.org/archives/desktop-devel-list/2017-July/msg00027.html [2]: https://mail.gnome.org/archives/release-team/2017-October/msg00018.html [3]: https://wiki.gnome.org/Projects/BuildStream [4]: https://blogs.gnome.org/tvb/2017/06/01/continuous-bst-conversions-of-gnome-modulesets/ [5]: https://wiki.gnome.org/Newcomers/BuildSystemComponentBst [6]: https://wiki.gnome.org/Newcomers/BuildSystemComponent ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Modulesets migrating to BuildStream
On 11/09/2017 03:20 AM, Tristan Van Berkom wrote: . This cut off wont happen in 2017, but will happen before the release of GNOME 3.28 stable. From now on, we will be creating the development releases using BuildStream. I'm all for seeing the BuildStream conversion happen. But I do have some concerns regarding the timeline. Many of us have been pushing hard to improve developer workflow. It appears that BuildStream will, very soon, be a great tool in that endeavor. However, many of us plan our cycles before the cycle starts so that we ensure we have time to implement features without burning out. We're already two months into the 3.28 cycle and not far away from the beginning of freezes. Doubly so when you take into account winter holidays. This change will undoubtedly affect those of us working on tooling, newcomer documentation, and worflow. So I'm somewhat concerned that I'm having, what appears to be, a large amount of work dropped on my plate mid-cycle if Builder is to not degrade in usefulness for GNOME developers. How can we ensure that this change happens without breaking Builder users using the jhbuild runtime? If I somehow miraculously find time to both learn BuildStream and automate it in Builder's nightly builds, that still means we have to get people using Nightly instead of the stable release. That sort of ties my hands in terms of stability in git master, but in the realm of possibility. Change of this magnitude is a lot of work and we all value the amount of effort you're putting into this. Cheers, -- Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal for reducing the number of unremovable apps in GNOME Software
On Tue, 2017-11-07 at 11:05 +, Allan Day wrote: > Bastien Nocera wrote: > ... > > I don't think that applications such as Calendar, Contacts, or > > finding > > and reminding apps should be removed from the requirements for a > > well- > > rounded, default desktop. How they're installed is a technical > > question > > that's not relevant to the fact that they're needed. > > That's certainly true. I'm mostly coming it this from a direction of > a) trying to figure out what the user experience will look like on a > flatpak-based system and b) having done some digging, feeling > somewhat dissatisfied with the current use of > . Particular issues that I see: > > 1. is only respected by Software or other > "app centers", so you get different behaviour with the command line, > which lets you install and remove apps that Software doesn't. This > adds complexity, makes testing difficult, and introduces bugs. It > also creates ambiguity; I don't think anyone is really sure what the > experience is supposed to be. I think that's actually a benefit. rpm/dpkg don't know about Flatpak, and vice-versa. But Software knows both, and I should be able to remove the distro provided version of the software if I've installed the same "mandatory" app using Flatpak (they should have the same ID, otherwise it's a bug). Installing Flatpaks and removing RPMs is how some of us are slowly edging towards Flatpak, dog-fooding Flatpak itself, the infrastructure around it such as portals, and the software itself if we use nightlies. > 2. In Software, is used to hide apps that > belong to other desktops. In part I think this is motivated by the > desire not to end up with identical apps (because stock apps tend to > use the icon theme and often have identical names). However, it has > the side-effect that applications that could easily be installed > can't be. This is because it equates something being essential to an > environment as meaning that it shouldn't be available outside of it, > which I don't think is always the case - we might well say that > Photos is essential to GNOME 3, but that doesn't necessarily mean > that it shouldn't be installable on a non-GNOME system. That seems like a problem in the appstream format which needs to be fixed, and possibly have better replacements. Incidentally, do you rename Photos to GNOME Photos when the current desktop isn't GNOME? > 3. I guess I just find it strange that this mechanism is so > decentralised. Can anyone use ? Who makes the > decisions about what's included and what isn't? How is that monitored > and managed? If the lack of centralisation is a problem, we can move that "you can't uninstall this" list to gnome-desktop for the GNOME desktop. It would make it easier for the release team to maintain, and curate. > Relying an the ostree/flatpak split to determine which apps are > removable has some advantages in relation to this - it would remove a > layer of configuration, you'd get a consistent experience and GUI > tools would be transparent in how they operate, it would be the OS > builder who decides what forms part of the product, and projects > could decide what to make available as standalone apps simply by > making them available as flatpaks or not. > > Maybe there are issues with this approach - and I certainly take the > point about updates - but maybe it's also illustrative of what we > ought to be aiming for. I don't think that the underlying technology should be used as the safeguard for whether or not something can be uninstalled. As a case in point, most core applications on iOS, the mail client for example, are shipped and updated with the OS (the "ostree" in your example above), but can be "removed" (hidden actually). The mail client is core, can't be removed physically, but can be removed from view. So the OS technology is always going to allow us to remove/hide. How to add back is probably relevant. I think the short answer to this thread is that we need use something other than mandatory_for_desktop. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal for reducing the number of unremovable apps in GNOME Software
On Tue, 2017-11-07 at 09:11 -0600, PWR PWR wrote: > Great discussion! I would encourage making things as customization > and personalized as possible, as a principle of open source software. Close enough: http://www.islinuxaboutchoice.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
