|
OpenBSD General Other questions regarding OpenBSD which do not fit in any of the categories below. |
|
Thread Tools | Display Modes |
|
|||
Working with CVS?
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. |
|
|||
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.. |
|
||||
Quote:
Quote:
Quote:
I'm running -current branch on my laptop and it functions just fine most of the time. Quote:
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. |
|
||||
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.
__________________
My Journal Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''. |
|
|||
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. |
|
|||
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. |
|
|||||||
Quote:
Quote:
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:
Quote:
Quote:
Quote:
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:
|
|
|||
Quote:
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). |
|
|||
Quote:
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. |
|
|||
Quote:
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. Quote:
|
|
||||
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 .
__________________
My Journal Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''. |
|
|||
Quote:
|
|
|||
Quote:
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. |
|
|||
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.
Quote:
Quote:
|
|
|||
Quote:
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. |
Tags |
cvs, development |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
x11 forwarding over ssh not working | kasse | OpenBSD General | 14 | 23rd December 2008 02:21 PM |
pf: why is that rule not working? | ivanatora | FreeBSD General | 14 | 11th December 2008 09:32 AM |
USB not working after suspend | stukov | Other BSD and UNIX/UNIX-like | 5 | 11th August 2008 06:48 PM |
Crontab not working | beandip | FreeBSD General | 6 | 6th August 2008 08:33 PM |
Is powerd really working? | yurtesen | FreeBSD General | 16 | 12th June 2008 11:10 PM |