Dev - this week's development blog is done!

[David E. Jones]

Hans,

This is nothing personal, but I really don't want to do anything with the opentravelsystem or other specialized components right now. The library and code review of the main stuff is a pretty big scope and I'd like to focus on that.

I am also hoping that we will get a "top level project" status at the ASF and if so then things like the opentravelsystem component could be effectively managed as sub-projects.

In the mean time we will be keeping the Undersun SVN server up where everything is now, and the code can continue to live there.

There was also a comment from someone else about putting this in the applications folder and making it a core part of OFBiz. This has been developed, as I understand it, as an add-on to OFBiz that customizes it for a more specific purpose. I also understand that the purpose has changed over time and isn't really just a travel system any more.

For this sort of code base I think the best place is a library of OFBiz add-ons for a specific purpose, in this case a specific industry (or 2 specific industries?).

-David


Hans Bakker wrote:

> On Saturday 27 May 2006 12:52, Jacopo Cappellato wrote:
>> I agree that it's very important that someone (David Jones) has admin
>> privileges on the ASF SVN server so that he can manage permissions and
>> the migration of the source code from our current server to the new one.
>> As soon as David has these rights (Yoav, David W., do you have any hints
>> about this subject?) everything will be easier.
>> About the structure, what about the following one:
>>
>> trunk/ofbiz
>> trunk/website
>>
> I would appreciate if a third could be added, currently called the
> opentravelsystem, but now evolved into a shared ofbiz system addon where more
> customers/sites can share the same physical installation. The first sites
> will go in production the next few months.
>
> Is this possible?
>
> Congratulations with the fact that LGPL packages are now removed!
>
>> ?
>>
>> It has been recently suggested by Andy in the thread "specialized and
>> website folders in SVN tree" in this list.
>>
>> About the ASF Jira server: it would be really nice to setup things to
>> get a mailing list for jira issues (Yoav, David W. do you think it is
>> possible to set up it?)
>>
>> Have a nice weekend,
>>
>> Jacopo
>>
>> David E. Jones wrote:
>>> Jacopo Cappellato wrote:
>>>> Now that JOTM has been replaced with Geronimo TM I think that all the
>>>> dependencies to LGPLed jars has been resolved (the jars are now optional
>>>> components under the specialized folder). Is this true?
>>> Yes, I think this is true at this point and we can now put something in
>>> the ASF SVN server without LGPL jars that will build and run straight
>>> from SVN (which has been the goal of course).
>>>
>>>> If so, should we move the code to the ASF SVN? When? During this
>>>> weekend, the next one, or later on?
>>> I think this depends on what needs to be done and who can do it, and I'm
>>> not totally clear on this yet. It look like (from INFRA-741) that the
>>> repository already exists and we should all have commit privileges.
>>>
>>> Of course, there are some issues still with who can commit where, and I'm
>>> not sure if it's possible to configure that given the way the ASF server
>>> is setup, and if so then who could do it (would you have permissions for
>>> this David Welton?).
>>>
>>> Also, it would be better to wait until we have done the Jira move as well
>>> (which should be soon, I want to make sure at least Si also has his
>>> account setup there; both Jacopo and I have dev access setup).
>>>
>>>> Should we discuss about the new SVN layout? I.e. what to do with the
>>>> website and specialized folders etc...
>>> I don't think we should change the structure at all. I propose that
>>> everything except the specialized directory in the current SVN should be
>>> put in the ASF SVN server and then removed from the current SVN server
>>> (though of course they will still be available if revisions previous to
>>> the removal are checked out).
>>>
>>> -David
>>>
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

I commented in another message about the opentravelsystem component stuff. This is the course that we discussed quite a while back, and I'd rather stick to it than expand the scope of the OFBiz to ASF move before we're even done...

Anyway, on the directory organization...

It sounds like you're proposing that the website directory be moved out from under the main OFBiz directory. Is that correct? Is there a particular reason for this?

I've thought about splitting out the applications directory in a similar way, and perhaps even creating a "framework" directory that would contain everything except the applications directory, but in a way it's a pain to have that be a peer to the framework directory, and if we did it with that we should do it with the "hot-deploy" and "specialized" directories too...

Anyone have any thoughts on this?

