On Thursday, March 03, 2016 08:43:44 AM you wrote: > Forgive me for jumping into this mid-discussion, and admittedly I have > not read every word of this thread, but...
Others are always welcome, mid-discussion or not. > I have understood that there are two primary points that William is > promoting: > > 1) breaking-up the installation so that it becomes more-integrated with > the system - such as logs going in /var/log, pid files going in > /var/run, etc., instead of everything being under one common > installation path. This one I must adhere to per FHS, thus I am pushing this one. > 2) breaking-up the code into multiple files in order to make it easier > to digest, especially for prospective co-developers. This one I personally do not care about as much. I just know people who love perl, and are itching to work on perl projects. But these days major projects written in perl are not as wide spread as in the past. Most are python, java, ruby, or other, like Go is on the rise. > If I have understood correctly, please allow me to respond in-line below... > > On 03/03/2016 07:05 AM, William L. Thomson Jr. wrote: > > That might be a good thing given the age of the code base. I do not > > believe > > its ever had a complete redesign and code clean up. I believe it has just > > had features added on over the years, as the file grew. > > Here you're suggesting that code quality will improve if it is > refactored. This is not necessarily true. Refactoring also risks > introducing bugs that were not there before. So, while the auditing > that occurs during refactoring can be beneficial in optimizing and > finding problems that were not obvious before, my experience is that > there is also a considerable likelihood that problems that did not exist > before will be introduced by the refactoring process. That very same argument could be made for anyone wanting to further the existing monolithic code. If they are not 100% familiar with the code, in its entirety, there is a very good chance they may introduce new bugs. Go try to contribute yourself. Likely will not know where to begin, unless trying to address/fix an issue. The smaller the code in question, the less chance of a bug. Easier for others to digest, and further. There is also unit testing that can help to eliminate bugs. Though I am not sure Perl has unit testing like some other languages. I agree anytime you make changes you can introduce bugs. There was development done to go from single thread to multiple via V2 from V1. Thus I think it is totally feasible for other major changes to happen while keeping code quality and bugs to a minimum. That said the reason there was a community release in the past. Fritz used to do so many releases, there were LOTS of issues and bugs. Thus the community decided to slow down, and vet releases a bit more, and let Fritz continue on with his frequent releases. This was a mess... > In my experience it is developer exposure, varied usage, and operational > feedback that promote coding improvements. While code refactoring can > increase these things, it can also restrict the same depending on how > it's done (most developers need to be committed to it, users need to be > committed to using it, and mechanisms for feedback need to be there to > conclude that improvements have actually occurred). > > Given the push-back that your ideas are getting with Thomas, I'd say > that you are unlikely to achieve the requirements for a refactoring to > result in an improvement unless you somehow have several developers and > a lot of users waiting to follow your ideas. I am getting push back because ASSP is not developed by many but a few. Those few get to control ASSP, and are closed minded to feedback and suggestions from the community, and/or long time users. That is not good for any open source project. That type of closed mindedness will prevent other contributors with other ideas who want to develop not debate. Again not addressing the potential issue that if Thomas moves on, who will replace him? There are not many if any other than Thomas who are familiar with all the code. I have made effort to get people I know involved. I am not sure others can say the same. If I worked with perl or liked it, I would do it myself. But I would likely look to port to Java or something else entirely. Rather than go that direction. I have just tried to find passionate perl developers to get involved. I encourage all to do the same, if you know someone who codes in perl or is a perl developer. Ask that they take part in ASSP development, or ask them to look at the code and give you their thoughts. > > NO, time well spent to make the code base more manageable. It will be in > > smaller pieces that will allow others to more easily digest and > > contribute. > > Not to mention making it like just about every other modern program and > > project, code split across multiple files. > > This last bit about "just about every other modern program and project" > is irrelevant and a red herring fallacy. Do you have some statistics on > every other modern program and project to substantiate this? Or are you > just explaining your own perceptions? I have worked with packaging software on Gentoo for over a decade. I have worked with so many different projects, languages, build systems, and platforms. I rarely if ever see monolithic projects, and surely not large ones like ASSP. Do you have any stats or facts to counter my statement or just playing devils advocate? Can you show me one large popular open source project that is monolithic? Any language. I can only think of one.... > In my experience there are a lot of well-used, good programs out there > that are contained in one (or very few) code files. I, myself, work > with both types. I don't perceive one approach to be superior to the > other. Each method has its own strengths and weaknesses, and ultimately > it really just comes down to developer preference. Some developers like > to work with huge code files. Others prefer the code broken up into > numerous files. Manageability comes down to developer preference. Do you have any examples of said programs? Are these open source projects? > > Its question if you want to be the ONLY one working on ASSP, or if you > > want a more active development team furthering ASSP. Over the years seems > > like very few are interested in working with ASSP codebase. I have tried > > to get several I know who are VERY enthusiastic about perl and it is > > their go to language. However all come back with the same complaint, and > > NONE are willing to get involved as a result. > > I don't buy it. You may like to think that they would have gotten > involved if things were different, but you don't know that for-sure. > Even they, themselves, don't know that for-sure. There would need to be > two projects - one written one way and the other written the other way - > to know if they would have gotten involved with either. Your argument > here is conjecture if not merely another red herring fallacy. I know, because they took time to look at the code. You are not understanding, I asked them as a personal favor. I work with a variety of developers. We ask each other to work on stuff we are familiar with at times. They were eager to want to participate till they discovered the mess. Then realizing it would take them considerable time just to become familiar with the code due to it all being in one file. More than one has come back with the same comment. > In my experience developers who would get involved do get involved > regardless of these kinds of things, and they will do the development in > a way that they prefer - whether that is by working in cooperation with > the existing developers or whether that is by developing their own > fork. My experience is that developers who don't get involved wouldn't > have ever gotten involved even if these kinds of things were different. > They may *say* that they don't get involved because of these things, but > when I have made efforts to accommodate potential co-developers in > similar ways ultimately I find exactly what I'm saying. In my experience people do not like to participate in a mess unless they really need to. Even then they have to have considerable motivation to keep the status quo as is. More than likely would want to take it a different direction. Also what existing developers? Do you mean Developer, as in singular. Do you not understand this project is not active developed by multiple individuals and has not for some time. I do not think Fritz was really into building an active community or development team. I am not sure how Thomas feels about building or having an active development team, but seems he rather keep things his way than consensus. > Generally speaking developers get involved only when they are > motivated-enough. I have not seen developers get involved out of sheer > academic interest and agreement with coding practices. Really? I see that allot in Gentoo. Not to mention its part of the idea behind Google Summer of Code. Over the past ~13+ years, over half those I have worked with in Gentoo do it for academic purposes, learning, and move on to other things, careers in the industry. Just the same, there is also a lack of people coming to Gentoo due to close mindedness, keeping the status quo, and more things get outdated and further from others licking. Less and less will come to contribute. I have seen projects thrive and projects die. How many are coming to further ASSP today or tomorrow? How many are furthering it now? Things to think about if you care about, use, or depend on ASSP. -- William L. Thomson Jr. Obsidian-Studios, Inc. http://www.obsidian-studios.com ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Assp-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/assp-user
