Re: git: 0668752 Revert "Framework: Introduce bsd.sponsor.mk"

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
>
> >  In D44487#1014651, @mat wrote:
>
>>>
>>>
> >>         but we want users to stop using ports and use packagesPiotr Kubaj <pkubaj_at_anongoth.pl> wrote on
>
> This in fact *will force users into dependency hell like on Linux*.
>
> To use clear words: I dislike paternalism and general decisions made under the hat of portmgr@ during the recent years.
> There are plenty of Linux distributions doing it 'right' and making it easy for 'the users'.
> Please stop forcing FreeBSD into that direction - you will loose those 'users' able and willing to dig deeper and improve/fix/extend software.
>
> There are portmgr@ people deleting foreign ports for no reason and now _you_ 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 revert woulnd't get approval!
> But better not to ask but to dictate of course. That way will allow portmgr@ 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 FreeBSD.
> 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, because on FreeBSD it's much easier to participate or add customization in a sensible 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 users)
> 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 ideas! This especially would harm FreeBSD since it hasn't billions to spend just add human resources by try'n'error.
> (Look at any commercial software product after 10 years evolution with paid people - now name ONE, which is better today than it was 10 years ago. Better for the customer/user, not for the vendor! As time goes by, the advantage relation will turn imho, but that's another topic)
>
> Naming sponsors imho improves the willingness of employers trying out active 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 resources 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 your 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 sponsorship 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, where possible, but the statement that "we want users to stop using ports and use packages" does not come off well. I love the duality of the system. I can 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 than a few disgruntled posts of a similar nature, though.

-Henrich