BTW, _if_ we do any directory reorganization it will happen in the current SVN repository and be before the ASF move. I want the initial ASF SVN check-in to be the same (as much as possible...) to a specific SVN revision in the current repository...

-David


Jacopo Cappellato wrote:

> Hans,
>
> I think that you have introduced an interesting point about the
> opentravelsystem component: should we move some of the specialized
> components to the ASF together with the core OFBiz?
>
> For me it's ok to move the OTS component to the ASF, by the way I'd
> prefer a structure like this:
>
> trunk/ofbiz
> trunk/website
> trunk/specialized/opentravelsystem
>
> What others think about this?
>
> Jacopo
>
> Hans Bakker wrote:
>> On Saturday 27 May 2006 12:52, Jacopo Cappellato wrote:
>>> I agree that it's very important that someone (David Jones) has admin
>>> privileges on the ASF SVN server so that he can manage permissions and
>>> the migration of the source code from our current server to the new one.
>>> As soon as David has these rights (Yoav, David W., do you have any hints
>>> about this subject?) everything will be easier.
>>> About the structure, what about the following one:
>>>
>>> trunk/ofbiz
>>> trunk/website
>>>
>> I would appreciate if a third could be added, currently called the
>> opentravelsystem, but now evolved into a shared ofbiz system addon where more
>> customers/sites can share the same physical installation. The first sites
>> will go in production the next few months.
>>
>> Is this possible?
>>
>> Congratulations with the fact that LGPL packages are now removed!
>>
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Daniel Kunkel]

Hi

> It sounds like you're proposing that the website directory be moved
> out from under the main OFBiz directory. Is that correct? Is there a
> particular reason for this?

I see this as being a good move for the simple reason that most OFBiz
users never use the website directory, and removing it would better
utilize their server's disk space. It's not a big deal either way.

--
Daniel

*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
Have a GREAT Day!

Daniel Kunkel           [hidden email]
BioWaves, LLC           http://www.BioWaves.com
14150 NE 20th St. Suite F1
Bellevue, WA 98007
800-734-3588    425-895-0050
http://www.Apartment-Pets.com  http://www.Focus-Illusion.com
http://www.Brain-Fun.com       http://www.ColorGlasses.com
*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[BJ Freeman]

the only question I have is if you split off all this won't it get lost
in the ASF since is is one big SVN?

maybe it is my old age, and not wanting to got thru major changes.. LOL.


David E. Jones sent the following on 5/28/2006 1:52 PM:

> I commented in another message about the opentravelsystem component stuff. This is the course that we discussed quite a while back, and I'd rather stick to it than expand the scope of the OFBiz to ASF move before we're even done...
>
> Anyway, on the directory organization...
>
> It sounds like you're proposing that the website directory be moved out from under the main OFBiz directory. Is that correct? Is there a particular reason for this?
>
> I've thought about splitting out the applications directory in a similar way, and perhaps even creating a "framework" directory that would contain everything except the applications directory, but in a way it's a pain to have that be a peer to the framework directory, and if we did it with that we should do it with the "hot-deploy" and "specialized" directories too...
>
> Anyone have any thoughts on this?
>
> BTW, _if_ we do any directory reorganization it will happen in the current SVN repository and be before the ASF move. I want the initial ASF SVN check-in to be the same (as much as possible...) to a specific SVN revision in the current repository...
>
> -David
>
>
> Jacopo Cappellato wrote:
>> Hans,
>>
>> I think that you have introduced an interesting point about the
>> opentravelsystem component: should we move some of the specialized
>> components to the ASF together with the core OFBiz?
>>
>> For me it's ok to move the OTS component to the ASF, by the way I'd
>> prefer a structure like this:
>>
>> trunk/ofbiz
>> trunk/website
>> trunk/specialized/opentravelsystem
>>
>> What others think about this?
>>
>> Jacopo
>>
>> Hans Bakker wrote:
>>> On Saturday 27 May 2006 12:52, Jacopo Cappellato wrote:
>>>> I agree that it's very important that someone (David Jones) has admin
>>>> privileges on the ASF SVN server so that he can manage permissions and
>>>> the migration of the source code from our current server to the new one.
>>>> As soon as David has these rights (Yoav, David W., do you have any hints
>>>> about this subject?) everything will be easier.
>>>> About the structure, what about the following one:
>>>>
>>>> trunk/ofbiz
>>>> trunk/website
>>>>
>>> I would appreciate if a third could be added, currently called the
>>> opentravelsystem, but now evolved into a shared ofbiz system addon where more
>>> customers/sites can share the same physical installation. The first sites
>>> will go in production the next few months.
>>>
>>> Is this possible?
>>>
>>> Congratulations with the fact that LGPL packages are now removed!
>>>
>>  
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

David,

the only reason I've proposed this is that the website directory is not
needed to run or customize OFBiz... by the way this is a detail and is
not urgent at all.
Maybe it's better to keep things as they are now and go on with the
migration to ASF.

Jacopo



David E. Jones wrote:

> I commented in another message about the opentravelsystem component stuff. This is the course that we discussed quite a while back, and I'd rather stick to it than expand the scope of the OFBiz to ASF move before we're even done...
>
> Anyway, on the directory organization...
>
> It sounds like you're proposing that the website directory be moved out from under the main OFBiz directory. Is that correct? Is there a particular reason for this?
>
> I've thought about splitting out the applications directory in a similar way, and perhaps even creating a "framework" directory that would contain everything except the applications directory, but in a way it's a pain to have that be a peer to the framework directory, and if we did it with that we should do it with the "hot-deploy" and "specialized" directories too...
>
> Anyone have any thoughts on this?
>
> BTW, _if_ we do any directory reorganization it will happen in the current SVN repository and be before the ASF move. I want the initial ASF SVN check-in to be the same (as much as possible...) to a specific SVN revision in the current repository...
>
> -David
>
>
> Jacopo Cappellato wrote:
>> Hans,
>>
>> I think that you have introduced an interesting point about the
>> opentravelsystem component: should we move some of the specialized
>> components to the ASF together with the core OFBiz?
>>
>> For me it's ok to move the OTS component to the ASF, by the way I'd
>> prefer a structure like this:
>>
>> trunk/ofbiz
>> trunk/website
>> trunk/specialized/opentravelsystem
>>
>> What others think about this?
>>
>> Jacopo
>>
>> Hans Bakker wrote:
>>> On Saturday 27 May 2006 12:52, Jacopo Cappellato wrote:
>>>> I agree that it's very important that someone (David Jones) has admin
>>>> privileges on the ASF SVN server so that he can manage permissions and
>>>> the migration of the source code from our current server to the new one.
>>>> As soon as David has these rights (Yoav, David W., do you have any hints
>>>> about this subject?) everything will be easier.
>>>> About the structure, what about the following one:
>>>>
>>>> trunk/ofbiz
>>>> trunk/website
>>>>
>>> I would appreciate if a third could be added, currently called the
>>> opentravelsystem, but now evolved into a shared ofbiz system addon where more
>>> customers/sites can share the same physical installation. The first sites
>>> will go in production the next few months.
>>>
>>> Is this possible?
>>>
>>> Congratulations with the fact that LGPL packages are now removed!
>>>
>>  
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Andrew Sykes]

David,

I can imagine that having a split applications and framework layout
would lead to lots of posts to the mailing list asking why a specific
combination of the two weren't working. Obviously an increase in the
number of people generating content that says OFBiz doesn't work isn't
really good for the brand profile.

Although it would make downloading quicker!
--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

As pointed out by crisg in
http://ofbizwiki.go-integral.com/Wiki.jsp?page=LibrariesIncludedInOFBiz

the xom-1.0d25.jar in the framework/webapp component is licensed under
the LGPL license.

After a quick review it seems that the code that is using it is in the
we webapp component: org.ofbiz.webapp.barcode.*

The three classes there define an OFBiz transform ("barcodeTransform")
that is initiated in the FreeMarkerWorker class; however the tag is not
really used in the system.

So I think we should move this stuff under the specialized folder.

Jacopo


Andrew Sykes wrote:
> David,
>
> I can imagine that having a split applications and framework layout
> would lead to lots of posts to the mailing list asking why a specific
> combination of the two weren't working. Obviously an increase in the
> number of people generating content that says OFBiz doesn't work isn't
> really good for the brand profile.
>
> Although it would make downloading quicker!

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

As a side note, you can generate a barcode in a pdf report (without
using the barcodeTransform") in the following way:

<fo:block>
   <fo:instream-foreign-object>
     <barcode:barcode
           xmlns:barcode="http://barcode4j.krysalis.org/ns"
           message="my message">
       <barcode:code128>
         <barcode:height>8mm</barcode:height>
       </barcode:code128>
     </barcode:barcode>
   </fo:instream-foreign-object>
</fo:block>

Jacopo

Jacopo Cappellato wrote:

> As pointed out by crisg in
> http://ofbizwiki.go-integral.com/Wiki.jsp?page=LibrariesIncludedInOFBiz
>
> the xom-1.0d25.jar in the framework/webapp component is licensed under
> the LGPL license.
>
> After a quick review it seems that the code that is using it is in the
> we webapp component: org.ofbiz.webapp.barcode.*
>
> The three classes there define an OFBiz transform ("barcodeTransform")
> that is initiated in the FreeMarkerWorker class; however the tag is not
> really used in the system.
>
> So I think we should move this stuff under the specialized folder.
>
> Jacopo
>
>
> Andrew Sykes wrote:
>> David,
>>
>> I can imagine that having a split applications and framework layout
>> would lead to lots of posts to the mailing list asking why a specific
>> combination of the two weren't working. Obviously an increase in the
>> number of people generating content that says OFBiz doesn't work isn't
>> really good for the brand profile.
>>
>> Although it would make downloading quicker!
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[davidnwelton]

> I think this depends on what needs to be done and who can do it, and I'm not totally clear on this yet. It look like (from INFRA-741) that the repository already exists and we should all have commit privileges.

Yes.

> Of course, there are some issues still with who can commit where, and I'm not sure if it's possible to configure that given the way the ASF server is setup, and if so then who could do it (would you have permissions for this David Welton?).

I'm not much of a subversion expert, but I will ask around this
evening about getting you permissions to work on the configuration for
ofbiz corner of the repository.

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Christian Geisert]

Jacopo Cappellato schrieb:
> As pointed out by crisg in
> http://ofbizwiki.go-integral.com/Wiki.jsp?page=LibrariesIncludedInOFBiz

Thats me, I started reviewing it but ran out of time...

I think it would be a good thing to have this list checked before the
svn move and I hope to find some time to help.

mail.jar seems to be another problem seems but this could be replaced
with a version from Geronimo or Glassfish

Christian
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

Hi Christian,

your help is *really* welcome!
Yes, we have to review the list before the move to Apache...

Thanks,

Jacopo

Christian Geisert wrote:

> Jacopo Cappellato schrieb:
>> As pointed out by crisg in
>> http://ofbizwiki.go-integral.com/Wiki.jsp?page=LibrariesIncludedInOFBiz
>
> Thats me, I started reviewing it but ran out of time...
>
> I think it would be a good thing to have this list checked before the
> svn move and I hope to find some time to help.
>
> mail.jar seems to be another problem seems but this could be replaced
> with a version from Geronimo or Glassfish
>
> Christian
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[davidnwelton]

A consistent part of the answers I got from the ASF folks indicate
that subdividing permissions within a project isn't viewed all that
well.  If that's what you guys decide you need, we will make it happen
for you, but might it be a good moment to try an experiment and have a
process more along the lines of "please don't step on toes - it's a
good idea to ask prior to committing outside your area of expertise",
and 'enforce' that by keeping a sharp eye on the commits mailing list?

Entirely up to you guys to decide, but at the practical level, it
would also make things just a bit easier in the time before OFBiz
becomes a full-fledged top level Apache project.

BTW, the efforts you guys have put in to collect icla's and remove the
LGPL code are impressive, and reflect really well on the whole ASF
transition.

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Andrew Sykes]

David,

On Tue, 2006-05-30 at 11:36 +0200, David Welton wrote:
> A consistent part of the answers I got from the ASF folks indicate
> that subdividing permissions within a project isn't viewed all that
> well.

Given the scale of OFBiz, it's not just a case of people asking when
they don't know how something works, but also when they think they do.
There are any number of examples of patches that look perfectly fine to
an outside observer, but to the person who owns that part of the code,
they are far from that.

I'm rather nervous at the idea of commit privileges changing, because
they form part of a fairly mature way of working and would probably
adversely effect QA.

OFBiz developers are under time pressure from the projects that fund
OFBiz development. Offering a route to circumvent the normal commit
process is probably a bad thing as it would most likely reduce scrutiny.
--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[davidnwelton]

On 5/30/06, Andrew Sykes <[hidden email]> wrote:

> On Tue, 2006-05-30 at 11:36 +0200, David Welton wrote:
> > A consistent part of the answers I got from the ASF folks indicate
> > that subdividing permissions within a project isn't viewed all that
> > well.

> Given the scale of OFBiz, it's not just a case of people asking when
> they don't know how something works, but also when they think they do.
> There are any number of examples of patches that look perfectly fine to
> an outside observer, but to the person who owns that part of the code,
> they are far from that.

> I'm rather nervous at the idea of commit privileges changing, because
> they form part of a fairly mature way of working and would probably
> adversely effect QA.

> OFBiz developers are under time pressure from the projects that fund
> OFBiz development. Offering a route to circumvent the normal commit
> process is probably a bad thing as it would most likely reduce scrutiny.

Like I said, if the consensus is not to change, it certainly won't be
forced on you - I was suggesting that it might be an opportune moment
to reflect on whether it's the best way forward.

Clearly, utilizing svn permissions has advantages in terms of control
and helping people to 'avoid temptation'.  One might make the counter
argument that in a group like the ASF, the preferred way of working is
to create the right community climate so that people are discouraged
from doing the 'wrong thing' via social pressure, respect for, and
trust in the next guy rather than a technical barrier.  Not to say
that those things are lacking if the technical barrier is the
preferred route, but perhaps it becomes more critical to foster them
to ensure the smooth flow of development.

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Ray Barlow]

Given the success that the ASF have shown within the work that they
already do it would suggest that the change of perspective might not be
as bad as it sounds. Certainly control has to be handled through some
mechanism but by the very nature of giving a person any commit access
you are allowing them a level of trust, which they could abuse but it
wont really be in their interest to do so.

Peer review of changes will still take place and any one deemed to be
consistently miss using any trust they are given by the group/community
can also have that access removed. Certainly committers should be clear
about the modules they can commit to and who other modules are owned by
and they should seek clearance before committing changes outside of
their scope.

You could suggest that this also might save the core developers (module
owners) a small amount of time, depending on the change how they review
it. For changes where they can review just the patch file direct they
will only need to give the all clear and the submitter can then take
care of committing, saving the reviewer the time taken to download,
apply and commit the patch with comments etc.

Ray



David Welton wrote:

>On 5/30/06, Andrew Sykes <[hidden email]> wrote:
>
>  
>
>>On Tue, 2006-05-30 at 11:36 +0200, David Welton wrote:
>>    
>>
>>>A consistent part of the answers I got from the ASF folks indicate
>>>that subdividing permissions within a project isn't viewed all that
>>>well.
>>>      
>>>
>>Given the scale of OFBiz, it's not just a case of people asking when
>>they don't know how something works, but also when they think they do.
>>There are any number of examples of patches that look perfectly fine to
>>an outside observer, but to the person who owns that part of the code,
>>they are far from that.
>>    
>>
>>I'm rather nervous at the idea of commit privileges changing, because
>>they form part of a fairly mature way of working and would probably
>>adversely effect QA.
>>    
>>
>>OFBiz developers are under time pressure from the projects that fund
>>OFBiz development. Offering a route to circumvent the normal commit
>>process is probably a bad thing as it would most likely reduce scrutiny.
>>    
>>
>
>Like I said, if the consensus is not to change, it certainly won't be
>forced on you - I was suggesting that it might be an opportune moment
>to reflect on whether it's the best way forward.
>
>Clearly, utilizing svn permissions has advantages in terms of control
>and helping people to 'avoid temptation'.  One might make the counter
>argument that in a group like the ASF, the preferred way of working is
>to create the right community climate so that people are discouraged
>from doing the 'wrong thing' via social pressure, respect for, and
>trust in the next guy rather than a technical barrier.  Not to say
>that those things are lacking if the technical barrier is the
>preferred route, but perhaps it becomes more critical to foster them
>to ensure the smooth flow of development.
>
>  
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

I was pretty resistant to this more global approach at first, but am warming to it as a possibility... especially since OFBiz is becoming more and more committee driven.

Before going on I should that I've tried to discourage the "ownership" idea of any of the code in OFBiz, regardless of who wrote it or is current working on or maintaining it.

The real point, and this I think is somewhat new for an Apache project, is that OFBiz is fairly large and different parts require very different expertise and knowledge. As Andrew pointed out issues can (and have a bit...) arise from people not having sufficient experience with something and putting in something they think is fine.

It is true that the commits are monitored by various people, and that is why I'm considering this going forward. Even with the current technical controls there have been instances where something less than ideal was committed that served a particular need, perhaps for a particular client, but broke other more general things that were more important. These have resulted in discussion and being fixed, and hopefully that will continue (and in some cases with less friction... ;) ).

I, and probably others, would be much more comfortable with this if there was at least a distinction between the framework and the applications, and perhaps that will come in the near future as we've been talking about splitting these for a long time. If we get a TLP position then maybe we'll get these split out as sub-projects with separate repositories or something...

-David


Ray Barlow wrote:

> Given the success that the ASF have shown within the work that they
> already do it would suggest that the change of perspective might not be
> as bad as it sounds. Certainly control has to be handled through some
> mechanism but by the very nature of giving a person any commit access
> you are allowing them a level of trust, which they could abuse but it
> wont really be in their interest to do so.
>
> Peer review of changes will still take place and any one deemed to be
> consistently miss using any trust they are given by the group/community
> can also have that access removed. Certainly committers should be clear
> about the modules they can commit to and who other modules are owned by
> and they should seek clearance before committing changes outside of
> their scope.
>
> You could suggest that this also might save the core developers (module
> owners) a small amount of time, depending on the change how they review
> it. For changes where they can review just the patch file direct they
> will only need to give the all clear and the submitter can then take
> care of committing, saving the reviewer the time taken to download,
> apply and commit the patch with comments etc.
>
> Ray
>
>
>
> David Welton wrote:
>
>> On 5/30/06, Andrew Sykes <[hidden email]> wrote:
>>
>>  
>>
>>> On Tue, 2006-05-30 at 11:36 +0200, David Welton wrote:
>>>    
>>>
>>>> A consistent part of the answers I got from the ASF folks indicate
>>>> that subdividing permissions within a project isn't viewed all that
>>>> well.
>>>>      
>>>>
>>> Given the scale of OFBiz, it's not just a case of people asking when
>>> they don't know how something works, but also when they think they do.
>>> There are any number of examples of patches that look perfectly fine to
>>> an outside observer, but to the person who owns that part of the code,
>>> they are far from that.
>>>    
>>>
>>> I'm rather nervous at the idea of commit privileges changing, because
>>> they form part of a fairly mature way of working and would probably
>>> adversely effect QA.
>>>    
>>>
>>> OFBiz developers are under time pressure from the projects that fund
>>> OFBiz development. Offering a route to circumvent the normal commit
>>> process is probably a bad thing as it would most likely reduce scrutiny.
>>>    
>>>
>> Like I said, if the consensus is not to change, it certainly won't be
>> forced on you - I was suggesting that it might be an opportune moment
>> to reflect on whether it's the best way forward.
>>
>> Clearly, utilizing svn permissions has advantages in terms of control
>> and helping people to 'avoid temptation'.  One might make the counter
>> argument that in a group like the ASF, the preferred way of working is
>> to create the right community climate so that people are discouraged
>>from doing the 'wrong thing' via social pressure, respect for, and
>> trust in the next guy rather than a technical barrier.  Not to say
>> that those things are lacking if the technical barrier is the
>> preferred route, but perhaps it becomes more critical to foster them
>> to ensure the smooth flow of development.
>>
>>  
>>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

This is taken care of in SVN rev 7721.

For anyone watching in: I didn't test this new code as I'm not sure of a good example, so if anyone runs into an issue with it let me know...

-David


Jacopo Cappellato wrote:

