Commit Access

[Adrian Crum]

Could I be given commit access to framework/webtools please? I'd like to continue working on the UI
in that component.

-Adrian

[Ean Schuessler]

On Monday 27 August 2007 10:28:39 am Adrian Crum wrote:
> Could I be given commit access to framework/webtools please? I'd like to
> continue working on the UI in that component.

We were playing with SVK to manage "rouge committless forks" of OFBiz but are
starting to lean towards GIT because it does the job much better. Have you
played with GIT at all?

Regards,
Cpt. Schuessler
32nd Armored Rouge Fork Division

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

[Adrian Crum]

No I haven't.

Define "rouge committless forks" please.


Ean Schuessler wrote:

> On Monday 27 August 2007 10:28:39 am Adrian Crum wrote:
>
>>Could I be given commit access to framework/webtools please? I'd like to
>>continue working on the UI in that component.
>
>
> We were playing with SVK to manage "rouge committless forks" of OFBiz but are
> starting to lean towards GIT because it does the job much better. Have you
> played with GIT at all?
>
> Regards,
> Cpt. Schuessler
> 32nd Armored Rouge Fork Division
>

[Ean Schuessler]

On Friday 31 August 2007 09:56:19 am Adrian Crum wrote:
> No I haven't.
>
> Define "rouge committless forks" please.

I mean forks in the tradition of the Linux kernel. GIT was designed around a
development model where there are many paths of simultaneous development
going on, each with their own version history. None of those repositories
are, functionally, a "master" repository. They are all peers and the role of
Linus' repository is strictly a matter of convention and reputation.

I think following a similar model would be beneficial for OFBiz. There are a
lot of reasons to constrain the number of primary committers and most serious
users are going to need to maintain their own private "fork". At this point I
mostly regard the Apache repository as the Hotwax version of OFBiz. The other
major version at this point being the Open Source Strategies OpenTaps
repository.

We started out using SVK here in order to create our own local revision
history but still find that tool limiting. GIT and Mercurial are the leaders
for that style of development and GIT would seem to have the most intensive
community around it.

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

[Adrian Crum]

Ean,

Thank you for the explanation.

Where I work there would be no need to create/maintain a separate fork. I have a few enhancements to
OFBiz that I maintain for my employer - I'm not the type of developer who would create a cottage
business based on OFBiz.

I was given commit priviledge to the applications folder with the understanding that I could use
that priviledge to continue enhancing the OFBiz UI. Problem is, some of the UI stuff is in the
framework folder - that's why I asked for additional commit priviledges.

-Adrian

Ean Schuessler wrote:

> On Friday 31 August 2007 09:56:19 am Adrian Crum wrote:
>
>>No I haven't.
>>
>>Define "rouge committless forks" please.
>
>
> I mean forks in the tradition of the Linux kernel. GIT was designed around a
> development model where there are many paths of simultaneous development
> going on, each with their own version history. None of those repositories
> are, functionally, a "master" repository. They are all peers and the role of
> Linus' repository is strictly a matter of convention and reputation.
>
> I think following a similar model would be beneficial for OFBiz. There are a
> lot of reasons to constrain the number of primary committers and most serious
> users are going to need to maintain their own private "fork". At this point I
> mostly regard the Apache repository as the Hotwax version of OFBiz. The other
> major version at this point being the Open Source Strategies OpenTaps
> repository.
>
> We started out using SVK here in order to create our own local revision
> history but still find that tool limiting. GIT and Mercurial are the leaders
> for that style of development and GIT would seem to have the most intensive
> community around it.
>

[David E Jones]

Ean Schuessler wrote:

> On Friday 31 August 2007 09:56:19 am Adrian Crum wrote:
>> No I haven't.
>>
>> Define "rouge committless forks" please.
>
> I mean forks in the tradition of the Linux kernel. GIT was designed around a
> development model where there are many paths of simultaneous development
> going on, each with their own version history. None of those repositories
> are, functionally, a "master" repository. They are all peers and the role of
> Linus' repository is strictly a matter of convention and reputation.
>
> I think following a similar model would be beneficial for OFBiz. There are a
> lot of reasons to constrain the number of primary committers and most serious
> users are going to need to maintain their own private "fork". At this point I
> mostly regard the Apache repository as the Hotwax version of OFBiz. The other
> major version at this point being the Open Source Strategies OpenTaps
> repository.

This seems different from what you described above with the Linux kernel... but I'm interested to hear more of how you think that would work independent of what is going on with OFBiz and OFBiz derivatives right now.

