PR the PR. Is it worth it?

I did submit a PR (about the chromium port), but the actual process of doing the PR was almost too difficult for me.

The form seems quite simple and straight forward. There are only a few fields to fill in. Two of these are Component: and Version:.

1630816487818.png

I spent ages trying to fill in these fields. It seems quite clear (to me), that I am supposed to fill in these two fields, the component being www/chromium (as it was), and the version being whatever.

But how do you actually fill in these two fields? Drop down, cut and paste, drag and drop? Tried it in both chromium and firefox (in case there was a bug in either browser).

Finally I figured it out (I think). No need to fill in these two fields at all. They are already filled in as Individual Port(s) and Latest, and I was expected to include the name of the port in the Summary.

Now I know how to use this form and have submitted the PR (I think ... yet again). But I do consider the layout of the form misleading to the degree it may be considered a bug. Certainly, if I had ever designed such a form for a client, I would have been expeced to do something better.

So, should I submit a PR about the PR? Is it worth it?
 
I filed a PR once. ONCE.
Waaaaay too complicated and got no response.
Totally not worth it.
If the developers don't watch the forums, they're lost. No fancy OS any more.
The dark side (and the bugs!) of FreeBSD happens here, in the forums and not far, far away in candy, colorful Bugzilla land.
 
I spent ages trying to fill in these fields. It seems quite clear (to me), that I am supposed to fill in these two fields, the component being www/chromium (as it was), and the version being whatever.
The component here is the port tree itself and the version is the latest branch. Whether this does makes sense or not is debatable, however those are standard Bugzilla fields and they have to be filled with something.
So, should I submit a PR about the PR? Is it worth it?
Meta bug reports regarding Bugzilla are unlikely to see any action. This software is simply to much of PITA to modify.

The dark side (and the bugs!) of FreeBSD happens here, in the forums and not far, far away in candy, colorful Bugzilla land.
That's not true at all.
 
Now I know how to use this form and have submitted the PR (I think ... yet again).
Yes you did. And I just took the liberty to suggest a solution over there (PR 258271) :cool:

As for the question about the form, to me, it was pretty obvious there's only one possible value for these fields when reporting an issue for an "individual port". ?‍♂️
 
Yes you did. And I just took the liberty to suggest a solution over there (PR 258271) :cool:

Thank you. I have applied the patch and of course it works. I had considered merely removing the offending lines beforehand.

As for the question about the form, to me, it was pretty obvious there's only one possible value for these fields when reporting an issue for an "individual port". ?‍♂️

I bow to your superior common sense.
 
I had considered merely removing the offending lines beforehand.
This would probably break the build on more recent 14-CURRENT systems, so wouldn't be acceptable ;) – I'm curious whether my fix will be accepted. It works, but it's a bit hard to read…
 
In the old days, there was the send pr thing, where it was all in text, that you filled out on your machine. It's been awhile and I don't remember how intuitive it was.
With a port, one can sometimes just email the port maintainer. I've done that a few times, and gotten a quick response, and other times, gotten no response. In this case, it looks like you got a quick response that has worked, at least for now, though Zirias isn't sure it'd work on CURRENT. I would say, just addressing the issue of whether or not filing a PR is worth it, that it often is. Yes, sometimes you get no response, but you often do get a useful answer, as you did in this case.
 
Zirias isn't sure it'd work on CURRENT
Uhm ... just removing the check completely wouldn't work on (recent) -CURRENT. My patch will work, the only problem is, it's really hard to read ;)
Code:
EXTRA_PATCHES+= ${"${:!${GREP} mempcpy ${CROSS_SYSROOT}/usr/include/string.h \
        || ${TRUE}!}" == "":?${PATCHDIR}/extra-patch-no-mempcpy-nasm:}

Maybe there's a better way to solve it, I don't know…
 
grahamperrin Yes, that is a quick way to get to the form, and it fills in the summary. Than you. It still has got those Component and Version boxes, that apparently are filled in, but look to me like they are expecting something.

Is it only me? Does everyone else look at those wanting yellow boxes and ignore them?
 
