Streamlining Subversion patch releases

[Julian Foad <ju...@apache.org>]

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.

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).


== Streamlining Patch releases ==

We would like to streamline our release processes. What can we do given
limited resources?

Concentrate on streamlining patch releases. We should also be able to
streamline the minor (1.x) releases, but I would concentrate on patch
releases for now because they are more frequent and simpler, so more
benefit can be gained for each one and in total. We would expect some of
those benefits to trickle down to the less frequent and more manually
intensive "minor" releases.

- For "minor" releases (1.x) we traditionally put in significant
effort such as manually curating the changelist and release notes,
reviewing API changes, and so on. This makes sense when a number of
relatively major and minor changes are bundled up together. OK.

- Patch releases (1.x.y) are different: it should be a simple matter
of "here's another little fix" every single time.

I see no reason why we should:

- keep on bundling multiple changes together, if we can streamline
the process so that releasing one change is easy.

- be doing significant manual work for any one change/fix/patch
release, beyond that which we already require to propose and accept a
fix into a back-port branch.

One change, one patch release:

- Releasing little and often, for maintenance releases, is generally
accepted good practice. For us one of the biggest advantages is then
the releases will no longer be a special extra burden that we have to
discuss and plan and resource, as they become a small, easy, routine
step in everyone's work.

- Requires making our patch release process much easier, so that
there is little or no extra work involved that could be combined more
efficiently by bundling multiple changes in one release.

- We should apply the same amount of manual review and testing to
each patch, but instead of delaying it until the RM says it's time to
review, approve and release many months' changes, we would more easily
do it close to the time of writing the patch.

- We could surely we can make it so the very same set of review and
test effort serves to authorise both the backport merge of the patch and
the consequent release, combining what are currently two separate
review-and-test efforts. Yes that means the per-release effort would no
longer be spread across a number of patches. The proposition, and
dependency, is that that per-release effort should be almost entirely
automated and so would cost little.

