ADempiere ERP Business Suite

Hi developers, we need to start stating this post is result of a team work between Heng Sin Low, Teo Sarca and Carlos Ruiz.

SOME HISTORY:

When we started adempiere there was a big issue to solve - we had very few developers.
So, we have had open doors for everyone - i.e. with one line bug fix you could obtain commit permissions on trunk.
Then we saw that was problematic - having newbies working in trunk without noticing what they're breaking.
So we tried a mentor strategy with two layers - trying to give more knowledge to newbies, and trying to have guaranteed peer review.
In some way this strategy worked - newbies learned asking to oldies.
In other way the strategy failed - the peer review was not implemented.

CURRENT SITUATION:

So, we have this situation now:
- a trunk with 79 registered developers with commit permissions (good!)
- developer base kept growing (really good!)
- contributions arriving at a pace that is over our capacity of review (not so good)
- peer review is not guaranteed (bad!)
- we don't have unit testings - so every day is more frequent that a commit breaks something and it pass unnoticed (really bad!)
- we don't have enough modularity to work some things isolated from trunk (something with we still need to live for a while)

Well - that's a good problem to solve - having too many resources and trying to organize the quality control.

On the other hand - we have established in this project that we allow:
- experimental branches with lazy rules
- "private" branches - ruled by the owner (team or developer)
- and we have the trunk with 79 potential developer and some rules established - *but hard to enforce in real life*

Well, trying to bring solutions for the current situation - Heng Sin Low, Teo Sarca and Carlos Ruiz met and agreed to create a "private" branch and put some strict rules on it.

***********
ABOUT NEW BRANCH:

So, we're planning to make this movement in immediate future (this is not subject to voting, is just a decision of a team to work in a "private" branch with own rules):
- we're going to create a branch (name still not defined - suggestions welcome)
- we're going to work on such branch, initially just the three of us - the number of committers of this branch will be very limited (still not decided the number)
- and we're planning to write some strict rules about gaining and losing commit permissions on this branch
- gaining commit permissions on this branch initially will be based on merits and just voted by branch committers

We're going to write some rules in order to allow feature requests to reach the new branch.
Initially we think that to reach new branch things must be contributed in a patch format in trackers. Depending on the rules and quality of trunk - it's possible that we can consider some process to integrate things passing first via trunk.

Further actions (non-immediate) on this new branch will be:
- Inventory of things that have changed in core respective to 340s
- testing cases on those things and fix or revert potential backward compatibility problems
- evaluate implement SaaS strategy on seed to demarcate specific limits in modules - and allow enabling/disabling whole modules
- isolate new modules (creating flags or parameters to keep backward compatibility)
- freeze this branch
- make a release (name to be defined) after we finish all the fixings and testings

***********
ABOUT TRUNK:

Well - trunk has some rules actually - but every day is harder to enforce them.

We can just SUGGEST some rules for trunk (asking for votation if you want).
And if you like them we can help to enforce them - but what we need to try is that rules are so clear that we don't need to keep fighting for them to be enforced.

In past days we have written some important rules in these forums, but additionally we think that we need to set these:
- all new features entering trunk must be tested first in an experimental / project / task branch
- to integrate in trunk it must be complete - documented - testeable
- it must support oracle and postgres and pl/java
- it must support java 5 and java 6
About code it must have:
- proper indentation
- proper usage of variable names
- all comments and variables in english
- no duplicated code
- using constants or MSysConfig instead of hardcoded things

As always: Bug fixing can be done directly - it needs to be straight

***********
ABOUT LIBERO STABILIZATION:

Trying to stabilize libero in trunk is a problem because there are more things entering and unstabilizing the whole picture (i.e. posterita integration)

Our SUGGESTION is to open a specific branch with specific goal for libero stabilization, owned and ruled by Victor and Teo.
This branch can be more open for developers - but still we suggest to set some QA rules.

Specially we recommend this branch will allow just commits towards stabilization goal and manufacturing related additions, nothing else must be added or changed there.

Anyways, we encourage to define the plan for libero stabilization - this is - to have detailed tasks in order to ease the way for contributors wanting to help on this goal.

***********
ABOUT EXPERIMENTAL AND OTHER BRANCHES:

We consider that "experimental" branch is not very good approach, because it lacks of specific goal.
Maybe if ruled or defined a goal it can serve for a purpose.

Instead we encourage to create branches with specific goals, this is for specific projects, tasks, teamwork, feature request, etc.

As we're organizing ourselves with some rules to obtain quality - we encourage others to make the same - maybe in future we can set up several teams working in parallel goals.

The rule in this case could be that things in branches need to pass correctly to trunk, this is, following all rules suggested for trunk.


Regards,

Heng Sin Low, Teo Sarca, Carlos Ruiz

Congratulations Gentlemen,

I understand the importance of this decision, and maintain as I always have that the absolute highest priority must be stability.

I hope that once the branch rules are established and elucidated we can adopt them for the betterment of the whole project

From a stable foundation and clear direction we can grow exponentially.

Thanks to the three of you for your outstanding service. Please let us know of any way that we can help.

Best Regards,

Joel Stangeland

Low, Teo and Carlos,

I'm sorry to see you feel compelled to go down this path again, as it seems likely that most serious developers will attempt to follow you (if you let them) because without doubt you are three of the most prolific contributors to the project. (It also seems likely that the trunk will again be abandoned unless you choose to contribute your private branch work back to trunk.)

Can we not first attempt to impose some formal rules on trunk? When it was decided that stable branch should become trunk there was a consensus that there would be restrictions placed on committing to it. I believe a large part of the problem lies in the informal definition of those rules. Perhaps I could draft a set of rules that could be reviewed and voted on (including rules for voting!) if that would help.

Regards,

Paul

Hello private team,

this is the worst that can happen to open source project. Divide.

As bigger team we ca fix more things. Don't you see that Manufacturing is more stable now then i was before?
Idea is to work together not to divide us.

Trifon

IMHO working on branches is always good unless there is branch which have the same idea/goal/manner as another one since it will deconcentrate/discrete the focus on the mainstream branch.

I understand _some_ of the "Praetorian"'s concerns however this is not the way to go IMO -there's a Persian saying: "Trying to fix someone's eyebrow, you happen to blind his eyes." I would recommend everybody to read SVN book published freely on SVN project website to get a deep grasp of how branches and trunk work together -in a SVN managed project.

I'd like to add that there is _no_ emperor to guard, only the _people_.

Bahman

PQPQA: Populusque Populusque ADempieranus

Sorry, small typo:
"Praetorian"'s should be "Praetorians"'

Bahman

Hi all,

I fail to see how splitting the developers helps anything... if everyone is working on different branches then the issues of integration of a bug fixed in one but not the other is even greater. Ultimately it means we all have less eyes.

Branches should be used as a place of collaboration if more then one contributor wish to work together on specific enhancement/project ... but, assuming it was successful, it must then always be merged back to trunk.

I would have a very strong opinion that any such new branch created as suggested here cannot make binary releases of Adempiere, but must merge back to trunk to be released. Anything else would mean a fork and a take over of the bazaar project itself.

Contributors are more than people who commit code. They are they people who report bugs, the people who make suggestions for new features, they are people who offer support in forums and irc and so increase the community & marketplace size out. Those who commit code should remember they are only part of bigger picture. These days I have no Adempiere work so I do not find and fix bugs as part of my daily work ... I could do but since I must work on other things than Adempiere I only have a couple of hours a day and there are plenty of developers here, so I try and help others in the forums & irc and spread the word of Adempiere. I do not believe my contribution is any less than those committing code (well it is in that it's most liekly les tiem - but two hours helping equals two ours coding!) ! I think all “Contributors” should have an equal say and an equal vote!

It is disappointing to see 15k downloads a month and confirmed 125 odd confirmed implementations and then see how many bugs fixes are submitted. Surely all those who have implemented have support contracts and are required to fix many of these bugs under those contracts? I guess many act like Compiere partners of old and hope their private repository is more stable and offers them an advantage?

It is said that the free for all trunk was a total failure, but I'm not so sure. It allowed many to work on Libero together and while Libero wasn't perfect it was enough to make it look somewhat stable and so it was decided to merge selected enhancements back to stable. This to my understanding was always supposed to be how such a scenario would work... so, in that respect, it seems like it was was somewhat successful!? In such a scenario Trunk was never intended be stable ... but aspects would be and, as they matured, be extracted and merged with Stable. That was my understanding of the purpose of open Trunk. I think it is naive to hope that the integration of a huge piece of work like Libero was would be introduced with no errors.

A not so happy community member ...

Colin

Hi all:

Colin summed it up my feelings in this sentence:

"any such new branch created as suggested here cannot make binary releases of Adempiere, but must merge back to trunk to be released. Anything else would mean a fork and a take over of the bazaar project itself"

Congratulations gentlemans! we are getting stronger! in the immediate future we will have Adempiere distributions:

HenTeCar's Adempiere 1.0 release based on Adempiere vanilla 3.4?
Known as the bullet proof distribution. No new functionality here. Just bug fixing. Using linux distributions equivalent will be the Debian or Slackware

Victim's Adempiere 1.0 release based on 3.52
Another Adempiere distribution created by Victor and Tim. It is less stable than HenteCar's Adempiere but with some other features bleeding edge distribution. Includes manufacturing, payroll. Something like Fedora and Ubuntu.

Trifon's Adempiere 1.0 release based on 3.4 + 3.52
A mix between Victim's Adempiere and HenTecar's plus a point of sale and replication functionality not included in any of those versions. Something like PCLinuxOS.

Colmoy's Adempiere 1.0 release based on HenTeCar's Adempiere 1.0 with elements borrowed from Victim's and Trifons. Distribution focused on the customer than in the developers technical debate. Something like Mandriva or OpenSuse.

Of course they are not compatible between them. You can't go back and forth between them. If you want to jump to the other you have to start over. What a great scenario!

So if a question in the forums pops up for HenTeCars Adempiere that means they are the only one responsibles for answering them? Or second class Ademperians should help them?

I wonder how this project would have evolved since the very beggnining , with only those three persons.

After all you are now a single group not open to public votation, you are more like a private, selected group that for accident are reunited around Adempiere.

Another not so happy Adempiere lurker-community-member.

moyses

Hello,

our company can't afford to test two versions of Adempiere at the same time, so we will have to decide which version to follow. I believe others will face the same decision. We have in our young Adempiere history a similar case: the former trunk which had the Libero functionalities starved because most of us flocked to "stable".

Personally, I suppose we would work with and support the new, "private" branch, mainly because it is the way development should occur. If -as I strongly believe- others think similar and draw the same conclusions as we do, this "private" branch will sooner than later become the "de facto" Adempiere trunk.

Which leads us to people. In my opinion, though it maybe great differences of opinion now, there are more people than Carlos, Low and Teo who should be part of the Adempiere development team, being Trifon and Victor the first ones who come to my mind.

This pledge is to Carlos, Low and Teo to make efforts to integrate them (and others who may have won merits in the past) as quickly as possible into this "private" branch and call it "trunk", as far as the rules are accepted. It is only fair.

I see the actual discussion as a big chance to become more professional. and I strongly believe that developing under "best pratices" and "common sense rules" will give Adempiere a still greater push than as with the actual behavior.

Best regards,
Mario Calderon

Hello,

After reading all the messages, It's easy to sense that this will make some people go away really fast. I believe this is really bad and against the purpose of this project.

I strongly agree with everyone that are trying to suggest the approach to use trunk as the main dev.

And I also strongly agree with the view that the three of you(Heng Sin Low, Teo Sarca, Carlos Ruiz ) have regarding the lack of procedure on how to do things, and the big confusion that this is starting to generate.

I think this is a chance that the ADempiere community has to prove that we're made of serious and professional people that are here to achieve a single and main goal, a really great project. And to do this, I believe all should go the way it always went, by voting.

I would like to suggest voting for :

The main developers that will have access to trunk - I guess this would include only the one's with great experience and proven to be helpful

Someone or a group of reviewers of some kind - This would be the ones that are responsible for gathering the community help and passing over to the main developers in a proper way. I also think that the community would be able to come up with a documentation for standards on how to send things and how to validate them. As someone starts to contribute more and more, there should be another vote, to check if he or she should be moved to the main commiters group; As a small suggestion on how this could work, today I've posted a bug I found, and I was able to correct it myself, and I tested it. Therefore, in my bug post, I tried to describe as best as I could how I fixed it and why, so that someone with commit access(the reviewers group) can post it.

I don't think it will be easy, I do think that some people will still try to move away from the project.
But I think that most of us would benefit from it and be able to keep single goals for release versions, so that we won't have a situation as chaotic as the one moyses described.

And let's never forget, that, as Colin Rooney has nicely said, there's a lot of people helping the community in different ways. It may be a little bit harder to measure, but we all know that it's there and it helps this project to be gaining visibility in the whole market.

I was just trying to add my thoughts and reinforce the one's that I strongly agree with. I have faith that this community will prove itself strong again and we'll come out of this with a great solution that most people will be comfortable with, and ADempiere will continue to grow.

Best Regards,

Alvaro Montenegro.

Hi,

i don't think splitting up power will help project.
it will slow down development and will confuse users.

more branches will generate overhead.

private branches for new big features would be good in future, but they have to be temporary and have to disapear after integration into main development tree.


Regards

Dominik

Hi Dear Community

Any people is free the to do, so if this developers want to create your private or restrictive branch,is ok , BUT a project for a ERP software does not only need developers if this is possible then any developer would create an ERP,Then I do not see some future with Carlos approach and your private team.

When worked as business consultant for a proprietary ERP I saw that the developer try get the solution for any issue writing code, but this do not is approach right.

Then we need of good developers and good people with knowledge in business process , multiples areas (Accounting, Distribution, Manufacturing, etc) and best practices of the industry.



So I think that the people do not is the issue (Red1, Trifon, Mike, Victor), The issue is that the development process for developers this community do not is clear, or can be that it only is clear in the mind the Carlos , Low , Teo. but the development methodology or the development should be clear for any developer even for a newbie developer.

we can corroborate this with some questions.
What are best practices for commit in SVN?
What is the Development methodology that we using in ADempiere?
What are the Coding Standards for write java class in ADempiere?
What is the Coding Style that the Developer should using in ADempiere?
What are the Test Units that a developer need to make for test you new functionality in ADempiere?
What is the policy for create documentation for new functionally in ADempiere?
What is the process the design new functionality?
What is the process for implementing de solution?
What is the process for Developer Tests?
What is the process for Run the Tests?
What is the QA process?
how we can validate the build?

So , I think the unique way to go for get a professional development is we need time for build our methodology or adopting some, this way any Developer have the knowledge for build any development based in the ADempiere Best Practices.

But I Think that Carlos , Low, Teo have a good issue here, the issue how we can build an ADempiere stable, I think the is only can get when we have the documented QA process. so if we follow the process then we will have an ADempiere stable.

Teo , Trifon and me chatted for some time about What happen with Trunk , Libero project and the stabilization.

We have the following agreement:

1.- The main goal now for we are get an ADempiere stable version with manufacturing.
2.- Create basic infrastructure for ADM(ADempiere Development Methodology )
3.- Create the ABP(ADempiere Best Practices)
4.- We need to Frozen the current trunk for concentrate in work in the stabilization of Libero. (we only accept commits for stabilization of Libero and bug fix but this need complaint with the ADM and ABP)
5.- Work for get the goal based in ADM and ABP
6.- Release a stable version.
7.- Documentation for new functionality.

I think that we should to do in trunk repository, But Teo want go a Libero branch, so here I ask the community what do you think?

Well, like we can see exist a lot of work where we can start , so any help or suggestion is welcome (remember we need be productive quickly).

I create a new wiki page for start the work for define our ADM and ABP here:

http://www.adempiere.com/wiki/index.php/ADempiere_Best_Practices

Please if you have some suggestion please adding in the suggestion and question section.

I think we can adopting Eclipse Process Framework Project (EPF) methodology with some adjust for ADempiere.

http://www.eclipse.org/projects/project_summary.php?projectid=technology.epf
http://www.eclipse.org/downloads/download.php?file=/technology/epf/general/EPFC_10/Eclipse%20Process%20Framework%20Composer%201.0.html&r=1

What do you think?

Kind regards.
Victor Perez
http://www.e-evolution.com











What is the process for

I am a muslim fundamentalist. It is fundamental in my faith that:

1) One do not say what he does not do.