The way I look at it is that the open source project really has one purpose: it allows different groups to collaborate and do things together that would be too difficult and expensive any group to really do on their own.

Hotwax is becoming one of the larger OFBiz-based consultancies (though certainly not even close to the biggest), but even Hotwax is WAY too small to handle something the size and scope of OFBiz... like probably at least 10 to 1 and perhaps a 100 to 1 level of magnitude difference.

The ASF repository is definitely not meant to be Hotwax only, and I don't see it as that at all. In fact, it worries me a LOT to see anyone say something like that. I don't think it's even close to true either... the traffic in the mailing lists, issue tracker AND the SVN repository all tell a very different story!

> We started out using SVK here in order to create our own local revision
> history but still find that tool limiting. GIT and Mercurial are the leaders
> for that style of development and GIT would seem to have the most intensive
> community around it.

IMO it's totally fine and normal for there to be local repos that groups maintain for their projects.

Whatever is done and however it's done the trick is how do you work with others? If you don't have processes and practices to participate in a group effort, then you're really not participating in the group...

OFBiz could greatly benefit from more contributors and committers, and from experience with this type of software it is difficult for enthusiasts and hobbyists to participate part-time, so the people doing stuff full-time based on OFBiz are the most valuable to the project... and by participating in the project open the door to receive benefits that just aren't possible any other way! Collaboration really is the WHOLE point of an open source project, or to put it in ASF terms: communication is the key!

-David

[Ean Schuessler]

On Monday 10 September 2007 03:40:59 pm David E Jones wrote:

> This seems different from what you described above with the Linux kernel...
> but I'm interested to hear more of how you think that would work
> independent of what is going on with OFBiz and OFBiz derivatives right now.
>
> The way I look at it is that the open source project really has one
> purpose: it allows different groups to collaborate and do things together
> that would be too difficult and expensive any group to really do on their
> own.
>
> Hotwax is becoming one of the larger OFBiz-based consultancies (though
> certainly not even close to the biggest), but even Hotwax is WAY too small
> to handle something the size and scope of OFBiz... like probably at least
> 10 to 1 and perhaps a 100 to 1 level of magnitude difference.
>
> The ASF repository is definitely not meant to be Hotwax only, and I don't
> see it as that at all. In fact, it worries me a LOT to see anyone say
> something like that. I don't think it's even close to true either... the
> traffic in the mailing lists, issue tracker AND the SVN repository all tell
> a very different story!
>
> IMO it's totally fine and normal for there to be local repos that groups
> maintain for their projects.
>
> Whatever is done and however it's done the trick is how do you work with
> others? If you don't have processes and practices to participate in a group
> effort, then you're really not participating in the group...
>
> OFBiz could greatly benefit from more contributors and committers, and from
> experience with this type of software it is difficult for enthusiasts and
> hobbyists to participate part-time, so the people doing stuff full-time
> based on OFBiz are the most valuable to the project... and by participating
> in the project open the door to receive benefits that just aren't possible
> any other way! Collaboration really is the WHOLE point of an open source
> project, or to put it in ASF terms: communication is the key!

I may be overstating matters and its certainly a matter of perception. I
suppose I may just be grumpy because no one paid any attention to my
ProductRole patch (OFBIZ-1177).

Grand Hotwax cabal conspiracies aside, I think the point is cogent that the
project would benefit from the highly decentralized development strategy
implied by GIT/Mercurial. We are all going to have different priorities about
what should or shouldn't be done in the project, everyone is capable of
making mistakes and market forces will (presumably) eventually direct users
to whichever source base provides the most value.

I think Si's development efforts are the starkest example currently because
their can be little doubt about the role of Open Source Solutions in the
OpenTaps repository. Being able to submit patches to Si or OFBiz, but then
later coordinate a merge between sourcebases with, perhaps, some patches
already applied on both sides would be a real convenience.

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

[Adrian Crum]

Ean Schuessler wrote:
> I may be overstating matters and its certainly a matter of perception. I
> suppose I may just be grumpy because no one paid any attention to my
> ProductRole patch (OFBIZ-1177).

I hadn't noticed that Jira issue before, but it's something I would very much like to take a look
at. I've complained in the past about the inability to assign party roles to products, and your
patch addresses that.

Btw, I had similar feelings as you prior to OFBiz joining the ASF. Up until then, OFBiz was somewhat
Undersun-centric and Jira submissions languished. After a number of developers complained (including
myself) David worked to get more committers involved. Now we have a good sized team, but I'm sure we
could always user more.

