From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Christopher Dimech Newsgroups: gmane.emacs.devel Subject: Re: non-gnu elpa issue tracking Date: Sun, 13 Dec 2020 02:28:34 +0100 Message-ID: References: <20201209125516.lenqswi7fhiscbr2@E15-2016.optimum.net> <86360apxbk.fsf@stephe-leake.org> Mime-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13317"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Jean Louis , Richard Stallman , thibaut.verron@gmail.com, Boruch Baum , Emacs developers , Stefan Kangas , stephen_leake@stephe-leake.org, Stefan Monnier To: Tim Cross Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 13 02:32:25 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1koGFN-0003Lv-8g for ged-emacs-devel@m.gmane-mx.org; Sun, 13 Dec 2020 02:32:25 +0100 Original-Received: from localhost ([::1]:38760 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1koGFM-0003SD-8o for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Dec 2020 20:32:24 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44678) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koGCg-0002Xq-ES for emacs-devel@gnu.org; Sat, 12 Dec 2020 20:29:38 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:51841) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koGCa-00037Y-F9; Sat, 12 Dec 2020 20:29:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1607822914; bh=s8aYvP282kVoBKd36hvCBe5KuAirGPdOtkGKTcG7Db4=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=eMzDQ8z72zKr8IWkUYRqlEvzrpAkUve6AkIHnmNw+Ub+IDj1+tSnim43waIT+ZQ7+ C51DpKiF0vEY77o+A/qUW8UkwEDrQBL/cbG86RHFeWyekedOLhBZikpF4F3Ig6zqQz d1F69FTa7huULQkG+04Aovf9ggDvl9fdIKztX2Gg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [213.165.168.94] ([213.165.168.94]) by web-mail.gmx.net (3c-app-mailcom-bs06.server.lan [172.19.170.174]) (via HTTP); Sun, 13 Dec 2020 02:28:34 +0100 Importance: normal Sensitivity: Normal In-Reply-To: X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:FGmt6vhIuJLLz+Y3MLGWmQ+atHxXOLsDL5ExnyOuk6IeI47tkGnTPGDXYVFXka6CmKRZR dLM7V2AQqwF7jliPbZt7RmN9YdkZ4cJqNrIZXYqI86/HuIhqOG/5aBmPmfbsh5SdM7QWMwy+f+H2 lpwYq6Y34YBm3L/CJad92U/3VABqur55jKqO87FguQukSsONfqSZWe63CqLYvh6ei0RWnKhTlbb8 P3yiFAO9dRnc+e3b2deqiRIhyQko5ueueHp4Nn0Y/LL9g2nc4Ab1S6KZHJWe/I93vxBhmsMAMDNF c4= X-UI-Out-Filterresults: notjunk:1;V03:K0:LDZZESnXbBk=:TkTLJ1vL9EF+YULccaxdOI 5hkxCZALlgFCN+zRjTV3jrj1mHd7pKVXHZaLvPnK94lN4Hap2rbVYG5cFTlnbVRhdYPVcObok x5NGsn6tLvE8kRK4FdFrC/6rFBSFBK/lB02TA/8y52u3oErGNtAYhhKaUiQUXvIztZ9zo+SCA EjYqe3nvlu3w1QegO/BznsHYG6mEawRU+lkzOmVyrJydOkq2TnLNVFL0zUuKfsJADK5tENnyD Nk68WutYHbpG5r8ieIV0wZ1Un/8g72RPvk/cSMo680e+IwDmluFAnRPgogqlrpC71rL8YPAaZ pgDRVmjoBn9tL+BeNiTkC3+dNjP+/ED1EubXr0ChZt8P+8uTeI0ADNujUl3RwIajz4DgytPOv zlzvqGb8mReNd4/KEJwBxJvUL1gr2tMCH6fgI4F5f2b+qAYVrwlrQlJBK3X1JfktiIA6eB9Ua 3Y1Jgm0Bl+tnnHmluS7dRxH9LlZSwjqQ1hkiNinv0nD+1PADjXr25ewYNi5Nf7vdsUDJLKOAz BBhNh1bnmrbUWepyeYp54q/FHLUAsvOvfYITSJTK43qVa44NdzaZitcepBfFf4oNg/vAOY8r3 7aqp6LJpXBCMM= Received-SPF: pass client-ip=212.227.17.22; envelope-from=dimech@gmx.com; helo=mout.gmx.net X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:260739 Archived-At:
From: "Tim Cross" <theophilusx@gmail= =2Ecom>
My main point here is that many of the problems associated with maint= enance of packages, such as issue tracking, are being significantly complic= ated because the code is being maintained on a platform which does not meet= GNU/FSF guidelines, philosophy and goals=2E If a key goal of the FSF = is to promote an ethical position with respect to software, it has to prior= itise that ethical position over convenience=2E Convenience is probably the= number one threat to software freedom=2E 
 