2) One do not kill innocent women, children, old folks and not even green trees <-- terrorism not allowed at all.

3) Go with the right intention.

Here i know Carlos Ruiz for a long time and i go with his right intentions. His intention is clear - which is for trunk stability, albeit bazaar's destabilizing openness in attendance.

Why he says 'no vote needed' is a mystery. He need not say that. He is the Head of PMC. He has some authority to propose or enact rules in good faith.

Also he has name 2 other Mahagurus in the project - Teo and Heng Sin. Again, their intentions are coded and cannot be prejudged. But to mention as if it was pre-counciled gives people wrong idea about a scheme that we vs they should not know.

About 'non-vote' ruling, i like to ask, "What is it to fear from this bazaar?' Who? Colin? Victor? Karsten? me? ( i left names out cos i m not sure which side they are on and i respect their choice, whatever it may be).

Take Colin for instance. We can see where he stands. Which is not far away. His stand is merely that his vote be counted on and he be considered as equal to a coder for all his forum and subject matter help as well as some coding checks, debug and review. Should be easy to comply. Ok, we throw Colin a coin and say, 'join in brother'.

What will Colin say? "No branch for you Carlos!". Wouldnt he at least listen to your fine arguments? You do have fine arguments here.

You would have persuaded Colin easily with 2 lines to stand in with you. And he could even influenced this other supporter he just gained from his words.

