subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: Display outstanding backported fixes for each release?
Date Sat, 15 Dec 2018 21:55:42 GMT
On 15.12.2018 22:22, Mark Phippard wrote:
>> On Dec 15, 2018, at 3:47 PM, Julian Foad <julianfoad@apache.org> wrote:
>>
>> Mark Phippard wrote:
>>>>> On Dec 15, 2018, at 2:47 PM, Julian Foad <julianfoad@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.
> I am just saying these are both still pretty vague.
>
> 1. You are talking about the website right?  So I am saying throw together the HTML that
shows what you want to see.  Maybe that will stimulate some ideas.  I am just saying for me,
as more of just a user than you are, I would not care about seeing commits.  I would want
something higher level (like a Jira issue) for it to be of value to me.

We're actually talking about populating CHANGES for patch releases (and
for .0 releases too, but that's tangential). We have a rather strict
process for backports, so "what's new in the patch release" is fairly
easy to find, but "how does that relate to CHANGES entries on trunk" is not.

Jira will not help unless we force ourselves to use it to prepare
CHANGES entries. I don't see that happening, unless we ditch CHANGES and
move that tracking to Jira. But IMO that would make the project far too
dependent on one particular issue tracker ...


> 2. Again vague. Isn't svn log a query?  I am sure what you are thinking is not vague
to you.  Maybe if we could see what you were thinking for the previous point then the sort
of thing you are looking for here would be more clear.

This talk of queries comes from Julian's comment about "designing and
implementing some more powerful querying, starting with "changes in
1.10.x but not in 1.10.3" in a previous message and my thinking aloud
about not jumping without looking first. It's not a declaration about a
new feature in 1.13.


> I am also not clear whose itch you are scratching here.

The release manager's. Managing CHANGES on release branches is quite
painful.

-- Brane


Mime
View raw message