As a committer, I would like to do more to get the patches in Jira fed into the project - but there
are only so many hours in the day. I know other committers are in the same position. Sometimes you
just have to be patient.

-Adrian

[David E Jones]

Adrian Crum wrote:

> Ean Schuessler wrote:
>> I may be overstating matters and its certainly a matter of perception.
>> I suppose I may just be grumpy because no one paid any attention to my
>> ProductRole patch (OFBIZ-1177).
>
> I hadn't noticed that Jira issue before, but it's something I would very
> much like to take a look at. I've complained in the past about the
> inability to assign party roles to products, and your patch addresses that.
>
> Btw, I had similar feelings as you prior to OFBiz joining the ASF. Up
> until then, OFBiz was somewhat Undersun-centric and Jira submissions
> languished. After a number of developers complained (including myself)
> David worked to get more committers involved. Now we have a good sized
> team, but I'm sure we could always user more.
>
> As a committer, I would like to do more to get the patches in Jira fed
> into the project - but there are only so many hours in the day. I know
> other committers are in the same position. Sometimes you just have to be
> patient.

Be patient... or do something about it!

Like Adrian did...

-David

[Ean Schuessler]

On Monday 10 September 2007 07:23:36 pm David E Jones wrote:
> > As a committer, I would like to do more to get the patches in Jira fed
> > into the project - but there are only so many hours in the day. I know
> > other committers are in the same position. Sometimes you just have to be
> > patient.
>
> Be patient... or do something about it!
>
> Like Adrian did...

I believe Adam had commit access at one time but no longer does. Do something
about it!

:-D

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

[David E Jones]

Ean Schuessler wrote:

> On Monday 10 September 2007 07:23:36 pm David E Jones wrote:
>>> As a committer, I would like to do more to get the patches in Jira fed
>>> into the project - but there are only so many hours in the day. I know
>>> other committers are in the same position. Sometimes you just have to be
>>> patient.
>> Be patient... or do something about it!
>>
>> Like Adrian did...
>
> I believe Adam had commit access at one time but no longer does. Do something
> about it!
>
> :-D

touché.

It would be great to have Adam involved again, and his contributions from before really made a difference.

There is a bar to make it over for new committers and for previous committers it would obviously be lower, but the same stuff applies in general:

http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best+Practices
http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities

-David

[Jacques Le Roux]

Hi Ean,

De : "Ean Schuessler" <[hidden email]>

> On Monday 10 September 2007 03:40:59 pm David E Jones wrote:
> > This seems different from what you described above with the Linux kernel...
> > but I'm interested to hear more of how you think that would work
> > independent of what is going on with OFBiz and OFBiz derivatives right now.
> >
> > The way I look at it is that the open source project really has one
> > purpose: it allows different groups to collaborate and do things together
> > that would be too difficult and expensive any group to really do on their
> > own.
> >
> > Hotwax is becoming one of the larger OFBiz-based consultancies (though
> > certainly not even close to the biggest), but even Hotwax is WAY too small
> > to handle something the size and scope of OFBiz... like probably at least
> > 10 to 1 and perhaps a 100 to 1 level of magnitude difference.
> >
> > The ASF repository is definitely not meant to be Hotwax only, and I don't
> > see it as that at all. In fact, it worries me a LOT to see anyone say
> > something like that. I don't think it's even close to true either... the
> > traffic in the mailing lists, issue tracker AND the SVN repository all tell
> > a very different story!
> >
> > IMO it's totally fine and normal for there to be local repos that groups
> > maintain for their projects.
> >
> > Whatever is done and however it's done the trick is how do you work with
> > others? If you don't have processes and practices to participate in a group
> > effort, then you're really not participating in the group...
> >
> > OFBiz could greatly benefit from more contributors and committers, and from
> > experience with this type of software it is difficult for enthusiasts and
> > hobbyists to participate part-time, so the people doing stuff full-time
> > based on OFBiz are the most valuable to the project... and by participating
> > in the project open the door to receive benefits that just aren't possible
> > any other way! Collaboration really is the WHOLE point of an open source
> > project, or to put it in ASF terms: communication is the key!
>
> I may be overstating matters and its certainly a matter of perception. I
> suppose I may just be grumpy because no one paid any attention to my
> ProductRole patch (OFBIZ-1177).

Now everybody is aware of it ;o)

Jacques

[jonwimp]

Ean,

I agree that the branch-explore-prune strategy is wickedly rapid, for quick prototyping and
cultivation of "best of breed" directions.

