openerp-community-leaders team mailing list archive

[Niels Huylebroeck <red15nls@xxxxxxxxx>]

Jan Verlaan - Veritos wrote:
>  i think you hit with your doubts the hart of this discussion. At least 
several community members I spoke in the Netherlands have the same 
doubts together with most of the others here in the mailinglist.
>  The rest of the discussion held is about a possible solution to 
overcome these doubts.
I think to maintain a positive attitude it would be more constructive to 
talk about possible fixes instead of repeating the problems, it's true 
we have to realize what problems there are at this point but it's not 
worth repeating them over and over.

Lets get some technical talk going on the topic of maintaining a 
"community" branch.
>  I propose to discus further on the work involved to establish a 
separated branch, what are the pro and cons, what rules we want to 
introduce in maintaining a branch.
>  As mentioned in previous mails when we do branch-off,  I expect that 
Tiny will not commit many more updates/fixes to their stable branch and 
we will stand more or less alone. I guess they will merge our bugfixes 
in there own private branch and trunk only. Why would Tiny put efforts 
in the stable branch when the  community branch-off and doesn't use it?
Tiny will still have a public interest in portraying their stable branch 
and supporting it, thus there will still be effort in it, maybe not as 
much as there is now but that's partly the idea of why we need a 
community branch: to create an actively developed branch which tiny can 
cherrypick fixes from.

I do not see why Tiny would stop posting / fixing their public branch, 
in fact they would have a lot less to worry about if they can just 
"steal" their fixes from our community branch and the community will 
"steal" the bugfixes that Tiny implemented.

This brings me to a point where I would have to say our number 1 
priority would have to be staying compatible with the Tiny stable 
branch, meaning if they did a refactoring of a function in a way that 
isn't compatible with our implementation (or dependent modules) we would 
have to refactor our work to match their work, basically it would mean 
we would have to take a tiny step backwards.

I guess there will sooner or later be such a change and people are 
likely to feel like they are stepped on their toes, but going 
all-stand-alone on this community branch sounds like the worst idea ever 
to me, since from that moment on you can call our effort a fork...

The idea is to keep the possibilities open to share code between both 
branches as easily as possible, without this both the branches will divert.

I realize that bending our community branch to match the Tiny branch 
will upset some people as it would appear Tiny would still maintain 
grasp over this branch, but look at it from the other way : if the 
community branch implements something that's well executed, why would 
they want to rewrite it, it would be much easier for them to just 
integrate our version.

The biggest issue with duplicated efforts is in communication, if Tiny 
doesn't know what we're developing and we don't know what they're 
developing things are heading for a collision course. So all we would 
need from Tiny is someone who would notify us what kind of functionality 
Tiny is developing, we don't need to be able to watch every step of the 
way while it's developing, but we would have to get an idea of what it 
is going to do/change. That way we can anticipate and also avoid 
duplicated effort.

From our side it would mean we would have to find a very clear way to 
inform Tiny of our development projects, it means that you'd have to at 
least have a post on some mailinglist or something stating your 
intentioned work/changes. This also helps us with finding origins of 
regressions, as each person would be "liable" for their changes and 
having this "central directory" allows people to easily contact and 
coordinate efforts.

Regards,
Niels 'Red15' Huylebroeck