The next time you have an interesting plot at least BCC me. :-)

> Take Colin for instance. We can see where he stands. Which is not far away.
Actually I think I stand very far away!

>His stand is merely that his vote be counted on
No!
I only used myself as an example.
My issue is that in a COMMUNITY project some INDIVIDUALS cannot say we taking control, we don't care what you think, if you don't like it take a running jump! The COMMUNITY must decide!

This is very fundamental to me! The baazar cannot be based on a privately controlled branch - otherwise we arejust saying we are CompiereII but we are different because our dictators are benevolent. The problem is many start benevolent but change. So the safest (if perhaps less efficient) way is is not to place the power in INDIVIDUALS but in COMMUNITY as a whole.

Now a private branch that is merged back with the project is perfectly ok. But a private branch cannot be released as "Adempiere"!

I will not be following to a private branch.

Colin

Colin,
For the sake of some light hearted taking up of a shoe, let me say that there are fundamental differences with Compiere here.

1) Compiere does not allow you commit rights. Here we determine commit rights. Member branches aside.

2) Compiere won't be handing you release rights either. But then does it matter if i cannot release from Compiere? A private branch can make a release does not stop another branch from making a separate release. In ADempiere i have made solo releases such as:

a) AVA release without respecting whether its official or still unstable build.
b) Binary Snapshot releases

3) Compiere does not allow bug fixes. All our branches die for bug fixes.

4) You cannot experiment there but here we can. Albeit more branches.

I think its safe to have a private branch and see how it goes. The name does not matter, even though it should be called stable anyway. So ppl know good codes only will enter it.

The other branches which for all intents/purposes i intend to maintain experimental only and not wanting anyone to regard it further than something very twiggy.

But the experimental for your info has zero compile error, cos i brush my teeth each morning watching it compile. And i run it from time to time. And i synch any changes i find in trunk to it.

So now i switch to stable branch.

I think you are just been a sensitive twig. :-)

In the bazaar, i (speaking for myself) have always advocate that we must tolerate a broad range of behaviour. Some may be extreme. Some may be strict.

Your stature is also not impaired. You can still draw analysis from any branch and write your say on subject matter and framework.

I think we must break the branch i mean borders once and for all. Ireland has always been free *sniggers*

red1

I have to agree with Colin and Victor in this topic so far.

I think that creating a private branch is counter intuitive and counter productive to the spirit of the project and the community. I think there should be a stable branch, where the rules are well defined. As a starting point I would suggest no new functionality enters stable except migration from a release after a defined period of time. Only bug fixes should enter the stable. This is a way to ensure stable is always stable. This also prevents stable becoming another (possibly competitive) branch to trunk. Rules should exist for trunk also, and I see trunk entering different 'states' where different sets of rules apply (like phases in a recurring game). There will be a phase of relaxed rules where new functionality is added and then a phase of bug fixing and maturation leading up to new releases. We could put a colour coding system in place to indicate at what 'threat' level the trunk is at.

So I urge all of us to respect the community in all of the ways people contribute, and accept that this will always cause some pain - but no individual is bigger than the community.

