[haiku] Re: please keep non-GSoC comments out of these threads; was [GSsC] usermode Haiku or file system development
- From: "Jorge G. Mare" <koki@xxxxxxxxxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Thu, 08 Apr 2010 10:03:20 -0700
Hi Stippi,
Stephan Assmus wrote:
On 2010-04-08 at 14:21:31 [+0200], Jorge G. Mare <koki@xxxxxxxxxxxxx> wrote:
scott mc wrote:
Haiku R1 is already mostly defined. Most of the GSoC projects will
not be in R1, so don't get overly concerned with it.
And that's the point; too many projects (GSoC or not) going on that do
not contribute to R1...
Which ones?
Off the top of my head: OSS, the ports to various processor platforms,
and the various GSoC-related projects whose code is gathering dust
(BFS-FUSE, beacon, zeroconf, etc.). See below for some more
GSoC-specific projects.
These email threads are from potential GSoC students to present their
project ideas and for getting feedback, please try to keep them on
topic.
...so +1 on being off topic, but unfortunately the guy does have a
point: Haiku development does lack focus. I know this may shuffle some
feathers, but I just had to get it off my chest...
GSoC students should be encouraged to propose what they feel most motivated
to work on. Our list of ideas is pretty focused otherwise, AFA I am aware.
Preferring projects that bring us closer to R1 may or may not be a good idea.
It's been discussed in past GSoCs. For example GSoC projects being successful
to the point of being integrated with the code and part of the image are not
the majority. It means focusing GSoC projects on R1 bullet points may
actually delay R1 if they are not successful.
Looking at how GSoC has played out in the past, I highly doubt that
encouraging students to work on what they feel most motivated works well
for Haiku. On the one hand, the resulting code is not likely to help the
project move forward along its development roadmap (in many cases, it
just ends up gathering dust); on the other, and perhaps more
importantly, you have to consider the fact that mentoring sucks up
developer attention and time, so you are in fact also diverting
resources from the R1 goal.
A much better strategy would be to try to match the priority of the GSoC
projects to that of the various milestones in the development roadmap.
In other words, list up what Haiku needs first as top priority ideas,
and then "the nice to have but not so important for now" projects after
that. You can then tell students they are more likely to be accepted if
they choose a high priority project, so that they have an incentive to
choose a project that will actually help Haiku move along its
development roadmap towards a release.
Not that one should totally rule out original proposals from students;
there is always a chance that a student could come up with a really good
idea. But at least the project should make it clear what it's priorities
are, so that the students also know what areas are more important to
work on.
This approach may well result in getting less GSoC spots, but in the
bigger picture being focused is more likely to make better use of mentor
time in the context of advancing development.
In any case, I find these "potentially feather shuffling" statements somewhat
discouraging. Bottomline is you (and others) are expressing your
disappointment. While you certainly have every right to do so, somehow I
wonder if this is deserved seeing how much the people who contribute code to
the project try to do their best.
Maybe the problem is that you take it personally. :) You see, I was
simply agreeing with an individual who expressed his view and was more
or less brushed away (as in, diplomatically told to shut up). I just
thought the guy made a good point in the context of the GSoC proposal
from the original thread; there is really nothing more to it.
As I have said many times, both on and off the record, and I repeat it
here: the Haiku developers do a great job and deserve all the praise.
However, that does not mean that everything is always rosy and peachy
and that there is no room for improvement, nor that people should shut
up and not voice their opinions or concerns about the project.
I don't agree it's true either. I don't see
those projects which are not focused on R1. I'd love to hear examples. The
only recent thing in this direction I noticed was the GoogleFS that François
worked on, but I can see why he would bring something he worked on back into
working order.
From the GSoC 2010 page on the website:
Updating AbiWord
Creating Services Kit
ExpressCard with hotplugging support
Port to x86-64 Architecture
NFSv4 client with xattr support and caching
Implement IPv6 support (big task)
Bluetooth Stack Improvements
Multi-monitor support for the app_server
Hardware 3D acceleration
Create Language Bindings to Haiku's C++ API.
There are more if you look at past GSoC idea pages (such as updating VLC
and Netsurf).
I admit (as I always do) that I could be missing something; but all
these projects seem like nice to have but not really critical to getting
an R1 release out the door (some even seem better suited as third party
projects rather than something that the project development team needs
to be directly involved with).
The fact that ideas these are being listed alone shows a lack of focus
IMO, as it does not seem to reflect the true priorities of the project
as it relates to the development roadmap. That's what I meant with the
"lack of focus" statement.
Then again, this is just my opinion, and you don't have to agree with it. :)
Cheers,
--
Jorge/aka Koki
Website: http://haikuzone.net
RSS: http://haikuzone.net/rss.xml
Other related posts:
