Subject: Re: git: 0668752 Revert "Framework: Introduce bsd.sponsor.mk" Message-ID: <O0FPZ6F--3-9@tuta.io> In-Reply-To: <aef95175-249f-4e77-877f-217e7c41e524@omnilan.de> References: <aef95175-249f-4e77-877f-217e7c41e524@omnilan.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Jun 25, 2024, 07:39 by freebsd@omnilan.de: >> Revert "Framework: Introduce bsd.sponsor.mk" >> >> This reverts commit 274cd4df4dcce0a9aa78da47bb6e35ab3dbcbf8c >> > > > See also: > https://reviews.freebsd.org/D44487 > > >=C2=A0 In D44487#1014651, @mat wrote: > >>> >>> > >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 but we want users to s= top using ports and use packagesPiotr Kubaj <pkubaj_at_anongoth.pl> wrote o= n > > This in fact *will force users into dependency hell like on Linux*. > > To use clear words: I dislike paternalism and general decisions made unde= r the hat of portmgr@ during the recent years. > There are plenty of Linux distributions doing it 'right' and making it ea= sy for 'the users'. > Please stop forcing FreeBSD into that direction - you will loose those 'u= sers' able and willing to dig deeper and improve/fix/extend software. > > There are portmgr@ people deleting foreign ports for no reason and now _y= ou_ decide that Gleb's bsd.sponsor.mk needs approval - Approval from people= who destroy one of the key principals of FreeBSD. > This is ridiculous. Users will need to approve portmgr@ decisions! Your r= evert woulnd't get approval! > But better not to ask but to dictate of course. That way will allow portm= gr@ to continue dismantling FreeBSD from the inner. > > To return to the topic: > I liked the idea very much. > It is very important that skilled people are supported by their employer = to work on OpenSource projects, which directly or indirectly involves FreeB= SD. > Naming sponsors might attract more skilled people - not those looking for= arbitrary company paying them their bills, but those enthusiasts and smart= ones, who have chosen FreeBSD instead of any fancy Linux distribution, bec= ause on FreeBSD it's much easier to participate or add customization in a s= ensible and fertile manner. > ports/ was and still is a very important entrance. FreeBSD will decay if = it only has consumers! (and if ports/ is continued to be made distracting u= sers) > If there are only paid people left to do the work, FreeBSD won't improve,= simply because there will be much less creative, fresh and individual idea= s! This especially would harm FreeBSD since it hasn't billions to spend jus= t add human resources by try'n'error. > (Look at any commercial software product after 10 years evolution with pa= id people - now name ONE, which is better today than it was 10 years ago. B= etter for the customer/user, not for the vendor! As time goes by, the advan= tage relation will turn imho, but that's another topic) > > Naming sponsors imho improves the willingness of employers trying out act= ive OpenSource partnerships and allowing their employees to spend time not = only on CONSUMING OpenSource, but on participating. This can be for mutual = benefit. OpenSource doesn't work with consumers only, and supplier resource= s aren't available for free! > Sponsorship naming was always an appreciated additional meta info. > > If you need time to lift this to be beneficial for packages too, take you= r time, but don't remove it just because _you_ or portmgr@ as a whole want = users to force using packages. Please stop dictating FreeBSD users! > > Thanks for sending this to the list, Harry! There's a few points I'd like to cover. 1. The commit was reverted: It looks like the commit hadn't been approved, so I can understand it being= reverted on those grounds. 2. The feature should be landed. I tend to agree with this. It seems nice. I can also see why you'd want spo= nsorship info to end up in packages as well. Ideally, it should be in ports= and packages. I don't know if this would in any way negatively impact also= deploying it for packages. 3. Statement about moving users away from ports to packages. I can understand wanting to have ports features available in packages, wher= e possible, but the statement that "we want users to stop using ports and u= se packages" does not come off well. I love the duality of the system. I ca= n throw some packages on quickly, or I can compile from ports. I feel like = good ports make for good packages, and if ports suffer the build process is= questionable. 4. Long term sentiment about ports/package-related decision making: I don't know much about this, so I can't comment here. I have seen more tha= n a few disgruntled posts of a similar nature, though. -Henrich
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?O0FPZ6F--3-9>