With multiple official/public OFBiz branches, each branch can be more specialized to cater more
tightly to particular user groups.

Then David or Undersun could oversee all the official branches, and pick up best of breed ideas to
be merged back into main OFBiz SVN. Yes, they'll need more hires for this, possibly. And they are
busy enough already. Note that without this step, each fork will simply do their own dances and
end up duplicating each others' functionalities over time. Wasteful.

Note that packaging of the forks is very important to facilitate easy reconciliation! Ideally,
each fork should only contain files that are specialized, and not files that duplicate core OFBiz
parts.

Each fork manager should be responsible for removing specialized components that have been merged
back into main OFBiz SVN, to keep forks lean.

Personally, I have several forks by now, each catering to an individual customer. I package the
forks with this policy: "strictly no duplication of core OFBiz". All my SVN repos are lean,
minimalistic, containing only specialized files. This makes it very easy for me to update from
OFBiz SVN (the Undersun one) to any of my forks.

Nothing more than simple party tricks with SVN, really. But it all goes a long way to managing and
maintaining disparate projects.

Jonathon

Ean Schuessler wrote:

> On Monday 10 September 2007 03:40:59 pm David E Jones wrote:
>> This seems different from what you described above with the Linux kernel...
>> but I'm interested to hear more of how you think that would work
>> independent of what is going on with OFBiz and OFBiz derivatives right now.
>>
>> The way I look at it is that the open source project really has one
>> purpose: it allows different groups to collaborate and do things together
>> that would be too difficult and expensive any group to really do on their
>> own.
>>
>> Hotwax is becoming one of the larger OFBiz-based consultancies (though
>> certainly not even close to the biggest), but even Hotwax is WAY too small
>> to handle something the size and scope of OFBiz... like probably at least
>> 10 to 1 and perhaps a 100 to 1 level of magnitude difference.
>>
>> The ASF repository is definitely not meant to be Hotwax only, and I don't
>> see it as that at all. In fact, it worries me a LOT to see anyone say
>> something like that. I don't think it's even close to true either... the
>> traffic in the mailing lists, issue tracker AND the SVN repository all tell
>> a very different story!
>>
>> IMO it's totally fine and normal for there to be local repos that groups
>> maintain for their projects.
>>
>> Whatever is done and however it's done the trick is how do you work with
>> others? If you don't have processes and practices to participate in a group
>> effort, then you're really not participating in the group...
>>
>> OFBiz could greatly benefit from more contributors and committers, and from
>> experience with this type of software it is difficult for enthusiasts and
>> hobbyists to participate part-time, so the people doing stuff full-time
>> based on OFBiz are the most valuable to the project... and by participating
>> in the project open the door to receive benefits that just aren't possible
>> any other way! Collaboration really is the WHOLE point of an open source
>> project, or to put it in ASF terms: communication is the key!
>
> I may be overstating matters and its certainly a matter of perception. I
> suppose I may just be grumpy because no one paid any attention to my
> ProductRole patch (OFBIZ-1177).
>
> Grand Hotwax cabal conspiracies aside, I think the point is cogent that the
> project would benefit from the highly decentralized development strategy
> implied by GIT/Mercurial. We are all going to have different priorities about
> what should or shouldn't be done in the project, everyone is capable of
> making mistakes and market forces will (presumably) eventually direct users
> to whichever source base provides the most value.
>
> I think Si's development efforts are the starkest example currently because
> their can be little doubt about the role of Open Source Solutions in the
> OpenTaps repository. Being able to submit patches to Si or OFBiz, but then
> later coordinate a merge between sourcebases with, perhaps, some patches
> already applied on both sides would be a real convenience.
>

[rajsaini]

> I may be overstating matters and its certainly a matter of perception. I
> suppose I may just be grumpy because no one paid any attention to my
> ProductRole patch (OFBIZ-1177).
>  
We have rolled out our own similar implementation and think it is common
requirement for products such as books magazines. it will be a good
inclusion.

Thanks,

Raj

[David E Jones]

Jonathon -- Improov wrote:
> Ean,
>
> I agree that the branch-explore-prune strategy is wickedly rapid, for
> quick prototyping and cultivation of "best of breed" directions.
>
> With multiple official/public OFBiz branches, each branch can be more
> specialized to cater more tightly to particular user groups.

This would be done better with add-in components than with branches, or forks, or intended branches that turn into forks.