I believe Victor still has the lead at the moment and I look forward to seeing more eyeballs on his work. I would vote for Victor to be able to commit his work to trunk after a a new stable branch snapshot has been created (if necessary).

Regards,

Mike

red1,

>Here we determine commit rights.
Ah but that is the point WE don't!

> A private branch can make a release does not stop another branch from making a separate release.
Well if that is the case then we really are heading into the farcial world described by moyses in his post!
With respect, releasing something like an AVA is completely different that is not the same as releasing Adempiere ver. X.

> I think its safe to have a private branch and see how it goes.
As I say ... a private branch is ok. To develop a new functionality in a stable environment say. But to move the main project to a private branch is not ok... IMO.

> You can still draw analysis from any branch and write your say on subject matter and framework.
yes but this is "Do I want to anymore or not" matter

colin

Good post Victor.

A much more productive approach than "It's my ball and you can't play".

colin

Hi all,

Regarding Victor post:
First of all, i agree with Victor we need all these procedures and conventions but my entire discussion with Victor was about libero branch. So all my opinions from that discussion are related to that branch.

------------------------------------------------------------------------
Regarding Trifon post which sounded totally funny from a guy that was asked a lot of time to come and contribute in trunk and to not isolate in a private branch.
Sometimes argued that we contribute to trunk if a client pays you.
Same here, my clients and my possible clients want stability. So how can I contribute that ? ;)

------------------------------------------------------------------------
Regarding other felling i have some questions:
* Why do you call it private branch. Has anybody said that will be hosted on our company servers ? No won't be private. Any company can use it, test it, report on it.

* it's not the first time when a new branch is opened; a lot of developers/companies from this community had "private" branches hosted on ADempiere. They use that branches to prepare for trunk integration or to share a customization with a customer. Same thing was proposed here: share stability.

* don't forget that ADempiere has 79 developers with commit rights. They were voted and accepted
democratically by community. What is the problem if 3 of them want to focus on stability branch? And thinking again, there are not only 3 developers but 3 companies with more people behind which advice and make specifications, develop with company developers and test inside company using company resources. After this code is contributed back and eagerly waiting to somebody to mess all, fair ? ;)

* regarding Colin: nobody excluded Colin from anything. As I know Colin rarely commits. He is an excellent functional consultant and he helped ADempiere a lot. I am not doubt Colin high quality contributions (thanks again Colin), but here we talk about code quality and stability. And I think that Colins wants to be a consultant in a more stable environment ;) . Regarding all those which help this project a lot, but they are not developers, i think they want to do this with a much more stable and predictable system.

* it not about ignoring community and it's pointless to say that i have ignored community

* comparation with Compiere it's far out because we are not in same situation.


------------------------------------------------------------------------
Gentlemen i think we need to calm down a little and to revise the reason of us being here in this community.
I think that best approach is if we group around targets and interests. That the only way we can bring productivity and satisfaction to us, to our company and to our clients.
But first, maybe it worth that people express these objectives. Here are our company's (ARHIPAC) focus and ways to contribute:
* have ADempiere stable; can contribute with development & testing
* have Libero stable and complete; can contribute with developement & testing

So what's yours ?

Best regards,
Teo Sarca - http://www.arhipac.ro

Teo,
> use that branches to prepare for trunk integration
If this is the purpose then there is no issue!
The issue for me is IF the official release comes from there then it is to me.

re: colin (me)
Just to be clear - I wear two hats here.
One for Colin that is, a developer (not a functional consultant! but when you spend more than 20 years developing you pick up some functional understanding!), looking for customers to implement Adempiere. But, as I said previously, alas I have not been so successful with Adempiere recently. When I am working on an implementation and I find bugs or make enhancements I submit them. Now, I could do that anyway but there seems to be plenty of developers able to do that so I, with the shorter time (as I must work on other things), help in other ways that I think will also be beneficial.

The other hat I wear is Colin as a Council member who is always looking to protect the project & the community from changes that I think will not be to its benefit. It is with this hat on that I say the central code that is released must not be kept in a private branch.

And I do not say you (or Carlos or Heng Sin) any of the others have ignored the community! To date you have been shinning examples!

As I say for me it's all in the details; if as you say the branch is to prepare & stabilize for trunk integration then I have no issue.

colin

Hi Teo:

Well Carlos was the first to call it a "private" branch.

