Due to some recent questions, I decided to post a new message here about a few of the details of a software engineering project. I'm thinking specifically of Slimserver, but most of this information is applicable to other projects as well, both proprietary and open source.
Some background info: This link contains information about what's going to be in upcoming versions of Slimserver: http://wiki.slimdevices.com/index.cgi?SoftwareRoadmap. Typically these are new features. For information about what bugs will be fixed, you can use the search feature on http://bugs.slimdevices.com, which is our bug tracking system (running software called "Bugzilla"). Slim Devices uses a "revision control" system (sometimes called "source control" or the "source tree") called "Subversion" (or "svn" for short) to store the source code for Slimserver. Detailed information about revision control is available at http://en.wikipedia.org/wiki/Revision_control if you are interested. The jargon of using a revision control system will often appear in our conversations about other aspects of Slimserver. When a developer (either an employee or a contributor) makes a change to source code stored in a revision control system, they have to "commit" (also called "checking in") their change. This is part of the system's mechanism to make sure two or more people don't check in incompatible changes to the same part of the code. In addition, revision control lets us have "branches" in the code. A branch starts off as an exact copy of all the source files needed to build Slimserver. From that point, the source files can be changed independently. So, next time you see a new branch appear in the nightlies, you'll know, generally, what the differences are between branches. Not much. It's only after divergent changes have time to start happening that noticeable differences appear. The main reason we create branches is to try to have a more stable software product. Most development goes on in a branch called the "trunk" (or in some systems "main"). Typically, when we get close to where we want to have a release (such as the recent 6.5.1 release) we will create a "branch" from the "trunk". This way, risky development can continue in trunk without causing major bugs in the branch about to be released. Since perl is not a language that needs to be compiled, it's possible for developers (and brave users) to just download the source code from our Subversion server and run it. For users that require a more friendly installation package, we make nightly automated "builds" of all branches for a number of operating systems. For most platforms this is basically an installer to go with the source. For Windows, we also put the Slimserver source in a "wrapper" so it can be run as a windows executable on systems without perl installed. At the moment, there are two branches in our revision control system. The trunk is being called 7.0, and there is a branch called 6.5.2. 6.5.2 is very close to release, so we are trying to minimize the changes that go into it so that we don't introduce new bugs. Nightly builds are available. The builds from the trunk (7.0) are not yet available on the nightly web page because there are still many known problems. It would not be constructive to have many end users filing duplicate bugs at this point. After it becomes more mature, we'll link to the nightly builds. If you file a bug you are having with 6.5.1 (or an earlier version), one of the first things we'll do is ask you to try it on 6.5.2, which at the moment is quite stable. If the bug also exists in 6.5.2, we'll try to assess the severity and risks associated with fixing the bug in the 6.5.2 branch. If there's a risk of creating or exposing new bugs, we'll probably decide to mark the bug to be fixed in 7.0. This is not an absolute decision; if there's a lot of interest in having it fixed for 6.5.2 by all means let us know and we'll do what we can. There have been some recent posts about how there's not much development going on with Slimserver at the moment. The main thing that's really happening is in the "trunk" of our source tree, there is under way a complete rebuild of error and status reporting between different portions of Slimserver that should allow much better error messages and error logging. There have also been some questions regarding bugs filed. I believe you if you say that you saw a bug in 6.5.1! However 6.5.1 is done. That branch is now called 6.5.2! So if your bug is fixed in 6.5.2, then that's where it's fixed. We're not going to make any more 6.5.1 builds. Similarly, if a bug has been fixed in 7.0 but still exists in 6.5.2, it has probably been fixed by the major changes that have been done on 7.0 and it may not be possible to fix it in 6.5.2. Ever! If we were to make those same major changes to 6.5.2, then it would be 7.0, and you'd have to wait for it, too. :-) If you file an enhancement request, what's going to happen is it will get marked to fix for a "Future" release. We already know what our goals are for 6.5.2 and 7.0. If your request is extremely important, or happens to correspond with work we're already doing for those branches, it might make it in. Otherwise we'll review it in a meeting later to determine what version we want to put your request in to. Hopefully, this post about the background of software engineering going on with Slimserver will explain some of the strange behavior you see from developers and QA people! But we haven't all been replaced with policies and automation. If there's something you have a strong opinion about, always feel free to make a comment or send some email! -- ChrisOwens Christopher Owens QA Manager [EMAIL PROTECTED] (650) 210-9400 x717 ------------------------------------------------------------------------ ChrisOwens's Profile: http://forums.slimdevices.com/member.php?userid=4240 View this thread: http://forums.slimdevices.com/showthread.php?t=33033 _______________________________________________ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
