Development

[ColErr]

I just wanted to bring up that I don't think the current progress is going well. It seems like people are putting up code that they had, and not worrying if it conforms to what we are trying to build, nor if it even works with the other code that is being written.

I think we need to take a step back, and figure out absolute basics of what we need, and the building blocks needed to get there. Then from there, create milestones, and work on the project in pieces, so that we can build on basic code, like memory management, then write code on top of that, rather than trying to write two separate pieces of code, and then worrying about trying to get them to fit and work together.

[dilbertfan]

We did see what we needed, and now we are pushing it- if you feel the need to rewrite a block to suit our needs better, then go for it! We have a custom mem manager and multitask system which have been spec'd together.

[Lukew4lker]

The first stepping-stone which I would believe we could all agree, would be loading of more than one program while the computer is still running. The next most obvious step would be the ability to choose which program to run via some sort of shell which operated with the kernel. Things like process scheduling and virtual memory can come into play later.

[M52]

I do agree with Collerr that we need to tailor all code towards each other, not take bits and piece and throwm em together and try to make it work.

Fresh, entropy specific code is what we ned. Hence, I say we SPEC EVERYTHING first!!

I am getting courses in project management and as much as I hate the course, it is useful to know, you need to have a PLAN and you need to work it out in minute detail.

For example, the MOSCOW method I used earlier, Must Have, Should Have, Could Have, Won't Have. It's tedious but there is a reason there are people who do project management for a job...

[trillek]

Indeed. Scope documents, requirements documents, design documents. Ideally, these would all exist before we wrote any code. Knowing how everything will work, work together, and be used, prior to coding the pieces is really important.

[M52]

There is only one thing to decide:

WHO is going to design the whole thing? We really need to think it out in advance. It could be several people (2 or 3) who release a new document every now and then. That document is then discussed here and modified accordingly. Then the "commitee" moves on to the next document, etc...

From there we can then actually assign people to certain tasks and start building!

[dilbertfan]

We already have docs for different components, and I don't see an issue with what we have now, beyond that palin cant be active very often.

On Sat, Oct 27, 2012 at 7:43 AM, M52 notifications@github.com wrote:

There is only one thing to decide:

WHO is going to design the whole thing? We really need to think it out in advance. It could be several people (2 or 3) who release a new document every now and then. That document is then discussed here and modified accordingly. Then the "commitee" moves on to the next document, etc...

From there we can then actually assign people to certain tasks and start building!

— Reply to this email directly or view it on GitHubhttps://github.com/trillek/entropy/issues/18#issuecomment-9834786.

[viccuad]

I do like the way of thinking it all out first, building all the specs. Its the way it's all done (you dont start building a car just to finish it out and find that it doesnt pass the wind tunnel, for example, or the gravity center is missplaced). its the same here. its pointless to start coding like mads to find in the 4º iteration that the in order to get trully multitask without bugs you need to recode half the project (for example). this is a kernel. its not easy to build it. but hey, we are not the first ones: many have done it before. just take a look to books and document ourselves and so on.

milestones are cool. you feel cool and productive when you reach one, and they give focus. for me, it would be:

1. first iteration or milestone: designing the kernel. almost everything: bootloader, filesystem, memory manager, what libraries are we going to need, processes scheduler, processes communications/signals/semaphores.., internal library for comunication with hardware modules.
2. start coding from bottom to top: we first will need the bootloader, filesystem, hw functionality for the disks.
3. memory manager, some little libraries.
4. build the processes scheduler.
5. now that we have the processes, communicate them: processes communications/signals/semaphores..
6. add hw functionality
7. ???
8. profit :D

In my opinion, we should just start grouping issues on milestones, and begin to make milestones. that would shape our plan. please do it if you feel free. I will gladly do it if people likes it.

also, I think that having an irc chat available to discuss fast some things would be really useful. In every project i have made, we had a chat when everyone should be when he/she was coding. Its like a virtual office, really helpful (even if you are phissicaly in the same place, to share snippets of code or asyncronous demands/comments/etc while not interrupting others). if you like it, say it or open an issue about this. and this allows us to see our number.