← Back to team overview

openerp-community-leaders team mailing list archive

Re: Simple things we need from Tiny for better bug planning/management

 

P. Christeas wrote:
Trying to control access to a limited set of branches, and then endlessly discussing about what each branch should contain, is the same plague that Subversion had introduced in OSS projects.
That plague is not technical nor VCS bound, it's just the fact that Tiny wants and needs absolute control over the result.
I think handing over control of your project to the crowd that uses it 
is a hard step to make, usually only reserved for when maintaining 
coders retire from the project, even then this amount of control is 
usually reserved for the next head maintainer.
Considering the fact that the only option DVCS brings to the table is 
the ability to branch off your own version it never solved the "problem" 
of limiting access to ensure stable releases. Sadly the only option that 
remains is to "branch" off and do your changes on a separate image of 
the software.
This in itself isn't a problem in my opinion, but the problem is getting 
the changes back, as the person who wrote the new features is probably 
best capable of integrating it back to the stable version, but he does 
not have access so the job of re-integrating the changes falls on 
someone who hopefully can foresee any regressions that might occur.
As soon as the regression is in the stable software it would become 
something that the original author of the changes would probably see 
quite easily.
I take for example the case where I re-factored the Aging Partner 
Balance, as I needed it for a customer I rewrote the report generation 
process so it would run faster and was able to print when you had more 
than 200 customers. However when rewriting it both time and 
functionality required differed from the original report. So the Aging 
Partner Balance report was broken when you went into the future (or was 
it the past ?) When this regression came to my attention I immediately 
noticed it was because of my re-factoring, so I just pointed out I had 
only tested it in the other time direction and the problem was quite 
easily fixed.
In the end, would the fact that this regression took place be worth it 
that I just gave up trying to integrate the faster report ? No, the 
regression was unfortunate but as I was only asked to make the Aging 
Partner Balance work the way we had expected to and time/money was limited.
However after this regression the problem was soon fixed because of 2 
important reasons in my opinion :
* Integration was fast, I wrote it and it was accepted within 2 days or so
* Regression detection was fast.

If neither of these 2 reasons where there the whole ordeal could have been a lot worse, either I would give up trying to return my changes to stable branch, resulting in a non-production ready Aging Partner Balance
Or if the regression took too long to detect I would not remember that I 
could have been my change that broke the stable.
So speedy releases would benefit everyone in my opinion.

To conclude:
Opensource works because it should have a fast turnaround, release early, release often, repeat that mantra and realize it's full potential.
Regards,
Niels 'Red15' Huylebroeck



Follow ups

References