Johan Corveleyn wrote:
> [...] a vote in STATUS does not necessarily imply that I have run the
> entire testsuite across 3 ra flavours etc.
You noted current differences. Let's say the testing of all required
combinations was automated. Can we examine what remains? What are your
thoughts on the pr
On Wed, Feb 9, 2022 at 2:19 PM Stefan Sperling wrote:
>
> On Wed, Feb 09, 2022 at 08:01:26AM -0500, Mark Phippard wrote:
> > Anyway, my feeling has been that one of the blockers to being RM is
> > motivation. My feeling has been that it is a fair amount of work that
> > might not go anywhere becau
Thomas: Thank you for speaking up about distro packaging. I can't see us
making changes that would put more work on you; that would not be
sensible. But rather than us guessing about that, it is good that we
heard from you directly.
Stefan: Thank you for the perspective about the how the current p
Am Wed, 9 Feb 2022 10:25:06 +
schrieb Julian Foad :
> Another question we ask ourselves from time to time is whether we could
> release some fixes more quickly with less effort by releasing them as a
> patch (that is, a diff) instead of the full sets of source code (tarballs).
On that point:
On Wed, Feb 09, 2022 at 08:01:26AM -0500, Mark Phippard wrote:
> Anyway, my feeling has been that one of the blockers to being RM is
> motivation. My feeling has been that it is a fair amount of work that
> might not go anywhere because we do not have enough interest in
> reviewing and signing the
Den ons 9 feb. 2022 kl 13:51 skrev Stefan Sperling :
> I would recommend setting up a Linux VM instead.
>
Off-topic: On Windows 10 and/or Windows 11, I'd recommend to use WSL. On
Windows 11, there is even full graphics integration so you can use your
favourite *nix GUI programs right on the Windo
On Wed, Feb 9, 2022 at 7:51 AM Stefan Sperling wrote:
>
> On Wed, Feb 09, 2022 at 07:23:55AM -0500, Mark Phippard wrote:
> > 2. We need a RM to produce the release. Only a handful of people have
> > done this and I am not one of them so I cannot comment on how hard
> > this is. It does feel like t
On Wed, Feb 09, 2022 at 07:23:55AM -0500, Mark Phippard wrote:
> 2. We need a RM to produce the release. Only a handful of people have
> done this and I am not one of them so I cannot comment on how hard
> this is. It does feel like this entire process could be completely
> automated though. As in,
For the sake of argument here, let's assume we choose a unit of
review-and-test that contains one-or-more significant patches (worth
releasing) plus zero-or-more trivial patches.
Julian Foad wrote:
> These two things [double voting, automatable process] seem to
> be the two main burdens we could r
On Wed, Feb 9, 2022 at 7:32 AM Julian Foad wrote:
>
> Mark Phippard wrote:
> > [...] Or are you suggesting
> > the vote in STATUS essentially "counts" as the approval we need?
>
> That, plus automating the mechanical parts, forms the essence of it.
> These two things (the current double voting (on
Mark Phippard wrote:
> [...] Or are you suggesting
> the vote in STATUS essentially "counts" as the approval we need?
That, plus automating the mechanical parts, forms the essence of it.
These two things (the current double voting (once to apply the patch and
again to release it) and the non-autom
I am top-posting because the comments are just general feedback.
I think any changes that help create releases would not be a bad
thing. If we were to adopt a process like this though, I do think we
should be a bit selective about the type of bug that warrants a
release like this. Releases, even i
12 matches
Mail list logo
