Hi everyone, this is just a heads up, as some of you are aware there were some recent developments regarding the DragonFly ports collection and FreeBSD-ports in general. Huge graphics stack update (including but not limited to dri, gbm, libdrm, libEGL, libGL, clang39, xorg-server and its drivers) was just pushed without giving us a any heads up to prepare for it or perform an early testing. This came as a surprise since last time we were notified about upcoming developments that allowed us could construct, patch and test the new stack. This is how radeonSI card support was added to xorg for the radeon owners to enjoy running their Desktop machines with accelerated graphics. We pushed ours and later FreeBSD pushed theirs since we have a different level of GPU support in kernel DRM drivers yet we share the same ports tree.
However, this time it was not the case and we are trying to understand what has happened. We are aware that there is huge ongoing effort to finally import the drm 4.9 gpu drivers from linux using linux-kpi emulator layer allowing to cp/paste linux drivers almost without modifications including the OFED. We understand this is quite an achievement that FreeBSD users will finally will be able to run their Desktop machines without a need to buy expensive nvidia cards and use binary blobs. I'm a fan of this work cause I have been struggling to get amdgpu working on few cards that I have stacked (drm/ttm + amdgpu is complicated), but given that few years old Radeon R7 360 spins quite nicely, does not overheat and allows to hook monitor to my Xeon box I am golden. I know I know, radeonkms has few quirks and I was not paying enough time for it, there are a lot of other fun stuff to experiment and I have to choose :) So to catch up with graphics stack update and not to have version locked packages for such low level ports I for now will put other ongoing projects and will concentrate on cooking up a quick and dirty ports tree for testing the new stack. With a bit of luck we might not need any additions to our current i915 and radeonkms kernel GPU drivers and new stack will turn out to be quite compatible. This is just a heads up that during upcoming weeks ports tree might be a bit unstable as we patch and test cause testing takes time. First quick go through the changes both in packages and patches gives the impression that it should not be very complicated. Mainly thanks to the freebsd-xorg developers, who looks like added almost all cases needed to support this complicated Xorg stack on DragonFly too. Maybe Wayland will be easier to maintain. That is yet to be seen. Luckily this update has not hit us unprepared and by pure luck we had to delay the DragonFly BSD v4.8 final release tag due to few last minute bugs noticed in VM subsystem. So at least we have not branched out new release before the recent unexpected freebsd-ports changes. To make things worse one of major contributors was just suspended literally the day before ports changes were introduced. We still not sure about the details, just hope this was not a permanent ban from FreeBSD-ports and he will still be able to contribute for both open source projects. https://svnweb.freebsd.org/ports?view=revision&revision=433827 I was not aware how much John contributes outside DragonFly BSD, just did a quick at recent Marino contributions at FreeBSD-ports: https://svnweb.freebsd.org/ports?view=revision&revision=432948 https://svnweb.freebsd.org/ports?view=revision&revision=433191 https://svnweb.freebsd.org/ports?view=revision&revision=433339 https://svnweb.freebsd.org/ports?view=revision&revision=433630 https://svnweb.freebsd.org/ports?view=revision&revision=433681 https://svnweb.freebsd.org/ports?view=revision&revision=433771 https://svnweb.freebsd.org/ports?view=revision&revision=433775 https://svnweb.freebsd.org/ports?view=revision&revision=433804 https://svnweb.freebsd.org/ports?view=revision&revision=433810 I could not find any indication of him going turbo by committing changes without port maintainer approval (he reported to port maintainers as per rules, patched only the ones that that have no maintainer assigned) or harming ports in any way. So far it is unclear why so suddenly his ports commit rights were taken without giving any specific reason why. Only one older (two weeks ago) commit might had an issue: https://svnweb.freebsd.org/ports?view=revision&revision=432860 But again that should have not been enough for anyone to get sacked. John was the main developer bringing Ada language support for both DragonFly and FreeBSD as far as porting Ada to work on FreeBSD aarch64 architecture. Guy has even written awesome ports building tool almost in pure Ada: https://github.com/jrmarino/synth Yet just yesterday all his ports and Ada infrastructure support were resetted to a global ports pool without assigning any person to take over all his hard work to maintain the ports. https://svnweb.freebsd.org/ports?view=revision&revision=433856 https://svnweb.freebsd.org/ports?view=revision&revision=433961 And, even worse, preventing him or any other user to even have a contact to submit the patches or updates. Maybe something like freebsd-ada@ would work and would help other users as well. Luckily looks like somebody stepped in and took over https://svnweb.freebsd.org/ports?view=revision&revision=434055 however this has one of those restricted access to phabricator links: https://reviews.freebsd.org/D9572 I, as open source proponent and contributor to many projects including but not limited to open source drivers testing (both Linux and BSD), fortran development for HPC and number crunching packages, compiler toolchains, hope this is not a sign of reducing openness and transparency in FreeBSD project or even implementation and use of secret courts. I am aware of strict rules they have: https://www.freebsd.org/internal/code-of-conduct.html and https://www.freebsd.org/doc/en/articles/committers-guide/rules.html 7th rule "Do not fight in public with other committers; it looks bad." + the "As noted, breaking some of these rules can be grounds for suspension or, upon repeated offense, permanent removal of commit privileges." It is unclear weather "some of these rules" includes the 7th. I very doubt John would have broken any other rule, specially the 10th one. I had and hope will continue to have a pleasure to work with John while fixing ports, yes he sometimes can be painfully correct for technological reasons and he is right in most of the cases, but in none of the cases he exhibited the "Do not make it personal. Do not take it personally.", nor in any time I had suspicion that he would try the backroom deal me. We all come from different backgrounds, with different temperaments, different expectations from other people, but lets not forget that anyone might just be having a bad day, family, work related problems. After all we are just a humans who happen to dedicate their free time to hack on stuff and have a joy of getting stuff to work. Granted I'm not familiar with what exactly happened there and weather John went turbo and started to intentionally break the ports, limit their functionality by removing support for different things. If that was the case FreeBSD board have every right to temporarily suspend the commit rights while leaving a way to contribute to the project while emotions cool down. However, from what I have gather so far, recently there was no reason for it. If it was some heated technical discussion over IRC, guys please.. What happens on IRC, stays on IRC. Mentioned rule works both ways "Do not make it personal. Do not take it personally." The question were there any provocations by other people. Hopefully John would not become the 3rd person in the list mentioned in a recent presentation at linux.conf.au https://www.youtube.com/watch?v=Ib7tFvw34DM Such things can be misinterpreted for attempts to install censorship and justify its use, nor does it benefit the open source community in any way. It just promotes the ideas how badly the open source written code is, discourage the new people joining and hacking on the various projects give it be ports, base system or even documentation. Most of us are not paid to do it, we do it in our free time cause it is fun. Ah! Lets not forget the most important one activity - Testing! There are no way to have too little testers who are wiling to test changes by integrating them into their running systems. Some features might even end up with bricked hardware for some unlucky every day guy who just installed the BSD on a brand new laptop, just because of by one error in GPU voltage table due to various reasons like ported driver and the home user was simply not aware that he might look for system instability signs and power down the system in time avoiding the permanent damage. This me speaking as one of Skylake brick owner while testing changes for stability on Fedora. Power button blue led went pup-pup and silence =) Hmm I got sidetracked, you get the idea, I think I have spent at least 5h just researching the recent changes in FreeBSD-ports and an hour just writing this, what can I say am a slow writer, English is a hard language. I sincerely ask DragonFly BSD community not to engage in fights over this with certain FreeBSD community members. Fighting between the projects only makes benefit for third parties and just distances the developers by not sharing good ideas. In the end sharing is caring. It is still not clear what happened so lets not jump to conclusions. To end up this email with a bit brighter mood. I think I managed to get clang import into base to almost done state. Currently to get a clang built system I think i got it to just: cd /usr/src/nrelease make release WORLD_CCVER=clangb WORLD_ALTCOMPILER=all dd if=/usr/obj/release/dfly.img of=/dev/da8 bs=1M && sync boot the usb on testing setup And it worked, even the loader. I have even verified the: # CCVER=clangb cc -v # strings /boot/kernel/kernel |grep clang # strings /lib/libc.so.8 |grep clang they do have: DragonFly clang version 3.9.1 (tags/RELEASE_391/final) (based on LLVM 3.9.1) So far I am very happy how clang import went through and soon DragonFly will have 3 base compilers, yes three, gcc 4.7, gcc 5.4.1 and now clang 3.9.1 too. This will allow to further increase the spectrum we can experiment with and do the further research. Fun fact I just learned that clang's -O defaults to -O2 and not -O1 as it is on gcc :) But for now I'll will focus on DPorts issues. Just hope I will be able to squeeze clang addition before we do the release. Best regards, Rimvydas This email contains personal opinions and shall not be interpreted as an official opinion of DragonFly project or any persons associated with it.
