hmmm..... no, patches shouldnt be submitted to anyone. If you modify something, you commit it in the CVS, if Ton ( or whoever is the leader ) decides there is something wrong with a particular commit he can revert that changes.

Nobody other than a very small core group has currently write access to CVS. So post your patches somewhere in this forum. Or better, upload them somewhere and post a link. Then, start your threads in this forum with "[PATCH] comment translation in some/thing/toets.c". Use "diff -Naur" for your patches (if you can - Windows developers might have to install Cygwin).

Patches should be tested by a small group of people anyway before incorporating them into the main CVS tree.

Anonymous wrote:hmmm..... no, patches shouldnt be submitted to anyone. If you modify something, you commit it in the CVS, if Ton ( or whoever is the leader ) decides there is something wrong with a particular commit he can revert that changes.

The code in CVS should always at least compile and run. If anyone could change the code in CVS this couldn't be ensured.

IMHO only a small core group of programmers should have write access to CVS and they should inspect all patches before applying them. This is needed to keep "bad code" out of the repository and to ensure that nothing breaks. There might be even thousands of people using the CVS version so it is very important that the code in CVS actually works.

I thought there would be multiple CVS versions here, perhaps there will soon/someday. So the "main" CVS could be for the stable-code, plus bugfixes, say, and then there would be "development" for a team doing work on making the current blender better, and often changing thing. this one might not always compile. a "blender3.0" one could be for the next version alltogeather, which probably wouldnt'compile at all for ages. anyway. the normal way for CVS to work, that I have seen on many projects is that the CVS isn't stable, and the release tarball, or binaries, or whatever are the stable ones. before each release, they have a time of "feature-freeze" in which new features are not added, and only development in that tree is towards bugfixing and making prepaired for the release.

Only the bleeding edge development code is kept in CVS. Of course, releases can be branched off of it so applying bugfixes to them becomes easier, but generally most of the people using CVS versions are developers.

So the "main" CVS could be for the stable-code, plus bugfixes, say, and then there would be "development" for a team doing work on making the current blender better, and often changing thing. this one might not always compile. a "blender3.0" one could be for the next version alltogeather, which probably wouldnt'compile at all for ages.

I'm sorry but this is dead wrong ;-)

The code in the repository ABSOLUTELY MUST be compilable.

For example, let's assume that Bob Lamer has written a patch that allows you to fetch pr0n from the internet to be used as textures with one button click. He applies it to the main tree (since there is no control of access to the main repository) but unfortunately he has a bug there, causing Blender to segfault a few seconds after it is started. 53 developers update their sandboxes (their checked out versions from the CVS) in the morning, and start hacking on whatever they were working on. To their surprise everything just keeps crashing. Will they all just stop the development and wait for Bob to fix the code (IF he is even going to fix it)?

If this was done the right way Bob would have posted his patch here and asked for it to be included in the main tree. Some BF programmer would have taken a look at it and told Bob either that A) This patch is too specialized and this feature isn't needed in vanilla Blender or B) if they actually would want a silly feature like that, he would have told him that he cannot accept the patch because it keeps crashing.