Le 27/11/2014 16:30, Jacopo Cappellato a écrit :
On Nov 27, 2014, at 3:16 PM, Jacques Le Roux <[email protected]> 
wrote:

Hi Jacopo,

I looked a bit back. Even if it's not clearly related I trace this back to the 
slim-down effort. We can forget it since nobody never complained (pfew...).

Then you proposed to move some component from specialpurpose to extras.
As you said, not every people were happy with it (at least Pierre and in a less 
measure I)
I then suggested some components to keep markmail.org/message/4camcprzximkcftc

<<assetmaint
ecommerce
example*
pos
maybe myportal?
projectmgr
scrum
and maybe webpos?>>

In a very recent thread http://markmail.org/message/ctusiepnuciofc32 I 
suggested to associate people with components
I don't like the idea of associating code to persons: this is not in line with 
the spirit of the project in the ASF. Once the code has been contributed, it is 
owned by the community and not by a group of persons.

Don't get me wrong, this is only to remind who are the interested persons and hopefully those who can help to maintain and contribute. The volunteers you seek below.

As regards the list of components, I am having an hard time at following what 
you would like to release or not: could you please (changing the subject would 
be great) provide the list of components that you think are worth of being part 
of the release and why?

Yes I thought about create a new thread for that but since you asked, I 
answered :).
I always like to have references that was also the reason of this message, a 
kind of summary of my thoughts and of the situation as I see it.

Others will comment with their own.
In this way we will understand how many volunteers we have to maintain them, 
make sure the vulnerabilities are fixed, that they comply the analysis 
performed by tools like RAT etc...

Just one (important) clarification: we are talking about the components that 
you would like to have in the releases, not the component that should go to 
attic.

Do we want to keep all current components (some disabled) until we decide those which should go to Attic? For instance we already kind of spoke about appserver going to Attic. This could be decided before for some components; the less components, the less discussions. But yes, we can go with separate discussions, or we will see that later...

One final point: do we all agree that all the components that either override the web 
applications of other components or modify the entities defined by other components or 
override service definitions in order to provide more specialized features should be set 
as "disabled" by default? In my opinion this is an important point because 
otherwise, even when you install OFBiz in production (ant load-seed) you will get a data 
model with a specialized set of fields. Special components and special behavior can be 
released but should be disabled by default.

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

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.

Everybody agree?

Jacques


Best regards,

Jacopo

<<project manager (Pierre Smits?)

    scrum (Hans?)

    examples and ext (at least me)

    myportal (French people use portals, not sure for myportal?)
When I look now at my 1st list, obviously I can also support the POS even if I 
have less interest in it now.

Pierre at http://markmail.org/message/n23oyye2i24kqzpg suggested
HHFacility, ASSETMAINT, CMSSITE, PROJECTMGR, MYPORTAL, SCRUM, etc.
I don't like the etc. ;) but I can agree to add
HHFacility and CMSSITE to my list

Also in this list birt is missing, clearly at least Chatree has an interest in 
it and knows how to maintain it.
I don't know if Anil or/and Adrian have still an interest in ASSETMAINT but 
anyway it seems it's worth to keep it.
HHFacility does not need much work to maintain
For CMSSITE I'm unsure, but it's interesting for the online help (too bad BJ is 
no longer with us)
BTWcmssite/cms/APACHE_OFBIZ_HTML  
<https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML>  is no 
longer working (was still in August in trunk demo) I will investigate why

At http://markmail.org/message/5dbs3g3vbdfo7dlx I wrote
<<A moment I even thought about Attic for some unmaintained components
(ebaystore?, googlebase?, googlecheckout?, jetty?, webpos?, ...), WHO
cares?>>

But this is not a good idea. Obviously we have some responsabilities with our 
users.
Now I still wonder about who is really using appserver, ebaystore, googlebase, 
googlecheckou, oagis and jetty components...

This is what I can say so far

HTH

Jacques


Le 14/11/2014 14:20, Jacopo Cappellato a écrit :
It was a long discussion that was done in the public lists and I wouldn't
want to rehash it (you have been part of it for sure): there were concerns
and discussions about duplicated jars, poor quality code, stale code, files
with questionable licenses etc... on the other side there were people
worried about removing features from the system etc...
I think it would be better to address each component individually and,
since you would like to "cope with missing specialpurpose components in
released packages", this is why I am asking you what are the components
that should be included in the trunk/release branch/releases.

Jacopo

On Fri, Nov 14, 2014 at 1:55 PM, Jacques Le Roux <
[email protected]> 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 <
[email protected]> 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 <

[email protected]> 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 <
[email protected]> 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






Reply via email to