On 01/08/19 01:37, Horst Burkhardt wrote:
On Mon, 7 Jan 2019 20:13:20 -0600
"A. Wilcox" <awilfox(a)adelielinux.org> wrote:
> User handbook (10-14 days)
>
> Write.
On this one, don't be afraid to steal from any CC or similarly licenced
source if it suits our needs - no need to reinvent the wheel if someone
else has already written something that just needs a polish.
It's mostly going to be links to relevant KDE handbooks. I'd like to
also include a similarity matrix, where people can look up "I use
Illustrator on Windows, what is the equivalent in Adélie" or such.
Basically, a "best of alternativeto.net".
> alpha2 list (5-10 days)
>
> Package.
I have to ask why it's taken this long to get to the alpha2 list - I
mean, it was quite some time ago that alpha2 dropped. Can we point our
increasing corps of packaging personnel at the list, perchance?
This list is specifically "packages we shipped in alpha2 that were
dropped when we switched to APKBUILD instead of ebuild". It's been a
crazy ride since then, as you're well aware.
> alpha7 list (3-7 days)
>
> Package.
See my comments re alpha2 - many hands make the lights work.
aerdan@ already did four or five of the alpha7 list; multiplexd did three.
The lists are public and anyone is free to take them, except x11vnc
which needs my special attention. I'd encourage you to maybe take a
whack at the ones you had requested, even :)
> POSIX: VSC (10-14 days)
>
> Set up tests on all architectures (arm64, ppc32, ppc64, i586, x86_64).
> Run tests on all architectures. Verify test results. Attempt to make
> fixes, if possible.
How do we deal with low-level things like the linux kernel? Will Open
Group still call us a Unix if we smile and blink our eyes prettily?
No. VSC is shell utilities. VSX is the C/Linux/musl stuff.
I don't believe VSC will use too much in the way of kernel interfaces
beyond what coreutils does. In this instance, I believe it should much
easier to pass - or at least much easier to know we can't. Much fewer
grey areas.
> First of all, I think that perhaps we should have a BETA3 release
with
> some of the more pressing issues fixed. Scratch Fake Horizon and
> we're still looking at 102 days or mid-April.
I'm in favour of having a BETA3 - especially if it buys us time to
polish things up so that we get 1.0-RELEASE done right. We're already
doing better than most 1.0 releases of other operating systems from an
engineering and functionality standpoint, so all that remains is to get
lots of people using Adelie and proselytising to their friends.
If I can be blunt, no, I don't think we are better than 1.0 of most
Linuxes from a functionality standpoint. You can't even stick a USB in
and click "open files"; it pops an error.
You can't choose a Gtk3 DE, and honestly, XFCE is so bad you can't
choose a Gtk2 one either. A significant portion of Linux users are Gtk
lovers and we have no good options for them. We really need Cinnamon
and possibly MATE.
The USB one is listed in the roadmap. The other DEs aren't going to
happen until later, I'm afraid.
> Suggested BETA3 goals:
>
> KDE theme (2 days)
>
> Wallpapers (1 day)
>
> User handbook (10-14 days)
>
> image.git (2 days)
>
> alpha2 list (5-10 days)
>
> alpha7 list (3-7 days)
>
> Rust (bump) (1 day)
>
> Firefox 60 (ppc64) (1+ week)
>
> POSIX: VSC (10-14 days)
>
> More TrueType fonts (2-3 days)
>
> Fix GRUB 2 package (3-5 days)
>
> Fix KDE card decks (1 day)
>
> Sort out kernel options between architectures (5-10 days)
>
> At least one more KDE bump (1-2 days)
>
> Package rdesktop (2 days)
>
> Fix AltiVec detection code in GCC (2-5 days)
>
> Add _NPROCESSORS_ONLN to getconf(1) (1-2 days)
As wallpapers is low hanging fruit, I say we definitely have that ready
for BETA3, along with the KDE theme; I'd prioritise the alpha2 and
alpha7 lists after that. Kernel rationalisation, as long as it doesn't
break anything, would also be nice.
In case it isn't obvious, I'm in favour of a BETA3. I'd suggest,
however, that we start doing some of the marketing work in the lead-up
to BETA3 dropping; I think we've started laying the foundations for a
high quality distribution and it's time to get more people involved.
Marketing BETA3, if all of those things are indeed fixed, wouldn't be
terrible. The 1.0 roadmap is almost entirely features, not bugfixes, so
it doesn't make me too nervous to do that.
However, I don't think we should really start hard marketing until
ConsoleKit 2 is fixed. Perhaps that should be in BETA3 instead of the
getconf stuff. That would make me much more confident in marketing BETA3.
> This has a best case of 58 days (a fox gestation cycle, or 6
March
> 2019), and a worst case of 95 days (12 April 2019). Pad it out a
> little and BETA3 would have a Wish of 9 March, and a Due of 14 April.
Unless we're planning to ship with a skulk of kits for every new user,
I'm not sure how a fox gestation cycle helps or hinders us.
Are we planning to ship with a skulk of kits for every new user?
Can we? :D
...
On second thought: factory closed.
> My preference for this thread would be one discussion about
whether a
> BETA3 should be added or not, and another thread about item
> discussion.
>
> Is there something missing from this list that needs to be in 1.0?
> Maybe something I forgot, or something you feel is critical? (Perhaps
> armhf/armv6 should be added; that could be running in the background
> while real work is done on all the other items, since it shouldn't
> need much in the way of hand-holding.)
Uh, I'd rather we support armv7 than arm6hf; other than the first
generation Raspberry Pi (which I'm willing to not support, let them run
RISC OS, it's nicer on that hardware), pretty much everything worth
having is armv7. That's definitely a discussion to have with people
more knowledgeable about ARM, but there's my opinion.
It's amazing to me that after 10 minutes of searching using multiple
search engines, I can't find a single comprehensive list of Linux ARM
SBCs/EVBs that shows the CPU architecture of each one.
That's frustrating. Perhaps we should fix that.
I was under the impression that ARMv6 was actually in use on more than
just the first Pi. For example, I *know* the Pi Zero and the Marvell
88F6781 SoC (used in Wyse terminals) are v6.
Oh. Well, there we go:
https://archlinuxarm.org/platforms/
Perhaps we should have an ARMv7 build and a generic armel (down to v5te,
which is musl's baseline) instead of armel and armhf. You convinced me.
I also may have someone who's eager to help us get going on
armv7, I've
been feeling them out for a little bit. But that's something we'll
probably end up hashing out over IRC.
Sounds great to me.
Best,
- Horst Burkhardt / mc
Best to you and yours,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org