emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: non-gnu elpa issue tracking


From: Tim Cross
Subject: Re: non-gnu elpa issue tracking
Date: Sat, 12 Dec 2020 17:37:10 +1100

Bottom line is that if packages in non-GNU ELPA are hosted on Github, like it or not, you are encouraging the use of Github. Yes, there are many Github features you can access from the command line and via other means, like commenting on issues via email, but these other mechanisms typically take more effort and are not as convenient (and have limitations - you cannot use markup when commenting on issues via email for example). 

The non-GNU ELPA is supposed to be a repository for packages which are GPL compliant and it is a reasonable expectation that those who make their packages GPL compliant do so because they support the philosophical goals of the FSF. Therefore, I don't think it is too much to ask that they also have those packages hosted on a platform which also supports these same philosophical goals. As I understand it, non-GNU ELPA is not supposed to be a repository for all other packages where the author doe snot want to assign copyright to the FSF. It is supposed to be for all other GPL compliant packages where the author does not want to assign copyright to the FSF. 

I think a mandatory requirement should simply be that any packages which go into non-GNU ELPA are hosted on an approved platform. We could point to a list of such hosting providers e.g. https://www.gnu.org/software/repo-criteria-evaluation.html and say Grade C or better only. . 

This will also have the added incentive of encouraging better hosting options. It might even encourage GitLab for example, to enhance their environment to meet Class B. 

Many people have selected Github for hosting simply because it was the best known solution. With a little encouragement, they would probably be willing to move to at least GitLab, which offers many of the similar convenience features of Github.  Being able to host your package in non-GNU ELPA might be that encouragement. 

BTW I also think the questions regarding openess, arguments, not hurting feelings etc can be largely avoided by simply having clear well publicised policy which outlines the requirements for inclusion in non-GNU ELPA. The README is a good start, but it will likely take a few rounds of editing to get it right and make it clear (a challenging task, but not impossible) and a documented process for requesting a review for a rejected package or a package which has been included which someone thinks is not compliant. 

On Sat, 12 Dec 2020 at 16:36, Richard Stallman <rms@gnu.org> wrote:
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > As far as I remember from a previous discussion, it is possible to use
  > github with _javascript_ disabled, but creating an account requires
  > running non-free _javascript_ for the captcha. And it is not possible to
  > open or comment on issues without an account.

Assuming someone who knows for certain confirms that information, I
have to conclude that reporting bugs via GitHub comments is not an
ethical way to accept bug reports.  We cannot direct users to report
bugs in the package that way.  We should edit the README file to
remove that.

But there are other kinds of arrangements we can ask to make with the
package developers, such as

* The developers check bug-gnu-emacs for reports about their package.

* Establish an email address which will forward to them,
and give that as the way to report bugs in that package.

* A volunteer relayer who already has a GitHib account checks
bug-gnu-emacs for reports about that package, and enters them in
GitHib as comments.  The developers will have to reach the OP by email
-- the relayer would not want to keep relaying every conversation
for its whole length.

If the developers propose something else, and it meets the moral
requirements and isn't too much work, and we can do it, we should be
flexible.  I expect most packages won't get a bug report every month.

--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





--
regards,

Tim

--
Tim Cross


reply via email to

[Prev in Thread] Current Thread [Next in Thread]