View Single Post
  #8   (View Single Post)  
Old 5th October 2009
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 3,318
Default

Quote:
Originally Posted by Zmyrgel
I'm wondering how OpenBSD devs work with the source code.
The underlying assumption is that whatever is checked into CVS is at least compilable. Those that break the build process are spanked, & sometimes spanked publicly. To help maintain that check-ins are relevant & correct, the Project also requires sign-off by at least one other developer. There is a developer-only mailing list which we heathens do not have access. I suspect a number of diffs are traded & discussed there.
Quote:
Do they use another personal source tree and then commit from it the main sources at some intervals and so.
In general, code is committed only when it reaches some level of (arbitary) maturity. Be aware that everything that is in CVS is not always ready for real-world usage. Some drivers/daemons may be present but not active after installation. Those in the know or those that are interested in testing can finish configuration of such features & report back to the developers if they find issues. This is especially true of snapshots which may or may not have uncommited code present.

It is important to recall that the Project's target audience is the developers themselves. By leaving code to new functionality dormant sometimes for several releases or placing uncommitted code in snapshots is not a sneaky practice. These are simply ways to identify code which is not fully tested or possessing less confidence than what is officially in CVS. The goal is to maintain a high degree of code integrity. Individual developers may not have the resources by themselves to fully test code which in time will be checked into CVS, so uncommitted code is also traded about.

Yet to answer whether code is occasionally checked back in on a regular interval, the answer is no. If the functionality is half-baked such that it is unusable or does not compile, there is no reason to check it in. The Project's goal is to have experienced developers participate in the development process, & maintaining a high confidence in what is officially in CVS. Milestones are coordinated on the developer-only mailing list.
Quote:
Originally Posted by BSDfan666
The developers coordinate their commits, to avoid conflicts and such.
In general, yes. Many developers work on different problem domains which usually means that they are working on different parts of the code base. But not always. When reading the source-changes@ mailing list, you will see occasional bouts where code is backed out or quickly replaced by different code by different developers.
Quote:
Originally Posted by jggimi
Every patch, no matter how trivial, requires peer review.
The point of this practice is to minimize errant check-ins. Sometimes needed header files are missed for one reason or another, but these are corrected in CVS rather quickly. Given that anyone from anywhere may be checking out the CVS tree followed by building, the goal is that the head of CVS remains at least compilable.
Quote:
Originally Posted by Zmyrgel
Isn't the code in snapshots already in the tree and will appear in the next release?
In general, yes, but as has already been mentioned uncommitted code may be put into a snapshot in order to make it more easily available to a wider audience.
Quote:
One possible project would be a AMD rewrite.
Although you haven't specified the scope of what you are intending, this sounds exceptionally ambitious. As a benchmark, the link below is from someone who ported OpenBSD to the Xbox a few years back:

http://tobias.schroepf.de/doku/doku....sd_to_the_xbox

Unless you have a lot of time & experience, this may be an unattainable goal.
Quote:
Hard part is that I'm not experienced programmer and most courses at school focus on OOP and Java which doesn't help on this.
My suggestion would be to branch out from your strengths. If your background is in Java, consider porting a Java application to several platforms. Plus, the Java compiler & runtime itself is not available on all platforms either. From what (limited) information you have posted, I would say that looking for an application to port may be the most feasible problem to solve.
Reply With Quote