OSDev.org

Hi,

There are plenty of all-in-one code solutions out there (repository, wiki, bugtracker, that kind of thing) - Sourceforge, Googlecode, Bountysource, etc., but none of them have a feature which I really want (will be explained in a second). I'm therefore thinking of creating my own as a sort of side project.

What I want to decide though, is whether to design this system purely for my own OS project (Pedigree), or whether to design it generically and make it available to anyone. What I'd like, if you can spare a minute or two, is several people's answers to a few questions, so that I can make my decision.

The features that I want that are not currently available are:

* Automated testing integration. This would in my case involve a CDash style web-based display and analysis of test results.

* Change requests. This is the feature I most want. I want to allow people to commit to my repository, but I don't want to give everyone trunk commit privileges. What if they break builds or functionality? Yes, I can roll back but (a) that's time consuming, (b) not particularly scaleable and (c) loses all the breaker's changes - it almost certainly won't be a deliberate break and possibly very easily fixed - no need to go throwing away their code!

So what I propose/want is a system where a user can submit a "Change request" or "CR". They would fill in a form giving what the change was, the rationale behind it etc etc, then either submit a patchfile to the system or the system would create a SVN/CVS branch to which they get commit access.

When the patch (or work on the created branch) is final, the change can be reviewed by a moderator, along with automated testing data (see first bullet point) to see if it is (a) wanted and (b) stable. If so, the system will merge it into the trunk. (If conflicts arise, the system will reject the change and notify the originator to update to a newer revision and solve the conflicts).

The first advantage to the above system is that you can allow many people access, not all of which you nessecarily trust 100%. The second advantage is that you can monitor testing regressions before it is too late (before the change gets into the trunk).

So, the big questions are:

(a) What do you think about my proposed features? Do you like the sound of them? Do they sound useful?
(b) Are there any features in your current repository (SF.net, googlecode etc) that you find lacking? Any features you want?
(c) Do you think I should make this available to anyone? Just to people in OSDev (I.e. make it OSDev specific), or just for myself and don't give up my day job?

Any responses would be much appreciated!

Thanks.

James

a) Testing integration sounds wonderful. I haven't had much experience with projects on the tens-of-programmers scale even, so the second feature you mention (change requests) isn't too much of a big deal for me. I know a few large corporations however do implement EXACTLY this sort of thing in their custom CMS / Version control systems all the time, and so I could imagine it would be useful.

b) Documentation & User-friendlyness. The easier it is for people to get stuck into their code without worrying about the repository, the better off everybody is going to be. Nicely named commands and documentation (even embedded in the client!) would go a long way to solving this problem.

c) If you're going to write code and not make money out of it, why not make it free for everybody? In any case, there is nothing lost by just making the source available and telling people to modify it to their needs! As for OSDev-specific, I wouldn't. People will use it more if they only need to learn the one single system, as opposed to one for OSDev and one for everything else.

Your 'change requests' sound a lot like the git hosting site's idea of a mob user account.

Hi, thanks for the reply!

Yayyak wrote:a) Testing integration sounds wonderful. I haven't had much experience with projects on the tens-of-programmers scale even, so the second feature you mention (change requests) isn't too much of a big deal for me. I know a few large corporations however do implement EXACTLY this sort of thing in their custom CMS / Version control systems all the time, and so I could imagine it would be useful.

Yes, the company I work for implements this and it works extremely well.

b) Documentation & User-friendlyness. The easier it is for people to get stuck into their code without worrying about the repository, the better off everybody is going to be. Nicely named commands and documentation (even embedded in the client!) would go a long way to solving this problem.

Could you give an example of documentation embedded in the client? I'm not sure quite what you mean here!

c) If you're going to write code and not make money out of it, why not make it free for everybody? In any case, there is nothing lost by just making the source available and telling people to modify it to their needs! As for OSDev-specific, I wouldn't. People will use it more if they only need to learn the one single system, as opposed to one for OSDev and one for everything else.

