Working with CVS?

[Zmyrgel]

I'm wondering how OpenBSD devs work with the source code.
I mean, I know the basics of CVS, but I can't think a way how to use it to efficiently.

How developers work with their sources? Do they use another personal source tree and then commit from it the main sources at some intervals and so.

I'm just planning trying to do something with the source tree but I'd like to hear about how people work with it. Any suggested development methods etc.

[BSDfan666]

The developers coordinate their commits, to avoid conflicts and such.. as such a developer must get permission from other developers before something goes into the main tree.

I'm certain that developers maintain their own private trees, either locally or somewhere private on the central server.

The snapshots that are produced by the project include patches that haven't made it into the tree, often they use this avenue to test code in the wild before they consider it stable enough.. unfortunately not a whole lot of people test the snapshots, except for the developers and some dedicated users.

OpenBSD has it's own CVS server and client project, OpenCVS, they popularized anonymous CVS access (..nobody did that before them).

Hope that helps..

[Zmyrgel]

Originally Posted by BSDfan666

The developers coordinate their commits, to avoid conflicts and such.. as such a developer must get permission from other developers before something goes into the main tree.

Quite obvious that they coordinate their commits but how exactly? Do they just send patches via email or do they use some common test repo to pass these or something completely different?

I'm certain that developers maintain their own private trees, either locally or somewhere private on the central server.

Ok, if they have separate trees, how they can be coordinated with the main source tree so that history is correct.

The snapshots that are produced by the project include patches that haven't made it into the tree, often they use this avenue to test code in the wild before they consider it stable enough.. unfortunately not a whole lot of people test the snapshots, except for the developers and some dedicated users.

Isn't the code in snapshots already in the tree and will appear in the next release? The patches that need testing seem to be posted on the tech@ mailing list.
I'm running -current branch on my laptop and it functions just fine most of the time.

OpenBSD has it's own CVS server and client project, OpenCVS, they popularized anonymous CVS access (..nobody did that before them).

Yes, I'm aware of this. Hopefully they get it released soon. I could give it a spin to see if it will be already usable. There seems to be a warning that bugs can cause data loss still but I don't have anything important to use with it anyway.

I'm more interrested in the actual use of CVS. Like actual use scenarios how others use CVS.
Probably best method would be to just start to use it on something and work my way from there.

[jggimi]

This is -my- understanding. It's probably wrong, therefore.

• Every patch, no matter how trivial, requires peer review.
• Developer and peers are listed in each patch log.
• Functional patches must be tested before commitment. Therefore, each developer keeps their own working set containing their uncommitted patches that are not yet ready for committment.
• Snapshots are built, when needed, as needed. These vary. Obviously, snapshots are made on all architectures for -beta, and for flag days and other architectural changes... but there are usually many more snapshots created during the normal development cycle.
• As BSDfan666 said, snapshots may include uncommitted patches. If you run -current by upgrading snapshot to snapshot, and many people do, you may occasionally be running uncommitted code. If you run -current by installing a snapshot, then building from source, you will be running only committed code.
• Huge, complex hunks of code may be developed in its own CVS branch, by the developer(s) working on it, prior to being synced into the main branch. Historical examples: multiprocessing, and the Unified Buffer Cache. X11 has been historically kept in separate branches: XF3, XF4, and XENOCARA

[TerryP]

There are basically two usage scenario groups, 0.) you have your own CVS repo and are the only dork to commit to it; and 1.) there is a central CVS repo that people commit to IAW pre-agreed upon policy, and dorks who break the unbreakable stuffs get mooned!

You can probably find some examples online, most would probably compare distributed and non-distributed workflows (e.g. git versus cvs). Several projects may have there commit policies published on the net (FreeBSD does), and others that have since changed systems (perl, mozilla, etc) may be accessible on their sites or via the way back machine.

When dealing with a largely centralized solution, like CVS or Subversion: you generally organize things so that work gets done and people don't rip each others throats out. Some examples:


There can be one or several merge meister of ceremonies, who is/are responsible for getting everyones latest work imported into the main line without conflicts between commits; who if smart, would also delegate fixes to other developers to sort out on there own .

And of course, you can have a core who can do whatever the want, and establish policy to minimize foul ups. Some projects for example declare that the bleeding edge (e.g. trunk) will always be a cutting board with no obligation that it even compiles, or that it will always be the most stable code in the tree. The concept of trunk, branches, and tags, are fairly common among developers whether or not the software enforces it.


Think about team work and multithreading, and you'll likely get some ideas of how it works. OpenBSDs website & mailing lists may also provide information, if you wish to help the project with development; just don't expect commit access in the short term.



Personally, I use git for my code.

[Zmyrgel]

Yeah, I'm just interested how things are done in OpenBSD development.

I'm slowly completing my studies on software engineering degree and I have to do a graduation work. One possibility for it would be to contribute something to the OpenBSD.
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.

One possible project would be a AMD rewrite.

[BSDfan666]

Nobody here is likely to know intimate goings on in developer land, they communicate with each other in various ways.. via email, and ICB (..kind of like IRC).. but also in real life via hackathons/alcohol-consumption-gatherings.