> As pointed out by crisg in
> http://ofbizwiki.go-integral.com/Wiki.jsp?page=LibrariesIncludedInOFBiz
>
> the xom-1.0d25.jar in the framework/webapp component is licensed under
> the LGPL license.
>
> After a quick review it seems that the code that is using it is in the
> we webapp component: org.ofbiz.webapp.barcode.*
>
> The three classes there define an OFBiz transform ("barcodeTransform")
> that is initiated in the FreeMarkerWorker class; however the tag is not
> really used in the system.
>
> So I think we should move this stuff under the specialized folder.
>
> Jacopo
>
>
> Andrew Sykes wrote:
>> David,
>>
>> I can imagine that having a split applications and framework layout
>> would lead to lots of posts to the mailing list asking why a specific
>> combination of the two weren't working. Obviously an increase in the
>> number of people generating content that says OFBiz doesn't work isn't
>> really good for the brand profile.
>>
>> Although it would make downloading quicker!
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[davidnwelton]

> The real point, and this I think is somewhat new for an Apache project, is that OFBiz is fairly large and different parts require very different expertise and knowledge. As Andrew pointed out issues can (and have a bit...) arise from people not having sufficient experience with something and putting in something they think is fine.

No argument that it's large, complex, and contains functional areas
that are quite different from one another - especially with regards to
'real world knowledge' needed to work on them (accounting,
manufacturing and so on).  There are other big, complex ASF projects,
though - Geronimo and Harmony come to mind.

> It is true that the commits are monitored by various people, and that is why I'm considering this going forward. Even with the current technical controls there have been instances where something less than ideal was committed that served a particular need, perhaps for a particular client, but broke other more general things that were more important. These have resulted in discussion and being fixed, and hopefully that will continue (and in some cases with less friction... ;) ).

You could always give it a try and if it doesn't work, add some restrictions.

> I, and probably others, would be much more comfortable with this if there was at least a distinction between the framework and the applications, and perhaps that will come in the near future as we've been talking about splitting these for a long time. If we get a TLP position then maybe we'll get these split out as sub-projects with separate repositories or something...

You'd want to try and be careful to avoid having a subproject run by
only one or two people, but I think on the whole it might be
beneficial as it would also give the framework some room to build up
some momentum of its own outside of OFBiz.

I think the distinction really comes down to people being cognizant of
what they know and don't know - if someone can't be trusted to be
careful with a portion of code, even after a warning to be careful and
not stomp on it, they might not be the sort of 'community minded'
individuals that you want to hand the keys to in any case... ?

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Andrew Sykes]

David,

On Wed, 2006-05-31 at 13:33 +0200, David Welton wrote:
> I think the distinction really comes down to people being cognizant of
> what they know and don't know - if someone can't be trusted to be
> careful with a portion of code, even after a warning to be careful and
> not stomp on it, they might not be the sort of 'community minded'
> individuals that you want to hand the keys to in any case... ?

The problem with this idea is, that by definition, it's very difficult
to know what you don't know - especially when there's so much to, er,
not know.

It may work out fine, and it would certainly make an interesting
experiment, but it would be a shame if a massive increase in interest
coincided with a lot of muddled revisions, thus negatively impacting
uptake.

Anyway, I'm not opposed to it as a way of working, as I have no hard
evidence to corroborate that position. Do you think that productivity
could be improved or is currently stifled etc?
--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

This is an interesting thread.
If I'm not wrong, the main admin problems in granting fine-grained
commit privileges are caused by the fact that, while OFBiz is in the
Incubator, all the admin tasks are managed by the Incubator PMC. When
(if!) OFBiz will become a TLP project at Apache, things will be easier.
So, this could be probably a good chance to make this experiment, in
fact the number of committers is at the moment rather small (7 persons).

Just my 2 cents.

Jacopo

Andrew Sykes wrote:

> David,
>
> On Wed, 2006-05-31 at 13:33 +0200, David Welton wrote:
>> I think the distinction really comes down to people being cognizant of
>> what they know and don't know - if someone can't be trusted to be
>> careful with a portion of code, even after a warning to be careful and
>> not stomp on it, they might not be the sort of 'community minded'
>> individuals that you want to hand the keys to in any case... ?
>
> The problem with this idea is, that by definition, it's very difficult
> to know what you don't know - especially when there's so much to, er,
> not know.
>
> It may work out fine, and it would certainly make an interesting
> experiment, but it would be a shame if a massive increase in interest
> coincided with a lot of muddled revisions, thus negatively impacting
> uptake.
>
> Anyway, I'm not opposed to it as a way of working, as I have no hard
> evidence to corroborate that position. Do you think that productivity
> could be improved or is currently stifled etc?

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev