Suggest branch rather than release strategy?
Locked
1234
1234
Re: Suggest branch rather than release strategy?
 
Administrator
|
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 <[hidden email]> 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 >> >> On 11/27/2014 5:41 PM, Jacopo Cappellato wrote: >>> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux <[hidden email]> 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 >>> > > |
Re: Suggest branch rather than release strategy?
|
In reply to this post by Adrian Crum-3
Sounds like a good idea.
What do you need from Sharan and I in terms of documentation support and space in the wiki for project management, functional documentation and marketing/promotional details. Any suggestions about wiki structure for this as a separate sub-project? 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 < >>> [hidden email]> 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 < >>>>> [hidden email]> 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 < >>>>>>> >>>>>>>> [hidden email]> 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 < >>>>>>>>>>>>> [hidden email]> 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: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
Re: Suggest branch rather than release strategy?
|
Administrator
|
In reply to this post by Jacques Le Roux
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. 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? 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 <[hidden email]> 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 >>> >>> On 11/27/2014 5:41 PM, Jacopo Cappellato wrote: >>>> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux <[hidden email]> 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 >>>> >> >> > |
Re: Suggest branch rather than release strategy?
|
|
On Nov 28, 2014, at 11:24 AM, Jacques Le Roux <[hidden email]> wrote:
> 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? I already expressed my point of view on this so I will let the others to comment their opinion. Jacopo |
Re: Suggest branch rather than release strategy?
|
|
In reply to this post by Jacques Le Roux
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. > 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 >>> <[hidden email]> 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 >>>> >>>> On 11/27/2014 5:41 PM, Jacopo Cappellato wrote: >>>>> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux >>>>> <[hidden email]> 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 >>>>> >>> >>> >> |
Re: Suggest branch rather than release strategy?
|
|
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? 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 >>>> <[hidden email]> 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 >>>>> >>>>> On 11/27/2014 5:41 PM, Jacopo Cappellato wrote: >>>>>> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux >>>>>> <[hidden email]> 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: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
Re: Suggest branch rather than release strategy?
|
|
In reply to this post by Jacques Le Roux
What is the effect of this strategy on the implied warranty?
What is "guaranteed to be tested? Where will the test results for the release be available? What is the responsibility of someone who changes the release branch after it is "released" in terms of testing, support and documentation? Is this going to make fixing bugs found in a release to onerous? What is the effect on documentation and the web site in terms of describing the release? Ron On 28/11/2014 5:24 AM, Jacques Le Roux wrote: > 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. > > 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? > > 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 >>> <[hidden email]> 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 >>>> >>>> On 11/27/2014 5:41 PM, Jacopo Cappellato wrote: >>>>> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux >>>>> <[hidden email]> 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: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
Re: Suggest branch rather than release strategy?
|
|
In reply to this post by Ron Wheeler
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 >>>>> <[hidden email]> 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 >>>>>> >>>>>> On 11/27/2014 5:41 PM, Jacopo Cappellato wrote: >>>>>>> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux >>>>>>> <[hidden email]> 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 >>>>>>> >>>>> >>>>> >>>> >> >> > > |
Re: Suggest branch rather than release strategy?
|
|
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 >>>>>> <[hidden email]> 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 >>>>>>> >>>>>>> On 11/27/2014 5:41 PM, Jacopo Cappellato wrote: >>>>>>>> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux >>>>>>>> <[hidden email]> 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: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
Re: Suggest branch rather than release strategy?
|
|
Oh, sorry i did miss a big point :)
I miss-interpreted Adrian proposal on "seperate project", not enough self-explanatory for me I guess :). Gil Le 28/11/2014 17:01, Ron Wheeler a écrit : > 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 >>>>>>> <[hidden email]> 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 >>>>>>>> >>>>>>>> On 11/27/2014 5:41 PM, Jacopo Cappellato wrote: >>>>>>>>> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux >>>>>>>>> <[hidden email]> 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 >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>>> >>> >>> >> >> > > |
Re: Suggest branch rather than release strategy?
|
|
In reply to this post by Adrian Crum-3
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 < >>> [hidden email]> 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 < >>>>> [hidden email]> 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 < >>>>>>> >>>>>>>> [hidden email]> 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 < >>>>>>>>>>>>> [hidden email]> 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: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
Move The Asset Maintenance Component To A Separate Project (was: Suggest branch rather than release strategy?)
|
|
In reply to this post by Ron Wheeler
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 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 >>>>>>> <[hidden email]> 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 >>>>>>>> >>>>>>>> On 11/27/2014 5:41 PM, Jacopo Cappellato wrote: >>>>>>>>> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux >>>>>>>>> <[hidden email]> 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 >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>>> >>> >>> >> >> > > |
Re: Suggest branch rather than release strategy?
|
|
In reply to this post by Gil Portenseigne
NP.
This is a new idea for OfBiz. Some Apache examples http://db.apache.org/ where Derby is a sub-project with some others. http://xmlgraphics.apache.org/ is an example where the skill sets and interests of the sub-projects are very different from the core http://portals.apache.org/ is more of a layered approach similar to OFBiz where Jetspeed depends on Pluto and the Applications project depends on Jetspeed. http://hadoop.apache.org/ has a number of sub-projects and has spawned a number of top-level projects that could be sub-projects but they have sufficient communities to run their own and are able to use Hadoop "as released". There are probably more. Ron On 28/11/2014 11:06 AM, gil portenseigne wrote: > Oh, sorry i did miss a big point :) > > I miss-interpreted Adrian proposal on "seperate project", not enough > self-explanatory for me I guess :). > > Gil > > Le 28/11/2014 17:01, Ron Wheeler a écrit : >> 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 >>>>>>>> <[hidden email]> 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 >>>>>>>>> >>>>>>>>> On 11/27/2014 5:41 PM, Jacopo Cappellato wrote: >>>>>>>>>> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux >>>>>>>>>> <[hidden email]> 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: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
Re: Suggest branch rather than release strategy?
|
|
In reply to this post by Ron Wheeler
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." 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 < >>>> [hidden email]> 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 < >>>>>> [hidden email]> 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 < >>>>>>>> >>>>>>>>> [hidden email]> 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 < >>>>>>>>>>>>>> [hidden email]> 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 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> >>> >> > > |
Re: Move The Asset Maintenance Component To A Separate Project
|
|
In reply to this post by Adrian Crum-3
No need to fork the project. Let's keep it within Apache.
On 28/11/2014 11:20 AM, Adrian Crum 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). http://git.apache.org/ has a Git repo for OfBiz git://git.apache.org/ofbiz.git > 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 > > 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 >>>>>>>> <[hidden email]> 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 >>>>>>>>> >>>>>>>>> On 11/27/2014 5:41 PM, Jacopo Cappellato wrote: >>>>>>>>>> On Nov 27, 2014, at 6:25 PM, Jacques Le Roux >>>>>>>>>> <[hidden email]> 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: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
Re: Suggest branch rather than release strategy?
|
|
In reply to this post by Adrian Crum-3
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. Apache sub-projects seem to be very easy to maintain for other projects. Perhaps we should consult with the members of some of the Apache projects that have sub-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." > > 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 < >>>>> [hidden email]> 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 < >>>>>>> [hidden email]> 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 < >>>>>>>>> >>>>>>>>>> [hidden email]> 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 < >>>>>>>>>>>>>>> [hidden email]> 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: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
Re: Suggest branch rather than release strategy?
|
|
In reply to this post by Adrian Crum-3
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 < >>>>> [hidden email]> 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 < >>>>>>> [hidden email]> 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 < >>>>>>>>> >>>>>>>>>> [hidden email]> 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 < >>>>>>>>>>>>>>> [hidden email]> 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: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
Re: Suggest branch rather than release strategy?
|
|
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 < >>>>>> [hidden email]> 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 < >>>>>>>> [hidden email]> 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 < >>>>>>>>>> >>>>>>>>>>> [hidden email]> 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 < >>>>>>>>>>>>>>>> [hidden email]> 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 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>> >>>>> >>>> >>> >>> >> > > |
|
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" <[hidden email]> 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 < >>>>>>> [hidden email]> 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 < >>>>>>>>> [hidden email]> 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 < >>>>>>>>>>> >>>>>>>>>>> [hidden email]> 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 < >>>>>>>>>>>>>>>>> [hidden email]> 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 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> |
Re: Suggest branch rather than release strategy?
|
|
!) 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" <[hidden email]> > 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 < >>>>>>>> [hidden email]> 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 < >>>>>>>>>> [hidden email]> 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 < >>>>>>>>>>>> >>>>>>>>>>>> [hidden email]> 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 < >>>>>>>>>>>>>>>>>> [hidden email]> 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: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |