This whole discussion seems to revolve around power, who has it, who
wants it and which is better for the project on the long and short term.
To simplify the discussion I will refer to the *trunk* if we're talking
about long term and *stable* if we are talking about short term goals.
Who has power on both *trunk* and *stable* at this point ?
* Only Tiny
o because they need to exert quality control to avoid
regressions
o to maintain (at times seemingly random) direction
Who wants more control over *trunk* ?
* "consultant/thinker" members
o they want to steer to implement a bigger picture
Who wants more control over *stable* ?
* implementing members
o to implement fixes which hinder deployment with a client
Leaving out all the technical part of this discussion (VCS, organizing,
debugging, testing tools) it just seems the current way of splitting
*stable* and *trunk* isn't sufficient. I'd rather propose these branches:
*release*
This branch is the currently released stable version, only Tiny would
have commit rights
*bugfix
*This branch is a sub-branch of the *release* branch where the community
would apply bugfixes which hinder deployment
Community members should have commit rights here but the idea is to have
it really stable, when new versions are released in the *release* branch
we could have a *bugfix-5.0.6* or similar branch, these branches would
stay under development until for example release has reached version
5.0.8, that way you will still be able to revert to slightly older
branches when a new branch is breaking something. So no more than 2
*bugfix* branches would be active at the same time
*future*
This branch would be similar to the current trunk, all backwards
breaking stuff should be settled here until it's ready for release. Tiny
themselves should manage making a release from this future branch, also
only Tiny has commit rights. They should allow community submittals here
a lot easier than compared to the *release* branch.
Any developer / "consultant/thinker" member should branch off of
*future* to develop their new (long term) work, if Tiny then accepts
these changes in the *future* and if the feature is very desired effort
could begin to backport it to *release* this would the the developing
member his responsibility.
Possibly he would create a sub-branch of the *release* and propose a
merge when the same functionality has been reached as the merge that was
accepted into *future*
This idea is still very basic, but the way currently *stable* and
*trunk* are used just seems so wrong to me, there are no maintenance
branches or anything at this point.
Regards,
Niels 'Red15' Huylebroeck
ps, in case this mail appears more than once on the mailing, my
sincere apologies, launchpad does not seem to accept mail unless it's
an exact match (no +extensions...)
_______________________________________________
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
