I don't know anything but I will help wherever ignorance is some sort of
advantage to the process.
Ron
On 14/11/2014 9:13 AM, Pierre Smits wrote:
You'll be the first?
Verstuurd vanaf mijn iPad
Op 14 nov. 2014 om 14:26 heeft Ron Wheeler <rwhee...@artifact-software.com> het
volgende geschreven:
Can we start by separating the list into
Case 1 - Required. Were released in the past so have an implied warranty,
known to be used in production situations, were part of previous releases or
have current activity
Case 2 - Definitely don't need. Never finished. Tests that never worked.
Case 3 - Not sure. Can not remember who started this.
This would add some specificity to the discussion and would allow people to
come forward with objections or offers of support.
Can we start to develop a KB about what modules interfere with other modules,
where this shows up and how does one fix the problem if we need to run multiple
modules that normally interfere?
This would help determine the work required to support releasing them and might
lead to useful discussions about dynamic configuration tools that allow
conflicting modules to co-exist.
Is there a wiki page for each of the case 1 modules?
Do we have volunteers to create and maintain the wiki pages at least?
Ron
On 14/11/2014 7:55 AM, Jacques Le Roux wrote:
I think we need to be sure of what we are doing.
1st question, is why in the 1st place we did that? What pushed us to do so?
Jacques
Le 14/11/2014 12:47, Jacopo Cappellato a écrit :
What is your preference? Would you like to see them all in the release
packages? Some of them only? Which ones?
On Fri, Nov 14, 2014 at 12:38 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
This is the easiest part, I was more thinking about how much is downloaded
by users.
Anyway this was just an idea to help user to cope with missing
specialpurpose components in released packages.
Now a question comes to my mind, I don't clearly remember the reasons we
decided to remove them. Why keeping them in the releases branches but not
not in released packages is not clear to me.
I believe Jacopo kind of answered at http://markmail.org/message/
w3xw6lipifdeks3z
Actually we need to clarify 1st which components to keep active in release
branches. For now it seems only ecommerce which is for me too restrictive.
And then discuss about why not doing the same in released packages (sorry
if I missed some arguments here).
For that we need first to exactly know which components affect which ones.
I believe at this stage we don't want to send any specialpurpose component
to Attic, but this might be discussed also.
Jacques
Le 13/11/2014 22:51, Pierre Smits a écrit :
That is not difficult to assess. Do a download from trunk, and see how
many Mb's are transferred. Do a ./ant clean-all. Subsequently remove all
hidden files in .svn folders. Finally do a zip of the cleaned download and
compare the original amount of Mb's with the size of the zip file. That
difference is what is saved on storage and transfer cost of trunk code.
Now multiply that with the number of branches you had in mind.
Verstuurd vanaf mijn iPad
Op 13 nov. 2014 om 22:32 heeft Jacques Le Roux <
jacques.le.r...@les7arts.com> het volgende geschreven:
Le 13/11/2014 21:25, Ron Wheeler a écrit :
Is it Apache's concern that while people may be free to choose, ASF
server capacity is not free nor unlimited?
I doubt that OFBiz really puts a big load on the ASF infrastructure but
users are not supposed to be downloading from the SVN.
They are supposed to get downloads from local mirrors.
You said it :) At the moment I don't fear any overload on the svn server
from users downloading from releases branches instead of released packages.
OFBiz is not Tomcat ;)
But I must say I have no measures, so you got a point until-we/if-we-can
discover that. Because users can already do that, I think it's fair to use
this method as long as it's reasonable.
Of course, having that suggested in a TLP project could be viewed as an
abuse from the Board, but let's be pragmatic, numbers should tell us the
truth (if can get them)
That may be the practical side of Apache's urging to get the releases
following their guidelines.
Yes for Tomcat, HTTPD or such that's understandable. For OFBiz I "fear"
it's not a problem. Can we discuss with the board in case, instead of
hiding behind unknown numbers?
Jacques
Ron
On 13/11/2014 3:13 PM, Jacques Le Roux wrote:
Le 13/11/2014 20:03, Ron Wheeler a écrit :
Does this solve ASF's issue about having users access the main
servers?
I don't try to solve an issue, just to propose an alternative. It's a
free user choice, but with more elements
What do you put on the mirrors and how do you stop users from
accessing the development SVN which is ASF's concern?
Things stay as they are, it's only that we inform our users than
another way is possible and we give them enough elements of comparison to
choice, it's called freedom
Jacques
Ron
On 13/11/2014 1:55 PM, Jacques Le Roux wrote:
For the licence free issues (an other related stuff) we could put a
disclaimer in the wiki page where all alternatives would be explained
Jacques
Le 13/11/2014 12:38, Jacopo Cappellato a écrit :
In the past the ASF Board asked to the OFBiz PMC to fix the release
strategy of the project by providing officially voted release files
thru
the ASF mirrors: at that time we were pushing the users to get the
trunk.
Officially asking the user to use a release branch would be better
than the
trunk but would bring back similar concerns: an official vote is
required
to publish a product to the outside of the project in order to
guarantee
License free issues etc...
On Thu, Nov 13, 2014 at 11:38 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Hi,
In a recent user ML threadhttp://markmail.org/
message/ivjocjr2ull7lwqe I
suggested we could propose our users to use a release branch
strategy
rather than downloaded packages.
And that we could expose this way of doing in our download page,
or maybe
better with a link to an explaining page (in details) in the wiki.
I know it's not the recommended way of doing at the ASF. But we
all know
the OFBiz differences when compared with other TLPs which are
mostly libs,
and even mostly jars.
Most of us are actually using this way in their custom projects
and I have
a feeling it would not only help our users but also us to support
them.
What do you think?
Jacques
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
