[haiku-development] Re: Beta1 and R1 release plan
- From: Adrien Destugues <pulkomandy@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 7 Nov 2014 15:53:09 +0100
On Sat, Nov 08, 2014 at 01:47:20AM +1300, Richie Nyhus wrote:
> Regardless, BeSnow was only an example. I am hoping that the bundled apps
> in the next release will be based on what you decide as release manager,
> rather than on conventions.
The rules are simple: fill the CD with as much useful software as
possible, with our 3 main target audiences in mind:
* Developers wanting to start working in Haiku and porting their
software or writing new apps,
* Users trying Haiku for the first time,
* Haiku devs or community members doing demos of Haiku at various shows
such as RMLL, Ohio LinuxFest, etc.
In the past releases our main problem here is that fitting everything in
a 650MB CD image was not possible. The package management solves this in
two ways:
* Packages are compressed, so we can fit more in the same space,
* Installer should list the packages again and allow to remove some at
install time.
I don't think the space which could be recovered by removing the little
demo apps would be of much use. Including more apps however is
definitely possible, if we can agree on a list.
>
> > 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.
>
> My overall critique was not aimed solely on developers, but project wide at
> an organisational level. It was also ment to be positive criticism rather
> than anything snide on my behalf.
This is the development list, which is used mainly by developers :)
What I mean here is:
* Haiku is a "meritocracy". To become an active project member (with
vote rights and everything), you first need to start contributing in one
way or another (code patches, QA testing, communication/marketing/PR,
whatever you think is useful). And then at some point someone says "hey,
why aren't you a project member yet?".
Since there aren't much people interested in the PR side of things
(especially on the developer list), I think you can start working on it.
Even without access to the social network websites, there are a lot of
tasks that can be done and have been waiting for years for someone to
take care of them. I can think of some:
* Updating the design for our flyers and posters, which are still using
pre-alpha1 screenshots featuring the Opera 3 browser showing the bebits
homepage.
* Designing new T-Shirt and other goodies designs (mugs, mouse mats,
etc). Possibly setting up a new store as I think cafepress isn't working
really well. I made some test T-Shirt prints with Zazzle, which worked
well and has lower shipping costs than cafepress at least for here in
France. There may be other alternatives.
* Adding entries to alternative.to for Haiku applications such as
Wonderbrush.
* Keeping Wikipedia entries for Haiku and related things up to date.
I don't know exactly which parts of this you are willing to handle.
>
> On the community management side I am interested in what users/supporters
> feel are the stumbling blocks or hurdles that stop their engagement.
the forums or main haiku mailing lists (and a dedicated topic) are a
better place to discuss this.
>
> However the desires of core devolpers on communty issues are also an
> important factor.
A separate topic on this list may be a good place to discuss this :)
>
> For example, there is an open source community tool called Discourse [2]
> which is meant to replace the traditional forums and mailing lists, but
> also to meant to appeal to enterprise and non-profits. It is built from the
> ground up to be a hybrid mailing list/fourm that allows people to send and
> receive messages by both email and the web UI. This might be a way of
> closing the gap between the forum and the mailing lists.
>
> Charging ahead would be pointless as devolper feedback on matters like this
> is critical. I can not answer the question myself of whether Haiku
> devolpers would be intrested in using Discourse (if it was used for end
> user and non-development usage).
I can give you some feedback: I think most of the devs are fine with a
separate mailing list for haiku-development, which we try to keep very
focused and relatively low-traffic. There has to be a place where
discussion can take place between the developers for development
decisions to be made.
Some of the developers also watch the main haiku mailing list, and a few
also have an occasional look at the forum. I think these communication
channels all have different purposes and it's fine to keep them
separate, so everyone can subscribe only to the parts he is interested
in.
> > 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.
>
> My assertion of it being 2/3 finished was an attempt to (badly) factor in
> the work needed to get the same amount of software in HaikuDepot as 32bit.
> Plus I never saw a final decision on how much backwards compatibility is
> appropriate between R1 and R2.
A blocking task for the release is automating the building of packages
for releases. This will make roughly the same packages available on both
architectures. Some software may still need 64-bit safety fixes, but I
think there is not much of those.
> > But don't worry, there are pleinty other ideas on what to do there.
> Are the other Idea in new message thread that is yet to come?
A short and incomplete list is available on the trac wiki in the
"FutureHaiku" pages:
* API changes:
https://dev.haiku-os.org/wiki/FutureHaiku/APIChangesOnCompatibilityDrop
* New features that were rejected for R1:
https://dev.haiku-os.org/wiki/FutureHaiku/Features
* File system replacement:
https://dev.haiku-os.org/wiki/FutureHaiku/BFSIssues,
https://dev.haiku-os.org/wiki/FutureHaiku/FileSystem
I think there are some more ideas that were not written/voiced yet. My
personal focus is on getting R1 released, and I will let others start
the work on what R2 should be like.
> > 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.
>
> I would be intrested in making a start in the guides section for starters,
> but my editing permissions on drupal are quite random (some articles or
> nodes I can edit, others I can not edit even if I created them in the first
> place).
Yes, this shows how deep the problem of a badly organized website can
go. Even the permissions management is a mess. Try to contact one of the
website admins to get additional permissions there.
>
> > 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.
>
> How do you add a builder for haikungfu.net ? Though Buildbot? I might be
> able to help by running a builder 24/7 thoughout December.
I think it's not ready yet. Instructions will be published as we get
things running.
>
> > 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.
>
> Of course there is a big difference between hacking on JamMin and hacking
> on abiword (good going btw), but even on the more challenging apps users
> can do QA and submit bugs and enhancements.
Right, encouraging users to do QA is fine, but maybe it's easier for
them to do so on apps that are already available on HaikuDepot.
> > What's the point of this? What would you expect
> > to come out of it?
>
> Sorry I should of been more clear. This would be more about tinkerers
> playing around with Haiku on a cheap x86 SOC device, aimed at the same kind
> of people who got a Raspberry Pi in 2012. The same people who still ask on
> the forums about whether Haiku been ported to ARM6 yet.
>
> The comment about putting it in the hands of a few of the devs was more
> about making sure it was " guaranteed to work", while the comment about a
> mini fundraiser meant something like a "freedomsponsors" unofficial bounty
> for it [5].
There are two different issues there. We get a lot of requests for Haiku
on the Pi because a lot of people expected to buy a $30 device and get a
full-scale computer. But they discovered that there is no magic and the
Pi is indeed a very slow device, and the design choices made to keep it
cheap means it does not perform as expected. Now the same people keep
dreaming that there is an operating system that could be fast on the
same hardware and have the same features as Linux. I'm afraid it's not
going to work that way.
There are frequent requests for a well supported "official" hardware platform
on the forums, but I think this is better solved by maintaining a list
of hardware that's known to work. Maybe we could also create a
partnership with some hardware vendor to have machines coming factory
setup with Haiku (how nice would that be?). Buying a batch of todays
hype development board and lending those to the devs isn't the best way
to handle this, because by the time someone actually gets interested in
it and fixes the issues, there will already be a newer board available.
>
> Talking of official fundraisers, what do you think of using something like
> Causes [6] to do some "targeted" fundraising, such as raising money to
> extend your paid contract? Being less abstract and more definitive, people
> might be more likely to donate.
My contract continues without a need for this, and Haiku, inc. is even
putting some money aside for future uses. I must say this funcing method
worked much better than I expected.
There was already a lengthy discussion about "bounties" based funding,
such as what Haikuware did in the past. The general feeling is that they
are not suitable for long-term work such as what I'm doing with my
contract. It is nice that I can work for Web+ for one year, then focus
on coordinating Beta1/R1, or work on something else, as I see fit (with
control from Haiku, Inc.). Bounties would force me to work on a single
task at a time until the bounty is complete, which is not the way I want
to work. They are also not a reliable way to ensure I can continue
working full-time on Haiku (there is a high risk of failing a bounty,
and not getting any money - not a risk I'm willing to take). There is a
similar problem with upfront crowdfunding such as what kickstarter does.
It's difficult to raise a lot of money upfront for a big project (like
paying one dev for a whole year of work). The current scheme focusing on
smaller but recurring donations seems to be the most appropriate one for
this.
That being said, I think it should be more clear that funding Haiku does
not need to go only through this way. If there are people willing to
setup bounties, the bountysource website is an easy way to do so. If
someone wants to run a kickstarter and then use the funds to help Haiku
in anyway (hiring a dev, buying some hardware, or anything else), that's
fine. If people donate to the HSA to help making BeGeistert happen,
that's also a great thing. But so far it seems that going through Haiku,
Inc. is what donors feel is the best way to spend their money. So I
think on this side we are doing things right.
--
Adrien.
Other related posts:
