Re: non-gnu elpa issue tracking

[Tim Cross <theophilusx@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4295 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 5326 bytes --]