Quote:

So to see if I understand what you are saying -- we still have a set of requirements for 0.1 -- BUT -- we don't necessarily need to feel the need to complete one milestone before we can embark on aspects of another? In that case, let's not call them "0.1", "0.2", "0.3". Let's call them design goals, "3.1 compatibility", "net subsystem", "sound subsystem" and so on. And just list the requirements for each and what's left for each. Like:

"3.1 compatability"
A. Come up with a list of things we intend to leave out, and explainations as to why.
B. Implement everything else.
C. Test it with current open source projects written for AmigaOS 3.1, and check to see the behavior is the same, as well as our own testsuites.

Profit!

We'd have one of these little lists for each subsection.

And of course, "1.0 milestone: All other milestones (net, sound, 3.1 compatibility, 3.5&3.9 additions) must be complete".

This way developers can (as they already do) jump around as they please, get things done, do the stuff they want to do, but still be working towards a clear goal, and there's no implication that one must be done before another (no reason that sound must be before or after net, for example).

I guess there's one thing there seems to be agreement on -- the milestone 1.0 does NOT require additions above and beyond 3.9 AmigaOS, except as where required to make it work on new hardware and implement the new .hidd system.

I must say, as for "getting things done" I'm generally impressed by the KDE team. They've got a system, and it works fairly well.

Check this out:

http://developer.kde.org/development-versions/kde-3.3-features.html

Very orderly. But it's still seperate developers working on their own thing.

EDIT:

Please note I'm not talking about a schedule here (!! -- -- !!) just a todo list.

Road? what road?

aren't we using machetes to cut thru the jungle thick C=AL cures first?

;)

AROS Development, it's all relative...

Quote:

Since the developers habits are quite chaotic, it doesn't seem like a feasable thing to model in the roadmap.

I still think the roadmap makes sense, although perhaps you shouldn't view it linearly but more like a set of requirements for 1.0.

by Tjodden on 2004/4/6 8:13:17


Quote:

Perhaps if the milestones are in conflict with the devs current coding habits, maybe the milestones should be adjusted to reflect the dev's advancements?

Dammy

Quote:

We haven't passed the 0.1 milestone yet, because there are still quite a bit of outstanding OS 3.1 compatability issues. One problem here is that we don't yet really know what's left or decided what things of OS 3.1 we will omit. Also, the milestone includes comprehensive developer documentation, which is probably the biggest task left for that milestone.

Ofcourse we have implemented quite a bit off several other milestones. AROS developers don't work linearly, but rather what they feel like doing, so...

Why you little... URG! Damn, topic thefts

Um, What do sprouts have to do with the AROS RoadMap?

Sweet. That's exactly how the Display implementations work.

DisplayWindow::getDrawSurface() returns a Surface* wrapping an offscreen BitMap

DisplayScreen::getDrawSurface() returns a Surface* wrapping the screen's BitMap

DisplayScreenBuffered::getDrawSurface() returns a Surface* wrapping the non-visible screenbuffer's BitMap (OS3.x friendly screenbuffering style).

So, the HIDD stuff operates directly on BitMaps and provides genuine RGB rendering of primitives. This sounds very promising

Quote:

In that case everythin will work just fine, you'll simply need to get hold of the bitmap object for the screen, in case of DisplayScreen, or create a new offscreenbitmap in the case of DisplayWindow and DisplayScreenBuffered.