Ticket #810 (closed task: fixed)

Opened 2 years ago

Last modified 2 years ago

Clarify our position on forks

Reported by: cwickert Owned by:
Priority: major Keywords: meeting
Cc: Blocked By:
Blocking:

Description

phenomenon

We have a policy to forbid bundled libraries, but it's unclear what this means for forks.

background analysis

With mate and cinnamon, forks seem to become more and more popular. Some of these forks are about to enter Fedora and therefor we need to clarify our position on forks and the duplication of system libraries.

Both muffin (fork of mutter) and cinnamon (fork of gnome-shell) are forks for nearly a reason. The code changes are minimal, the biggest change is the change of the headers to include the new FSFE address - and it seems not even this trivial change was forwarded to the GNOME developers.

There are more problems:

  • We are already working around problems in packaging that were fixed in the orignal code upstream
  • Given the rate of commits the forks will have a hard time catching up with the originals. They already lag behind massively.

More background info in Bugzilla

implementation recommendation

I have no idea, that's why I want a statement from FESCo.

Change History

comment:1 Changed 2 years ago by kevin

  • Keywords meeting added

comment:2 Changed 2 years ago by toshio

This may be an FPC issue. For the case of individual libraries, FPC has long said that forks are okay, and in fact, are one legitimate way to get out of a bundled library situation. If the question is whether packaing forks is allowed, I think that is definitely an FPC question. If the question is should there be some criteria to discourage forking (for instance, "If you are packaging a fork, you should ask upstream why they have chosen to split off from the main upstream development) that would also be an FPC issue.

This could also be a FESCo issue or responsibility might be shared. FPC tries not to say what may or may not be packaged but rather how to package those things. (as an example, no bundled libraries is not forbidding the packaging of an upstream piece of software that bundles in the upstream tarball -- it's saying that the upstream piece of software may not use the libraries that are shipped in their tarball; they must use a system version that is potentially shared with other software instead[but that system version could still be a forked copy -- it's just that the library is made available to all]). So if the question is should this particular fork be specifically disallowed despite not violating any packaging guidelines, that would be a FESCo question.

I can think of two other discussions in Fedora that are similar to this. One is the prohibition against shipping external kernel modules. The other was the discussion about whether old versions of software may be packaged for parallel installation without the consent of the primary maintainer of the software (note that that policy was written specifically to address someone who wanted to ship an older python-2.4 stack concurrently with the python-(2.5.x at the time) stack so that zope would run.) Both of these are much larger in scope than the forking of one library. Both of these ended up passing through FESCo (and were contentious). They may have also been reviewed by FPC -- I'd need to research the very old meeting notes to find that out. I know that FPC members weighed in but that is separate from them actually taking it up in a meeting. Since the zope packager dropped his request to package an older version of python before the discussion completed, I'm not certain if the latter was voted into a FESCo policy or simply dropped. So if the question is whether to prohibit shipping the code that's forked in the Mate project, that could be a FESCo issue but FESCo will probably want to consult with FPC as well.

I'll also note that one of the principles of the package collection is that we do not forbid people from packaging things that are... poorly written. We make the decision on what to do with poorly written software when we decide what software will go into our images, be default systems, etc. We still let people who want to install the properly packaged but poorly written software do so from the yum repositories. We do have an explicit note on the wiki that when people wish to adopt software which is retired because upstream is dead, the Fedora package maintainer is still responsible for fixing bugs (and therefore, they may have to do more coding to fix bugs in the package). Extending that to cover the case where an upstream is unable to keep up with their bug load is another possible way forward.

comment:3 Changed 2 years ago by mmaslano

After reading: https://bugzilla.redhat.com/show_bug.cgi?id=771252#c21 I don't think we should be looking into quality of code, because that's not a part of the package review. If the issue was only bundling libraries, then it would be work for FPC.

But forking doesn't sound like a bundling exception. I wouldn't ban packaging of Mate or Cinnamon especially if they were installed from non-Fedora repositories. I guess those packages will be popular and we should encourage maintainers to share library if it's a possible.

+1 for accepting forks, but it needs defined boundaries, probably given by FPC.

comment:4 Changed 2 years ago by kevin

  • Status changed from new to closed
  • Resolution set to fixed

At the 2012-02-27 meeting we agreed to forks are allowed provided they do not conflict or interfere with other packages. FPC may add additional guidelines to forks as they see fit

I've filed a FPC ticket to ask them if they would like to add any additional guidelines on forks. https://fedorahosted.org/fpc/ticket/148

Note: See TracTickets for help on using tickets.