As has been said, before anything ends up in -CURRENT.. it's reviewed by others.. and if someone breaks the tree they get punished.

Theo has a talk and paper about OpenBSD release engineering, you can find them below:
http://www.openbsd.org/papers/asiabs...e_engineering/
http://keepvid.com/?url=http%3A%2F%2...%3Di7pkyDUX5uM

Send him an email if you want, he does usually reply.. maybe he can answer your questions.

[ocicat]

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.

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.

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.

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.

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.

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.

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.

[BSDfan666]

Originally Posted by ocicat

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.

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.

I do believe he means the automouter daemon, amd(8).. not OpenBSD/amd64.

The developers are very unlikely to accept a replacement written in C++ or Java, and even more so accept a complete rewrite from a novice programmer.. feel free to submit patches for specific things you feel could be better, someone on the lists might give you some pointers (..unless nobody is interested in such changes).

[Zmyrgel]

Originally Posted by BSDfan666

I do believe he means the automouter daemon, amd(8).. not OpenBSD/amd64.

The developers are very unlikely to accept a replacement written in C++ or Java, and even more so accept a complete rewrite from a novice programmer.. feel free to submit patches for specific things you feel could be better, someone on the lists might give you some pointers (..unless nobody is interested in such changes).

Yes, I meant the Automounter daemon.
Of course I would work with C on it to even have the possibility to enter the tree.

That was just one idea I had. At least the amd configuration file syntax is awful so I think rewrite for it would be welcome. I doubt it would be easy assignment at all. It would require knowledge on NFS too at least.
I haven't gone through the sources of the amd to see if I can make sense out of them. Once I have had proper glance I can have some estimate on the difficulty level of such a task.

And theres still the point that I have at least half an year before I can start working on graduation work. Theres still time to choose proper project.

[ocicat]

Originally Posted by BSDfan666

I do believe he means the automouter daemon, amd(8).. not OpenBSD/amd64.

Fair enough.

Nevertheless, to rewrite amd(8) in Java, Zmyrgel will need to interface with various system calls which will require knowledge of C & Java's lower-level JNI interface. This may be a bit daunting for those who are not familiar with either. Again, it comes down to how much time can be alloted.

The developers are very unlikely to accept a replacement written in C++ or Java, and even more so accept a complete rewrite from a novice programmer..

The exercise has some merit, however I agree with BSDfan666 that expecting such an application to be accepted by the Project may be expecting too much -- not because of novice knowledge, but the fact that Java is not the classic choice for systems programming.

[TerryP]

Drastic changes to the configuration file syntax might be shot down if anyone actually uses amd for something, then again you could also provide a(n effective) tool to migrate the config files with your patches .

[Zmyrgel]

Originally Posted by ocicat

Fair enough.

Nevertheless, to rewrite amd(8) in Java, Zmyrgel will need to interface with various system calls which will require knowledge of C & Java's lower-level JNI interface. This may be a bit daunting for those who are not familiar with either. Again, it comes down to how much time can be alloted.

The exercise has some merit, however I agree with BSDfan666 that expecting such an application to be accepted by the Project may be expecting too much -- not because of novice knowledge, but the fact that Java is not the classic choice for systems programming.

Where did I say I was planning to use Java or C++?

[Zmyrgel]

Originally Posted by TerryP

Drastic changes to the configuration file syntax might be shot down if anyone actually uses amd for something, then again you could also provide a(n effective) tool to migrate the config files with your patches .

I think Theo uses amd so if any changes are made to it they better be good ones.

The configuration syntax of amd seems quite horrible that I've seen. It could use some tuning up to bring it to same level with rest of OpenBSD.

But anyway, these are just some ideas I'm pondering. Obviously if I'm going to start something like this I have to ask the devs for their opinion.

[ocicat]

Originally Posted by Zmyrgel

Where did I say...

If you look at the timestamps of the messages in this thread, five minutes lapsed between response #10 & #11 in this thread. In other words, I never saw #10 as I was composing #11.

...Java...

In #6, you state that this is your predominant experience. We can only work with the information provided.

...or C++?

BSDfan66 brought this up in pointing out a general preference of the Project developers for code written in C, shell, or Perl. Yes, I'm the one bringing up shell programming & Perl.

[Zmyrgel]

Originally Posted by ocicat

If you look at the timestamps of the messages in this thread, five minutes lapsed between response #10 & #11 in this thread. In other words, I never saw #10 as I was composing #11.

In #6, you state that this is your predominant experience. We can only work with the information provided.

BSDfan66 brought this up in pointing out a general preference of the Project developers for code written in C, shell, or Perl. Yes, I'm the one bringing up shell programming & Perl.

As I said in the #6, my experience is with OOP and Java which doesn't help on this. .
I was trying to make the point that OOP and Java knowledge wouldn't help in C programming.
I understand it wasn't quite clearly said but I thought it would be quite obvious that only real option for a rewrite would be to use plain C.

Adding anything Java related to base would require JDK to be also included. Same goes for another languages. C++ code could still be included but once PCC will replace GCC as default compiler any C++ would need a separate compiler as PCC is (AFAIK) only able to compile C code.