From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Suhail Singh Newsgroups: gmane.emacs.devel Subject: Re: Reconsider defaults for use-package-vc-prefer-newest Date: Sat, 21 Sep 2024 15:04:21 -0400 Message-ID: <87tte8akwa.fsf@gmail.com> References: <87wmj7dftf.fsf@posteo.net> <87setvxyt6.fsf@gmail.com> <87jzf7o13b.fsf@posteo.net> <87msk3jr0u.fsf@gmail.com> <87setum5do.fsf@posteo.net> <87msk1520e.fsf@gmail.com> <87settknf1.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29349"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Suhail Singh , Martin =?utf-8?Q?Edstr=C3=B6?= =?utf-8?Q?m?= , "emacs-devel" , Tony Zorman To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Sep 22 06:37:24 2024 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 1ssELb-0007U9-Rp for ged-emacs-devel@m.gmane-mx.org; Sun, 22 Sep 2024 06:37:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ssEKv-00076t-4g; Sun, 22 Sep 2024 00:36:41 -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 1ss5PI-0003fa-6k for emacs-devel@gnu.org; Sat, 21 Sep 2024 15:04:36 -0400 Original-Received: from mail-qk1-x744.google.com ([2607:f8b0:4864:20::744]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ss5PG-00082C-K9 for emacs-devel@gnu.org; Sat, 21 Sep 2024 15:04:35 -0400 Original-Received: by mail-qk1-x744.google.com with SMTP id af79cd13be357-7a9aa913442so315155485a.1 for ; Sat, 21 Sep 2024 12:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726945473; x=1727550273; darn=gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=Qlp/hSi8nlNrAxFgTiY46WJJSb92diiamf2JAZXNfOQ=; b=cTO+bkJg3N/YWR0BWk06C92F06YPxrDybGbuQ9ZbiTznmMHDneTpj8fAot/Po7Pf5h QriQzUHLNb2KboRcYuk5LcGVYQpN6TC5W9o1/xvdOT+hjnKDmWFptZtSi46zPnEEpHZp EuOp9+D1lszLfVE2xqkZ/0m7N4Evad9AziCLs2fgLrssgrsxLrjhz34LA9ssfurcxGiX Thsze9JGVcR55G61W4PV6Ikg5zzcnlIKZe+q7ut3i+KD9x66HC1Kkzzv3wiPVC+VnVYD uX65PU7OTwhB/1DbBKXNWuZsD9/AVXQtM85/0UNb7Mtkq/V1W6cuRiGy2Uh9+0VepRu4 J42w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726945473; x=1727550273; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Qlp/hSi8nlNrAxFgTiY46WJJSb92diiamf2JAZXNfOQ=; b=eKgwDy/LyXSoHVm5TMp1z2OjpFDbs6JtydqYvrNzGD4lTqJNdbHzY0wB/BJUllNzWr cc236ThZ0FPxp/rBVY4prKwcKPD58CNDlYGyUjpsL9+L5EVMOA9M9i3b8Jm6D0k2PR07 s/VZ+zf/76PMv028vm6u6S5GvGGDEDImXHaabB7mL/qAgGchenf0AB3Z+ky/If/ucEij mk2DydULbJiKWzkHI53B4KP/Jj0lZNp8AMH4VJZ2QTmGfpdAWfivohwvh61kJOJiaR70 y5wq6VnlylGecMcj8uF+bQUHtrEVZJ7lvZ4uLsXjRzP6kvZK/84J3QM6A9n30al7LGw2 MKIw== X-Forwarded-Encrypted: i=1; AJvYcCXuE/MGEKtR4Hv9BF+ybxB/TrZh9NkcAodQrle3nvxbGM2E9TXdzrIfXowNxwxUV9RwGzDSyZJtNPMpXQ==@gnu.org X-Gm-Message-State: AOJu0YyB5wcUXQkYIU8bZz89tmiAD7otlfwd7nijvLqK7x7s0jPSRRr9 MpIoxSRAA7kVF+vAWcgwC3U1PHclofn4fIHdlFwfNVoou1pWs2Te2NlLg06n X-Google-Smtp-Source: AGHT+IGnfveEDRjCrYPdj7nDJnX5iiaDLwGf/lTLvRoaE05RI2CHhBl46KdQMNIJOA+3fLIQcdiBIQ== X-Received: by 2002:a05:620a:472b:b0:7a9:c129:5da7 with SMTP id af79cd13be357-7acb80cae13mr1172512585a.29.1726945473334; Sat, 21 Sep 2024 12:04:33 -0700 (PDT) Original-Received: from gnus ([65.94.70.53]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7acb08bc668sm314236385a.95.2024.09.21.12.04.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 21 Sep 2024 12:04:33 -0700 (PDT) In-Reply-To: <87settknf1.fsf@posteo.net> (Philip Kaludercic's message of "Sat, 21 Sep 2024 15:59:46 +0000") Received-SPF: pass client-ip=2607:f8b0:4864:20::744; envelope-from=suhailsingh247@gmail.com; helo=mail-qk1-x744.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sun, 22 Sep 2024 00:36:39 -0400 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: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:323911 Archived-At: Philip Kaludercic writes: >>> I wonder if indicating a "commit mismatch" for remote packages might >>> be interesting (we explicitly don't want this for local packages, >>> e.g. packages installed via package-vc). >> >> Depending on the logic of "commit mismatch" detection, that may be >> sufficient. Could you describe what you had in mind? > > In your case/the case of julia-mode, something like > > Other versions: 1.2.3 (melpa-stable, COMMIT MISMATCH). > > with a help annotation. Yes, something like that would have worked. Thanks in advance, if you do implement something of that nature. It would be useful. >>> Could you perhaps elaborate on why you consider this to be a bug? >> >> To be clear I meant that it's a bug in the remote package. > > Perhaps I am being pedantic, but this sounds like a mistake, not a /bug/ > in the code itself. I meant that I considered it a software defect in the packaging process. It might have been more accurate to term it a bug in the remote package's packaging process. In any case, the implication wasn't that it was a bug in the remote package's source code. I hope it's clearer now. >> Specifically, in the case of julia-mode, it was a bug for it to have >> introduced the 0.4 package header in a commit that was different from >> the one that was tagged as 0.4. > > Do you know which of the two is correct? In cases like these, it sounds > like one should contact the maintainers to remind them that they > shouldn't repeat the same issue in the future. Given that the change that was added between the commit that updated the package header and the commit that corresponded to the git tag was a fairly important bug-fix, I believe the intended revision (for 0.4) was the one corresponding to the git tag (i.e., the more recent commit and the one available via melpa-stable). In general, for packages with a git repository that have a presence outside of GNU and NonGNU ELPA, I believe the version corresponding to the "git tag" to be more closely aligned with the maintainer's intent. That being said, however, based on a recent exchange, the recommended version that the maintainer of julia-mode wishes users download is the "rolling release" equivalent from melpa. I believe it is for this reason that they have not made a tagged release in the last four years. Quoting below the maintainer's response on the issue ([1]) where I brought this matter to their attention: #+begin_quote Since we do not make stable releases (effectively, it is just rolling on `master`, I think we should just clarify that users should use `melpa`, and if possible expunge the package from `melpa-stable` etc. #+end_quote [1]: -- Suhail