When people stop filling in PR because the interface is non-intuitive, too complex, too cumbersome, quality of software will go backwards.
In that case i must think of switching to linux.

Is there no part in the handbook explaining how to ordently file a PR ?
And this starts with being able to file a PR in the first place, i.e. having a login and password allowing it.
Or maybe there is place in the howtos or faqs on this forum ?
 
I've dealt with sunpoet as Maintainer of a few different ports and always got a quick response by email.



That isn't one, but at least the home page is valid HTML now and the markup in a readable format straight down the page.

Every time I think of that "Lost in Space" markup with elements floating all by their lonesome in the far right quadrant somewhere I think of poor Marta Kristen and how happy our lives would have been together if she was back on Earth, and I wasn't just 8 years old at the time it first aired n 1965. :)

I knew all about that kind of thing by then. My 16 year old babysitter "Candy" had already taught me about conquering the Galaxy.
 
But how do you actually fill in these two fields?
I never tried. This tool is there only for some 5 or 7 years now, and I am still waiting until my bug reports (or more precisely: ready-made patches for very obvious base-OS coding mistakes) from the old tool will finally be read by somebody (waiting 12 or 13 years already).

So, should I submit a PR about the PR? Is it worth it?
No. It's clearly not worth to submit PR; that is a WORN device (Write Once Read Never).
You must understand that there is a gentry, and there is the plebs. And the plebs is allowed to post their patches and bug-fixes into the PR. That is all. Nothing more needs to happen. And this is friendly indeed - other software may require you to sign your slavery-treaty first, before you're even allowed to send fixes.

One must understand that in the Internet everything is data, everything gets published, and therefore everything is part of the product. Actually, anybody filing a code-fix into the PR (or posting an answer to a question here) is an unpaid worker (or in German: "nutzlicher Idiot"), creating part of the product of which others then can be proud that they made it.

There is a better solution. Since you get the code for free, you are certainly ethically oblidged to give your fixes back to the people. But this can be fulfilled in any way: you're not required to make other people proud for the army-of-ants they control; just create a blog somewhere and publish your fixes there.
 
Pmc,
do you claim mentioning a problem without providing a fix is useless ?
No, the opposite. I say that describing a problem with providing a fix in the officially designated tool appears to be useless.
And if you manage to get an audience with a developer - I have already two or three times seen them openly admit that the only way to get something done is via insider relationships.

So yes, mentioning a problem could be useful, if you have insider relationships.

Do you claim problem fixers don't get any credit ?

No. I do not care about credit. I do care about engineering quality.

And concerning quality, one can roughly cut the Internet at the switch of the century. In the old century there was an Internet, and engineering quality was valued. In the new century there actually is something we might call a Googlenet. And the major purpose of that is moneymaking, and to shape the entire culture of work in a way that serves best for them.
That means, quality doesn't matter anymore, and instead of fixing the code, one only need to fix the code-of-conduct. In other words: brainwash the people instead of doing good engineering. (And, to repeat: this concerns the entire network, not a specific product or service.)

The main impetus in changing the Internet into the Googlenet seems to be that money is actually made with it. And it seems to be quite a lot of money.
I for my part have nothing to do with that, and I do not understand how that may work. I for my part don't get any money from anybody as I'm longterm unemployed, and my only concern usually is how to pay for some needed hardware.
Back 20 years ago I used to develop&design unix high-availability solutions for banks, telcos and hospitals all over the continent. That was engineering quality, and was regarded as such. But then it was decided that engineering should no longer be done and unix skills no longer be valued, and these customers should instead buy Cloud for their services, and so I was fired.

Nevertheless I continue to believe in engineering quality. And I repeatedly tried to aquire those necessary insider relationships, but to no avail - it is very difficult.
 
No. I do not care about credit. I do care about engineering quality.
But FreeBSD cares ;) and although this isn't the most important thing in the world, it's a nice trait, showing appreciation for your work.

