Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
First off, I didn't want to complain. I know that what I get here I get for free, I am deeply grateful for this, and appreciate the effort and the willingness to share the results. Maybe some of my concerns are a misunderstanding, but maybe some are not. Some comes from deep down in the gut of a project manager looking at a managed project... Tony Hoyle wrote: >> Binaries for previous stable builds are not available anymore (so you >> need to keep > > They're in the archive. I'm not sure what that means, but when I go to the cvsnt.com page, I don't seem to get a choice of download -- the only version I see is "CVSNT 2.5.01.1927", and I can't find an "archive" link there. When I go to the "open source project" page (the wiki), the download link takes me back to the MarchHare cvsnt.com page. I don't see release notes, history of stable releases, nothing of that kind. They used to be there, IIRC, but some time ago these things kind of vanished, it seems. > Disk space limits mean I can't keep anything before 2.0.58d at the > moment, but that's 7 months old! Can't you host the files on sourceforge? >> your own copies around), there's no publicly available bug database (so >> you need to keep your own log, extracted from the mailing list about >> what works and what doesn't in every stable build you may consider for >> updating), > > In general cvsnt develoment has been very stable - the bug list was 90% > installation problems and old versions and had frankly become a waste of > time. The list is a much better place for it as the simple stuff can be > filtered and I can concentrate on the real bugs. > > Most bugs are found pre-release. Any extra ones are found usually > within a few days of the initial release and fixed (which is why I often > say don't upgrade immediately). This may be so. But there's nothing (except from your phrase above) that tells me that this is so. No release information, for current and past releases, no bug database. Bugs are, as you say, part of a normal development process. I'm not saying that cvsnt is any more buggy than anything else. I'm not saying the development process is not a good one -- I know I don't know enough about it to be able to say that. But when the svn guys put out a stable version, they publish a list with everything that has been changed in that version WRT the last stable version. User-visible fixes and new features, developer-visible things, AFAICT everything. Kind of a change log, like what you can get out of a traditional bug tracker; something very familiar to me and probably most other developers who have managed projects. This creates /confidence/. My word was not that the cvsnt process is not a good one, it was that I don't know where to take the trust from. It seems to me to be a "take it or leave it" kind of thing -- the "internal" guys know what was fixed and when, what feature was introduced in what version, what feature got broken in what version and got fixed (or is scheduled to be fixed) in what version, and so on. But the "outside" guys don't know that, and there's nothing that would tell them. And I'm an "outside" guy; maybe less than others (and that's the reason why I even think about these things), but still. My story is this: I'm running 2.0.34 on my server. Some obscure bug prevented me from updating to the next stable release at the time (I think it was 2.0.41a or so). I could pinpoint the "breaking point" to exactly between two releases, but I couldn't figure out what in the sources could have made the server break on my system. Ever since then I've been wanting to try a new version. But then people come and say "my xml files are messed up with that ampersand" and I don't have a clue when that got fixed. I have ampersands in file names, and it would be a major deal if I had to go through the whole repository, break projects and histories and rename a lot of files. So some people know when that got fixed, but I don't, and nobody really tells me. You say that this is what MarchHare and pro support is for, and that's ok. I don't have a problem with that. But I also know that when I see a project where these things are more transparently, and when I see a project where the user documentation is in sync with the code, I like it better -- it gives me confidence in the process. It sometimes seems that for quite a number of features, the only one who knows how they are supposed to work is Tony (not even talking about how they really work). And I don't really know what I could do about that. (Besides, of course, becoming a main developer on the project and knowing the sources as well as Tony.) > All stable releases are released with zero known bugs, unless noted (for > example rename isn't worth fixing as it's being gutted and rewritten in > the development branch). Where is noted what is noted? Can this be found before installing the version? See, it all comes back to the same theme: there's obviously lots of information around that's somewhere but not easily accessible. One has to be "insider" to know how to get these things, and working with cvsnt for 5 years and regularly reading this newsgroup didn't make me an insider yet. Just going to the web sites (both the commercial and the open source project's) doesn't give me any of this information. > There have always been exceptions (it used to be '+'). Also, that bug > was fixed in under 24 hours. Again, how would I know this? It is nowhere published, according to you this list is the ultimate source of information, and just recently there was a post (on this ultimate source of information) about someone having a problem with that... I /need/ something that tells me "in versions x, y and z file names are not allowed to contain '+'" and "in versions a, b and c file names are not allowed to contain '&'" -- whether that is a feature or a bug. There's nothing like this available, and I feel really lost. I don't have any way to tell what on my server will break if I update. I'm not talking about breaking due to some obscure, never before seen bug, but breaking because of known changes. There's no list of known changes that would allow me to take an educated guess about what can be expected to break. Or what new features can be expected to work. The main way to find that out is to try it. So there are thousands of cvsnt admins trying out these things, and there is no pool where this information gets shared. And also, how could one share? You never know what's specific to a specific version, what's a bug and what's a feature... > If something breaks you have 3 choices (and this applies to subversion as > much as cvsnt or any other community supported project) Agreed on all that. But this wasn't the core of what I wanted to say. It's not about code quality or bug counts or time to fix or how to fix, it's about transparency. To me, as a casual distant observer, subversion development seems a lot more transparent than cvsnt, of which I'm an active user and close observer. Which scares me -- and might scare me away. One single thing that would probably take away most of my current insecurity about cvsnt would be a list of all things done, published with every release. And access to these lists of previous releases. This is something I think every project should have (and something I require on my own projects, even if it's only me working). It still wouldn't help me with my next step (because I guess it's pretty unlikely that I will get a list of changes since 2.0.34), but it would still help people from here on. Again, this all is not a complaint. Nobody here owes me anything. But I feel that I owe you to present my view of these things, for one because you answered me and tried to address my concerns, and also because I sincerely think that at least some the points are valid and improving on them could maybe even make your life easier (again knowing very well that I don't know a whole lot about your life :). Thanks, Gerhard