Re: [DISCUSSION] R16 and R17: email password issue and releases

[Michael Brohl]

According to 
https://issues.apache.org/jira/projects/OFBIZ/versions/12338772 there is 
not too much to do to get the r17 branch issues solved.


We could start an initiative to check the issues and their relevance, 
fix the remaining and and do the release.


What do you think?

Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 22.01.20 um 12:11 schrieb Michael Brohl:
I am also in favor to get the r17 Branch released soon and not 
skipping it.


Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 09.10.19 um 11:56 schrieb Deepak Dixit:

Yes Jacques,
We can make 16 as old, release R17 as current release (once we 
officially

released it), start working on R18 to make it ready for release.

Kind Regards,
Deepak Dixit


On Wed, Oct 9, 2019 at 1:01 PM Jacques Le Roux 


wrote:


Hi Deepak,

I have no problems with that. For demo R16 would stay our stable or we
could have it as old but not deprecated for instance? Ie we would 
continue

to
maintain R16 (as we currently do as much as possible) it but not 
demo it

and demo R17 as stable, right?

Jacques

Le 09/10/2019 à 08:19, Deepak Dixit a écrit :
I think due to one feature/bug skipping R17 is not good idea, I'll 
try to

backport this work to R17.
We all are working since long to make R17 stable, and I think R17 
is in

good shape.

Making R16 deprecate, I think we need to think about Release life 
cycle,

release should have at least 5-7 year of life span. As a developer
perspective it's easy to switch to new branch, but as a user 
perspective

its not easy to switch to new branch frequently.


Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org


On Sat, Sep 28, 2019 at 5:11 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi,

As reported by Rashi Dhagat in OFBIZ-11215 "Email password is not

working"

in R16, and actually nor in R17.

It has been fixed in trunk and R18 with OFBIZ-4361. As mentioned 
there,

it's hard to backport to R17 not even speaking about R16!

I wonder if a case like that would not make R16 deprecated and 
start to

release R18, skipping R17.

Of course if people has the time, the nerves and the guts to 
backport to

R17 and R16 they are welcome

What do you think?

Jacques








smime.p7s
Description: S/MIME Cryptographic Signature

Re: [DISCUSSION] R16 and R17: email password issue and releases

[Michael Brohl]

I am also in favor to get the r17 Branch released soon and not skipping it.

Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 09.10.19 um 11:56 schrieb Deepak Dixit:

Yes Jacques,
We can make 16 as old, release R17 as current release (once we officially
released it), start working on R18 to make it ready for release.

Kind Regards,
Deepak Dixit


On Wed, Oct 9, 2019 at 1:01 PM Jacques Le Roux 
wrote:


Hi Deepak,

I have no problems with that. For demo R16 would stay our stable or we
could have it as old but not deprecated for instance? Ie we would continue
to
maintain R16 (as we currently do as much as possible) it but not demo it
and demo R17 as stable, right?

Jacques

Le 09/10/2019 à 08:19, Deepak Dixit a écrit :

I think due to one feature/bug skipping R17 is not good idea, I'll try to
backport this work to R17.
We all are working since long to make R17 stable, and I think R17 is in
good shape.

Making R16 deprecate, I think we need to think about Release life cycle,
release should have at least 5-7 year of life span. As a developer
perspective it's easy to switch to new branch, but as a user perspective
its not easy to switch to new branch frequently.


Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org


On Sat, Sep 28, 2019 at 5:11 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi,

As reported by Rashi Dhagat in OFBIZ-11215 "Email password is not

working"

in R16, and actually nor in R17.

It has been fixed in trunk and R18 with OFBIZ-4361. As mentioned there,
it's hard to backport to R17 not even speaking about R16!

I wonder if a case like that would not make R16 deprecated and start to
release R18, skipping R17.

Of course if people has the time, the nerves and the guts to backport to
R17 and R16 they are welcome

What do you think?

Jacques






smime.p7s
Description: S/MIME Cryptographic Signature

Re: Welcome to Olivier Heintz as new committer!

[Michael Brohl]

Congratulations and welcome on board, Olivier!

Michael


Am 16.01.20 um 15:23 schrieb Taher Alkhateeb:

The OFBiz PMC has invited Olivier Heintz to become a new committer and
we are happy to announce that he has accepted this role.

Some of the reasons for inviting Olivier Heintz include:

- He is invested in the OFBiz project and has been a member for many years
- He is taking an initiative towards improving the UI part of the system
- He has functional experience in various areas of the framework
- He enjoys working with the community and collaborating with others

Please join me in welcoming and congratulating Olivier!

Cheers,
Taher Alkhateeb




smime.p7s
Description: S/MIME Cryptographic Signature

Re: OFBiz features/functions overview in the wild

[Michael Brohl]

Just to keep you updated: we have contacted the site owner and got no 
answer yet. We also contacted the German site owner.


We are waiting for a reply until end of the week and try again if there 
is no answer.


Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 10.01.20 um 14:35 schrieb Michael Brohl:
This is the english version: 
https://www.capterra.com/p/164046/Apache-OFBiz/


There are similar websites providing such informations with very 
different quality. In a few occasions where I tried to get the data 
updated/corrected I learned that I would have to pay for it. Seems 
most of them are targeted to commercial software vendors.


