On May 18 06:47 PM, A. Wilcox wrote: > On 05/18/18 10:07, Max Rees wrote: > > 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.
That is correct - "all" is more broad than I had meant. > 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. This seems a more reasonable goal for the target 1.0 user base. > Nothing like SuSE's 1-click is planned until after 3.0. I had not intended to give the impression that this should be a goal, anytime soon or at all. Just something to consider :) > 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. This is indeed a complicated issue of priority here. I had considered that this is what you intended with Parcel, but I think it is a reasonable assumption that a lot of people just burn the ISO and boot it up. From there hopefully they can be guided to the desktop package manager to look at available software... but the more I think about it, maybe Parcel should be prioritized over the desktop software. Alpine of course gets along just fine with pkgdb and no desktop package manager (does ACF have package manager functionality? I forget), but Alpine has a different focus than us. Again it all comes back to what you are expecting from the 1.0 user base. If they can run "apk add / del / update / upgrade" from the CLI then maybe Parcel is more important. The more I think about it the more I flip flop. On a related note, I am wondering if there is anything preventing Adélie from reusing pkgdb (at least in the interim). It doesn't have all the features that the requirements laid out, vaguely recalling from memory because foxkit.us died :( but maybe it can be extended. De-duplication of effort can be a good thing, although I am aware that cooperation has been a little strained lately. > > 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.) I did not intend to mean that gcompat should / need be worked on to support widevine, just noting that I already need a chroot for such purposes and thus it's not a big deal at least for me when I need to turn to it for things Adélie doesn't support. > >> 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. That doesn't seem like a terrible idea. Maybe also hold the release until the documentation is complete as well (which I think is your goal anyway based on the roadmap, though it isn't clear). > >> 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. LibreOffice says "[clucene] is used to index our downloadable help packages, and allow them to be searched efficiently at run-time." so perhaps it isn't a huge concern for now... The problem is compounded however because clucene upstream on SF appears to be dead, evidenced by no commits since 2013 and no activity on a 2016 PR to add GCC 6 support to their cmake files, resulting in a patch that must be carried by all distros that ship clucene. The clucene patches and such in LibreOffice's tree also seem a little stale. I will do some more research this weekend on this. Max _______________________________________________ Adélie Development mailing list -- adelie-devel@lists.adelielinux.org To unsubscribe send an email to adelie-devel-le...@lists.adelielinux.org
