On 15.12.2018 22:22, Mark Phippard wrote: >> On Dec 15, 2018, at 3:47 PM, Julian Foad <julianf...@apache.org> wrote: >> >> Mark Phippard wrote: >>>>> On Dec 15, 2018, at 2:47 PM, Julian Foad <julianf...@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
