Move GNU projects under appropriate publisher directory

[ghost]

This repository contains quite a few GNU projects, but they all live under different publisher directories. I think for the sake of consistency they should be moved under one publisher directory, such as manifests/GNU.

Here's a quick overview:

• GNU Emacs, Gforth, GNU Octave and GNU Solfege are already in the right place.
• GNU Radio is currently under manifests/GNURadio not manifests/GNU.
• GIMP is currently under manifests/GIMP, manifests/GNU might be more suitable.
• GnuPG should live under manifests/GNU not manifests/gnupg. Gpg4win seems to be a separate effort entirely, so perhaps manifests/Gpg4win would be best.
• Curiously, Gnuplot is not a GNU project, so it's in the right place.

I've used the software list on the GNU website as my main source of information about what software is "a GNU package".

Of course, I tried my best to be thorough, but chances are I'm missing something.

[ghost]

I've taken the liberty of opening a PR (#1956) for this issue.

Note that I did not make separate PRs for every commit, because I felt that would be silly. The down side of this is that the bot will fail to validate the PR. Manual review is required.

[qiancy98]

Maybe you have to creat 14 pr's...

[qiancy98]

Also GnuWin32 should be merged? Now it should take 20 pr's. :-/

[ghost]

Also GnuWin32 should be merged?

I don't think it should. GnuWin32 is a port just like Cygwin or MinGW. Probably best to keep it separate.

[ghost]

Seems like GnuCash should be under manifests/GNU too. I've added it to the PR.

[superusercode]

GNUCash and GNUradio are not actually part of the gnu project, which is why I did not include them in that namespace. Please research whether each one of them is involved with GNU/FSF before making PRs.

[latere-a-latere]

GIMP isn't part of the GNU Project either. We shouldn't "group up" packages just for convenience sake.

[ghost]

GNUCash and GNUradio are not actually part of the gnu project, which is why I did not include them in that namespace.

GIMP isn't part of the GNU Project either.

That's entirely debatable, but I do get your point. Both GnuCash and GIMP are listed under GNU packages. As far as I can tell, they both have as much to do with the GNU Project and the FSF as any other GNU project. That is, they have "GNU" in the name and are licensed under the GPL. Development is usually separate. Do you have evidence of the contrary?

Please research whether each one of them is involved with GNU/FSF before making PRs.

I did. Also, I don't see that as an issue. After all, PRs don't need to be merged as per the "request" part of "pull request".

We shouldn't "group up" packages just for convenience sake.

Shouldn't we? I'm thinking maybe we should, but that's not for me to decide. Alas, there does not seem to be guidelines on this. This is partly why I opened this issue.

Also, there's the issue of what does "publisher" even mean. Is GNU a publisher? Wikipedia calls it a mass collaboration project.

[ghost]

The language on the GIMP website is unclear. Although, GNU claims that GIMP is a "GNU Project". @marnicgit, perhaps you know more about this?

[qiancy98]

Also GnuWin32 should be merged?

I don't think it should. GnuWin32 is a port just like Cygwin or MinGW. Probably best to keep it separate.

Thanks. (I searched a bit and got lost in information. Maybe I should quit the talk :-)

[latere-a-latere]

@mattiasmarka
https://www.gnu.org/philosophy/categories.html#GNUsoftware

From what I understand is that "GNU Software" is just software that follow the GNU ideologies/licenses and not necessary software that's published/developed by the GNU Project.

Current packages either use the publisher, the developer, the name of the app (in the case of a team effort like GIMP for example) or the name of a person (usually single-dev projects) as the publisher field.

[ghost]

From what I understand is that "GNU Software" is just software that follow the GNU ideologies/licenses and not necessary software that's published/developed by the GNU Project.

@marnicgit, that's not strictly true. You also need to go through a legal process in which you give your software to the GNU Project. The GNU Project seems to act as a sort of umbrella organization, so I think it's fair to call them the publisher. Also, all GNU Projects are part of the GNU system, whatever that means.

Maintainers can't choose to leave the GNU Project, as far is I understand. They can fork the project if they wish, but then it becomes a separate project. I think this is what happened with Nano at some point.

Current packages either use the publisher, the developer, the name of the app (in the case of a team effort like GIMP for example) or the name of a person (usually single-dev projects) as the publisher field.

Fair enough. But there's also directories like manifests/Microsoft and manifests/canonical. So the question remains: what constitutes a "publisher"? I'd be happy to follow whatever guidelines the repo maintainers think are best.

[latere-a-latere]

@marnicgit, that's not strictly true. You also need to go through a legal process in which you give your software to the GNU Project. The GNU Project seems to act as a sort of umbrella organization, so I think it's fair to call them the publisher. Also, all GNU Projects are part of the GNU system, whatever that means.

That's an interesting link you post there - The things they describe there fit the role of a publisher quite well actually. Looks like we're going to need some input from MS maintainers on this before continuing. I still think that GIMP.GIMP should keep that package name, because in the end it's still the "GIMP project" doing all the work, even though it's GNU appointing the people who are in that team.

Fair enough. But there's also directories like manifests/Microsoft and manifests/canonical. So the question remains: what constitutes a "publisher"? I'd be happy to follow whatever guidelines the repo maintainers think are best.

To be fair the Microsoft and Canonical folders both contain software developed by MS and Canonical. If they contain packages where this isn't the case, please correct me and look into correcting those packages as well.

As for guidelines regarding naming, we don't really have any set in stone - Someone should probably raise an issue about that, same with tagging and other manifest stuff, haha. I've been planning on publishing my own workflow on my own fork sometime and asking people to take a look at it to see how things can be improved and to learn from it.

[ghost]

@marnicgit, I think we're more or less on the same page then. I'm not sure who's in charge, so I don't know who to tag for input.

[denelon]

We asked ourselves some similar questions when the project started. I'm glad to see the community chiming in here. One of the concepts we're considering is how we can streamline the publish/approval process. Part of that would likely mean we're going to want to leverage the directory structure as a way to identify a publisher/owner for a package. It seems like different folders make sense when there is a GitHub team we can take advantage of. I was working on a Gist a while back. I'll see if I can dig it up and link it to this Issue.

[denelon]

https://gist.github.com/denelon/0285ade55410f118b92d03e883a24c5e

[peter-dolkens]

@denelon

Could CODEOWNERS not be used for this?

Instead of closing a PR, if we use CODEOWNERS, then the bot could be updated to require approval from one CODEOWNERS and one MS representative.

This would allow the community to continue contributing, and suggesting to the CODEOWNERS on what packages/features they may be interested in supporting.

[ghost]

@denelon, so am I to understand in the future the publisher parent directory should be representative of who's in charge of the package? In that case perhaps "publisher" isn't the best name for this. The word "publisher" is more to do with where the package came from. Then again, I can't think of a better word.