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
_______________________________________________
Mailing list: https://launchpad.net/~openerp-community-leaders
Post to : openerp-community-leaders@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openerp-community-leaders
More help : https://help.launchpad.net/ListHelp
