Github messages for voidlinux
 help / color / mirror / Atom feed
From: jcgruenhage <jcgruenhage@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: gitui: update to 0.10.1.
Date: Thu, 03 Sep 2020 17:05:50 +0200	[thread overview]
Message-ID: <20200903150550.GwfwgAui7QibIxpLl5G-VgJYyhJvEUljBsxQHUf0kUg@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-24547@inbox.vuxu.org>

[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]

New comment by jcgruenhage on void-packages repository

https://github.com/void-linux/void-packages/pull/24547#issuecomment-686556041

Comment:
> CI doesn't run package checks, so it's possible that one of the many moving pieces involved broke a new release. And even if it did run, checks can't cover all runtime related stuff. At least launching it quickly and being sure that basic functionality is still there is very important.

Luckily that's quite rare with rust (which is the reason I didn't do that stuff for version bumps so far, because I thought the risk was low enough), but I agree. Will compile locally and launch it at least once.

> This isn't a critical package, so breakages are a smaller issue, but it isn't nice anyway.

Of course, breakage is never nice.

> CI is limited and it blocks other PRs.

Well, so is my time and resources. waiting a bit until CI has run through doesn't block the workflow usually, building the packages locally is more overhead IMO.

Would integrating sccache into rust packages in xbps-src be accepted upstream? That would make it easier for me to test the packages locally. Would be optional of course, behind an env var or something like that.

  parent reply	other threads:[~2020-09-03 15:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-30 12:24 [PR PATCH] gitui: update to 0.10.0 jcgruenhage
2020-09-03 11:53 ` [PR PATCH] [Updated] " jcgruenhage
2020-09-03 12:02 ` [PR REVIEW] gitui: update to 0.10.1 jcgruenhage
2020-09-03 12:10 ` jcgruenhage
2020-09-03 12:16 ` ericonr
2020-09-03 14:43 ` jcgruenhage
2020-09-03 14:48 ` jcgruenhage
2020-09-03 14:51 ` jcgruenhage
2020-09-03 14:53 ` Duncaen
2020-09-03 14:59 ` ericonr
2020-09-03 15:05 ` jcgruenhage [this message]
2020-09-03 15:10 ` ericonr
2020-09-03 15:10 ` jcgruenhage
2020-09-03 15:12 ` jcgruenhage
2020-09-03 16:25 ` jcgruenhage
2020-09-03 17:40 ` Duncaen
2020-10-24 10:41 ` [PR PATCH] [Updated] " jcgruenhage
2020-10-24 10:44 ` jcgruenhage
2020-10-24 11:26 ` jcgruenhage
2020-12-20  1:26 ` [PR PATCH] [Merged]: " ericonr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200903150550.GwfwgAui7QibIxpLl5G-VgJYyhJvEUljBsxQHUf0kUg@z \
    --to=jcgruenhage@users.noreply.github.com \
    --cc=ml@inbox.vuxu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).