Regards
Scott
On Sat, Nov 29, 2014 at 3:49 PM, Ron Wheeler
<rwhee...@artifact-software.com
<mailto:rwhee...@artifact-software.com>> wrote:
On 28/11/2014 9:38 PM, Scott Gray wrote:
OFBiz itself went through that on a much larger scale when
joining the ASF.
It took some time but it wasn't a big deal.
No users are forced to do anything other than make a choice:
stick with
what you have or change to what is now available. Open source
users make
these types of decisions on a regular basis.
Your statement is generally are correct but in this context, it
related to the suggestion about (#5) deleting Asset Management
from OFBiz.
Regards
Scott
On 29 Nov 2014 14:51, "Ron Wheeler"
<rwhee...@artifact-software.com
<mailto:rwhee...@artifact-software.com>> wrote:
Don't forget to get ICLAs and Corporate CLAs for the new
site for each
contributor otherwise you will have trouble if you want to
submit it to
Apache OFBiz in the future.
I guess that if you offer it under an Apache license
without having an
ICLA /CCLA in place, you would be personally liable for
any claim by
contributors in the future.
Not sure that you can/should force any existing users to
move to the new
project.
Perhaps no one is using it so #5 is not a problem but I am
not sure how
you can reach all of the people who have downloaded it.
Ron
On 28/11/2014 7:54 PM, Scott Gray wrote:
Hi Adrian,
Sounds like a good plan to me. I think there should
probably be some sort
of a delay in step #5 and it should ultimately be
decided by a PMC vote at
that point in time as well. I totally support the
concept though.
Regards
Scott
On Sat, Nov 29, 2014 at 5:20 AM, Adrian Crum <
adrian.c...@sandglass-software.com
<mailto:adrian.c...@sandglass-software.com>> wrote:
As has been discussed in this thread, we can spin
off special purpose
components to their own projects - where they can
form their own
communities and support structure.
I am willing to use the Asset Maintenance
component as a trial run. Here
are some of my initial thoughts, comments are welcome:
1. Check with the ASF legal department before
doing anything.
2. Create a project on a popular hosting site
(like SourceForge, but it
could be anywhere).
3. Set up initial committers.
4. Notify the OFBiz mailing lists about the new
project.
5. Drop the Asset Maintenance component from the
ASF repo.
The component would maintain the ASL 2 license.
Support for various
versions of OFBiz will be decided by the Asset
Maintenance community.
If the spin-off is a success, then all is good. If
it fails, then the
Asset Maintenance component is added back to the
ASF repo.
Adrian Crum
Sandglass Software
www.sandglass-software.com
<http://www.sandglass-software.com>
On 11/28/2014 4:01 PM, Ron Wheeler wrote:
The components not supported as part of the core
and framework would not
leave Apache.
They become separate sub-projects under OFBiz
so that they stay in the
community but are released and supported
separately so that there is
more transparency about their state.
The release of new core and framework versions
gets easier.
The implied warranties get clearer and the
sub-communities supporting
each of the non-core components are :
-easier to identify
- free to set their own roadmaps based on the
needs and the resources
- easier to join since you only need to learn
a small set of code in
order to contribute
- do not affect the core and framework code,
roadmap or release plans
except when they request extensions to the
core or framework through
JIRA issues.
The core and framework team will not have to
worry about the side
components unless they belong to the
sub-project and can release with a
full warranty.
Ron
On 28/11/2014 10:30 AM, gil portenseigne wrote:
First I might be a bit confuse in this
email, sorry for that, quite
ideas came up while writing it, some
organization missing.
Le 28/11/2014 14:31, Ron Wheeler a écrit :
What is the downside if the non-core
components are released on their
own with a clear set of documentation
that describes the state of the
component?
I guess there is none at first
glance, it's quite the same idea :
- A big release with core components
active, and non-core component
unactive (with included documentations)
A monolythique one, all-included...
- A Core release, first with then optional
non-core component releases
with their own documentations
A core with packages. Less heavy but more
actions... not a problem
The things that make me wonder, and that's
we try to achieve for
several years with an extension management
tool, are all the deviance
possible without the control of such an
Apache project.
It is Out of Apache ! The component
community can build their own
component at the speed they need (often
dependant on a personal
project), without the quality control.
It's good for this side
community, we are already doing that in
our way. But can lead to a
branch component, which can't be
contributed anymore to OFBiz if
needed (for any reasons I guess).
Why not stick with Apache OFBiz in
contributing more, into
desactivated non-core component using the
side community advancement,
and managing to level up these non-core
quality too make them stable
and reliable into Apache OFBiz.
Specifics devs that can't be contributed
into OFBiz, will remain as
extension into the side community.
If side community meets some deviance in
his evolution, not following
Apache OFBiz way, it must not have
consequences like removing these
non-core component from trunk or branches.
That's why i like the idea to have in
Apache OFBiz, release with
unactive components (which can always be
used and follow the Ofbiz
way), and then everyone have the
opportunity to offer other community
components to replace unactive one, or to
add to the core.
Then some questions remains :
- How can user be informed of such side
communities from the OFBiz
official site ? Is that possible ?
- We tried to introduce a new tool to
manage extension (which could be
a solution for the first question,
becoming a tool of indexation ) to
serve this kind of purpose, but their
wasn't much reactions to it. Cf
:
http://ofbiz.markmail.org/message/goxbqcgurpoy2yfp?q=ofbiz-fr
Gil
My feeling is that it is better to
release a clean core and framework
where ALL component are "warranteed"
by the team to be tested and
supported.
Components that are not part of the
core would be released on their
own with the warranty and support
specified on an individual basis.
At least the user community would know
where it stands if it depends
a non-core component to run their
business.
I think this is preferable than
releasing a big conglomeration of
working and non-working software that
the user has to sort through to
figure out if they can make a usable
OFBiz.
It also simplifies the release process
for the core and framework.
Ron
On 28/11/2014 7:18 AM, gil
portenseigne wrote:
Hello all !
I followed the discussion, a bit
late :
Le 28/11/2014 11:24, Jacques Le
Roux a écrit :
Afterthought: we agreed about
having the same setting in both the
releases branches and the
trunk. So if we disable a
component in
the releases branches it will
be also in the trunk.
Then, even we enable tests, we
will not be aware of UI related
issues and globally all those
which are no covered by tests.
Apart
if an users enable the
component and report issues.
This might be a compromise,
but we need our users to be
aware of.
So they will need to be warned
in the download page IMO.
I think it's a good
compromise, warning is needed
to ensure that
user is aware or possible
disfunctionment within these
components.
No tricks needed anymore to import
components from trunk. Good
enough for me.
My opinion is that OOTB
functionnalities are usable but rarely
sufficient for End-User, advanced
skills are needed in each project
to make OFBiz fit the needs. So i
guess there is no harm to let
inactive (uncomplete or so)
component at disposal for user who
might
need them.
Also if you remember this thread
started with my idea of creating a
wiki page to explain to our
users the alternative strategy
of using
release branches rather than
released packages.
I'd like to have a direct link
to this wiki page from the
download
page. This link name could be
simply "alternative strategy".
What
do you think?
Using the same method, i
like the idea.
Gil
I will stop this thread here and
will create a new thread to
discuss the modality of
putting back the
specialpurpose components
in the R13.07 branch.
Jacques
Le 27/11/2014 23:38, Jacques
Le Roux a écrit :
That sounds like a good
enough solution to me
Jacques
Le 27/11/2014 19:41,
Jacopo Cappellato a écrit :
This is a good point. We
could find a way to
programmatically
enable/disable the
components just for
the test run:
./ant
-Denable-all=true
clean-all load-demo
run-tests
but this is just an
idea; we could figure
out the best way to go.
Jacopo
On Nov 27, 2014, at
7:14 PM, Adrian Crum
<adrian.c...@sandglass-software.com
<mailto:adrian.c...@sandglass-software.com>>
wrote:
Be aware that
disabling a component
does two things:
1. Speeds up unit
tests because the
disabled component is
excluded from them.
2. Increases the
chance of
regressions
because the disabled
component is not
being tested.
Adrian Crum
Sandglass Software
www.sandglass-software.com
<http://www.sandglass-software.com>
On 11/27/2014 5:41
PM, Jacopo
Cappellato wrote:
On Nov 27, 2014,
at 6:25 PM,
Jacques Le Roux
<jacques.le.r...@les7arts.com
<mailto:jacques.le.r...@les7arts.com>>
wrote:
Yes, so we
need to define
which are
those
components. So 3
points,
which
should be
discussed
separately
it seems, not
sure of
the order
yet but
probably
this one
1)
Components
to move to
Attic.
They will
be freezed
but still
available
in this
state in
Attic (in
other
words
slowly dying)
2)
Components
to
disable.
They will
be
maintained, but
OOTB
will not
interfere
with other
components
(applications
or
other
specialpurpose)
3)
Components
to keep
enabled.
They must
be
maintained and
have no
interactions
with other
components
Components
enabled
and
disabled
must be
maintained
in the same
way: it is not
that a group
is more
important than
the other.
Also,
disabling a
component
doesn't mean
that it will
not go in
a release: we
could have
disabled
components in
releases and
enabled
components
excluded from
a release or
vice versa.
For the
point 2 we
need to
clarify if it
could applies to
trunk
also. I'd
now tend
to avoid
differences between
trunk
and branch
releases,
at the
functionality
or other
levels.
I agree
that the
same
settings
should be
maintained
in the
trunk and in
the release
branches.
Jacopo
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
<mailto:rwhee...@artifact-software.com>
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
<mailto:rwhee...@artifact-software.com>
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
