[haiku-development] Re: Beta1 and R1 release plan
- From: Adrien Destugues <pulkomandy@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 6 Nov 2014 12:14:03 +0100
On Thu, Nov 06, 2014 at 11:37:44PM +1300, Richie Nyhus wrote:
> > The goal should be to make Haiku OS interesting things for new users
> > and developers.
>
> New devs:
> I believe that all of the useless demos should be dropped in favour of
> Paladin (and other useful dev tools) being bundled in Haiku Alpha/Beta
> releases. Although it is true that Paladin is not perfect, it is far more
> useful than the likes of BeSnow.
BeSnow is already gone from the image. Paladin still needs a lot of work
to make it better usable, however a package is already available for it
and could easily be preinstalled on the install media.
>
> New users:
> The wider community should not simply be an afterthought that is only cared
> about after it is realised that non-mailing list subscribers wrongly assume
> that the project is dead. I do not believe that this lesson has been
> properly learnt.
It is not up to the developers to handle this. You applied to be the
marketing guy in another mail, I think, but there is no official
endorsement process for this. Just take actions you think are needed. It
would indeed be very great to have someone taking care of this again.
>
> > Therefore, we should rethink some things, like the compiler question
> > (gcc2, gcc4 or LLVM / Clang).
>
> I agree with what Niels said about LLVM/Clang being a good goal for R2, as
> it would give direction. I don't think that it would bog down/slow down
> Haiku development or releases, as there would still need to be point
> releases (R1.1, R1.2, R1.3 etc.) and Alphas/Betas for R2 (R2A1, R2A2, R2B1
> etc.).
>
> Moving to 64bit might be an easier endeavour for R2 than moving to
> LLVM/Clang, as it is already 2/3 complete. But for the mean time (for R1),
> 64bit and ARM should remain projects for those developers who are intrested
> in them.
There isn't that much work there at this point. Moving to 64bit is
essentially flipping a switch, we are already providing nightly images
and the system is as usable as the 32bit version.
The switch to clang needs slightly more work. Most things compile fine
with clang already, and the remaining tasks are cleaning our code to be
warning-free with clang and not use gcc extensions anymore. This does
not bring anything new to users, however, and is work that can be done
in the background and without too much planning. So I don't see how that
would give direction for R2. But don't worry, there are pleinty other
ideas on what to do there.
>
> I think most non-developers would happy if R2 took 4-6 years to release, so
> long as there were regular Point releases and Alphas/Betas releases between
> R1 and R2. The fact that Alpha 5 has been delayed for so long and how an
> Alpha 4.2 point release was not attempted in mid 2013 has been the more
> damaging factors.
There is little difference between no release and a release with no
changes included. I believe there are other ways to give signs of life
from the project, and we failed at this.
I still think that doing point releases of an alpha is nonsense. Alphas
should be drops of the current state of development for testing purposes
only, and come with no support of any kind. We are now working towards
R1, a stable release which will get support and point releases. Now it
is time to go public and these releases can be used for marketing
purposes.
> > But the most important is that the world out there also has what is
> > great and this system. This means we would have to Haiku OS otherwise
> > show the public and explain more and more work on the system,
> > applications should not come from us, special from the outside world.
> > Development for Haiku should mean to work on the system.
>
> Keeping contributors and app devs:
> I think there should be a Haiku Contributor Guide to match the User Guide.
> Currently contributor and developer documention is scattered all over the
> place, which is a hurdle to both acquiring and keeping new contributors and
> developers.
There is a more general problem of our website being badly organized,
making it hard to find any kind of document, even when you know what you
are looking for.
>
> More open source Haiku apps, games and libs should be available in
> HaikuDepot. Only about 1/3 of 3rd party Haiku apps with working build
> recipes are in HaikuDepot.
This is what is holding the release. The process of building and
uploading packages will be automated, so everything with a working
recipe gets in the depot.
However, managing depots is also a job for 3rd-party developers. There
is already one 3rd party repository at http://haiku.uwolke.ru. There
should be more of those, and it was part of the PM design that these
would be easy to setup and use, so the Haiku devs don't have to spend
time on packaging everything instead of working on the core system.
>
> Also if someone does not feel confident enough to start contributing code
> for Haiku, then they should be encouraged to contribute to apps on
> HaikuArchives.
Cleaning up the apps on HaikuArchives is sometimes a challenge requiring
better knowledge of Haiku internals than writing apps from scratch. I
don't think this is a matter of feeling confident, but a preference on
development workflow. Some people prefer starting from scratch, others
are more confortable starting from existing code.
>
> Keeping users and supporters:
> Haiku also does not have a marketing position and it shows. Apart from
> visiting the website, to keep informed of Haiku related news you need know
> the existence of obscure websites such as IsComputerOn; use RSS feeds or
> find the super secret links to the Haiku Twitter account (but which is not
> branded Haiku) and to a Facebook user group (that receives on average one
> post a year).
>
> There are other social media accounts around the net, but you have to
> actively search them out, yet they are not marked as being verified as
> official accounts.
Help welcome on managing those.
>
> > Also, I would welcome a developer Refernenz Board, as the minowboard,
> > so that's a base there.
>
> The MinnowBoard looks quite interesting. It would great if it would be put
> into the hands of the active devs, which also might be a good mini
> fundraising campaign. It could then be sold with a SD card copy of Haiku as
> a devolperboard during the beta phase.
I think Haiku is better suited to desktop or laptop computers than
development boards. We don't have, nor plan to have, drivers for SDIO,
GPIO, I2C, SPI. Currently we don't even have working USB3 drivers. This
makes half the board unusable. What remains is essentially a slow
computer with no case. What's the point of this? What would you expect
to come out of it?
We don't need a development board for working on Haiku, this is not an
operating system for embedded devices. If we decide to have a reference
platform, it should be a desktop or laptop computer. Intel NUCs might be
good candidates for this.
I'm not sure there is a need to flood the developers with more hardware.
I have several PCs at home and they can all run Haiku, and I would have
no use for such a board. There are better way to spend money to help the
Haiku project.
--
Adrien.
Other related posts:
