On 05/18/18 10:07, Max Rees wrote: > On May 17 07:47 PM, A. Wilcox wrote: >> Hi all, >> >> I'd like to have a discussion on whether or not it would be worth it to >> invest actual time and resources into the following projects before we >> release 1.0. Perhaps we could even delay 1.0's release slightly, if >> they are deemed critical enough. > > The relative importance of these projects depend on what the goals are > for the distribution - specifically what level of technical literacy we > expect our users to have. At early adoption levels it will be relatively > high of course, but at the 1.0 release I think Adélie should be > accessible to all.
This is a noble goal but I don't know if it is feasible. Quoting the roadmap directly: Adélie Linux 2.0 is meant to be the first release that is truly ready for the general public. Horizon is planned to be rock solid and fully tested on all architectures and in many corner cases. Other features TBD. The phrase "accessible to all" conjures up in my mind people who may not have even ever used a computer before, or at least anything beyond a smartphone. While I do want to support these kinds of users, 1.0 is not the time or place for them. What you probably meant, though, are the people who do know *basics* (how to use a mouse, what a 'software package' is, etc), and want to try a Linux system out for whatever reason. >> PackageKit Plugin for APK >> ========================= >> >> This would allow us to have graphical UIs for installing, removing, and >> updating packages with APK for "free". > > As such, this is probably one of the more important projects that needs > to get going. > >> One thing that bothers me is that APK doesn't yet have tagging or >> category support, so every package would be in a single, large, >> unwieldy list. It'd be very nice if we could add tagging first. >> >> Of course, writing the plugin and then adding tagging to APK later is >> another option. >> >> Note that both KDE (Muon) and Gnome (gnome-packagekit) have GUI tools >> built on top of PackageKit, so we would not need to write any GUIs. > > Tagging can probably be added after-the-fact if it is determined that > adding this functionality to APK will take too long. As long as the > search isn't too bad things should be fine for the time being. At this point, with two weeks to go before beta1 and three months to go before 1.0, any time mucking with APK's source is too much time. Search should be quite fine. I'm more concerned about discovery, which is why tagging would be useful. >> Parcel >> ====== >> >> This is the Web and CLI UI for determining package availability, >> version, and architectures. Similar to Alpine's pkgdb or Gentoo's >> Package Home for the Web UI, and similar to eix on the CLI. >> >> I still think this is a very worthy endeavour, but time is a precious >> commodity and I don't know if we have the time to build it before 1.0 >> unless 1.0 is delayed. > > This can probably be pushed back for now. I kind of see it as a > trade-off with the PackageKit plugin for APK since they have similar > features, but the plugin will have some functionality that Parcel > necessarily cannot have - such as being able to install packages to the > user's system, unless something like openSUSE's "one click install" > feature[1] is implemented. That would essentially be a bridge between > Parcel and the desktop package manager, so the plugin should still be > prioritized over Parcel. Nothing like SuSE's 1-click is planned until after 3.0. The point of Parcel was to allow people to see what we package *before* they install Adélie (do they have thunderbird? what about pidgin? etc), and also for maintainers (what version are they shipping? on what arches?). I do agree that this is probably less of a concern for users than it seems, so it should probably be pushed back. >> Register >> ======== >> >> This is the popcon-like system that will let us explore and inspect >> packages that are popular (and not popular) with the user community at >> large. Cadey on IRC has been writing a prototype. >> >> This, too, seems like a very important feature for 1.0. > > Can't say I disagree. I'm sure it would be very nice to know what to > prioritize, which is also the subject of this thread :) > >> Steam with gcompat >> ================== >> >> I still have been unable to test the Steam binary on gcompat because it >> requires 32-bit x86 and I don't have a 32-bit x86 installation with >> gcompat anywhere. (The only 32-bit x86 install I have of Adélie, >> outside of the builders, is a 500 MHz Pentium III laptop. Hardly an >> amazing gaming system, that.) >> >> I don't know if that is important enough to work on for 1.0, since you >> can just use an Ubuntu chroot to play Steam games (this also prevents >> the icky binary blobs from touching your rootfs). However, I will defer >> to the community for that decision. > > chroot is probably fine for now to keep the distro's focus narrow. I > already use a chroot for other software such as widevine (eww) and > LibreOffice, for example. This isn't really a distro focus. gcompat is a project "of" Adélie, but it is not Adélie. (It also sees use on other distros; I know at least Alpine and Void ship it in their repos.) LibreOffice *should* run on musl, but see below... >> Horizon >> ======= >> >> There has been renewed interest in Horizon since the linux-wiiu team has >> joined us. We could likely spin partitioning out to KDE Partition >> Manager (https://www.kde.org/applications/system/kdepartitionmanager). >> >> Since the linux-wiiu would like Horizon to use PackageKit (so that it >> can handle any future pivots, if desired), it'd be a great idea to have >> an APK PackageKit backend before we go back to Horizon. > > This is a pretty important project, if not one of the most important > projects in my opinion. The manual installation process works, but it > isn't without bugs at times and it's certainly not intuitive to the > casual user - reminiscent of the Arch installation process, but much > more streamlined at least. A simple yet configurable installation > process is key to onboarding new users and as such I think this project > should be given priority, as well as maintenance of the manual > installation documentation. Statements like these make me think that the best way forward is to get to beta3 (which was to be our last beta cycle before 1.0), and just *stop* and not release 1.0 until Horizon is ready, whether that is on time or six months late. You aren't the first one to make Horizon sound that important, and I doubt you'll be the last. > >> Others? >> ======= >> >> If anyone has any other 1.0 goals that aren't covered in the current >> roadmap (https://wiki.adelielinux.org/wiki/Project:Roadmap), let's >> discuss them here. > > It would be nice to have LibreOffice by 1.0 :) Of course, I can use my > chroot as long as need be but it's certainly very useful software for > both "Education" and "Office". You were the one who opened the clucene PR, as I recall. I still have not managed to track down why the tests fail so spectacularly; that is the main reason I haven't proceeded further with LibreOffice. The way the tests failed made me very nervous about the stability of projects that would use it as a library. It's even worse on PowerPC, for what it's worth. > > [1]: https://en.opensuse.org/openSUSE:One_Click_Install Best to you and yours, --arw -- A. Wilcox (awilfox) Project Lead, Adélie Linux http://adelielinux.org
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Adélie Development mailing list -- adelie-devel@lists.adelielinux.org To unsubscribe send an email to adelie-devel-le...@lists.adelielinux.org
