From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Bozhidar Batsov" Newsgroups: gmane.emacs.devel Subject: Re: Allowing rolling release packages on ELPA Date: Wed, 26 Oct 2022 11:07:07 +0300 Message-ID: <19e3b6a4-6278-46c4-a6b9-a9ce0f4631b8@app.fastmail.com> References: <87a65jt8ov.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=d9e64fe3864b4f6e8c096b2148b07854 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13310"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Cyrus-JMAP/3.7.0-alpha0-1047-g9e4af4ada4-fm-20221005.001-g9e4af4ad Cc: "Emacs Devel" To: "Payas Relekar" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 26 10:09:35 2022 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 1onbTh-0003Gk-QL for ged-emacs-devel@m.gmane-mx.org; Wed, 26 Oct 2022 10:09:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1onbRp-0003vG-HB; Wed, 26 Oct 2022 04:07:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1onbRk-0003PZ-3B for emacs-devel@gnu.org; Wed, 26 Oct 2022 04:07:32 -0400 Original-Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1onbRh-0008V8-CW for emacs-devel@gnu.org; Wed, 26 Oct 2022 04:07:31 -0400 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id C21615C0148; Wed, 26 Oct 2022 04:07:28 -0400 (EDT) Original-Received: from imap43 ([10.202.2.93]) by compute5.internal (MEProxy); Wed, 26 Oct 2022 04:07:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=batsov.dev; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1666771648; x=1666858048; bh=aXg4/OShBr DT7oo8AfY8JUTfDTpioWBVk7g5AigVb/o=; b=I+vpSCbIJwPb3Noq8424njdyRe Cp2vW4KD3l4iYT7uuAgk46BDpJn1+aR/5NLJ4yilfu/4RvUPpqd3sXFZxKD7OZUf J0/+UMRIuRmyZvYeglRKa5pY6Gsv2esyFvl3x0yari1gnrl514LFQsAnAyL8KJIw ARlDxow6nkvoftceDmEI/H7cY6qDn5MjTw58+73FNahkSB2AuWgZJFJ9wtoqSXeR UQlkgJ8LUo+iJyJBJ/aNMLfRIG831bJdAswndnq7lzGzg1zlGeT1TuNr1acowgwQ 9rN2y1Aztzkh4xV6bS1ipJIBg0wwZ2+t2ksm6OWPdIQeScRSzfNaDw3297oQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1666771648; x=1666858048; bh=aXg4/OShBrDT7oo8AfY8JUTfDTpi oWBVk7g5AigVb/o=; b=FcrHxPl+okiYZcQ3b2Pj+DbJelZ6eoJaZwCJMSX3SgNO qYas13rhbwDJj41s6eGqGwvtxwict6vkoH2sO/mCs6sx8yWMoe0VJvPjzBNbjGd6 /Rpl26d83IbTcEy+249KhIsA4HYThuQ+1ARZbdvCRoSG8a3tJqLnRn4gG6asd/b4 gBqQNFW3z1Hyb3T8GlhIccj+yxGWrXvtgPRf13qPOxgt69qYj1eJJ/Ekvggx95bD gXexLs39D0/hheaWwGIIa/usJ+XHQUn83GVEoKJzghB2zn4IJFmgog5JOuqTTO40 yu484lztQ/fNm6vyyHLUHZrohgW4SxpxoaDtay/A1w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrtddvucetufdoteggodetrfdotffvucfrrh hofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh epofgfggfkjghffffhvfevufgtsegrtderreerredtnecuhfhrohhmpedfuehoiihhihgu rghruceurghtshhovhdfuceosghoiihhihgurghrsegsrghtshhovhdruggvvheqnecugg ftrfgrthhtvghrnhepkeduhfevffdujefgkefgudelffekveeileeigfekveeuhfetledv veduheeltdefnecuffhomhgrihhnpehmvghlphgrrdhorhhgpdhsthgrlhhlmhgrnhdroh hrghdpghhnuhdrohhrghdpfhhsfhdrohhrghdpihhnthgvrhhnvghthhgrlhhlohhffhgr mhgvrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepsghoiihhihgurghrsegsrghtshhovhdruggvvh X-ME-Proxy: Feedback-ID: i025946a9:Fastmail Original-Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8E6982D40071; Wed, 26 Oct 2022 04:07:28 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <87a65jt8ov.fsf@gmail.com> Received-SPF: pass client-ip=66.111.4.26; envelope-from=bozhidar@batsov.dev; helo=out2-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "Emacs-devel" Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:298523 Archived-At: --d9e64fe3864b4f6e8c096b2148b07854 Content-Type: text/plain To be clear - I'm arguing against rolling releases, just pointing out they require a bit of due diligence on their maintainers part. But if someone requested this explicitly I guess we can assume they know what they are doing. On Wed, Oct 26, 2022, at 8:58 AM, Payas Relekar wrote: > I'd say this approach is quite feasible, there are even popular GNU/Linux > distributions out there who don't do big timely releases, but have > rolling package updates, one of them I've been using for years with zero > issues. > > This generally relies upon development and deployment being supportive > of it. > > Some developers prefer to do development in separate branches. Git makes > this cheap and easy to the point of being free. When features/bug fixes > are good enough they can be safely merged to master with little to no > effort. Emacs itself does this quite often for big features > (native-comp, pgtk, tree-sitter). This way master is almost guaranteed > to be 'green'. > > IMO the status quo is a good default, but having an option of rolling > updates is good for developers that follow branched development. > > "Bozhidar Batsov" writes: > > > Instead of setting version numbers manually (e.g. 0.1, 0.2) upon release time, > > with rolling releases every change (commit) pushed upstream results > > automatically in a new release and a version bump, with the version being a > > timestamp. E.g. if I push 3 commits one day with some time between them this > > will result in 3 releases. I think it's a great approach for snapshot (devel) > > repos, but I'm not so sure about "stable" repos, as it kinda of implies that the > > author will never have their project in an inconsistent state (e.g. halfway > > towards a new feature). > > > > This approach was made popular by https://melpa.org/ > > > > On Tue, Oct 25, 2022, at 11:14 PM, Richard Stallman 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. ]]] > >> > >> > I have heard from people who prefer a rolling release model for their > >> > packages, > >> > >> Can you explain what that means, concretely? How is t different from > >> what we do now? > >> > >> and requested that their packages not be added for {Non,}GNU > >> > ELPA if they would have to update the version header manually, > >> > presumably on every commit. > >> > >> Is this something we would _want_ to do? What would its implications > >> be for Emacs? > >> > >> We might decide to support their style of release, or decide not to > >> include their packages in NonGNU ELPA, or we might come up with > >> another solution. I don't know what's best. But I'm sure we should > >> think about that before we decide. > >> > >> > >> -- > >> Dr Richard Stallman (https://stallman.org) > >> Chief GNUisance of the GNU Project (https://gnu.org) > >> Founder, Free Software Foundation (https://fsf.org) > >> Internet Hall-of-Famer (https://internethalloffame.org) > >> > >> > >> > >> > > -- > --d9e64fe3864b4f6e8c096b2148b07854 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
To be clear - I= 'm arguing against rolling releases, just pointing out they require a bi= t
of due diligence on their maintainers part.  But if= someone requested this explicitly I guess
we can assume t= hey know what they are doing.

On Wed, Oct = 26, 2022, at 8:58 AM, Payas Relekar wrote:
I'd say this approach is quite feasible,= there are even popular GNU/Linux
distributions out there = who don't do big timely releases, but have
rolling package= updates, one of them I've been using for years with zero
= issues.

This generally relies upon developm= ent and deployment being supportive
of it.
<= br>
Some developers prefer to do development in separate branc= hes. Git makes
this cheap and easy to the point of being f= ree. When features/bug fixes
are good enough they can be s= afely merged to master with little to no
effort. Emacs its= elf does this quite often for big features
(native-comp, p= gtk, tree-sitter). This way master is almost guaranteed
to= be 'green'.

IMO the status quo is a good d= efault, but having an option of rolling
updates is good fo= r developers that follow branched development.

<= div>"Bozhidar Batsov" <bozhida= r@batsov.dev> writes:

> Instead o= f setting version numbers manually (e.g. 0.1, 0.2) upon release time,
> with rolling releases every change (commit) pushed upst= ream results
> automatically in a new release and a ver= sion bump, with the version being a
> timestamp. E.g. i= f I push 3 commits one day with some time between them this
> will result in 3 releases. I think it's a great approach for snap= shot (devel)
> repos, but I'm not so sure about "stable= " repos, as it kinda of implies that the
> author will = never have their project in an inconsistent state (e.g. halfway
> towards a new feature).
>
>= This approach was made popular by h= ttps://melpa.org/
>
> On Tue, Oct = 25, 2022, at 11:14 PM, Richard Stallman wrote:
>> [[= [ To any NSA and FBI agents reading my email: please consider  = ;  ]]]
>> [[[ whether defending the US Constitu= tion against all enemies,     ]]]
>= > [[[ foreign or domestic, requires you to follow Snowden's example. = ]]]
>>
>>   > I hav= e heard from people who prefer a rolling release model for their
>>   > packages,
>>
>> Can you explain what that means, concretely?  How = is t different from
>> what we do now?
>>
>>      &nbs= p;        and requested that their pa= ckages not be added for {Non,}GNU
>>   >= ; ELPA if they would have to update the version header manually,
>>   > presumably on every commit.
>>
>> Is this something we would _want_ to = do?  What would its implications
>> be for Emac= s?
>>
>> We might decide to supp= ort their style of release, or decide not to
>> incl= ude their packages in NonGNU ELPA, or we might come up with
>> another solution.  I don't know what's best.  But I= 'm sure we should
>> think about that before we deci= de.
>>
>>
>>= --
>> Dr Richard Stallman (https://stallman.org)
>> Chief GNUisanc= e of the GNU Project (https://gnu.org)
>> Founder, Free Software Foundation (https://fsf.org)
>> Internet Hall-o= f-Famer (https://internethall= offame.org)
>>
>>
<= div>>>
>>

--
<= /div>


--d9e64fe3864b4f6e8c096b2148b07854--