For things that need to be changed in the OFBiz framework or base applications patches should be submitted (or a committer working on it should just put them in). These would tend to be smaller and go in more quickly.

> Then David or Undersun could oversee all the official branches, and pick
> up best of breed ideas to be merged back into main OFBiz SVN. Yes,
> they'll need more hires for this, possibly. And they are busy enough
> already. Note that without this step, each fork will simply do their own
> dances and end up duplicating each others' functionalities over time.
> Wasteful.

Ummm... not sure where this idea came from...

Neither "David" nor "Undersun" (now part of Hotwax Media) nor any other person or organization are some central source of resources or driving force for the project. OFBiz is overseen by a PMC (project management committee) but everything that goes into OFBiz is contributed by users.

So no, this would never work. There is no central organization to pull stuff into the project, just users to push stuff into the project. That's the WHOLE point of a community driven project that facilitates collaboration.

Of course, this is also impossible with current forks like opentaps and Neogia because they specifically structure their licensing and copyright ownership so that it is impossible to bring the contributions back into OFBiz.

> Note that packaging of the forks is very important to facilitate easy
> reconciliation! Ideally, each fork should only contain files that are
> specialized, and not files that duplicate core OFBiz parts.

See the comments about components above.

> Each fork manager should be responsible for removing specialized
> components that have been merged back into main OFBiz SVN, to keep forks
> lean.

Again this can be avoided by focusing on add-ons combined with patches that go into OFBiz sooner and easier.

> Personally, I have several forks by now, each catering to an individual
> customer. I package the forks with this policy: "strictly no duplication
> of core OFBiz". All my SVN repos are lean, minimalistic, containing only
> specialized files. This makes it very easy for me to update from OFBiz
> SVN (the Undersun one) to any of my forks.

Ummm... there is no Undersun SVN except the pre-ASF SVN repo that is no longer active. It's the Apache Software Foundation SVN server we use for OFBiz.

I don't think people understand just how incorrect and harmful to the project this sort of thought is. If it isn't community driven people and organizations won't be as interested in contributing and the whole project will fall apart. It's a vicious and damaging lie! For anyone thinking this please check your facts and motives!

-David

> Ean Schuessler wrote:
>> On Monday 10 September 2007 03:40:59 pm David E Jones wrote:
>>> This seems different from what you described above with the Linux
>>> kernel...
>>> but I'm interested to hear more of how you think that would work
>>> independent of what is going on with OFBiz and OFBiz derivatives
>>> right now.
>>>
>>> The way I look at it is that the open source project really has one
>>> purpose: it allows different groups to collaborate and do things
>>> together
>>> that would be too difficult and expensive any group to really do on
>>> their
>>> own.
>>>
>>> Hotwax is becoming one of the larger OFBiz-based consultancies (though
>>> certainly not even close to the biggest), but even Hotwax is WAY too
>>> small
>>> to handle something the size and scope of OFBiz... like probably at
>>> least
>>> 10 to 1 and perhaps a 100 to 1 level of magnitude difference.
>>>
>>> The ASF repository is definitely not meant to be Hotwax only, and I
>>> don't
>>> see it as that at all. In fact, it worries me a LOT to see anyone say
>>> something like that. I don't think it's even close to true either... the
>>> traffic in the mailing lists, issue tracker AND the SVN repository
>>> all tell
>>> a very different story!
>>>
>>> IMO it's totally fine and normal for there to be local repos that groups
>>> maintain for their projects.
>>>
>>> Whatever is done and however it's done the trick is how do you work with
>>> others? If you don't have processes and practices to participate in a
>>> group
>>> effort, then you're really not participating in the group...
>>>
>>> OFBiz could greatly benefit from more contributors and committers,
>>> and from
>>> experience with this type of software it is difficult for enthusiasts
>>> and
>>> hobbyists to participate part-time, so the people doing stuff full-time
>>> based on OFBiz are the most valuable to the project... and by
>>> participating
>>> in the project open the door to receive benefits that just aren't
>>> possible
>>> any other way! Collaboration really is the WHOLE point of an open source
>>> project, or to put it in ASF terms: communication is the key!
>>
>> I may be overstating matters and its certainly a matter of perception.
>> I suppose I may just be grumpy because no one paid any attention to my
>> ProductRole patch (OFBIZ-1177).
>>
>> Grand Hotwax cabal conspiracies aside, I think the point is cogent
>> that the project would benefit from the highly decentralized
>> development strategy implied by GIT/Mercurial. We are all going to
>> have different priorities about what should or shouldn't be done in
>> the project, everyone is capable of making mistakes and market forces
>> will (presumably) eventually direct users to whichever source base
>> provides the most value.
>>
>> I think Si's development efforts are the starkest example currently
>> because their can be little doubt about the role of Open Source
>> Solutions in the OpenTaps repository. Being able to submit patches to
>> Si or OFBiz, but then later coordinate a merge between sourcebases
>> with, perhaps, some patches already applied on both sides would be a
>> real convenience.
>>
>

[Jacopo Cappellato]

David E Jones wrote:

>
>> Then David or Undersun could oversee all the official branches, and
>> pick up best of breed ideas to be merged back into main OFBiz SVN.
>> Yes, they'll need more hires for this, possibly. And they are busy
>> enough already. Note that without this step, each fork will simply do
>> their own dances and end up duplicating each others' functionalities
>> over time. Wasteful.
>
> Ummm... not sure where this idea came from...
>
> Neither "David" nor "Undersun" (now part of Hotwax Media) nor any other
> person or organization are some central source of resources or driving
> force for the project. OFBiz is overseen by a PMC (project management
> committee) but everything that goes into OFBiz is contributed by users.

And the members of the PMC and the committers of the OFBiz project are
clearly listed here:

http://docs.ofbiz.org/display/OFBADMIN/PMC+members+and+Committers

As you all can see, the core group is composed by persons from very
different countries (from all over the world) and different companies,
and also by private contributors.

Jacopo

[jonwimp]

David,

Sorry for the wrong attribution of OFBiz's management responsibility. The name "Undersun" just
stuck. I thought that's the "go-to guy" for OFBiz! In fact, I do watch you (or Undersun or Hotwax)
for directions in matters that might impact our "business viability with OFBiz". I still
unconsciously lump every contributor to you and company. Wrong, yes. Just convenient to refer to a
single entity, or just being lazy. Sorry. :P

I agree with the add-in components. But I encounter problems trying to make my individual projects
lean like add-in components. Quite a bit of the non-framework aspects of OFBiz are not generic
enough to render tweaks unnecessary, and those non-framework aspects are built into OFBiz like
they are core. OFBiz already has many mechanisms for "extensions coding (overriding, overloading,
etc)", to cleanly create add-in components, but some areas may still need to be developed further.
But I digress.

The forks and best-of-breeds strategy is for competition between implementations of complex core
functions. Often, it's hard to see in foresight what is the best way to go about a complex
function. The best way is to take a measured charge forward with SVN, and use cheaper hindsight to
guide us. Either that, or we get stuck with multiple camps arguing for opposing directions. The
typical "deep-thought-related team paralysis".

That said, the fact that "competition" is needed to hunt down the best of breed implementation
will bring in a whole suite of human problems. We've seen many fiefdoms in the open source arena
that simply don't match or merge. Few humans can lay down personal pride for greater good (so pat
yourselves on back, those of you who contribute to OFBiz!).

 > So no, this would never work. There is no central organization to
 > pull stuff into the project, just users to push stuff into the
 > project.  That's the WHOLE point of a community driven project that
 > facilitates collaboration.

Yeah, I guess you're right. It would never work. The only platform where it'll work is with
private... erm... users, who do "pull best of breed stuff" into their private SVNs. Hindsight can
bring a lot of insight.

Anyway, I think I have beaten this "SVN tricks and acrobatics" topic to death before. I'm either
an undiscovered genius, or I'm doing something terribly wrong with SVN and such! Heh. Probably the
latter, since I'm still undiscovered.

Jonathon

David E Jones wrote:

>
>
> Jonathon -- Improov wrote:
>> Ean,
>>
>> I agree that the branch-explore-prune strategy is wickedly rapid, for
>> quick prototyping and cultivation of "best of breed" directions.
>>
>> With multiple official/public OFBiz branches, each branch can be more
>> specialized to cater more tightly to particular user groups.
>
> This would be done better with add-in components than with branches, or
> forks, or intended branches that turn into forks.
>
> For things that need to be changed in the OFBiz framework or base
> applications patches should be submitted (or a committer working on it
> should just put them in). These would tend to be smaller and go in more
> quickly.
>
>> Then David or Undersun could oversee all the official branches, and
>> pick up best of breed ideas to be merged back into main OFBiz SVN.
>> Yes, they'll need more hires for this, possibly. And they are busy
>> enough already. Note that without this step, each fork will simply do
>> their own dances and end up duplicating each others' functionalities
>> over time. Wasteful.
>
> Ummm... not sure where this idea came from...
>
> Neither "David" nor "Undersun" (now part of Hotwax Media) nor any other
> person or organization are some central source of resources or driving
> force for the project. OFBiz is overseen by a PMC (project management
> committee) but everything that goes into OFBiz is contributed by users.
>
> So no, this would never work. There is no central organization to pull
> stuff into the project, just users to push stuff into the project.
> That's the WHOLE point of a community driven project that facilitates
> collaboration.
>
> Of course, this is also impossible with current forks like opentaps and
> Neogia because they specifically structure their licensing and copyright
> ownership so that it is impossible to bring the contributions back into
> OFBiz.
>
>> Note that packaging of the forks is very important to facilitate easy
>> reconciliation! Ideally, each fork should only contain files that are
>> specialized, and not files that duplicate core OFBiz parts.
>
> See the comments about components above.
>
>> Each fork manager should be responsible for removing specialized
>> components that have been merged back into main OFBiz SVN, to keep
>> forks lean.
>
> Again this can be avoided by focusing on add-ons combined with patches
> that go into OFBiz sooner and easier.
>
>> Personally, I have several forks by now, each catering to an
>> individual customer. I package the forks with this policy: "strictly
>> no duplication of core OFBiz". All my SVN repos are lean,
>> minimalistic, containing only specialized files. This makes it very
>> easy for me to update from OFBiz SVN (the Undersun one) to any of my
>> forks.
>
> Ummm... there is no Undersun SVN except the pre-ASF SVN repo that is no
> longer active. It's the Apache Software Foundation SVN server we use for
> OFBiz.
>
> I don't think people understand just how incorrect and harmful to the
> project this sort of thought is. If it isn't community driven people and
> organizations won't be as interested in contributing and the whole
> project will fall apart. It's a vicious and damaging lie! For anyone
> thinking this please check your facts and motives!
>
> -David
>
>
>
>> Ean Schuessler wrote:
>>> On Monday 10 September 2007 03:40:59 pm David E Jones wrote:
>>>> This seems different from what you described above with the Linux
>>>> kernel...
>>>> but I'm interested to hear more of how you think that would work
>>>> independent of what is going on with OFBiz and OFBiz derivatives
>>>> right now.
>>>>
>>>> The way I look at it is that the open source project really has one
>>>> purpose: it allows different groups to collaborate and do things
>>>> together
>>>> that would be too difficult and expensive any group to really do on
>>>> their
>>>> own.
>>>>
>>>> Hotwax is becoming one of the larger OFBiz-based consultancies (though
>>>> certainly not even close to the biggest), but even Hotwax is WAY too
>>>> small
>>>> to handle something the size and scope of OFBiz... like probably at
>>>> least
>>>> 10 to 1 and perhaps a 100 to 1 level of magnitude difference.
>>>>
>>>> The ASF repository is definitely not meant to be Hotwax only, and I
>>>> don't
>>>> see it as that at all. In fact, it worries me a LOT to see anyone say
>>>> something like that. I don't think it's even close to true either...
>>>> the
>>>> traffic in the mailing lists, issue tracker AND the SVN repository
>>>> all tell
>>>> a very different story!
>>>>
>>>> IMO it's totally fine and normal for there to be local repos that
>>>> groups
>>>> maintain for their projects.
>>>>
>>>> Whatever is done and however it's done the trick is how do you work
>>>> with
>>>> others? If you don't have processes and practices to participate in
>>>> a group
>>>> effort, then you're really not participating in the group...
>>>>
>>>> OFBiz could greatly benefit from more contributors and committers,
>>>> and from
>>>> experience with this type of software it is difficult for
>>>> enthusiasts and
>>>> hobbyists to participate part-time, so the people doing stuff full-time
>>>> based on OFBiz are the most valuable to the project... and by
>>>> participating
>>>> in the project open the door to receive benefits that just aren't
>>>> possible
>>>> any other way! Collaboration really is the WHOLE point of an open
>>>> source
>>>> project, or to put it in ASF terms: communication is the key!
>>>
>>> I may be overstating matters and its certainly a matter of
>>> perception. I suppose I may just be grumpy because no one paid any
>>> attention to my ProductRole patch (OFBIZ-1177).
>>>
>>> Grand Hotwax cabal conspiracies aside, I think the point is cogent
>>> that the project would benefit from the highly decentralized
>>> development strategy implied by GIT/Mercurial. We are all going to
>>> have different priorities about what should or shouldn't be done in
>>> the project, everyone is capable of making mistakes and market forces
>>> will (presumably) eventually direct users to whichever source base
>>> provides the most value.
>>>
>>> I think Si's development efforts are the starkest example currently
>>> because their can be little doubt about the role of Open Source
>>> Solutions in the OpenTaps repository. Being able to submit patches to
>>> Si or OFBiz, but then later coordinate a merge between sourcebases
>>> with, perhaps, some patches already applied on both sides would be a
>>> real convenience.
>>>
>>
>
>

[Adrian Crum]

Now that this thread has made the rounds for a few weeks, can we get back to the original subject? I
need commit access to framework/webtools and framework/example. Please.

:D

-Adrian

David E Jones wrote:

>
>
> Ean Schuessler wrote:
>
>> On Monday 10 September 2007 07:23:36 pm David E Jones wrote:
>>
>>>> As a committer, I would like to do more to get the patches in Jira fed
>>>> into the project - but there are only so many hours in the day. I know
>>>> other committers are in the same position. Sometimes you just have
>>>> to be
>>>> patient.
>>>
>>> Be patient... or do something about it!
>>>
>>> Like Adrian did...
>>
>>
>> I believe Adam had commit access at one time but no longer does. Do
>> something about it!
>>
>> :-D
>
>
> touché.
>
> It would be great to have Adam involved again, and his contributions
> from before really made a difference.
>
> There is a bar to make it over for new committers and for previous
> committers it would obviously be lower, but the same stuff applies in
> general:
>
> http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best+Practices
> http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities 
>
>
> -David
>

[David E Jones]

The PMC vote for this is underway...

-David


Adrian Crum wrote:

> Now that this thread has made the rounds for a few weeks, can we get
> back to the original subject? I need commit access to framework/webtools
> and framework/example. Please.
>
> :D
>
> -Adrian
>
> David E Jones wrote:
>
>>
>>
>> Ean Schuessler wrote:
>>
>>> On Monday 10 September 2007 07:23:36 pm David E Jones wrote:
>>>
>>>>> As a committer, I would like to do more to get the patches in Jira fed
>>>>> into the project - but there are only so many hours in the day. I know
>>>>> other committers are in the same position. Sometimes you just have
>>>>> to be
>>>>> patient.
>>>>
>>>> Be patient... or do something about it!
>>>>
>>>> Like Adrian did...
>>>
>>>
>>> I believe Adam had commit access at one time but no longer does. Do
>>> something about it!
>>>
>>> :-D
>>
>>
>> touché.
>>
>> It would be great to have Adam involved again, and his contributions
>> from before really made a difference.
>>
>> There is a bar to make it over for new committers and for previous
>> committers it would obviously be lower, but the same stuff applies in
>> general:
>>
>> http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best+Practices
>> http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities 
>>
>>
>> -David
>>

[Ean Schuessler]

On Tuesday 11 September 2007 03:22:24 am David E Jones wrote:

> Ummm... not sure where this idea came from...
>
> Neither "David" nor "Undersun" (now part of Hotwax Media) nor any other
> person or organization are some central source of resources or driving
> force for the project. OFBiz is overseen by a PMC (project management
> committee) but everything that goes into OFBiz is contributed by users.
>
> So no, this would never work. There is no central organization to pull
> stuff into the project, just users to push stuff into the project. That's
> the WHOLE point of a community driven project that facilitates
> collaboration.
>
> Of course, this is also impossible with current forks like opentaps and
> Neogia because they specifically structure their licensing and copyright
> ownership so that it is impossible to bring the contributions back into
> OFBiz.

[snip]
> I don't think people understand just how incorrect and harmful to the
> project this sort of thought is. If it isn't community driven people and
> organizations won't be as interested in contributing and the whole project
> will fall apart. It's a vicious and damaging lie! For anyone thinking this
> please check your facts and motives!

Don't be so defensive! There is a big difference between a vicious lie and a
widespread misconception. Hotwax has more committers than anyone else so its
easy to see why people might think something like this. If I was a
dangerously motivated liar I would do more than simply state the obvious!

Anyway, my main point was about the benefit of using a more modern and
distributed source management system for things that aren't ready to go into
SVN. Brainfood would rather make extensive changes to our local repository
and pool them up into change sets that go to mainstream. Repeated merges
where portions have been partially applied in multiple paths of development
isn't a workflow that is well supported by SVN but is easy (or way easier,
anyway) under GIT and Mercurial.

ps. Check your facts and motives before calling someone a vicious, damaging
liar.

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com