From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: non-gnu elpa issue tracking Date: Sun, 13 Dec 2020 11:39:36 +1100 Message-ID: References: <20201209125516.lenqswi7fhiscbr2@E15-2016.optimum.net> <86360apxbk.fsf@stephe-leake.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000046c96705b64dc33e" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34579"; 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: Christopher Dimech Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 13 01:47:32 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 1koFXv-0008qH-Rq for ged-emacs-devel@m.gmane-mx.org; Sun, 13 Dec 2020 01:47:32 +0100 Original-Received: from localhost ([::1]:45702 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1koFXu-0007e3-UY for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Dec 2020 19:47:30 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39600) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koFQf-0004cR-S4 for emacs-devel@gnu.org; Sat, 12 Dec 2020 19:40:01 -0500 Original-Received: from mail-ot1-x32c.google.com ([2607:f8b0:4864:20::32c]:41793) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1koFQd-0004Ay-JC; Sat, 12 Dec 2020 19:40:01 -0500 Original-Received: by mail-ot1-x32c.google.com with SMTP id x13so12110518oto.8; Sat, 12 Dec 2020 16:39:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JlH5g2SNBBnhu1ifRFUJMuWW6lQFuuPl5uD15STfH+c=; b=BaBc2R11wY2P9EriY+MJ8XLK9vMDUJVRrowzwMVAT7h542of+OmAzooxO4NK+1Ag9j kVQocLByheusGbfx1RFjdHh5ons1FHSr6BVhsUThjRO0o982DM5BcEATkHVA1B2DoHiP JsueHTTYRTyz/Id+/2SNE+yqytrF8DOIEtK1PKM132TMKSbrotG9xm3XYxKTyNMF1s9q RpBv1i1p6eQIp/uKq96ZitIMxumXuj7gGuvSomG6bWB15jGjU5j1emRdJtnYlJujt2cw GQdCs/b90Fd7G00WxW1gLLpAzJ20Gu74xgn/22e3faPWDmsuObbvzHsVs9I6nFD4pBbP 22SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JlH5g2SNBBnhu1ifRFUJMuWW6lQFuuPl5uD15STfH+c=; b=mbDmapGlCBJYasI0B7qBaay5Yix9pz8z+75NKunqE25RXQ6wjZ9tgaAiI0MR7sBkAG +LnXxIueHGOn0ZAUytdV3+1q5dpMM+I+kokN3H6j2fFPK1ztaJS4LJyavYWci8yurDoe FiH+5wbZ2j6WoNi8nBLxDmEbHXhX3oyckwrhPYugDC+AUyJrRt7A1V8DVPp9GGjGkK/K UaDYZSxdJ3jE7A7jaj8Z1e2decCZpfZXRRoUyekOZHY4XMW+E/kWoLbFOM5TT03wvlmZ m8rMKCqBwj4pE00+UXJmKzTPIj2Dy8nxZYgA5XKvrtKh6xC9VZhJ5j+5+xfwSOtv0jKn aHwg== X-Gm-Message-State: AOAM5302AdlaAPbemA06v79VVmuTMW7ce74oZzQS31BslPj1tuiRR/Vl D+QrRysE0Ek/a8LF/i1RRxXTppcqTXMUagdPyuc= X-Google-Smtp-Source: ABdhPJzyNq7knYfKBavD48nEhxDevfUrW0+CHPwr+Div7JU8SJp2BZXx/EUoCNed51/ksR1E8EMFwo1tL15SltX4T3Y= X-Received: by 2002:a9d:2c63:: with SMTP id f90mr14960452otb.325.1607819988485; Sat, 12 Dec 2020 16:39:48 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::32c; envelope-from=theophilusx@gmail.com; helo=mail-ot1-x32c.google.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:260738 Archived-At: --00000000000046c96705b64dc33e Content-Type: text/plain; charset="UTF-8" Just to clarify a bit. I am not suggesting we remove packages which fail to migrate from github/sourceforge to a more complaint hosting environment. A decision could be that we ask existing maintainers to move and require that all new packages from a specific date are only on a supported hosting environment. 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 with FSF philosophy and goals. In some sense, it could be a testbed to refine a more general repository approach that might be applied to GNU ELPA at some point in the future. I would never agree to a 'name and shame' approach. That is seldom an appropriate course of action and can only be justified when there are very serious direct consequences. What we want here is increased incentive, a carrot, not a stick. 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. Microsoft is a public company run by a board of directors who have an obligation to maximise the share prices and dividends for the shareholders. Ultimately, decisions are based on maintaining and increasing profit. The ability to make decisions to further such profit generation is closely tied to control. This makes any decision which gives up control less likely to be welcomed. I have little confidence Microsoft would be willing to give up the level of control necessary for it to become accepted under FSF guidelines as an ethical hosting provider. Some minor cosmetic changes might be possible, but little more. We would probably have better success moving Gitlab from Class C to Class B with respect to providing an FSF compliant hosting platform. My main point here is that many of the problems associated with maintenance of packages, such as issue tracking, are being significantly complicated because the code is being maintained on a platform which does not meet GNU/FSF guidelines, philosophy and goals. If a key goal of the FSF is to promote an ethical position with respect to software, it has to prioritise that ethical position over convenience. Convenience is probably the number one threat to software freedom. Rather than focus on the inconvenience of requiring maintainers to use a more appropriate hosting platform, consider the potential benefits with respect to issue tracking and maintenance that would be possible without the limitations and confusion caused by the current situation. Furthermore, consider the benefits to the core message of having an ecosystem which is actually based on more ethically compliant systems. On Sun, 13 Dec 2020 at 08:48, Christopher Dimech wrote: > > Sent: Saturday, December 12, 2020 at 9:46 PM > > From: "Stephen Leake" > > To: "Tim Cross" > > Cc: "Jean Louis" , thibaut.verron@gmail.com, "Stefan > Kangas" , "Boruch Baum" , > "Emacs developers" , "Stefan Monnier" < > monnier@iro.umontreal.ca>, "Richard Stallman" > > Subject: Re: non-gnu elpa issue tracking > > > > Tim Cross writes: > > > > > On Sun, 13 Dec 2020 at 00:50, Stefan Monnier > > > > wrote: > > > > > >> > 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. > > >> > > >> The overwhelming majority of ELisp packages out there are hosted on > > >> Github (that also applies to many GNU ELPA packages, many of them are > > >> developed by long time contributors to Emacs), so I think the evidence > > >> shows the above expectation doesn't hold at all. > > >> > > > Maybe. However, it could also be a combination of the fact github was > the > > > first free git hosting environment and is the better known one. Just > > > because it is this way now doesn't mean it has to be. If the GNU/FSF > > > doesn't take a clear position on this and do something to discourage > the > > > use of hosting environments that force the use of proprietary software, > > > this will not change and eventually all we will have are the > proprietary > > > solutions. It may not have been the right decision to allow code which > has > > > assigned copyright to the FSF to remain on Github. However, as non-GNU > ELPA > > > is just getting started, now would be a good time to try and change > > > things. > > > > +1. > > > > I think we should encourage people to move away from Github, for both > > GNU and non-GNU ELPA. > > > > Given that many ELPA packages are now on Github, we could have a > > transition policy, with enforceable deadlines (ie, remove package from > > *GNU ELPA if still on gitub after deadline). However, I doubt that the > > Emacs project is capable of such a thing, or that we want to be. > > > > So we are left with naming and shaming; in list-packages, show the > > upstream repository along with the license and other info on a package, > > and show unacceptable ones in red. That could still be a lot of effort > > to categorize obscure hosts. > > I do not see how putting a copy on GitHub is an offence. We can > discourage it, > But removing packages from GNU ELPA if still on Github after deadline, is > not the way forward. Removing free software from ELPA is a regressive move > that will not benefit Gnu in any way. > > > Disclaimer; my packages are hosted on Savannah, so any resolution of this > > will have no direct impact on me. > > > > -- > > -- Stephe > > > > > -- regards, Tim -- Tim Cross --00000000000046c96705b64dc33e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to clarify a bit.

I am not suggest= ing we remove packages which fail to migrate from github/sourceforge to a m= ore complaint hosting environment. A decision could be that we ask existing= maintainers to move and require that all new packages from a specific date= are only on a supported=C2=A0hosting environment. 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 est= ablishing a repository which is more in line with FSF philosophy and goals.= In some sense, it could be a testbed to refine a more general repository a= pproach that might be applied to GNU ELPA at some point in the future.=C2= =A0

I would never agree to a 'name and shame&#= 39; approach. That is seldom an appropriate course of action and can only b= e justified when there are very serious direct consequences. What we want h= ere is increased incentive,=C2=A0a carrot, not a stick.=C2=A0
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. Microsoft is a public company run by a boa= rd of directors who have an obligation to maximise the share prices and div= idends for the shareholders. Ultimately, decisions are based on maintaining= and increasing profit. The ability to make decisions to further such profi= t generation is closely tied to control. This makes any decision which give= s up control less likely to be welcomed. I have little confidence Microsoft= would be willing to give up the level of control necessary for it to becom= e accepted under FSF guidelines as an ethical=C2=A0hosting provider. Some m= inor cosmetic changes might be possible, but little more. We would probably= have better success moving Gitlab from Class=C2=A0C to Class B with respec= t to providing an FSF compliant hosting platform.

= My main point here is that many of the problems associated with maintenance= of packages, such as issue tracking, are being significantly complicated b= ecause the code is being maintained on a platform which does not meet GNU/F= SF guidelines, philosophy and goals. If a key goal=C2=A0of the FSF is to pr= omote an ethical position with respect to software, it has to prioritise th= at ethical position over convenience. Convenience is probably the number on= e threat to software freedom.=C2=A0 Rather than focus on the inconvenience = of requiring maintainers to use a more appropriate hosting platform, consid= er the potential benefits with respect to issue tracking and maintenance th= at would be possible without the limitations and confusion caused by the cu= rrent situation.=C2=A0 Furthermore, consider the benefits to the core messa= ge of having an ecosystem which is actually based on more ethically complia= nt systems.=C2=A0



On Sun, 13 Dec 2020 = at 08:48, Christopher Dimech <dimech@g= mx.com> wrote:
> Sent: Saturday, December 12, 2020 at 9:46 PM
> From: "Stephen Leake" <stephen_leake@stephe-leake.org> > To: "Tim Cross" <theophilusx@gmail.com>
> Cc: "Jean Louis" <bugs@gnu.support>, thibaut.verron@gmail.com, = "Stefan Kangas" <stefankangas@gmail.com>, "Boruch Baum" <= boruch_baum@gmx.co= m>, "Emacs developers" <emacs-devel@gnu.org>, "Stefan Monnier= " <mo= nnier@iro.umontreal.ca>, "Richard Stallman" <rms@gnu.org>
> Subject: Re: non-gnu elpa issue tracking
>
> Tim Cross <theophilusx@gmail.com> writes:
>
> > On Sun, 13 Dec 2020 at 00:50, Stefan Monnier <monnier@iro.umontreal.ca&= gt;
> > wrote:
> >
> >> > The non-GNU ELPA is supposed to be a repository for pack= ages which are
> >> GPL
> >> > compliant and it is a reasonable expectation that those = who make their
> >> > packages GPL compliant do so because they support the ph= ilosophical goals
> >> > of the FSF.
> >>
> >> The overwhelming majority of ELisp packages out there are hos= ted on
> >> Github (that also applies to many GNU ELPA packages, many of = them are
> >> developed by long time contributors to Emacs), so I think the= evidence
> >> shows the above expectation doesn't hold at all.
> >>
> > Maybe. However, it could also be a combination of the fact github= was the
> > first free git hosting environment and is the better known one. J= ust
> > because it is this way now doesn't mean it has to be. If the = GNU/FSF
> > doesn't take a clear position on this and do something to dis= courage the
> > use of hosting environments that force the use of proprietary sof= tware,
> > this will not change and eventually all we will have are the prop= rietary
> > solutions. It may not have been the right decision to allow code = which has
> > assigned copyright to the FSF to remain on Github. However, as no= n-GNU ELPA
> > is just getting started, now would be a good time to try and chan= ge
> > things.
>
> +1.
>
> I think we should encourage people to move away from Github, for both<= br> > GNU and non-GNU ELPA.
>
> Given that many ELPA packages are now on Github, we could have a
> transition policy, with enforceable deadlines (ie, remove package from=
> *GNU ELPA if still on gitub after deadline). However, I doubt that the=
> Emacs project is capable of such a thing, or that we want to be.
>
> So we are left with naming and shaming; in list-packages, show the
> upstream repository along with the license and other info on a package= ,
> and show unacceptable ones in red. That could still be a lot of effort=
> to categorize obscure hosts.

I do not see how putting a copy on GitHub is an offence.=C2=A0 We can disco= urage it,
But removing packages from GNU ELPA if still on Github after deadline, is not the way forward.=C2=A0 Removing free software from ELPA is a regressive= move
that will not benefit Gnu in any way.

> Disclaimer; my packages are hosted on Savannah, so any resolution of t= his
> will have no direct impact on me.
>
> --
> -- Stephe
>
>


--
regards,

Tim

--
Tim Cross

--00000000000046c96705b64dc33e--