From: "Christopher Dimech" <dimech@gmx=2Ecom><= /div>
Here, I fully agree=2E  If some packages are being maintained on= a platform which does not meet GNU/FSF guidelines,
then it is in our remit to track and support the various hosting pref= erences of maintainers=2E  Maintainers can have
releases on Non-Gnu ELPA if they wish, but as you correctly specified= , distributing code under Gnu requires adherence
of specific conformance levels=2E
        This leads naturally to th= e production of conformance requirements that pacakages have to reach in or= der to be
acceptable=2E  Thus, we get to have something like the  Gnu= Software Evaluatuion (let us say the Non-Gnu Elpa Software
Evaluation)=2E  That is, the process for inclusion in Non-Gnu El= pa should also be a formal process, as with Gnu Packages=2E
        I am of the position that = we formally have Gnu Conformance Levels associated with them, for user'= s sake=2E This is
important because if the software has some minor problems, how would = you know when or if the pcakage is sufficiently
conformant in way that supports user freedom?
        We should also reconsider = the name "Non-Gnu"=2E Ideally, it should be identified with Gnu S= tandards=2E  We need a better
name, although distinct from Official Gnu Packages=2E Though I recogn= ise that coming up with an appropriate name is not
an easy task=2E 
 
Sent: Sunday, December 13, 2= 020 at 1:39 AM
From: "Tim Cross" <theophilusx@gmail=2Ecom> To: "Christopher Dimech" <dimech@gmx=2Ecom> Cc: "Jean Louis" <bugs@gnu=2Esupport>, "R= ichard Stallman" <rms@gnu=2Eorg>, thibaut=2Everron@gmail=2Ecom, = "Boruch Baum" <boruch_baum@gmx=2Ecom>, "Emacs develope= rs" <emacs-devel@gnu=2Eorg>, "Stefan Kangas" <stefa= nkangas@gmail=2Ecom>, stephen_leake@stephe-leake=2Eorg, "Stefan Mon= nier" <monnier@iro=2Eumontreal=2Eca>
Subject: Re: non-gnu elpa issue tracking
Just to clarify a bit=2E
 
I am not suggesting we remove packages which fail to migrate from git= hub/sourceforge to a more complaint hosting environment=2E A decision could= be that we ask existing maintainers to move and require that all new packa= ges from a specific date are only on a supported hosting environment= =2E I raised this suggestion now specifically with respect to non-GNU ELPA = because that is a relatively new repository and as such, it could be a good= place to start with for establishing a repository which is more in line wi= th FSF philosophy and goals=2E In some sense, it could be a testbed to refi= ne a more general repository approach that might be applied to GNU ELPA at = some point in the future=2E 
 
I would never agree to a 'name and shame' approach=2E That is= seldom an appropriate course of action and can only be justified when ther= e are very serious direct consequences=2E What we want here is increased in= centive, a carrot, not a stick=2E 
 
With respect to Github and Microsoft, I have little confidence in the= proposition we could put pressure on Github to adopt practices that are in= -line with FSF philosophy=2E Microsoft is a public company run by a board o= f directors who have an obligation to maximise the share prices and dividen= ds for the shareholders=2E Ultimately, decisions are based on maintaining a= nd increasing profit=2E The ability to make decisions to further such profi= t generation is closely tied to control=2E This makes any decision which gi= ves up control less likely to be welcomed=2E I have little confidence Micro= soft would be willing to give up the level of control necessary for it to b= ecome accepted under FSF guidelines as an ethical hosting provider=2E = Some minor cosmetic changes might be possible, but little more=2E We would = probably have better success moving Gitlab from Class C to Class B wit= h respect to providing an FSF compliant hosting platform=2E
 
