On 15.12.2018 22:22, Mark Phippard wrote:
>> On Dec 15, 2018, at 3:47 PM, Julian Foad <julianfoad_at_apache.org> wrote:
>>
>> 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.
> 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
Received on 2018-12-15 22:55:50 CET