First of all, I understand that the official release can’t be constantly updated with each bugfix : there’s no telling how many downloads that would lead to.
Yet, when I report a bug, I’d still would like to have a patch that I could apply and that would solve the problem right away. An official realease would, at the end of its cycle, become a rock solid, industrial strength, smells like the roses version that many would love to use for most work.
Right now the problems in the official release are solved in the SVN trunk. This way we are always one Blender version remote from the solution. Moreover each new version comes with its new load of fresh bugs that will get fixed only in the following version… Bad karma.
Use post-it-notes to remind self to buy more post-it-notes.:spin:
Use SVN. I would assume the time it would take to sort out every single bug would mean bugfixes for 2.46 while 2.49 is rolling out. If that makes any sense :spin:.
Use SVN. I would assume the time it would take to sort out every single bug would mean bugfixes for 2.46 while 2.49 is rolling out. If that makes any sense :spin:.
If you read with a bit of attention you’ll see that it never was a question of fixing all the bugs that there may be in a release but those that are reported.
With the number of users for a given official release, plus the incentive to see the problem fixed in the release that they use, I bet that much more bugs would get reported and, at the end, each release version would become extremely solid if not perfect.
Besides, SVN has its own bugs that arise all the time, it is always changing and only a fool would use it on a day to day basis for serious projects.
not to get into a numbering debate, but perhaps a 2.47.1, 2.47.2, etc. that are the bugfixes for the current versions. Sounds like a good idea to me, and probably to other less tech-savvy folks. At the same time I’m sure you can find these versions on graphicall.
If the bugfixes came as patches then there would be bugfixed versions of the current official release on Graphicall for sure (and they’d need a lot of mirrors because the traffic would be something to contemplate…). Unfortunately these patches don’t exist for most bugsfixes, AFAIK (I hope that I am wrong) and what you find on GraphicAll are SVN, Branches and optimized builds, still AFAIK.
where rev is the revision number containing the bug fix.
When I close bug reports, I often give the revision number that fix it, I don’t think many others do, but they still always give the bug report ID in the commit log, so you can get it from there.
If you read with a bit of attention you’ll see that it never was a question of fixing all the bugs that there may be in a release but those that are reported.
Well thats uncalled for…
With the number of users for a given official release, plus the incentive to see the problem fixed in the release that they use, I bet that much more bugs would get reported and, at the end, each release version would become extremely solid if not perfect.
Actually, people would more likely just use the bug fix version like any other version. Bugs reports might actually go down with some few expecting the newest patch to have just manifested the fix without reporting. Much like now, but in smaller increments.
And say they manage to fix that one bug that’s getting on your nerves, then the next week the next official-official version is released.
Things work fine the way they are.
Besides, SVN has its own bugs that arise all the time, it is always changing and only a fool would use it on a day to day basis for serious projects.
J.
No more so than one would uses the bug plagued regular releases, right? Or those insane morons who use it for their silly but serious short films?
@ropsta:
I am sorry but I don’t see what’s positive that you are bringing to this thread.
@Theeth:
Well, that tells me that it is time for me to read the SVN manual… and find a couple of tutorial. LOL
I’ll do that.
Just one question, to give me hope in the meanwhile (until I understand, you know me…): using your technique would I be isolating the code that fixes the bug from everything else that gets added to the trunk (which may bring in some new bugs) ? (Hopefully I
It’s not really necessary to do what you propose. If it really is as important as you believe it to be then use the SVN. It is not as bad as you think.:yes:
Is that clear enough? I’m kind of tired now so you must forgive me if things are not. Clear that is.
Unless what you’re saying is that you’d rather I just agree with what you say or don’t post. That, then, would be eliminating the point of discussion, wouldn’t it?
Yeah that was normally the point where I insert some witty comment that at first doesn’t seem to make sense but later on it hits you. However, I hadn’t noticed how long I’ve been awake and so a few wires might have got crossed a bit, much like they are as I’m typing this.
I’m going to sleep.
@IamInnocent:
Make sure to have a warm glass of milk before bed… WHAT!? Huh? :spin:
I agree that it is not necessary but it would be quite nice.
I contend that it would be advantageous for Blender, which is already pretty stable BTW, to offer the industry the most stable product that it can.
If it really is as important as you believe it to be then use the SVN. It is not as bad as you think.:yes:
You say that SVN is not that bad and, as a matter of fact it is pretty good, for what it is.
Still it is not something one should rely upon for one’s livelihood. It is in constant flux ; it has more bugs that an official release evidently. It may happen that the tools that you used one day won’t work or won’t be the same the next. It may happens that a file that you saved with one revision won’t ever open in any subsequent revisions or it will be seriously messed up.
This is not the case with any official release. They are not in the same state of constant flux. A bugfix has nothing in common with the constant additions made to the trunk : if a tool didn’t work properly you just weren’t able to use it and so it won’t do anything to your file. When it get fixed you use it and no harm is done.
I compile SVN daily, a debug version that I run in gdb. I play with it for the fun of experimenting with the new features and to help with reporting bugs. I know pretty well what it is and no, I would never count on it for my work.
Is that clear enough? I’m kind of tired now so you must forgive me if things are not. Clear that is.
It is clear and I never had any problem understanding what you say.
I know that using the SVN for earning a living has to be done with the greatest care, only if there is no other way and if the possible gain balances the quite real risk one may be taking. So I don’t agree with you that ‘just using the SVN’ is a sound solution.
Unless what you’re saying is that you’d rather I just agree with what you say or don’t post. That, then, would be eliminating the point of discussion, wouldn’t it?
I never said anything close to that. I just think that my idea deserves better than being rejected off hand and I wasn’t seeing anything positive in your intervention.
That would give a patch for the exact change done in that revision. Problems will start appearing if those changes depend on something that is not in your (presumably outdated) target.
You are free to form your own opinion of me. I’ve been judged so often, to every extreme of hate and love, this at the same time, sometimes by the same person, that I don’t care anymore. I know that what I really am will prevail, at least for the people that matters to me.
What I get the less from your reaction and that of ropsta is that you act as if I attacked Blender in any way. I don’t know where that comes from.
I could be wrong.
You are, heavily
I’m not even sure what load of bugs you are referring to. And I’ll use the smiley that robsta used. :spin:
Is there anything to answer to that ?
What I try to do is something that I’d like to see : what is wrong with that? Who or what would it hurt?
Publishing patches, updates or diffs is a common practice you know. You never get updates for Firefox or other programs between releases ?
I use Code::Blocks as an IDE, for example, and it is constantly updated, almost daily.
I have a hard time to comprehend where you found out that I am talking about ‘loads of bugs’ ? Yet everyone know that there are bugs. There was a 5 pages long bug tracker just a couple of weeks ago. But I did contend that Blender was quite stable compared to many other apps I use.
Well, that is encouraging enough to go further.
For the rest I’ll have to get into the source sooner than I’d anticipated and maybe gain the confidence of a couple of coders. Good thing that I am not completely unknown. Now I may learn how I am known. LOL
The mountain out of a mole hills thing actually describes better what I was initially trying to say. I thought it was SVN that was used to make Big Buck Bunny (albeit with another name). I could be wrong, though. Backing up, saving often and saving many different version of a file help tremendously.
What I try to do is something that I’d like to see : what is wrong with that? Who or what would it hurt?
Publishing patches, updates or diffs is a common practice you know. You never get updates for Firefox or other programs between releases ?
I use Code::Blocks as an IDE, for example, and it is constantly updated, almost daily.
I get where you are coming from a little better now. Time and manpower become a factor though. Before each release, let me know if I’m wrong, the trunk is frozen and most the bugs are worked out. There is an official release. Then there is another possible release with even more bugfixes. I would imgine, but I’m not absolutely certain, that SVN is frozen to allocate manpower to fixing the bugs. After the release, work goes back to SVN. Any bugs fixed after the release are then met with other bugs that seem to pop up as things progress. So, the bug is fixed, but it is fixed along with the current state of the SVN.
What you want is those bugs to be isolated, and have fixes applied to official releases?
This could be implemented, but I think it would require more manpower or slower developement. I could be wrong though, as I often am.
If there is a way to implement what you propose without slowing things down or making more work, I’m purely for it.
I have a hard time to comprehend where you found out that I am talking about ‘loads of bugs’ ? Yet everyone know that there are bugs. There was a 5 pages long bug tracker just a couple of weeks ago. But I did contend that Blender was quite stable compared to many other apps I use.
Moreover each new version comes with its new load of fresh bugs that will get fixed only in the following version… Bad karma.
I firmly believe the only karma is the karma you make. If you think SVN will ruin months of delicate work, then it probably will. If you think, it’s more stable than most officials releases, then it is.
Well, who’s making the mountain ? What I am talking about is nothing new in the world and can only be beneficial. You were the one making a whole case out of nothing.
I thought it was SVN that was used to make Big Buck Bunny (albeit with another name).
You have to consider that Ideasman42 and Brecht were right there to develop and kill the bugs. Ton wasn’t far either although his coding time was limited. Other external coders contributed code too like Theeth. There are almost no users that can benefit from such instant backing. Pro Motion Studio has Matt Ebb full time and they hired Hamed Zaghaghi part time. Plumiferos had some help too but for small studios and even more for users like me who mostly do archiviz the delays for bugfixing are much longer and much more costly. The more those problems can be avoided the better we are.
I could be wrong, though. Backing up, saving often and saving many different version of a file help tremendously.
That is the basics and don’t worry we’ve got that covered.
I get where you are coming from a little better now. Time and manpower become a factor though. Before each release, let me know if I’m wrong, the trunk is frozen and most the bugs are worked out. There is an official release. Then there is another possible release with even more bugfixes. I would imgine, but I’m not absolutely certain, that SVN is frozen to allocate manpower to fixing the bugs.
The first step of bug fixing is the testing and there is not enough people testing the RCs and reporting bugs. It is hard and ungrateful work, costly too if you are normally using Blender to make a living. Whatever can be done is done and when the trunk seem to have no show stopper bug there’s a realease. Then users really start using it and then the bugs come out. If there are too many and if there is enough time, nothing more pressing there may be a bugfixing release. That doesn’t mean that all the bugs are fixed after that, far from it but Blender is then in the best shape, stabilitywise than it ever gets.
I want more. Where’s the drama in that ? If I hadn’t had whole days messed up by bugs believe me I wouldn’t be here considering this. I have better things to do.
After the release, work goes back to SVN. Any bugs fixed after the release are then met with other bugs that seem to pop up as things progress. So, the bug is fixed, but it is fixed along with the current state of the SVN.
You have to recognize by now that the SVN is too much in a flux to be of reliance when it comes to business.
What you want is those bugs to be isolated, and have fixes applied to official releases?
This could be implemented, but I think it would require more manpower or slower developement. I could be wrong though, as I often am.
What I want is a mean to an end. If you read what Martin (Theeth) said there may be a fairly simple avenue to explore.
If there is a way to implement what you propose without slowing things down or making more work, I’m purely for it.
It is about time…
Maybe you don’t know me but I give a lot of my time to help with Blender and I think that I succeed in making things just a little better. I don’t deserve the load of shit that you had for me today.
Strictly speaking, SVN-Trunk is not 100% recommended for production work (especially production work that is on-going for a long period). However, for the most part it is as if not more stable to use than the most recent ‘stable’ release, due to bugfixes that are made there.
You say that svn-trunk is “in too much of a flux” to be reliable. Sure, there’s always that factor. However, remember that no-one is forcing you to always update it, so just stick with a particular revision until your project is done if need be. Also, although many changes are made everyday, it is not very often that there is going to be a change that will cause any significant difficulties. The thing about using a source-control system is that you can also revert back to a previous “stable” revision and keep using that until any problems with a big new change are worked out.
It is worth noting that some professionals DO use SVN-Trunk for their work. See Promotion Studios (where Matt Ebb/“broken” works). With their relatively short turnaround time for projects, it is OK to use trunk as they can choose not to update for a few days if the project at hand is nearing completion, and then they can update to the latest to get the benefits of the latest changes.
As many people have mentioned already, backporting bugfixes is a reasonably time-consuming process, espcially if it means that new binaries must be released for it too. Just maintaining a separate branch where bugfixes are periodically ported across would need someone dedicated to doing it over a long time, as it would otherwise take away from time that could be spent by core developers on actually providing fixes and other improvements. However, we currently don’t have anyone volunteering for such a job.
Now, regarding how official releases often contain bugs as only then do people start really using the software and finding the problems. This is a bit of a vicious cycle… if no-one uses the svn-trunk versions for actual work, then of course we run into this problem of having an official release that has bugs that haven’t been discovered yet. To this end, the RC releases are aimed at solving this problem. A number of bugs ARE caught then… much more than during other stages of the development/release cycle.
Yet, in all logic, the SVN, prior to the RCs filtering, has to be buggier than once the debugging happened and a release is done. Otherwise why make the RCs at all if the SVN is “as if not more stable to use than the most ‘stable’ release”. With all due respect I can’t accept that.
You say that svn-trunk is “in too much of a flux” to be reliable. Sure, there’s always that factor. However, remember that no-one is forcing you to always update it, so just stick with a particular revision until your project is done if need be.
I can only speak for myself and my need. The title of this thread starts with “I wish…” not “We should…”. In my business there is no such thing like projects that are limited in time and here is why: designing a whole museum exposition, a whole house, a whole office takes a lot of time, a whole lot. The only way we can make money is if we re-use the most material that we can. That is one reason why we need stability. In SVN, which is for development, you cannot have a concern for this.
Also, although many changes are made everyday, it is not very often that there is going to be a change that will cause any significant difficulties.
Yet, when it happens it happens and it costs. The margins of profit aren’t that large with the concurrence that exists you know.
The thing about using a source-control system is that you can also revert back to a previous “stable” revision and keep using that until any problems with a big new change are worked out.
You see, that is something that I didn’t know ant that I am going to learn.
It is worth noting that some professionals DO use SVN-Trunk for their work. See Promotion Studios (where Matt Ebb/“broken” works). With their relatively short turnaround time for projects, it is OK to use trunk as they can choose not to update for a few days if the project at hand is nearing completion, and then they can update to the latest to get the benefits of the latest changes.
Good for them. It doesn’t apply here. I am the Matt Ebb of the poor here : no comparison can be made. Yet I bet that we are better off with me on the job than most.
As many people have mentioned already, backporting bugfixes is a reasonably time-consuming process, espcially if it means that new binaries must be released for it too. Just maintaining a separate branch where bugfixes are periodically ported across would need someone dedicated to doing it over a long time, as it would otherwise take away from time that could be spent by core developers on actually providing fixes and other improvements. However, we currently don’t have anyone volunteering for such a job.
All well understood and I never in my whole time using Blender asked for anyone to fulfill my needs. I’ll see how far my efforts for a version that is as stable as possible will lead me and then I’ll advise on how useful for everyone else the solution I will find and/or create will be.
Now, regarding how official releases often contain bugs as only then do people start really using the software and finding the problems. This is a bit of a vicious cycle… if no-one uses the svn-trunk versions for actual work, then of course we run into this problem of having an official release that has bugs that haven’t been discovered yet. To this end, the RC releases are aimed at solving this problem. A number of bugs ARE caught then… much more than during other stages of the development/release cycle.
Again, this is all understood and accepted as a fact of life. I’ll work from there on.
Thanks a lot Aligorith for your input. I get from it a much wider picture that what I could imagine from my specialized experience. You’ve also made me realize that I’ll need to learn more about SVN use, something I gathered from Theeth intervention too. That won’t be much of a problem now that I know.
As to using the SVN the fact is that I actually use it although differently than what you just described. For example I did use the Normal Map baking tool for quite some time before it was in any official release. There was no problem to it since the output was an image file, not a .blend file. I can use that image as much and as freely as it can be, just as a studio can use some footage once it has been rendered. In some other cases I will use a modeling tool that may of may not make it into any release. The trick is to not save it permanently with the SVN version of the moment, but to import it in one of my libraries and in a state that will never be a problem. An object that is just vertices, edges and faces won’t, ever.
But there are numerous other cases when I must be very careful. For example when you introduced a whole set of new constraints, I had to resist with all my will to the temptation of using them all, until I was sure that they were in a stable state. The most obvious example may be Python scripts. Nothing is more threatened of obsolescence even though the API has been very stable, minus constant addition, for quite some time, even years now. Soon enough though it is going to change, with 2.50 if the intention to stick to the data structure and functions of Blender’s core code is pursued ; also there may be a desire to use Python 3.0, that I haven’t heard but it is possible and that would break compatibility of the scripts quite a bit.
Anyway, I hope that everyone who had the patience, will or pure virtue to read this far understands that my desire for the most stability possible stems from necessity. I’ll apply everything I am learning reading you all to that goal.
