On Mon, Dec 4, 2017 at 2:05 PM, Adrien Destugues
<pulkomandy@xxxxxxxxxxxxx> wrote:
We can continue working on the beta release. I would think the 1 month
schedule is too short anyway, so we should start the process now and aim
for a release in january.
Let's have a look at the remaining tickets:
#11654 Create update repositories for the beta release
This one should be done before the release. The idea is that the
beta continues to get updates for packages (built on a stable beta
branch), and separately, the nightly gets updates with possible ABI
breaks, etc (eventually leading to an R2).
#10336 TRIM / fstrim can destroy data on SSD's when executed
Remove fstrim from image, or the trim command support from the ATA
driver (I'd prefer the latter, as fstrim works well on ram drives).
#13741 Ensure our wpa_supplicant is patched for KRACK
We should at least investigate wether backporting the fix is easily
possible
#9990 Installation of source packages fails
May not be a problem if it is still possible to put source packages
on the image at build time and the package_daemon manages to
activate them. Or we could even ship them un-activated and tell
people to extract them using the "package" command if needed.
We already failed point 3, but let's try to get the first two right, at
least. I would prefer the release schedule to be a bit longer (6 weeks
to 2 months) and flexible (goals-based rather than time based) so we can
do things at our own pace, and delay as needed if there are any
surprises.
We could also start working on the release notes, press release, etc.
These don't need to wait until the last minute.
Hello,
Let's have a look at the remaining tickets: > [...]
I propose to add https://dev.haiku-os.org/ticket/10071
Due to that one, attribute display and editing for many file types is
currently not available from Tracker, for a large number file types (even
including People files!). Given how much the extensive attribute usage is a
unique feature to BeOS/Haiku, one that is often cited, it would be
unfortunate to make a release where it's broken.
If a clean solution is not feasible in time for the release, at least a
workaround should be added to it (see ticket discussion).