From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Basil L. Contovounesios" Newsgroups: gmane.emacs.devel Subject: Re: GNU-devel and NonGNU-devel Date: Thu, 25 Feb 2021 02:19:47 +0000 Message-ID: <87tuq0rirg.fsf@tcd.ie> References: <878s7m1mo3.fsf@gnus.org> <87ft1u9xhh.fsf@telefonica.net> <87o8giz61u.fsf@gnus.org> <87blchzo9b.fsf@gnus.org> <875z2pu0as.fsf@gmail.com> <87pn0wuv0b.fsf@gnus.org> <87mtvxii7u.fsf_-_@tcd.ie> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14422"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Feb 25 03:21:11 2021 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 1lF6H9-0003fK-9p for ged-emacs-devel@m.gmane-mx.org; Thu, 25 Feb 2021 03:21:11 +0100 Original-Received: from localhost ([::1]:39078 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lF6H8-00022f-7c for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Feb 2021 21:21:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47352) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lF6Fs-0001ZA-TZ for emacs-devel@gnu.org; Wed, 24 Feb 2021 21:19:52 -0500 Original-Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]:39251) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lF6Fq-0007GR-WB for emacs-devel@gnu.org; Wed, 24 Feb 2021 21:19:52 -0500 Original-Received: by mail-wm1-x333.google.com with SMTP id u125so3496850wmg.4 for ; Wed, 24 Feb 2021 18:19:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd.ie; s=google21; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=QzdW3MG9ANZSj5cVdat6S1hMN/W41FkKzTi+GW1gdDg=; b=Q/E/Wc3AJX+HeLT6sGf+LyC0D/vfqwPDdKlrcxcOCVCNll0htddNCmmzP2wLOdTsfY 6SJ4x6z3pMM2hLoRfan1YIoi4sUy30e/Rbf4VT2M/CorYeOOVwKq+nmnkFGcjoYnq7w2 5jumfgOB5ihWzKuscURQtQtY1Mz9KVBXGdeNKl6An15guXd3TTWmoAyJ6YnvWDyI5al1 S+1xJOhmRYDVFSIb+S+jkrP6exhM2YFscpoXKoASxzWS5OETOZqmbs3Cq8mm9yhOyJR9 Y9arkI0hMRTrFYO6KjNLuz2A7Bfv80QBcynyeYRRyBGxhz/QhRvfAKjhEiQESKgT4/X1 H5Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=QzdW3MG9ANZSj5cVdat6S1hMN/W41FkKzTi+GW1gdDg=; b=BzmxZxcwWgXD5/wI3f0TGX6LYAYNFtIgp1lsmrgTOdzFxBUk4G3Cw6JurFyDgx9XjU X+I8EYTz2RVP77j99ehpp8pBno7zKZbn1pGygCXiDu9hRnDIMl+c+tD+w6nWkky6+U7t GSMAx1PDD3UlkLCsek57aSrxQKRI0WAKy04/3D9fAsq1sJcBIL2Ec3iuirIgNS+p5w74 h1qJ+WhYuxoTdIMA/lNHpD6qgwrsT7khygC8HSOAZKpt7Oks9H6wCwMSPoj7T+OWK12/ kPVW87E13J4nFQmdqBGkq3bWjdtDjIowWi8EnJiolkaCZml1oW/SVqE88Acxhr7ZKx49 bCoA== X-Gm-Message-State: AOAM533xyNCDhtJ03uASxp0d+v1zRXtgtHuIHEwSRV5tbrOunqSIEREO pXSeOR+1bwM3TGQZm/p7w9b+y89WQfIxOQ== X-Google-Smtp-Source: ABdhPJynQwaUz1mTjPzckp5lrq9x9RetP1CXLz/kO4r/1w5XBX4LBrwi1EKOMmRVq5ucntoF3EOqvA== X-Received: by 2002:a1c:1d42:: with SMTP id d63mr851433wmd.26.1614219588656; Wed, 24 Feb 2021 18:19:48 -0800 (PST) Original-Received: from localhost ([2a02:8084:20e2:c380:d15:339e:aa10:60f1]) by smtp.gmail.com with ESMTPSA id z5sm6535025wrn.8.2021.02.24.18.19.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Feb 2021 18:19:48 -0800 (PST) In-Reply-To: (Stefan Monnier's message of "Sun, 21 Feb 2021 15:25:43 -0500") Received-SPF: none client-ip=2a00:1450:4864:20::333; envelope-from=contovob@tcd.ie; helo=mail-wm1-x333.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham 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:265600 Archived-At: Stefan Monnier writes: >> What are the exact differences in theory and practice between >> elpa.gnu.org/devel and elpa.gnu.org/packages, and >> elpa.nongnu.org/nongnu-devel and elpa.nongnu.org/nongnu? > > The devel archives contain tarballs which reflect the current tip of the > Git branch (the one stored in `elpa.git` or `nongnu.git`, not > necessarily the same as the one upstream). > > In contrast the non-devel archives only contain tarballs for those > commits where the `Version:` was changed. > >> Are the devel archives intended as (possibly WIP) counterparts to MELPA? > > It can be thought of as following the model of the non-stable part of > MELPA, but that doesn't make it MELPA to me at all since MELPA is > defined rather by the breadth of its coverage. Right, I was referring specifically to its default bleeding edge update model. >> Based on which criteria are new versions of devel packages released, and >> are they subject to :auto-sync in the same way as non-devel packages? > > Sync'ing the elpa.git/nongnu.git branches with their upstream is > somewhat orthogonal to the devel-vs-release archives: the sync'ing is > always done between the upstream and the corresponding > elpa.git/nongnu.git branch. This sync'ing is done for all package in > nongnu.git and only for those tagged with :auto-sync in elpa.git. > Once a sync brings changes to a branch, that will always result in a new > tarball in the devel archive, but it will only result in a new package > in the release archive is the `Version:` changed. > >> Can the two devel archives be used as drop-in replacements for the >> default package-archives? > > If you're willing to use bleeding edge code, yes. > >> What are the pros/cons of doing so from a user's perspective? > > The risk of breakage? Makes sense. Thanks for the info and for working on these, -- Basil