-
Notifications
You must be signed in to change notification settings - Fork 752
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add new category fs for file systems #302
base: main
Are you sure you want to change the base?
Conversation
I personally like that idea. That sounds reasonable because there are more ports than x11-clocks. BTW, I like filesystem(s) more than fs. |
Hi',El 30 sept 2024 2:30, metalefty ***@***.***> escribió:
I personally like that idea. That sounds reasonable because there are more ports than x11-clocks. BTW, I like filesystem(s) more than fs.Same opinion +1Rodrigo
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
+1 I like this idea too. |
Robert, as we discussed in Dublin, I generally think creating a new Here are a few more for you:
|
@Jehops Thank you for your concerns. The current comment was supposed to read:
but I must have dropped the second half during copy editing. I'll restore that in my next push. I am open to having a category for only file system drivers, but I would prefer to also put the fs utilities in there. We could also add two categories: one for file system drivers and one for associated utilities (e.g. I'll go add the other two ports, too. |
Taking inspiration from existing comments, how about
|
@Jehops Yeah sure, works for me. I'll put that in with my next edit. |
Why this is submitted to GitHub? It's not a supported way of submitting patches (see Porters Handbook). Submit it to bugzilla and continue the discussion there. |
@Diizzy We do process pull requests against ports. I have submitted this change set like this as it's much easier to review the 137 individual ports affected than it would be with a big patch on Phabricator or Bugzilla. |
@diizzyy Other than "the rules" is there some good reason not do it here? It seems to have generated a reasonable amount of feedback so far. |
@bsdimp A lot more eyes and participants on bugzilla (and indirectly mailing lists), there's little to no involvement/interraction with most of the community including committers etc on GitHub. |
@diizzyy And bugzilla is the worst tool ever to review changes (even worse than phabricator). It's barely adequate as a conveyer belt for submissions. Github is much better, and can as easily be references in other forum as bugzilla. The current bugzilla workflow is unustainable, imho, and requires too much extra work. fuz's changes likely need detailed commentary, for which bugzilla is ill suited to do on a change this large. It can't handle 10 commits in one go, let alone 140. Since it is an imperfect fit, fuz will also need to seek review elsewhere (which I thought I'd seen an email go by that did), true, but going to bugzilla is setting him up to fail because it would be such a bad tool for a change like this. |
This is off-topic here, but you probably have never seen Jira that is used by many companies. The key to your submission is not the exact list of ports, but the portmgr approval. Here is my proposal for the physics and chemistry categories from 2018 which is still not approved: https://reviews.freebsd.org/D13481 The FreeBSD Portmgr is a bit slow, don't you think? |
@yurivict My original email went to ports@ as well as portmgr@ and explicitly asked for approval. I hope that suffices. If not, I'll bug portmgr some more (I encourage you to do the same about your proposal). |
@bsdimp |
Yes. And that's a problem too. The ossified FreeBSD processes aren't helpung the project. |
The fs category houses file systems and file system utilities. It is added mainly to turn the sysutils/fusefs-* pseudo-category into a proper one, but is also useful for the sundry of other file systems related ports found in the tree. Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
Approved by: portmgr
I have just requesed an exp-run on Bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281988 |
Approved by: portmgr
Approved by: portmgr
Please rename the category from |
@mat813 That's really quite a mouthful. Should we also rename |
As much as fs is likely to be obvious for advanced users using really short acronyms can also cause unnecessary confusion. |
I too prefer filesystems over fs. |
This patch set adds a new category fs for file systems and file system utilities. The new category is populated with some 126 ports (that's more than x11-clocks!) that look like they might be file-system related.
I was motivated to add this new category when I noticed that many FUSE file systems were shipped as ports named sysutils/fusefs-$foo, making sysutils/fusefs- a pseudo-category for FUSE filesystems. If that's the (anti) pattern, why not make it offical and add a true category for file system ports? Turns out there are a lot more than one might think.
I hope that with this move, we can reduce the load on devel and sysutils (the two most popular misspellings of misc) and make file-system related ports easier to find.
If accepted, this'll be the first new physical category since c5978f0 of 2007-05-19 to be added.
For a full list of affected ports, see the list of commits attached to this PR. If you would like to not have your port moved to fs, please comment or send me an email.
Note that this PR is still wip and will be reviewed, exp-ran, etc. before being committed.