- How would the downstream recipients be affected if we make faster
smaller releases? For minor (1.x) releases with API bumps we have been
made aware that at least in some cases (I'm thinking of ViewVCS) these
generate very considerable effort downstream. For patch releases, as far
as I know, that would not be the case at all.

Manual work:

We already have release tooling for most of the patch release process.
For example, that can place a new entry in the changelist; we should
just need a simple review that it looks ok and optionally minor editing
for formatting and wording. It's still some work but it's something
anyone can do in a few minutes rather than having to set aside hours.

Automation:

I feel we could improve our automation without excessive effort. We are
living a decade or two behind the times in terms of build-test-release
pipeline automation. Every time a change is approved on a release branch
we should have an automated tarball produced, with version bump and
accompanying external bits like release announcements drafted, ready for
a release manager to press the "Ship it!" button if
signatures have been collected properly and they agree it's ready.

It's much easier nowadays to take advantage of containers or VMs, and
build pipelines such as GitLab's. We might also find some relevance in
binary build/distribution systems such as Open Build Service.

Yes this is just talk, to float the idea and see if anyone is inspired
to try to actually do this. I'm quite interested myself but I don't know
if I'll spare the time to do so. I have some little bits of automation
scripts left over from previous RM work, that I haven't turned into
contributions, but not to the extent I'm now talking about.


== Releasing just the patch instead of full tarballs ==

We've said a few times in the past, we could perhaps save work and get a
small patch release out sooner if we just released the patch instead of
the full tarballs.

As far as I know, that would be both allowable and reasonable. When we
have discussed this before, my recollection is people have always said
it would be fine.

We need to stop making more work for ourselves than absolutely
necessary. Where possible, do what is simplest. If that's simplest, and
we decide it will be worthwhile, then we should agree the minimal steps,
here and now or in a similar thread, and start doing it.

Let's see what this might look like in more detail.

There are two styles of patch we could release:

1. A stand-alone patch that just fixes the particular issue.

- The recipient (an end user, IT department, or a downstream
packager) can choose to apply the patch if it seems relevant to them.
- The recipient should manage their own version numbering to
indicate patched versions.

2. A diff between one specific version and the next in our release
versioning scheme that we control, equivalent to a mechanical diff
between tarball releases.

- We apply our own version numbering scheme, just the same as if
we were releasing complete tarballs for each release.
- The diff includes a version bump, and successive patches apply
in sequence to generate successive release versions of Subversion.
- This need not imply we also release the complete code of each
version as tarballs.
- We retain the option to release the tarballs as well as or
instead of the patch, if and when we wish, at the same time or any later
(or earlier) time.

It would be good to include in any such patch:

- which versions we assert it does / might / does not apply to;
- a changelist addition;
- an addition to a list of "patches included" if we were to have
that (but we currently don't).

But would it be less work? Mustn't we still produce full tarballs in
order to test the result, or would we require that only for a patch that
involves build system changes? And doing so would only be a small
automated step away from having a patch. And there would be discussions
required and the procedural set-up to start doing this. So I'm not sure
it would be significantly less work; in fact it might be more.

Can anyone point out significant work that would be saved by doing this?
Is it work that would be saved in general, every time, or is it just
because the tarball-generation steps of the process are onerous because
they are not yet sufficiently automated?

It mainly feels to me that what we need to concentrate on is automation
and simplification, up to and including a standard pracice of making a
patch release for every bug fix.

Your thoughts?

- Julian

Re: Streamlining Subversion patch releases

[Julian Foad <ju...@apache.org>]

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 process
is a manageable amount of work for a willing volunteer. I hope someone
will step up.

It occurs to me if anybody does work on automation or procedural
changes, they would also benefit from experience of the current process.

- Julian

Re: Streamlining Subversion patch releases

["Dr. Thomas Orgis" <th...@uni-hamburg.de>]

Am Wed, 9 Feb 2022 10:25:06 +0000
schrieb Julian Foad <ju...@apache.org>:

> 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: This would be rather annoying to distro packagers /
build script maintainers. Usually, you got the upstream source, a
single tarball in the simplest case and some local patches if needed.
Most build frameworks have a mechanism to include patches, and also to
accompany multiple upstream sources (tar + patch1 + patch2), but
maintaining the varying list of sources and patches is more work than
changing

VERSION=1.2.3

to

VERSION=1.2.4

and have the rest follow. It's not a dealbreaker — and there is the
obvious benefit of possibly easier review and less waste in source
mirroring. It is just that this would differ from the simplest common
case of one upstream source archive that is extracted and built.


Alrighty then,

Thomas

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg

Re: Streamlining Subversion patch releases

[Julian Foad <ju...@apache.org>]

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 reduce.

To spell out the relationship between those two: if there's quickly and
magically a release-candidate tarball produced for each proposed
backport, then what we review and test for backport is assured to be
exactly what we would be reviewing and testing for a release.

Following on your tagging idea: Perhaps the tarball creation would be
triggered by each successive backport proposal (cumulatively) on the
branch; those that fail test/review are ignored; and when we make the
tag, the tagging triggers the later parts of the release process
(essentially, making the tarballs public).

- Julian

Re: Streamlining Subversion patch releases

[Mark Phippard <ma...@gmail.com>]

On Wed, Feb 9, 2022 at 7:32 AM Julian Foad <ju...@apache.org> 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 (once to apply the patch and
> again to release it) and the non-automated automatable process) seem to
> be the two main burdens we could reduce.
>
> +1 to your point about not making releases that just contain a trivial
> patch, so we do want some batching. How to combine "some batching" with
> the above, I wonder?

Just thinking out loud ....

What if the "patch release process" just involved a committer pushing
a tag that included the version bump and CHANGES update and then the
production of the release artifacts was automated off the tag creation
process? This would allow a release to include more than one fix if
desired.

I do wonder about the voting though. The Apache process requires us to
have a release vote. I am not sure we can count the STATUS votes. It
would certainly be something to key in on for discussion purposes.

I have long thought that committers building and testing the releases
was a waste of our limited capacity. It seems like the sort of thing
that could be automated with a few bots for different OS that can
build a release from the tarball and run the tests. Realizing that
building this automation also requires people to do it.

Mark

Re: Streamlining Subversion patch releases

[Julian Foad <ju...@apache.org>]

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-automated automatable process) seem to
be the two main burdens we could reduce.

+1 to your point about not making releases that just contain a trivial
patch, so we do want some batching. How to combine "some batching" with
the above, I wonder?

- Julian

Re: Streamlining Subversion patch releases

[Julian Foad <ju...@apache.org>]

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 proposal to unify them so that a single +1 means "I
approve this backport: it results in a release candidate that I approve
for release"? Can we define voting requirements that satisfy the
combined meaning?

One issue I see is the "resulting release candidate" for a given patch
depends on which patches were included before it. Whenever two or more
patches are being reviewed simultaneously, we need a way to track their
assumed ordering, and to re-evaluate when it changes. For example we
might assume initially that each will pass the vote, and so evaluate
them as if merged in order of proposal, and whenever a not-latest patch
is vetoed, re-start the evaluation of all later ones. I don't see that
as a problem, just something to be taken into account.

- Julian

Re: Streamlining Subversion patch releases

[Johan Corveleyn <jc...@gmail.com>]

On Wed, Feb 9, 2022 at 2:19 PM Stefan Sperling <st...@elego.de> 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 because we do not have enough interest in
> > reviewing and signing the release. So why put in the effort to do this
> > when the votes are not going to happen?
>
> It is a bit of a chicken and egg problem. We have never had a problem
> getting the release out the door once an RM did step up. Enough people
> always joined in to help once the ball got rolling.

Indeed. In recent years we never had a problem getting enough PMC
testers and signatures.

In fact, getting my build environment dusted off again, and testing
and signing releases, is about the only thing I still do around here
:-). So, dear RM, just give me a tarball (or release zip I should say
for Windows, I guess), and I'll give it a go.

> > We have also always had what I
> > thought was a peculiar policy that the RM's votes did not "count". So
> > often the most motivated member of our community steps forward to do
> > the RM work, and now we have lost the one sure thing vote we would
> > have had for the release.
>
> We have already made the RM's vote count during our most recent releases,
> as far as I remember. At least I did it that way to expedite the process.
> The ASF requires release signatures by at least 3 PMC members. Any further
> restrictions are self-imposed and can be avoided if needed.

Yes, the last couple of releases we relaxed our old "3 *nix + 3
windows" requirement to just "3 PMC sigs (of which at least 1 *nix and
1 Windows)" [1]. That last part (1 *nix and 1 Windows) is a
Subversion-PMC-self-imposed requirement, which could in theory be
lifted (depending on consensus of the PMC), but I'm not sure we
should. In any case, so far we've never been blocked by this.

For me that's also one of the main differences between votes in STATUS
and votes on the release. The voting requirements are different (not
only the "1 *nix and 1 Windows", which applies only to release votes;
but also the rule that backports of bindings and a couple of other
things only require 2 votes in STATUS). Also: a vote in STATUS does
not necessarily imply that I have run the entire testsuite across 3 ra
flavours etc. So a vote there does not mean the same thing as a
release vote.

[1] https://subversion.apache.org/docs/community-guide/releasing.html#releasing-votes

-- 
Johan

Re: Streamlining Subversion patch releases

[Stefan Sperling <st...@elego.de>]

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 release. So why put in the effort to do this
> when the votes are not going to happen?

It is a bit of a chicken and egg problem. We have never had a problem
getting the release out the door once an RM did step up. Enough people
always joined in to help once the ball got rolling.

> We have also always had what I
> thought was a peculiar policy that the RM's votes did not "count". So
> often the most motivated member of our community steps forward to do
> the RM work, and now we have lost the one sure thing vote we would
> have had for the release.

We have already made the RM's vote count during our most recent releases,
as far as I remember. At least I did it that way to expedite the process.
The ASF requires release signatures by at least 3 PMC members. Any further
restrictions are self-imposed and can be avoided if needed.

Re: Streamlining Subversion patch releases

[Mark Phippard <ma...@gmail.com>]

On Wed, Feb 9, 2022 at 7:51 AM Stefan Sperling <st...@elego.de> 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 this entire process could be completely
> > automated though. As in, someone creates a tag or pushes a button in
> > Jenkins and the rest just happens.
>
> I think our main problem is that not enough people have gone through
> this process, and it may seem more intimidating than it should be.
> It is not actually a lot of work. The process is well documented and
> already automated for the most part. The RM mostly runs release.py in
> a series of steps, by following our docs.
>
> Anyone on the PMC can do this. If you've made a commit to the project or
> to the website, have reviewed fixes in STATUS and have communicated with
> people in this project via mailing list and IRC, then you already know
> everything you need to know to become the RM!
>
> The main burden is to guess a future date for the release and then keep
> track of our progress until the release is done. The RM should ensure we
> don't miss the prospected date by a large margin. This requires constant
> attention to the project for a while. If you cannot afford to spend roughly
> half an hour per day on it for a week or two, you don't have enough time.
>
> During this time, the RM mostly keeps track of things in STATUS and keeps
> poking people to help with reviewing, testing, and signing.
> The actual releasing is done by doing a few SVN commits, again via release.py.
> And the RM writes release announcements, which is also automated by release.py.
>
> There is a one-time effort to ensure that sending mail via your apache.org
> account works; the ASF has an SMTP relay you can use for this purpose and
> this needs to be configured in your mail client.
>
> And you need a Linux system, which as we know is a show-stopper for some
> of our developers. Anyone who wants to RM on Windows would need to port
> the release.py process over first, which is probably a good chunk of work.
> I would recommend setting up a Linux VM instead.

Thanks Stefan, this is more or less what I thought. I do wonder if we
could somewhat easily switch to doing the entire process via Docker?
This would make it possible to do it from MacOS or Windows and it
would probably have some benefits for Linux users as well?

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 release. So why put in the effort to do this
when the votes are not going to happen? We have also always had what I
thought was a peculiar policy that the RM's votes did not "count". So
often the most motivated member of our community steps forward to do
the RM work, and now we have lost the one sure thing vote we would
have had for the release.

I guess if we could automate away the need for a RM or change the role
to be purely the steps that need to occur after the voting happens,
then that could solve some of these problems.

In theory ... we could do a release as long as we have 2 motivated
people right? Or does it require 3? One to nominate a fix and 2 to
vote? If the RM process were automated, we get the votes we need and
then just 1 of those people that voted need to do some final step to
publish the release? I think this sort of math is what we need to
focus on. What is the smallest number of people we must have to make a
release and then how can we make that work. If we get more votes,
great, but there is a minimum bar we need to reach that currently we
cannot do very easily.

Mark

Re: Streamlining Subversion patch releases

[Daniel Sahlberg <da...@gmail.com>]

Den ons 9 feb. 2022 kl 13:51 skrev Stefan Sperling <st...@elego.de>:

> 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 Windows desktop. I do 99% of my
Subversion work on WSL/Ubuntu.

Kind regards
/Daniel

Re: Streamlining Subversion patch releases

[Stefan Sperling <st...@elego.de>]

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, someone creates a tag or pushes a button in
> Jenkins and the rest just happens.

I think our main problem is that not enough people have gone through
this process, and it may seem more intimidating than it should be.
It is not actually a lot of work. The process is well documented and
already automated for the most part. The RM mostly runs release.py in
a series of steps, by following our docs.

Anyone on the PMC can do this. If you've made a commit to the project or
to the website, have reviewed fixes in STATUS and have communicated with
people in this project via mailing list and IRC, then you already know
everything you need to know to become the RM!

The main burden is to guess a future date for the release and then keep
track of our progress until the release is done. The RM should ensure we
don't miss the prospected date by a large margin. This requires constant
attention to the project for a while. If you cannot afford to spend roughly
half an hour per day on it for a week or two, you don't have enough time.