Well, trying to bring solutions for the current situation - Heng Sin Low, Teo
Sarca and Carlos Ruiz met and agreed to create a "private" branch and put some
strict rules on it.

No won't be private. Any company can use it, test it, report on it. Ummm this sentence sounds very much like old Compiere! Actually you can do the same with Compiere what's the difference?


* it's not the first time when a new branch is opened; a lot of developers/companies from this community had "private" branches hosted on ADempiere. They use that branches to prepare for trunk integration or to share a customization with a customer. Same thing was proposed here: share stability.

Here we some big differences compared to the previous private branches. Please clarify, are you going to integrate it to trunk? I have not seen others creating binaries distributions from "private" branches, that's something new.

If there are three companies behind this and everything is about code why not simply open a new project? Why not create the HenTeCar ERP? Under another name if you open a new sf project we would be able to test, use and report.
In the end you also have people doing specifications. So what's the point here? Feature request also will need approval from the trilogy, that means only three persons/companies decides what's worth and what is not.

I do believe that you are ignoring the community. Three persons/company have decided to create a new Binary Distribution under the project Adempiere with no votation or asking the community if they agree or not. Oh! I get it! you accept name suggestions but no one is allowed to vote in the naming decision. Thats Great!

This so called "Strategy Shift" is more like a takeover, betting that people will follow them and after that they will end up ruling the whole project. Compiere use to be owned by JJ. Now Adempiere will be owned by three guys/companies?


moyses

Colin,

> use that branches to prepare for trunk integration
>>>If this is the purpose then there is no issue!
>>>The issue for me is IF the official release comes from there then it is to me.

I think that we are already at the point where we're trying to integrate something to trunk, and that's creating all the headache. Mainly because if we have people trying to bring new things everyday to trunk, it'll never be stabilized. I think that we should all always agree on a time were trunk will be strictly controlled for Bug Fixes and Stabilization only. I just don't see any problem on voting as a community on who should be the "guards" who will decide what should pass and what shall not.

Regarding all the developer/functional guy discussion. We must always work as a team...most of the times, as a developer, we try to make things better and most of the times we're not able to test if this broke something else...so a functional is always good to help in this matter...and also, to help us finding better paths on how to do things in a very generic way that would be easy to configure during a specific implementation.

moyses,

It does not seem like that's what they're trying to achieve. If that was the case, I don't think they would have created this thread, they would just do whatever they wanted.

As red1 said, let's go with the "good intentions". It's very hard to understand what are the intentions of someone we've never meet face to face, and specially when we're dealing with a scenario where that guy is from an entirely different culture....language itself is a big barrier, English may be used for us to communicate, but we're all used to some words because of our culture, and to other cultures, the way we put them, it may sound bad....so I think that we should always try to "translate" the message into what we think is a nice way of saying things.

In this scenario, all I see is a community trying to decide something very hard....how do we stop new contributions to stabilize something, without making people upset. And "Heng Sin Low, Teo Sarca, Carlos Ruiz
" all seemed to be willing to "take the bullet". If most of us didn't like their proposal, I thing we should try to discuss another way of doing things in a way that we can get them to agree or even to add things to our proposal so that at least most of the community can agree on the same course of action.

Colin and guys,
>Do I want to anymore or not?
You have the best of both worlds - been Ofbiz and ADempiere conversant. I envy you already. Your input is still vital and academic and should not be soiled by the friendly fire of the day.

We did not have it this good since Compiere. Everyday and every commit is a miracle. Of course there is a dark side of occasional reverts.

IMHO you must not take Carlos' words in english sense. If he was schooled in Ireland, his words will come over more like Mike Judd's. It does not matter. What matters is his intent and direction it can lead to.

No one is advocating a fork here. A more controlled branch is what he seems to try to say it in spanish. Let him work out the details.

At the moment we have no reason not to trust his judgement. Only he has strong sentiments which is none of my care, as long as he does not lose his mind.

Your concerns are valid only if the project is been closed. In what way can it be? Good tested code are still accepted. I know it cos i did it on a daily basis. Only and until truly happens we sound the alarm.

What Teo said elsewhere makes sense in this practical context of the project. I do not for one see him having any scheme at all other than wanting a stable trunk to work from, knowing him from day 1.

