On 09 Feb 2022, Ruediger Pluem wrote:
When rebuilding my own Subversion build I stumbled across the
following
patch that I add to my build:
Index: subversion/libsvn_client/patch.c
===
--- subversion/libsvn_client/patch.c
I haven't heard any further feedback on this settings storage. I am
still favouring the new in-WC config file ('wc/.svn/config'). It seems
straightforward and understandable with hopefully not so much potential
for bikeshedding (no need for new command line options or commands, for
example).
On
I think this branch is now ready to merge to trunk.
In a series of commits I have added '--wc-format-version' argument to
the C and Python test suite framework on this branch, and tested that it
works with both '1.15' (the default, WC format 32) and '1.14' (wc format 31).
I tested that the
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
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
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
When rebuilding my own Subversion build I stumbled across the following patch
that I add to my build:
Index: subversion/libsvn_client/patch.c
===
--- subversion/libsvn_client/patch.c(revision 1897905)
+++
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
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
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
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
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
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
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
Dear devs, a long post with my thoughts.
Each time we discuss a new release, we return to the problem of lack of
resources and our cumbersome release process. Here are my thoughts.
One of the main questions is how much more we could automate the
procedure, given limited resources to do so.
17 matches
Mail list logo