That's why I was asking. The thing is, it's about 50% easier for me to code a system that has next to no security (against malicious attacks) and just add an .htaccess file to stop anyone from getting in except people I specify. Obviously, opening things up to everyone causes more security pain, so I wanted to know what people thought before I tried it!

Cheers,

James

Automated testing can be done - depending on the chosen VCS solution - be done by means of "commit hooks". Most VCS suites support the execution of a script prior to committing a changeset to the repository, and deny the checkin if the script indicates failure. This assumes the server having all the ressources necessary to actually do the testing (compiler, ...).

Change Requests / guest commits are easy to do. All bug trackers (or rather, "issue trackers") I know allow you to define categories, and at least for Subversion I know you can set user access privileges "by subdirectory", i.e. you can allow "guest commits" to an "incoming" directory without opening your whole repository.

Hi,

Solar wrote:Automated testing can be done - depending on the chosen VCS solution - be done by means of "commit hooks". Most VCS suites support the execution of a script prior to committing a changeset to the repository, and deny the checkin if the script indicates failure. This assumes the server having all the ressources necessary to actually do the testing (compiler, ...).

Yes, and actually in my case this would be better done with a pre-commit hook, to force testing to be done on the client before commits were allowed (as opposed to on-server AFTER commits are allowed). But, and here's the big problem - What if my code that I want to commit just isn't ready? It will cause tests to fail, it will cause builds to fail, just because I haven't finished it - I just want to push my changes off my current computer so I can pull them down onto another one. It's often done.

Change Requests / guest commits are easy to do. All bug trackers (or rather, "issue trackers") I know allow you to define categories, and at least for Subversion I know you can set user access privileges "by subdirectory", i.e. you can allow "guest commits" to an "incoming" directory without opening your whole repository.

Yeah, this was the technology on which I was intending to base my CR system.

Incidentally both of the above solutions are not applicable in current free VCS hosting as none of them allow you to add pre or post commit scripts (for obvious reasons, and with the exception of an email notification), or set directory privileges (must be done by 'svnadmin', iirc).

JamesM wrote:What if my code that I want to commit just isn't ready? It will cause tests to fail, it will cause builds to fail, just because I haven't finished it - I just want to push my changes off my current computer so I can pull them down onto another one. It's often done.

But surely not to HEAD / trunk (where it would affect all other developers), but your user branch? You can set the script to check only for HEAD / trunk commits.

Incidentally both of the above solutions are not applicable in current free VCS hosting as none of them allow you to add pre or post commit scripts (for obvious reasons, and with the exception of an email notification), or set directory privileges (must be done by 'svnadmin', iirc).

I don't know how things are on Sourceforge these days, but back then I had little trouble setting up a Subversion repository on the shell account. (That was back when they didn't offer Subversion yet but only CVS.) Also, I cannot imagine it to be impossible to talk an admin into allowing you to set your access rights.

If all things fail, vServer hosting is rather inexpensive these days, and more than sufficient for small-to-mid sized development projects.

Solar wrote:

JamesM wrote:What if my code that I want to commit just isn't ready? It will cause tests to fail, it will cause builds to fail, just because I haven't finished it - I just want to push my changes off my current computer so I can pull them down onto another one. It's often done.

But surely not to HEAD / trunk (where it would affect all other developers), but your user branch? You can set the script to check only for HEAD / trunk commits.

Incidentally both of the above solutions are not applicable in current free VCS hosting as none of them allow you to add pre or post commit scripts (for obvious reasons, and with the exception of an email notification), or set directory privileges (must be done by 'svnadmin', iirc).

I don't know how things are on Sourceforge these days, but back then I had little trouble setting up a Subversion repository on the shell account. (That was back when they didn't offer Subversion yet but only CVS.) Also, I cannot imagine it to be impossible to talk an admin into allowing you to set your access rights.

If all things fail, vServer hosting is rather inexpensive these days, and more than sufficient for small-to-mid sized development projects.

Aye, I have access to a VPS already, and have a subversion repo on there that I can administer myself. I was intending to just make this for my project only, but wondered what the audience would be. I reckon now it would be too much work to make this public (safety, security etc) and may just design it solely for my project.

Cheers for the replies Solar.

James