From nobody Tue Jun 25 17:21:00 2024 X-Original-To: ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W7s733FyLz5PgRG for ; Tue, 25 Jun 2024 17:21:03 +0000 (UTC) (envelope-from henrichhartzer@tuta.io) Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.tutanota.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4W7s726VmVz46Nt for ; Tue, 25 Jun 2024 17:21:02 +0000 (UTC) (envelope-from henrichhartzer@tuta.io) Authentication-Results: mx1.freebsd.org; none Received: from tutadb.w10.tutanota.de (unknown [192.168.1.10]) by w1.tutanota.de (Postfix) with ESMTP id 22E11FBFB89; Tue, 25 Jun 2024 17:21:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1719336060; s=s1; d=tuta.io; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=dBBmbyRHapKhSbGH/DGfKxySBanhQu41ehnSGAiaOAs=; b=NnpaPNzXlFDa93mm3fgOu37TRIBjvBU2Hlgcll7eyPsMnzYmulgGbtuavbyY60Qj skZePSkdLB/jK9/u97hItXdi8bNb+QDZBcGZiNj23mqhVpibDK/7RD+S3bcGDY9uR7Y nH7Zi8sLylVt7hQ5yiVzJzgWFcQu9wHAf7Yc8uiSNMvdvI7tiJX7RXeU6dLtcZ0e/mx S/nOk9OCvxKN73PamPmbJvUZvA6nelhxLKQ8MuAGStoUF7Yu8J6mFbQU2tO8BG/NXzJ kyAm6wAlJ3HkqTCqGHAeNgwPqAni1FpSMOpJmbCoZ8aytOXp3WnZfTtAwhF04NiFoOy jGMoZnhVnQ== Date: Tue, 25 Jun 2024 19:21:00 +0200 (GMT+02:00) From: henrichhartzer@tuta.io To: Harry Schmalzbauer Cc: Ports Message-ID: In-Reply-To: References: Subject: Re: git: 0668752 Revert "Framework: Introduce bsd.sponsor.mk" List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-ports@freebsd.org Sender: owner-freebsd-ports@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24679, ipnet:81.3.0.0/18, country:DE] X-Rspamd-Queue-Id: 4W7s726VmVz46Nt 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 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