[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Display outstanding backported fixes for each release?

From: Julian Foad <julianfoad_at_apache.org>
Date: Sat, 15 Dec 2018 20:47:33 +0000

Mark Phippard wrote:
> > On Dec 15, 2018, at 2:47 PM, Julian Foad <julianfoad_at_apache.org> wrote:
> > Branko ─îibej wrote:
> >> But before we start on something I'd like to see some proposals on query
> >> language, so that we don't implement ourselves into a corner. I'd
> >> propose this as a starting point:
> >>
> >> https://www.mercurial-scm.org/repo/hg/help/revsets
> >
> > Yes. To be clear, I was rather intending this suggestion might be taken
> as a nudge towards developing some structured queries. [...]
> Just a meta comment ...
> I am not 100% clear what you would like to see, [...]

Well, two things:
(1) an up-to-date public listing of what's pending on the release branches;
(2) development of structured queries, of any and all kinds, in Subversion.

These are very much different goals. The first is what I started this thread for -- to add visibility of what we are doing and what users can expect. This info should be simply generated, rather raw, not highly curated.

The second is a tangent, that's interesting and loosely related, with limited relationship between them.

> I personally think when you start talking about putting information on a
> website that I think the abstraction of using something like the Jira
> issues would be more useful than commits. [...]

Agreed. And I think we should more often ensure there is an issue tracking each change we backport.

However, nearer to what we currently have available, we could list the sections from "STATUS" files where a group of revisions is proposed as a backport. The backport merges themselves generally use that same text in their log msg, so listing those would be reasonable.

> Anyway, that is why I would suggest you start doing this manually.
> [...] that is going to give you a lot of hints about what would be
> needed in order to ever automate this.

Well, simply-scripted, I would say. I have no intention of adding another manual step to the backporting process. We already put manual effort into writing the backport nominations, and sometimes issues, and eventually changelog entries. Extracting any of those is what I would consider a reasonable short-term solution. (Even listing raw commits would be better than no visibility at all, though I completely agree it's not great.)

- Julian
Received on 2018-12-15 21:47:40 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.