Occasionally we’re called to account for our decisions, reflect upon their correctness and at times reverse the decision.
John Marino (John) has conducted himself with a passion for making decisions in the interests of ports' users over many years with great professionalism and enthusiasm. At times, this passion exudes into bravado, even exuberance. This is not uncommon when sharing deep-seated beliefs of how things should be done. Sometimes, perhaps too rarely we see contrary opinions expressed in the various FreeBSD lists. As I’ve observed with my first and second level managers, the weak managers never hire people that challenge their views, or have talents superior to their own; they hire people with lesser abilities. To their detriment they deny themselves the opportunity to grow. Similarly with community-based projects, I’m currently a Director of one, in this context strongly divergent views distract from the singular imperative of helping others. Regardless such views cause, reflection – are we heading in the right direction; are our actions aligned with our mission; is our strategy meeting the goals of our customers (the needy in the community); are we properly communicating and advocating our purpose. Time consuming and sometimes unpleasant, the opportunity to review and challenge is worthwhile. John is significant contributor to the ports user-base, he has advocated views which represent the needs of the user-community and his expulsion, the reasons for them and the analysis of his expulsion upon the project should be communicated, for transparency and reassurance that such decisions are in the interests of everyone. This is simply inadequate: https://svnweb.freebsd.org/ports?view=revision&revision=433827 https://svnweb.freebsd.org/ports?view=revision&revision=433856 I value John’s forthright opinions, and his motivations and contribution to GNU, Ada, DragonflyBSD and FreeBSD are not unrecognised. He articulates his position clearly; his design and development efforts are sound, and the development of Synth is appreciated. This lack of transparency suggests that he is divergent, so lets examine this as a reason for expulsion. Was it due to providing a choice. Users of FreeBSD have a choice: a) build their own build/development system b) use poudererie - which to me is another layer of complexity and another source of frequent change c) use synth - where transparency and is relatively simple to use. The ports system has undergone significant change over the last 4 years, much of it needed and requiring significant time and active contribution by the meta-ports developers. Unfortunately the cost to those using the ports system during this time has been significant. I see John as a stabilising influence (as Doug Barton was) - is this the reason? Lets just examine FreeBSD for a moment. The project is fantastic and so many different ideas and approaches have collaborated and continue to progress; I was a saddened when Matt Dillon split from FreeBSD. Its a testament to all that there remain, that a high level of exchange and collaboration continues and John has acted as a conduit and has contributed in this area also. So how should we view “The FreeBSD Project"? Its really split along the logical boundaries of: the base system, the ports meta-system, and the ports system. The ports system is actively maintained by many ports “maintainers” and the frequency of change reflects the changes to applications (source) that is under greater scrutiny to be (more) secure. This is ok, and I’ll come back to this. I started with FreeBSD in 2003, when packages were available and this greatly contributed to my uptake of FreeBSD. Over time, I needed to customise my settings sometimes for performance reasons, usually for security reasons. I was very happy with the ports system, and I was able to work-around the changing library versioning issues; but it did need to be fixed. Roughly 4-5 years ago pkg and the meta-ports system underwent significant and needed change. The folks doing this work have done a great job; but. The implementation of the changes had a deleterious effect. The frequency of change became intolerable, at one point we had 0.25 of an FTE just maintaining our build systems. We rebuilt all packages overnight which enabled testing in the event of critical issues for our clients. Had we known of the meta-ports flux we would've changed our business model and commitments to our customer base. Now we see discussions over whether ports should be supported past the EOL of an OS. Seriously? I had a client that refused OS upgrades, so we maintained up-to-date ports for around 4 years after FreeBSD 6.1 was EOL. Ridiculous but a credit to the ports and meta-ports developers/maintainers, at the time. Our view of FreeBSD being rock-solid was reinforced. However, nothing like this should be expected to be supported, though packages should be able to be built for two or three minor revisions back - if only to give the people looking after servers a time to schedule and update. The current practice of changing the ports system to disable the building of ports on “older” OS is a disservice. Another scenario: Lets say FreeBSD X.Y is EOL'ed, a CVE is issued for an application. Unfortunately we often hear: "Too bad, they should upgrade." Really? If that CVE was say, heartbleed, for (in my case) 1450 servers to be left unsupported, or according to the current paradigm - require an OS upgrade is frankly, ridiculous. When I was the Head of Security for a minor bank. I asked "Have you considered FreeBSD for this use?" - instant derision. Lots of reasons, little to do with the FreeBSD base system. Draw your own conclusions. Microsoft got it right. Users want applications, and they will rely upon the OS to provide a solid and reliable base. The FreeBSD project has dedicated and enthusiastic port maintainers. They can, do and should upgrade their ports with a tempo that maintains significance (for features, fixes) and timeliness (security); however the meta-system should be subject to the same rigor as the rest of the FreeBSD development to convey a sense of reliability and stability. FreeBSD base development progresses with: - an idea - discussion - code development and availability for open review - development and placement into current/head, further review - move the developed code into stable - further opportunities and testing - beta cycles - release candidate cycles - Release! vs the ports meta system. - an idea - code - release into production (at times re-release into production the same day) This isn’t to say the developers are wrong in their pursuit of enhancing the environment, which is commendable, rather this should be performed against a plan or schedule and perhaps notification of what’s coming or about to be changed so Admin’ers can plan and schedule their work. This comes back to governance. And we need to remain cognizant that not all FreeBSD users are in first world countries; with multiple boxes available for build/testing. If anyone is challenging the way things are, and trying to make the various FreeBSD domains better, good luck to them. The FreeBSD Foundation should be providing sound governance, and develop an advocacy program to RETAIN those that currently use FreeBSD, instead I'm witnessing departures at a disconcerting rate. It might say something about the SAMBA project, but I had maintained separate email folders from the SAMBA and FreeBSD lists since 2005; the level of interaction/discussion on these, relative to each other has dropped alarmingly (ie SAMBA remains high) So when someone makes a significant contribution, is an advocate for excellence - forcing them out raises serious issues about the management of the ports system and the overall governance provided by the FreeBSD Foundation. This calls into question the relevance of FreeBSD’s ability to continue to provide a reliable, solid body of work that Server owners in particular, are proud to use and advocate. Transparency, sound judgement and the criteria for rejecting high-value contributors are the issues here. And when someone with John's talent is being pushed out, then the wider community should be made aware of the circumstances and the criteria. (For the record, I've disagreed with John on something years ago - the discourse was invaluable, as John is at times a forceful antagonist which as history shows, is often, and at times unintentionally, of great value. BTW we use portmaster as it is fit-for-our-purposes; though we have (had) plans to migrate to Synth) FreeBSD is an amazing operating system, I’ve read every svn entry into stable for the last 4 years – unbelievably smart people. I use 1037 ports from the ports tree, and value all those that contribute their time and effort to the betterment of computational “stuff”; the features and the productivity that are provided. There are areas that need to be improved, and I think that John contributes positively (albeit abruptly) to the Project. At the very least we should know why, and by what criteria he is judged? Regards, Dewayne. PS I'd prefer to be silent and let things run their course - but that would be seen to acquiesce with something that I perceive as harmful to “The FreeBSD Project". -- *Disclaimer:* *As implied by email protocols, the information in this message is not confidential. Any intermediary or recipient may inspect, modify (add), copy, forward, reply to, delete, or filter email for any purpose unless said parties are otherwise obligated. Nothing in this message may be legally binding without cryptographic evidence of its integrity and/or confidentiality.* _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