I'm not offended when some patch I submitted is committed without any attribution, but this only happens rarely by accident. With SVN, it was common practice to add a "Submitted by:" metadata field to the commit message. This field is now deprecated with GIT because GIT distiguishes between "author" and "committer", so you should be mentioned as the author. You can make committers' lifes a lot easier by using git format-patch to create the patch you submit; this way, it will already contain the author information and a commit message ;)
 
waiting 12 or 13 years already
You should post something about it again instead of keep waiting forever. People are busy and things get forgotten with time.

Actually, anybody filing a code-fix into the PR (or posting an answer to a question here) is an unpaid worker (or in German: "nutzlicher Idiot")
Given that everyone gets the software for free, I don't see what's wrong with this. Most FreeBSD contributors don't get paid for their work.
 
Odd, I haven't found that submitting (or asking) for fixes depends upon insider relationships. Sometimes, nothing gets done, other times, it does. But my relationship with the maintainer has never been a factor as far as I know. I suppose that if it was someone I knew, it wouldn't be ignored, where sometimes, it does get ignored. But I have also found, even where I don't know the maintainer, a fix is quickly applied. It depends, obviously, on the port and maintainer. As for submitting a patch and getting credit, the last time I submitted a patch was over 10 years ago, and I don't remember if I got credit or not, I just wanted it to be fixed, and it was.
 
But FreeBSD cares ;) and although this isn't the most important thing in the world, it's a nice trait, showing appreciation for your work.

Alright, but that doesn't concern me. The thing that does concern me is that I have to keep a patch, and merge it for every update. When a patch gets committed, I get rid of that maintenance, and that is the benefit.

In the last century this did work different. Back then, problem reports, without any fix, were acted upon (after some time) and solved.

Contribution is not what matters to me. What concerns me is that contribution is subject to a class society, where the developers are supposed to contribute and the users are supposed to consume.

This was not the case in the last century. Back then everybody was welcome and treated equally.
It appeared when the moneymaking started - and obviousely, then it becomes necessary to decide on who belongs to producers class and who belongs to consumers class.

Consider e.g. a show star: they have millions of fans, and these fans are needed to consume, they are not supposed to get on stage and act along!

Or Let's look at another example, that just happened today: When I try to send mail, it comes back with this error:
Code:
... while talking to mx01.emig.gmx.net.:                                        
<<< 554-gmx.net (mxgmx115) Nemesis ESMTP Service not available                  
<<< 554-No SMTP service                                                         
<<< 554-IP address is block listed.                                             
554 5.0.0 Service unavailable

There is obviousely a problem with the IP address. I got that IP address in June (this year), and investigation shows that in August 2020 (more than a year ago!) somebody sent phishing spam from that very IP. (I have no idea who did use that address back then.)

Now trying to get that IP removed from those lists, turns out to not be easily possible: the operators of these lists are not reachable, their webpages are overloaded and/or broken and do not respond, and when you finally manage to post a removal request, you get told that it woll be processed, but that does just not happen.
What you get instead as the offered solution is this: you can pay 50$ per month, and then you will get in contact with a "tech expert" who will help you set up your mail.
Again you can see the clear distinction of classes.
 
You should post something about it again instead of keep waiting forever. People are busy and things get forgotten with time.
It was not forgotten. It was never recognized. And I am not waiting, I simply won't do it again. As my spiritual teacher used to say: you cannot hinder one from learning.

Given that everyone gets the software for free, I don't see what's wrong with this. Most FreeBSD contributors don't get paid for their work.
There was nothing wrong with that in the last century, when there was no e.g. Google and all still was a collaborative effort.
But then, when all do work for free. but for the benefit of e.g. Google, then this is something different already. And also, when on a galley some row for free, and some do whip the rowers for free, then that is again something different (and, contrary to popular belief, it can not be successfully remedied by simply changing "black list" to "block list").
 
So you mean FreeBSD isn't a collaborative effort anymore?

If you don't want big corporations to be able to make money using your code, don't share it on the web, or choose a license which bans commercial use. I don't know if such a license exists, but if not you can write your own. When you relase something as BSD, GPL, MIT, etc. you know that anyone will be able to use it, including big business.
 
Back
Top