During this time, the RM mostly keeps track of things in STATUS and keeps
poking people to help with reviewing, testing, and signing.
The actual releasing is done by doing a few SVN commits, again via release.py.
And the RM writes release announcements, which is also automated by release.py.

There is a one-time effort to ensure that sending mail via your apache.org
account works; the ASF has an SMTP relay you can use for this purpose and
this needs to be configured in your mail client.

And you need a Linux system, which as we know is a show-stopper for some
of our developers. Anyone who wants to RM on Windows would need to port
the release.py process over first, which is probably a good chunk of work.
I would recommend setting up a Linux VM instead.

Re: Streamlining Subversion patch releases

[Mark Phippard <ma...@gmail.com>]

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 if just a patch, generate a lot of
work for us and our downstream. Users tend to just look at the release
number and not what went into the release when asking their upstream
for updates. IOW, if I were still a vendor, I would get tired of being
asked why we have 1.14.x available but not 1.14.y when the only
difference was a fix to a comment or translation that was backported.

That comment aside, my main feedback is that I do not see how this
proposal has identified the problems that make releases difficult and
addresses how it would fix that. I have never had the sense that our
difficulty in producing patch releases was due to the quantity or
nature of the fixes. It has always just been a handful of changes. Our
problems have been one of the resources needed to create a release:

1. Fixes have to be nominated in STATUS and receive necessary votes. I
would say this has been only a minor problem
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, someone creates a tag or pushes a button in
Jenkins and the rest just happens.
3. We need people to test and sign the release. IMO, this is the major
blocker and because we all know this is a major blocker no one wants
to be the RM

It is unclear to me how a release with a single patch fixes the
problem. Did I miss in your text where you said we will be bypassing
most of this process to produce these releases? Given that much of
this process is the Apache Way, I would doubt you suggested that.

Are you just assuming if the release is just a single patch that more
people will be willing to vote for the release? Or are you suggesting
the vote in STATUS essentially "counts" as the approval we need?

Thanks

Mark





On Wed, Feb 9, 2022 at 5:25 AM Julian Foad <ju...@apache.org> wrote:
>
> 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.
>
> 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).
>
>
> == Streamlining Patch releases ==
>
> We would like to streamline our release processes. What can we do given
> limited resources?
>
> Concentrate on streamlining patch releases. We should also be able to
> streamline the minor (1.x) releases, but I would concentrate on patch
> releases for now because they are more frequent and simpler, so more
> benefit can be gained for each one and in total. We would expect some of
> those benefits to trickle down to the less frequent and more manually
> intensive "minor" releases.
>
> - For "minor" releases (1.x) we traditionally put in significant
> effort such as manually curating the changelist and release notes,
> reviewing API changes, and so on. This makes sense when a number of
> relatively major and minor changes are bundled up together. OK.
>
> - Patch releases (1.x.y) are different: it should be a simple matter
> of "here's another little fix" every single time.
>
> I see no reason why we should:
>
> - keep on bundling multiple changes together, if we can streamline
> the process so that releasing one change is easy.
>
> - be doing significant manual work for any one change/fix/patch
> release, beyond that which we already require to propose and accept a
> fix into a back-port branch.
>
> One change, one patch release:
>
> - Releasing little and often, for maintenance releases, is generally
> accepted good practice. For us one of the biggest advantages is then
> the releases will no longer be a special extra burden that we have to
> discuss and plan and resource, as they become a small, easy, routine
> step in everyone's work.
>
> - Requires making our patch release process much easier, so that
> there is little or no extra work involved that could be combined more
> efficiently by bundling multiple changes in one release.
>
> - We should apply the same amount of manual review and testing to
> each patch, but instead of delaying it until the RM says it's time to
> review, approve and release many months' changes, we would more easily
> do it close to the time of writing the patch.
>
> - We could surely we can make it so the very same set of review and
> test effort serves to authorise both the backport merge of the patch and
> the consequent release, combining what are currently two separate
> review-and-test efforts. Yes that means the per-release effort would no
> longer be spread across a number of patches. The proposition, and
> dependency, is that that per-release effort should be almost entirely
> automated and so would cost little.
>
> - How would the downstream recipients be affected if we make faster
> smaller releases? For minor (1.x) releases with API bumps we have been
> made aware that at least in some cases (I'm thinking of ViewVCS) these
> generate very considerable effort downstream. For patch releases, as far
> as I know, that would not be the case at all.
>
> Manual work:
>
> We already have release tooling for most of the patch release process.
> For example, that can place a new entry in the changelist; we should
> just need a simple review that it looks ok and optionally minor editing
> for formatting and wording. It's still some work but it's something
> anyone can do in a few minutes rather than having to set aside hours.
>
> Automation:
>
> I feel we could improve our automation without excessive effort. We are
> living a decade or two behind the times in terms of build-test-release
> pipeline automation. Every time a change is approved on a release branch
> we should have an automated tarball produced, with version bump and
> accompanying external bits like release announcements drafted, ready for
> a release manager to press the "Ship it!" button if
> signatures have been collected properly and they agree it's ready.
>
> It's much easier nowadays to take advantage of containers or VMs, and
> build pipelines such as GitLab's. We might also find some relevance in
> binary build/distribution systems such as Open Build Service.
>
> Yes this is just talk, to float the idea and see if anyone is inspired
> to try to actually do this. I'm quite interested myself but I don't know
> if I'll spare the time to do so. I have some little bits of automation
> scripts left over from previous RM work, that I haven't turned into
> contributions, but not to the extent I'm now talking about.
>
>
> == Releasing just the patch instead of full tarballs ==
>
> We've said a few times in the past, we could perhaps save work and get a
> small patch release out sooner if we just released the patch instead of
> the full tarballs.
>
> As far as I know, that would be both allowable and reasonable. When we
> have discussed this before, my recollection is people have always said
> it would be fine.
>
> We need to stop making more work for ourselves than absolutely
> necessary. Where possible, do what is simplest. If that's simplest, and
> we decide it will be worthwhile, then we should agree the minimal steps,
> here and now or in a similar thread, and start doing it.
>
> Let's see what this might look like in more detail.
>
> There are two styles of patch we could release:
>
> 1. A stand-alone patch that just fixes the particular issue.
>
> - The recipient (an end user, IT department, or a downstream
> packager) can choose to apply the patch if it seems relevant to them.
> - The recipient should manage their own version numbering to
> indicate patched versions.
>
> 2. A diff between one specific version and the next in our release
> versioning scheme that we control, equivalent to a mechanical diff
> between tarball releases.
>
> - We apply our own version numbering scheme, just the same as if
> we were releasing complete tarballs for each release.
> - The diff includes a version bump, and successive patches apply
> in sequence to generate successive release versions of Subversion.
> - This need not imply we also release the complete code of each
> version as tarballs.
> - We retain the option to release the tarballs as well as or
> instead of the patch, if and when we wish, at the same time or any later
> (or earlier) time.
>
> It would be good to include in any such patch:
>
> - which versions we assert it does / might / does not apply to;
> - a changelist addition;
> - an addition to a list of "patches included" if we were to have
> that (but we currently don't).
>
> But would it be less work? Mustn't we still produce full tarballs in
> order to test the result, or would we require that only for a patch that
> involves build system changes? And doing so would only be a small
> automated step away from having a patch. And there would be discussions
> required and the procedural set-up to start doing this. So I'm not sure
> it would be significantly less work; in fact it might be more.
>
> Can anyone point out significant work that would be saved by doing this?
> Is it work that would be saved in general, every time, or is it just
> because the tarball-generation steps of the process are onerous because
> they are not yet sufficiently automated?
>
> It mainly feels to me that what we need to concentrate on is automation
> and simplification, up to and including a standard pracice of making a
> patch release for every bug fix.
>
> Your thoughts?
>
> - Julian
>