My main point here is that many of the problems associated with maint= enance of packages, such as issue tracking, are being significantly complic= ated because the code is being maintained on a platform which does not meet= GNU/FSF guidelines, philosophy and goals=2E If a key goal of the FSF = is to promote an ethical position with respect to software, it has to prior= itise that ethical position over convenience=2E Convenience is probably the= number one threat to software freedom=2E 
 
Rather than focus on the inconvenience of requiring maintainers to us= e a more appropriate hosting platform, consider the potential benefits with= respect to issue tracking and maintenance that would be possible without t= he limitations and confusion caused by the current situation=2E  Furth= ermore, consider the benefits to the core message of having an ecosystem wh= ich is actually based on more ethically compliant systems=2E 
 
 
 
On Sun, 13 Dec 2020 at 08:48, Christopher Dimech= <dimech@gmx=2Ecom> wrote:
> Sent: Saturday, December 12, 2020 at 9:46 PM
> From: "Stephen Leake" <= stephen_leake@stephe-leake=2Eorg>
> To: "Tim Cross" <theophilusx@gmail=2Ecom<= /a>>
> Cc: "Jean Louis" <bugs@gnu=2Esupport>, thibaut=2Everron@gmail=2Ecom, "Stefan Kangas" <= ;stefankangas@gmail=2Ecom>, "Boruch Baum"= <boruch_baum@gmx=2Ecom>, "Emacs developers"= <emacs-devel@gnu=2Eorg>, "Stefan Monnier" &= lt;monnier@iro=2Eumontreal=2Eca>, "Ric= hard Stallman" <rms@gnu=2Eorg>
> Subject: Re: non-gnu elpa issue tracking
>
> Tim Cross <theophilusx@gmail=2Ecom> writes:<= br/> >
> > On Sun, 13 Dec 2020 at 00:50, Stefan Monnier <monnier@iro=2Eumontreal=2Eca>
> > wrote:
> >
> >> > The non-GNU ELPA is supposed to be a repository for pac= kages which are
> >> GPL
> >> > compliant and it is a reasonable expectation that those= who make their
> >> > packages GPL compliant do so because they support the p= hilosophical goals
> >> > of the FSF=2E
> >>
> >> The overwhelming majority of ELisp packages out there are ho= sted on
> >> Github (that also applies to many GNU ELPA packages, many of= them are
> >> developed by long time contributors to Emacs), so I think th= e evidence
> >> shows the above expectation doesn't hold at all=2E
> >>
> > Maybe=2E However, it could also be a combination of the fact git= hub was the
> > first free git hosting environment and is the better known one= =2E Just
> > because it is this way now doesn't mean it has to be=2E If t= he GNU/FSF
> > doesn't take a clear position on this and do something to di= scourage the
> > use of hosting environments that force the use of proprietary so= ftware,
> > this will not change and eventually all we will have are the pro= prietary
> > solutions=2E It may not have been the right decision to allow co= de which has
> > assigned copyright to the FSF to remain on Github=2E However, as= non-GNU ELPA
> > is just getting started, now would be a good time to try and cha= nge
> > things=2E
>
> +1=2E
>
> I think we should encourage people to move away from Github, for both=
> GNU and non-GNU ELPA=2E
>
> Given that many ELPA packages are now on Github, we could have a
> transition policy, with enforceable deadlines (ie, remove package fro= m
> *GNU ELPA if still on gitub after deadline)=2E However, I doubt that = the
> Emacs project is capable of such a thing, or that we want to be=2E >
> So we are left with naming and shaming; in list-packages, show the > upstream repository along with the license and other info on a packag= e,
> and show unacceptable ones in red=2E That could still be a lot of eff= ort
> to categorize obscure hosts=2E

I do not see how putting a copy on GitHub is an offence=2E  We can di= scourage it,
But removing packages from GNU ELPA if still on Github after deadline, is<= br/> not the way forward=2E  Removing free software from ELPA is a regress= ive move
that will not benefit Gnu in any way=2E

> Disclaimer; my packages are hosted on Savannah, so any resolution of = this
> will have no direct impact on me=2E
>
> --
> -- Stephe
>
>
 
 
--
regards,
 
Tim
 
--
Tim Cross