We must respect the guardians of the trunk that has found themselves elevated to that positions by merit and evolution of the project. (I wonder if anyone remembers that about someone called the leader around here)

Take Heng Sin for instance. He was a new entrant some days after our project formation. But he has unceasingly done brilliant work and so he is now the Commit Head. His views must be sought first. So far he has never made an untoward move against the project.

So i can say for Carlos' sake. Again he has his temper, but don't we now do too? I rather deal with an angry honest man than a cool dubious one.

We all have our grave limitations be it in our skills and leadership. I have been on the lookout for a good candidate but has never found anyone who accepts to take the lead.

Like the famous saying goes:

"Be a good leader. If you cannot be a good leader, then be a good follower. If you cannot be a good follower, then get out of the way".

Here, getting out of the way is meant in a strangely wise sense. We been getting out of the way of the devils and at their devices they done brilliantly.

Out project rankings is the top in its categories. Others are marvelling at how the hell we did it. One of them could be Jorg Janke, who predicted that these 15 or so freelance developers would never last 3 months. Hah! Wrong! We lasted beyond, let me count, 27 months.

I for one has often get out of the way of bazaar. We as high Council can do that as our wisest but subtle gestures towards something we love. Rmember the strange promise of GPL and SourceForge. Miracles can happen fast. Albeit one day when we are much older and see new generations to come, they will have to look at us and marvel, how did we hold this fort.

If you are around longer than i, then say this:

"You have no idea".

Today lets leave this sincere controlled branch alone. Let's give it a benefit of the doubt. Let's show that we are sincere and not opportunistic at the slight rustle. Not saying we are, but lets not give others the benefit of doubting. Stand on our moral high ground. If indeed we are worthy of the ground we stand on.

With this i humbly remain. Carlos and team must proceed with our full support.

red1

Hi everyone,

We are working more then 2 years together on this project.
It is quite sad to read that one group is forming and deciding to do something excluding other team members.

I started helping in Compiere forums before more than 3 years.
By that time from Compiere forums i remember Red1, Adaxa, Colin and few other people. Later appear Carlos and other people. Only after we formed Adempiere we found HengSin, Teo and other wanting to join the project.

I'm sorry to write, but my feeling now is the same when Compiere started to close itself.
No matter how good a developer is or group of developers is it is not stronger or bigger than entire community. No matter what technical issues we have i strongly believe that we can solve them. We already proved this, but dividing a strong project into groups is to going to help in any direction. Writing that decision is taken without discussing and voting is kiler for the community.

Just my 2 cents,
Trifon

Red:

I am afraid that we are understanding different things here. May be I am understanding something wrong.

I understand the concerns from the private group and I support their idea to restrict what should be commited, I support the idea about quality control and establishing very clear rules for those that commit code. What I don't support is the idea of dividing Adempiere and releasing different Adempiere versions not compatible between them.

Hey Red! no one is not respecting the guardians of the trunk. I simply don't agree with their decision. There is no lack of respect there. I expressed this to Carlos in a recent thread.

This is not about good or bad temper. This is not about something personal.

Is my belief that we achieved "sucess" and to survive 27 months because we have included other opinions, we have united, not divided. This Strategy Shift sounds more like the opposite to that premise.

As Colin expressed if the primary goal here is to have an stable ground for developing and after that bring it back to the trunk, and releasing Adempiere from the trunk, I don't have any problem here. I am against having two or three or n different Adempiere versions that in the end one (the ruled by this Strategy shift) eats the others.

I am nobody to give them the benefit of doubt. I am just expressing my concerns even though they are worth nothing. I can't vote here :) they will proceed even if I don't agree with them, remember this is not a COMMUNITY decision, this is a TEAM decision in a COMMUNITY PROJECT.

The original message was not asking for opinions or votation (well just asked name suggestions) it was just a message for letting us know THEIR decision.

In concrete it was:

New "private branch. Just three people allowed to work there with their respective release. No votation here is our team decision not a COMMUNITY decision. Managed with our three people rules.
Do wherever you want with the trunk we only SUGGEST. you may do some voting if you want. We don't care how do you manage the trunk.

"Carlos and team must proceed with our full support. "

Carlos and team, as free men/companies, can proceed with or without our support .That's for sure!,

I am just thinking if it is fair they do that in OUR COMMUNITY PROJECT.

moyses