Ben Reser wrote on Thu, Aug 08, 2013 at 00:58:50 -0700:
> On Wed, Aug 7, 2013 at 3:49 AM, Justin Erenkrantz <jus...@erenkrantz.com>
> wrote:
> > I'm okay with choice 3 - however, the "release a signed .diff" should also
> > include a full release - including whatever normal things we include with a
> > standard release process. If 1.8.(x+1) is *only* available as a diff
> > against 1.8.x, that makes it hard for downstream users (or packagers) until
> > 1.8.(x+2) is released. -- justin
>
> Not having tarballs is a huge problem since our most reliable
> packagers just release the latest version and don't put out patches.
>
I'm not opposed to this. I didn't suggest it since I remembered there
were objections to "secret tarballs" last time we discussed that option.
Naturally, if there are packagers in the audience who would not have
a problem with releasing, say, 1.8.3 as "1.8.2 + signed unidiff", please
raise your hand. (Note that 'svn patch' is available on windows to apply
the unidiff.)
> (v4)
> - Receive report
> - Come up with a fix
> - Have a private section of our tree that is always hidden and doesn't
> announce commits on public lists/svnpubsub. Create branches there to
> commit the work and handle the release branch from there.
...
> It probably will take some adjustment to some of the tools to support
> this I don't think svnpubsub and the emailer can ignore subtrees and
> we might want to make backport.pl capable of handling some of the
> merging for us. But none of this seems particularly difficult to me.
+1. Presuming "hidden branches" are a given, what you describe sounds
reasonable. As to how to implement those:
Infra is operating on the assumption that /repos/asf is entirely world
readable. That repository currently has authz but infra would like to
eliminate that some day (and instead have just "[/] *=r
@all-committers=rw", just like we have). We also publish monthly dump
files of /repos/asf which are unfiltered (contain all history). It is
not technically impossible to change this, of course, but we would need
to talk to infra beforehand.
I don't think there is an easy out here. Either infra stop assuming
that /repos/asf is world readable, or we have to do some of our
development outside of /repos/asf. That might mean in some other svn
repository --- either create a branch of 1.8.x in another repository
(and then we can use cross-repository merging to bring it back to the
public area), or store unidiffs in the private repository and version
those.
Perhaps just "cross-repository branching" would work? That is:
(v5)
- Receive report
- Come up with a fix
- Import /repos/asf/subversion/branches/1.8.x@HEAD without history to
/repos/private/pmc/subversion/shadow/branches/1.8.y
- Backport to the hidden branches and use the STATUS files there to vote.
- Tag and roll 1.8.(x+1) off the hidden branch (as in Ben's v4)
- Place dist files on password protected website for votes and
pre-notifications.
- In parallel:
+ Gather release votes
+ Send pre-notifications
- In parallel:
+ Merge back to publicly visible branches. Use cross-repository merging
('svn merge /repos/private/pmc/.../1.8.y@{r42,r142} wc-of-1.8.x
+ Release + announce publicly.
This also introduces a naming convention "1.8.y" for the
private/shadow clone of 1.8.x.
For completeness, annother option would be to do the work in a private
fossil/bzr/hg/git repository. That way we'll have history (eg, 'svn
blame' will work on 1.8.y) and infra's "/repos/asf is world readable"
invariant will be preserved. It would also mean that we aren't entirely
self-hosted and that our tools and scripts won't be trivially portable
(not just a matter of URL change).
So, to summarize, our options for working on the "secret" tree are:
(a) - Unidiffs in /repos/private/pmc/subversion
(b) - Branch in /repos/asf/subversion/shadow
(c) - Branch in /repos/private/pmc/subversion/shadow
(d) - Branch in fossil/bzr/hg/git
(e) - (We could ask infra to 'zfs clone' the asf repository and make
available a /repos/asf-clone which is not world readable --- i.e.,
fork the 'asf' repository itself [and use cross-repository merge
like (b)] --- but I can hear the objections already.)
> The only hole left is we need to place tarballs on the dist site 24
> hours in advance to mirror. However, I think we can simply workaround
> this issue for serious security issues by shortening that window and
> using the update flag on the download page.
+1. Our release artifacts are just 7MB: other projects have artifacts
of 100MB or more (per tarball), so I think we can afford to be lenient
on using the "updated since?" flag.
