A few responses below but all I really have left to say is that if Adrian or anyone else wants to take a fork of any special purpose component and maintain it outside of the OFBiz project then I'm all for it. Assuming those forks made good progress on improving the component then I'd also be in favor of removing the them from OFBiz and helping to promote the external component.
1. So status quo then for sub-projects, what was gained in this regard? 2. Obviously there's a bias there because you're only ever going to see examples of a positive determination when looking at existing sub-projects. 3: > This project is not short of forks. The project is extremely short of external component/add-on forks. I don't care about entire project forks, that's a completely separate topic. I'm aware of very few external "special purpose"-type components and as I've mentioned before I think this is detrimental to the OFBiz product. > Anyone can do this but you lose the advantage of building a team (unless > you pay them). Huh? How exactly do you lose this advantage? Any open source project can build a team simply by being useful enough to enough people. It also leads to duplication of effort and divergent products that dilute > the results and confuses the market. I wasn't aware the component being discussed had any competitors. Regardless, others might argue it leads to innovation. I still think on balance, that it is pretty clear that sub-projects is the > right way to go but it is not a magic solution to the problems in the OFBiz > project and will take some effort to achieve a good result. > There is nothing to stop anyone from doing a private fork but I don't > think that this is a good long-term plan and does nothing to build the > OFBiz community or reduce the workload on the current team. It is very far from clear to me but you've expressed your views numerous times now and if the PMC ever do vote to create a sub-project I'm sure they'll take your opinions into account. Regards Scott On Sat, Nov 29, 2014 at 12:09 PM, Ron Wheeler < rwhee...@artifact-software.com> wrote: > On 28/11/2014 5:49 PM, Scott Gray wrote: > >> Ron, we get that you really like the idea of sub-projects. The only >> positive I can see about a sub-project is that the component gets to >> stick with the Apache brand/trademark, I'm pretty sure that's the only >> positive I've seen you mention that doesn't also apply to an external >> project. With the correct marketing and promotion of an external >> project I'm sure we could virtually close that gap. >> >> Cons on the other-hand: >> 1. Still ultimately the responsibility of the TLP PMC >> > True but not on a day to day basis > >> 2. Burden of setting up all infrastructure required by the sub-project >> > This does need to be looked at. Clearly other projects feel that the > benefits outweigh the costs. > >> 3. Sub-projects are still bound by the constraints of the ASF >> community. If Adrian or whoever wants to do something in an external >> project, he can just do it, no votes, no repetitive discussions >> seeking consensus, none of the frustration that comes from a community >> driven project. From your point of view that may seem like a negative >> but trust me, for a piece of work you plan to take ownership of and >> push forward with, it's hugely liberating and allows progress at a >> much faster pace. Just ask David Jones, I'm sure he'd agree. >> > This project is not short of forks. > Anyone can do this but you lose the advantage of building a team (unless > you pay them). > It also leads to duplication of effort and divergent products that dilute > the results and confuses the market. > If Adrian does a private fork of Asset Management, what is the effect on > the users of the OFBiz version. > Will people want to use a "better" private fork from an unknown source or > stick with the Apache version even if it is less functional. > Can the Apache project abandon a component if someone says that they will > make a private fork? > > 5. Sub-projects would generally (I guess) still be bound to follow >> OFBiz "best practices". An external project would have no such >> constraint and could look for new ways (for example) to render the UI >> through something like >> AngularJs/Ember/Backbone/insert-flavor-of-the-month-here or take a >> completely different approach in other areas without dirtying the >> waters of the core OFBiz project. This could well lead to innovations >> making their way back into the OFBiz project. >> > If that is someone's intention, then setting up a fork would be the best > way to achieve this. > I was thinking of modules that would integrate with the core and framework > in a seamless fashion. > This depends on a certain amount of technological clarity and consistency. > > I get that it's unlikely anyone will sway your opinion at this point >> but still, it's important to consider the negatives of your approach >> as well. >> > I still think on balance, that it is pretty clear that sub-projects is the > right way to go but it is not a magic solution to the problems in the OFBiz > project and will take some effort to achieve a good result. > There is nothing to stop anyone from doing a private fork but I don't > think that this is a good long-term plan and does nothing to build the > OFBiz community or reduce the workload on the current team. > > > Regards >> Scott >> >> On Sat, Nov 29, 2014 at 10:56 AM, Ron Wheeler >> <rwhee...@artifact-software.com> wrote: >> >>> !) Sub-projects allow worthwhile projects to find new supporters through >>> better transparency, focused mission and clearer borders around the >>> knowledge needed to contribute. >>> >>> 2) I thought that Adrian was suggesting that Asset Management was an >>> effort >>> that he would support >>> >>> 3) Just when people say that they don't want sub-projects, they turn >>> around >>> and suggest activities and plans that look like sub-projects. >>> They just want to invent a new structure outside Apache to do this. >>> >>> Ron >>> >>> >>> On 28/11/2014 4:29 PM, Taher Alkhateeb wrote: >>> >>>> Hi Adrian and everyone, >>>> >>>> I think this issue was discussed in multiple threads before. There seems >>>> to >>>> be a general agreement that resources are low. The question is then why >>>> sub-projects or forks or spinoffs? Why not just keep specialpurpose in >>>> the >>>> project? It's live functioning code even if not updated and it is after >>>> all >>>> secondary to the core applications. If anyone then wants to contribute >>>> they >>>> would be supervised by experts. >>>> >>>> IMHO whatever you choose whether sub-projects or forks would probably >>>> just >>>> kill those components. >>>> >>>> My 2 cents >>>> >>>> Taher Alkhateeb >>>> On Nov 29, 2014 12:15 AM, "Adrian Crum" >>>> <adrian.c...@sandglass-software.com> >>>> wrote: >>>> >>>> This conversation has stopped making any sense. >>>>> >>>>> The special purpose components are removed from releases because we >>>>> don't >>>>> have enough resources to maintain them. Now there is interest in >>>>> putting >>>>> them back, but we STILL don't have the resources to maintain them. A >>>>> suggestion was made to make them sub-projects, but that requires MORE >>>>> resources. So the suggestion was made to spin them off to separate >>>>> projects >>>>> where they can stand or fall on their own. The sub-project idea (as far >>>>> as >>>>> I can tell) is dead. >>>>> >>>>> What part of that aren't you understanding? >>>>> >>>>> Adrian Crum >>>>> Sandglass Software >>>>> www.sandglass-software.com >>>>> >>>>> On 11/28/2014 7:37 PM, Ron Wheeler wrote: >>>>> >>>>> On 28/11/2014 11:23 AM, Adrian Crum wrote: >>>>>> >>>>>> I agree with Jacopo that OFBiz sub-projects will be nearly impossible >>>>>>> to maintain. That is why I suggested moving special purpose >>>>>>> components >>>>>>> to separate projects. >>>>>>> >>>>>>> I am willing to move one component to a separate project as a trial >>>>>>> run. I have no interest in being a "chair of a sub-PMC." >>>>>>> >>>>>>> Who would you be willing to have as leader and chief architect? >>>>>> >>>>>> Ron >>>>>> >>>>>> Adrian Crum >>>>>>> Sandglass Software >>>>>>> www.sandglass-software.com >>>>>>> >>>>>>> On 11/28/2014 4:12 PM, Ron Wheeler wrote: >>>>>>> >>>>>>> Can someone on the PMC or a current committer find out what has to >>>>>>>> be >>>>>>>> done to set up an Apacahe sub-project in terms of administration >>>>>>>> (might >>>>>>>> be nothing) and fixing the SCM access so that committers to the >>>>>>>> sub-project are not required to be committers to the core and >>>>>>>> framework. >>>>>>>> This may not be possible from a technical sense but at least it >>>>>>>> should >>>>>>>> be possible to organize the SCM so it is clear what sub-project >>>>>>>> committers are supposed to do. >>>>>>>> >>>>>>>> If Adrian is willing to act as Chair of the sub-PMC, that would be a >>>>>>>> great start. >>>>>>>> I will join on the documentation side to help set up the sub-project >>>>>>>> doc >>>>>>>> structure. >>>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>> On 27/11/2014 10:31 AM, Adrian Crum wrote: >>>>>>>> >>>>>>>> I would be willing to spin off Asset Maintenance to a separate >>>>>>>>> project. I was thinking it could be a good test-run of the concept. >>>>>>>>> >>>>>>>>> Adrian Crum >>>>>>>>> Sandglass Software >>>>>>>>> www.sandglass-software.com >>>>>>>>> >>>>>>>>> On 11/27/2014 2:16 PM, Jacques Le Roux 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 >>>>>>>>>> <<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 < >>>>>>>>>>> jacques.le.r...@les7arts.com> 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 > >