It would be interesting how it works on this website. If there isn't 
anyone working on this I'll see if our team can clarify with the 
website owner.


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 09.01.20 um 10:45 schrieb Pierre Smits:

Hi Jacques,

There are (as far as I can tell) 3 possibilities where this is coming 
from:


    1. It is automagically scraped from our official documentation (by
    crawling through our pages on the site and wiki) and collated
    2. it is taken from what is in the definition on
    https://projects.apache.org
    3. it is a manual action to provide that information (when this 
Dutch

    site is different from others)

Regarding aspects 1 and 2 the solution would be to insert the applicable
and appropriate keywords in our artefacts, so that they get reflected in
such sites.

Digging a little into the website I found that it is US based and
affiliated with Gartner.

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without 
privileges)

since 2008*
Apache Steve , committer


On Thu, Jan 9, 2020 at 10:31 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Pierre,

Right, how can we fix that though?

Jacques

Le 09/01/2020 à 10:01, Pierre Smits a écrit :

Hi all,

Recently I came across this Dutch website (
https://www.capterra.nl/software/164046/apache-ofbiz)  that states
functions about our product. I don’t know where this originated but I
presume somewhere data is is pulled/scraped from our official 
elements.


The most important thing I want to bring to the attention of this

community
is that under the functions section (I am confident you can find 
similar
sites in your country/language that shows the same) it does NOT 
highlight

key features/functions like purchasing, order management, planning,

project

and time management. This should be corrected asap.

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without

privileges)

since 2008*
Apache Steve , committer








smime.p7s
Description: S/MIME Cryptographic Signature

Re: What is OFBiz public API?

[Michael Brohl]

HI Piere,

inline...


Am 21.01.20 um 15:56 schrieb Pierre Smits:

Hi all,

The mission of the project is, in line with the ASF, to provide software
for the greater good and offering (potential) adopters a choice. In the
projects case this is done through providing the OFBiz works (each and all
products, as well as the supporting tooling for enabling contributors like
JIRA, Github services, etc.)

Agreed and in no way questioned in the preceding discussions.


The project has since its inception as a TLP made it clear, with the above
in mind, that the the project is not responsible for the choices a
(potential) adopter has made, nor that it will be held responsible for the
future choices of an adopter.


Of course we are not held responsible in a legal sense. But we (should) 
feel responsibility towards the users of the project and maintain it in 
a way which is in good balance between the user base needs and the 
contributions made to improve it.



This means, when talking about the code of the main OFBiz product, the
project does not care whether an adopter (being it either an enterprise
having OFBiz implemented, or a service integrator offering services and/or
solutions for payment or not) uses, enhances or diminishes the OFBiz
functionalities in upstream activities.


Where do I find this anywhere in the statutes of the project?

I strongly disagree with this statement. If we propagate that we don't 
care about the users and change the codebase, functionality and 
mechanisms without thinking about backwards compatibility, breaking 
existing projects and even don't support users with the documentation of 
a migration path, we will damage the projects' reputation.


This is not a playground project, it is used in serious businesses and 
we should have this in mind when changing things.


This is my main concern with the approach leading to the preceding 
discussion.




The project has also made clear in communications to every kind of
community member and adopter, that for use, enhancement or diminishment of
OFBiz functionalities in his environment of development and service
delivery the adopter should always start from releases and not from the
volatile trunk repositories.
Unfortunately, there have been (and are) several prominent members of the
OFBiz community that have made assertions that it was quite ok for adopters
to start with the code in the trunk branch of the repo for their own
develop and/or implementation.


Can you please point us to the source of these claims?


When these community members propagate this start-with-trunk paradigm in
their upstream needs-and-wants model, they tend to shoot in their own foot.
But instead of acknowledging that they took a wrong turn and remediate that
situation, they elect to bring their problem down to the OFBiz project and
demand that the other contributor removes this undesirable change from the
OFBiz code base, in order to keep the upstream deviation minimally
disrupted.


This seems to be very speculative to me. Where does the information for 
this claim come from?


The trunk is the source for the next stable branch and every change made 
there will sooner or later be in a next release and will have effects on 
users who will use it.


As a responsible developer, changes made to the codebase, especially if 
they are made to support a future change/improvement/refactoring, should 
be well planned, discussion, proved if they are really wanted/needed etc.


Another problem is that trunk receives a mix of functionality 
enhancements and improvements for the business part and also core 
improvements which might need a long time to be implemented (an example 
might be the initiative to make the framework container independent).


If we want to have shorter release cycles to bring the functionality 
updates to the users, this is in conflict with the improvements which 
needs more time to be implemented and thorougly tested. This is the 
reason why I would prefer to do these implementations in a feature 
branch which will be held up-to-date with trunk and allows experimental 
implementations without breaking anything. This is the classical and 
logical way when maintaining a product.


If you would see the project as a software development company which 
sells a product, this company would never start long-lasting 
developments in the base branch for the next release.


Release management and a clear roadmap would help, maybe a dicussion for 
another thread.




Given what Mathieu has brought forward regarding the 'depends-on'
enhancement of the OFBiz functionality, it is clear that it strengthens and
enhances understandings regarding the OFBiz product and its intricacies
(where the code is the documentation).


In this case, there seem to be plans in the minds of contributors which 
lead to the discussed changes. These plans are neither documented nor 
discussed in depth so that it is possible to make decisions. This is my 
main concern.


I also gave