+1 On Tue, Feb 27, 2018 at 2:50 PM, Jeremy Mitchell <[email protected]> wrote:
> I like that format. Bullets seems nice and simple with external links where > more info is required. > > I would be in favor of a PR to add these sections so it's easy for the next > person to add a bullet to the relevant section. > > On Tue, Feb 27, 2018 at 2:15 PM, Rawlin Peters <[email protected]> > wrote: > > > Hey folks, > > > > So I used the influxdb changelog as an example format, but @dew has > > shown me this popular project for changelog convention: > > http://keepachangelog.com/en/1.0.0/. For example see the project > > changelog: https://github.com/olivierlacan/keep-a-changelog/ > > blob/master/CHANGELOG.md. > > > > Since we now have a changelog, it would be best to have a standard, > > agreed-upon format for it so that we can keep it consistent for every > > release. > > > > Basically it means every release has its own section (with an > > "unreleased" section at the top), and everything will be > > bullet-pointed underneath one of these sections for every release: > > - "Added" for new features. > > - "Changed" for changes in existing functionality. > > - "Deprecated" for soon-to-be removed features. > > - "Removed" for now removed features. > > - "Fixed" for any bug fixes. > > - "Security" in case of vulnerabilities. > > > > For example with my per-DS routing name upgrade notes currently in the > > changelog, I would add that to the "Added" section and link to the > > upgrade notes in our docs. > > > > What do you all think? All in favor of accepting this keepachangelog > > format? > > > > - Rawlin > > > > > > > > On Thu, Feb 8, 2018 at 2:29 PM, Rawlin Peters <[email protected]> > > wrote: > > > I went ahead and created one: > > > https://github.com/apache/incubator-trafficcontrol/pull/1865. Please > > > review and merge if you are okay with the current format. I'm not sure > > > if we want to go back and add a list of all the new features in 2.2 or > > > not, but please add to the CHANGELOG.md file if you have any pending > > > release notes like 2.2 upgrade gotchas you'd like to get in. > > > > > > Thanks, > > > Rawlin > > > > > > On Wed, Feb 7, 2018 at 4:07 PM, Dave Neuman <[email protected]> wrote: > > >> Hey Rawlin, > > >> I think Steve was starting to work on one, so we will see what he > says. > > >> If he doesn't have one started, I think you can go ahead and create > one. > > >> > > >> Thanks, > > >> Dave > > >> > > >> On Wed, Feb 7, 2018 at 4:04 PM, Rawlin Peters < > [email protected]> > > >> wrote: > > >> > > >>> Hey all, > > >>> > > >>> So it appears this vote passed in favor of adding a CHANGELOG.md file > > >>> without having a changelog label in GitHub. Is anyone currently > > >>> working on one? > > >>> > > >>> With the 2.2 release planned for 2/12/18, I'd like to at least put in > > >>> some upgrade release notes about Per-Delivery-Service Routing Names. > > >>> If no one has a CHANGELOG.md in progress, I'll take the liberty to > > >>> start one and add those release notes in there (using > > >>> https://github.com/influxdata/influxdb/blob/master/CHANGELOG.md as > an > > >>> example template). > > >>> > > >>> -Rawlin > > >>> > > >>> On Wed, Jan 10, 2018 at 10:35 AM, Chris Lemmons <[email protected]> > > >>> wrote: > > >>> > [X] +1 to adding a changelog.MD file > > >>> > [] -1 to adding a changelog.MD file > > >>> > > > >>> > That said, I'm only in favour of it if we're fastidious about > > >>> > requiring changelog updates on every single PR. A PR should either > > >>> > provide a reasonable changelog entry, or, in the body of the PR, > > >>> > justify it's absence. A simple "This bugfix does not require a > > >>> > changelog entry." is sufficient for trivial bugfixes. That's plenty > > >>> > for a reviewer to quickly either agree or decide to request (or > > >>> > provide) an entry. > > >>> > > > >>> > If we add the changelog file, we need to update the contributing > file > > >>> > to include the new guidelines. > > >>> > > > >>> > On Wed, Jan 10, 2018 at 9:14 AM, Jeremy Mitchell < > > [email protected]> > > >>> wrote: > > >>> >> Yes, I was about to mention milestones. Why not leverage Github > > >>> milestones > > >>> >> on issues/PRs? We talked about using milestones at the last TC > > summit to > > >>> >> determine the scope of a release. Now is our chance to do that. > > >>> >> > > >>> >> Milestones can be applied to issues or PRs. I tend to create > issues > > for > > >>> >> everything I do, so I would put the milestone on the issue but > > others > > >>> can > > >>> >> simply put a milestone on their PR (if there is no related issue). > > >>> Either > > >>> >> way, it tags the items we want included in the changelog. And then > > the > > >>> RM > > >>> >> can build the changelog from the milestones. Easy peasy. > > >>> >> > > >>> >> Jeremy > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> On Tue, Jan 9, 2018 at 4:56 PM, Leif Hedstrom <[email protected]> > > wrote: > > >>> >> > > >>> >>> > > >>> >>> > > >>> >>> > On Jan 9, 2018, at 10:22 AM, Dave Neuman <[email protected]> > > wrote: > > >>> >>> > > > >>> >>> > Looks like this thread died over the holidays. Let me try to > > bring > > >>> it > > >>> >>> back > > >>> >>> > up before we cut a 2.2 branch. > > >>> >>> > Can you please respond with *just* the following: > > >>> >>> > > > >>> >>> > [X] +1 to adding a changelog.MD file > > >>> >>> > [] -1 to adding a changelog.MD file > > >>> >>> > > > >>> >>> > [] +1 to adding a changelog label in github > > >>> >>> > [X] -1 to adding a changelog label in github > > >>> >>> > > > >>> >>> > > >>> >>> > > >>> >>> To add to the previous thread / thoughts. I feel reasonably > > strongly > > >>> that > > >>> >>> having a changelog label in Github is not useful. In the ATS > > >>> community, we > > >>> >>> can *barely* get people to set the Milestone properly, and I feel > > that > > >>> the > > >>> >>> Milestone is a much more important thing to keep accurate than > > anything > > >>> >>> else. And, to be normalized, you don’t want to duplicate this > info > > :-). > > >>> >>> > > >>> >>> So, what we do is have the RM be like a hawk over the Milestones, > > and > > >>> then > > >>> >>> run Phil’s fancy pants script to generate the ChangeLog from the > > >>> Milestones > > >>> >>> on all PRs closed. > > >>> >>> > > >>> >>> Cheers, > > >>> >>> > > >>> >>> — leif > > >>> >>> > > >>> >>> > Thanks, > > >>> >>> > Dave > > >>> >>> > > > >>> >>> > On Fri, Dec 15, 2017 at 9:14 AM, Dewayne Richardson < > > >>> [email protected]> > > >>> >>> > wrote: > > >>> >>> > > > >>> >>> >> +1 on the CHANGELOG.md as well, but I like having the > changelog > > >>> label > > >>> >>> >> because it helps streamline it's creation. I also think the > > labels > > >>> are > > >>> >>> >> valuable because they help summarize the parts of the repo > that > > >>> changed > > >>> >>> and > > >>> >>> >> keeps the concept closer to the repository (where the real > > change > > >>> is). > > >>> >>> >> > > >>> >>> >> -Dew > > >>> >>> >> > > >>> >>> >> On Thu, Dec 14, 2017 at 3:01 PM, Robert Butts < > > >>> [email protected] > > >>> >>> > > > >>> >>> >> wrote: > > >>> >>> >> > > >>> >>> >>> +1. To clarify, I'm +1 on having the "changelog" label, to > help > > >>> whoever > > >>> >>> >>> manually goes thru and builds the CHANGELOG.md. > > >>> >>> >>> > > >>> >>> >>> But I agree with @neuman I don't think we can automate this. > > >>> Titles are > > >>> >>> >> too > > >>> >>> >>> short, some changes need longer explanations and some don't, > > only a > > >>> >>> human > > >>> >>> >>> can figure out how important something is to users; a high > > >>> priority bug > > >>> >>> >> fix > > >>> >>> >>> could still be low-impact, or vica-versa. Much as I dislike > > manual > > >>> >>> >> things, > > >>> >>> >>> this really needs human judgement. And we absolutely need a > > good > > >>> >>> >> Changelog > > >>> >>> >>> with each Release. > > >>> >>> >>> > > >>> >>> >>> On Thu, Dec 14, 2017 at 2:36 PM, Dave Neuman < > > [email protected]> > > >>> >>> wrote: > > >>> >>> >>> > > >>> >>> >>>> Thanks for putting that together Dewayne. I was just > starting > > to > > >>> do > > >>> >>> >> that > > >>> >>> >>>> myself when I saw it was already done. > > >>> >>> >>>> As a developer this is fine, I can see a list of PRs and > > click on > > >>> each > > >>> >>> >>> one > > >>> >>> >>>> to see the whole conversation. I can comb through them and > > get a > > >>> >>> >> general > > >>> >>> >>>> sense for what changed. > > >>> >>> >>>> > > >>> >>> >>>> However, as an operator and user of Traffic Control (which I > > >>> mostly am > > >>> >>> >>>> these days) I am -1 for the following reasons: > > >>> >>> >>>> 1) only committers can assign labels to issues and pull > > requests. > > >>> >>> This > > >>> >>> >>>> means that the committers need to be cognizant of the > > issues/PRs > > >>> they > > >>> >>> >> are > > >>> >>> >>>> reviewing and apply the change log label; > > >>> >>> >>>> 2) the title of a PR only gives so much information about a > > >>> change, if > > >>> >>> >> I > > >>> >>> >>>> want more information I have to click on each individual one > > >>> >>> >>>> 3) If I am not a developer, or someone who is very familiar > > with > > >>> our > > >>> >>> >>>> project, it is hard for me to ascertain from this list which > > >>> changes > > >>> >>> >> are > > >>> >>> >>>> super-important or have some operational considerations > > attached > > >>> to > > >>> >>> >> them. > > >>> >>> >>>> These are the issues I really care about. > > >>> >>> >>>> 4) When I go to do an upgrade, it's a lot easier to > > copy/paste a > > >>> nice > > >>> >>> >>>> bulleted list of what changed then it is to try to take a > > list of > > >>> PRs > > >>> >>> >> and > > >>> >>> >>>> turn it into a high level list of what's important. > > >>> >>> >>>> > > >>> >>> >>>> We need a solution that gives someone what they need at a > > glance. > > >>> >>> >>> Something > > >>> >>> >>>> that can be copy/pasted out or easily linked to. IMO not > all > > of > > >>> our > > >>> >>> >>> users > > >>> >>> >>>> are super technical or involved in the day to day so we > > shouldn't > > >>> just > > >>> >>> >>>> point them at a list of PRs and say "figure it out"; we > should > > >>> make it > > >>> >>> >>> easy > > >>> >>> >>>> for them to figure out. > > >>> >>> >>>> > > >>> >>> >>>> I have seen lots of alternatives suggested to what Steve has > > >>> proposed, > > >>> >>> >>> but > > >>> >>> >>>> I haven't seen anyone state why they don't like what Steve > has > > >>> >>> >>> proposed? I > > >>> >>> >>>> think what he is proposing is pretty standard across major > > Github > > >>> >>> >>> projects > > >>> >>> >>>> that I have seen. I understand that we can introduce some > > >>> additional > > >>> >>> >>>> inconvenience with having to manually write what your > feature > > or > > >>> bug > > >>> >>> >> fix > > >>> >>> >>>> does, and there could be some conflicts, but isn't it > > important to > > >>> >>> >>> clearly > > >>> >>> >>>> portray what has changed? I don't think we need a > > changelog.md > > >>> entry > > >>> >>> >> to > > >>> >>> >>>> every PR, in fact I hope we don't...we need a changelog.md > > entry > > >>> any > > >>> >>> >>> time > > >>> >>> >>>> we add a new feature, any time we have some operational > > >>> considerations > > >>> >>> >>> that > > >>> >>> >>>> need to be communicated, or any time that we fix a bug from > a > > >>> previous > > >>> >>> >>>> release. > > >>> >>> >>>> > > >>> >>> >>>> > > >>> >>> >>>> On Thu, Dec 14, 2017 at 2:02 PM, Jeremy Mitchell < > > >>> >>> >> [email protected]> > > >>> >>> >>>> wrote: > > >>> >>> >>>> > > >>> >>> >>>>> This label idea would require everyone to go back and find > > their > > >>> PRs > > >>> >>> >>> that > > >>> >>> >>>>> were closed after Aug 4th (the date 2.1 branch was created) > > and > > >>> >>> >> attach > > >>> >>> >>>> the > > >>> >>> >>>>> 'change log' label and the 2.2 milestone to the appropriate > > ones, > > >>> >>> >>> right? > > >>> >>> >>>>> And then that link dew provide would be an accurate picture > > of > > >>> what > > >>> >>> >> has > > >>> >>> >>>>> changed between 21. and 2.2... > > >>> >>> >>>>> > > >>> >>> >>>>> of course, ignore PRs that don't affect the "interface" > like > > >>> "license > > >>> >>> >>>>> changes", right? > > >>> >>> >>>>> > > >>> >>> >>>>> i like the idea... > > >>> >>> >>>>> > > >>> >>> >>>>> On Thu, Dec 14, 2017 at 1:59 PM, Dewayne Richardson < > > >>> >>> >> [email protected] > > >>> >>> >>>> > > >>> >>> >>>>> wrote: > > >>> >>> >>>>> > > >>> >>> >>>>>> As a POC for the Change Log label follow this link: > > >>> >>> >>>>>> > > >>> >>> >>>>>> https://github.com/apache/incubator-trafficcontrol/ > > >>> >>> >>>>>> pulls?q=is%3Apr+is%3Aclosed+label%3A%22change+log%22+ > > >>> >>> >>> milestone%3A2.2.0 > > >>> >>> >>>>>> > > >>> >>> >>>>>> -Dew > > >>> >>> >>>>>> > > >>> >>> >>>>>> On Thu, Dec 14, 2017 at 10:48 AM, Gelinas, Derek < > > >>> >>> >>>>>> [email protected]> > > >>> >>> >>>>>> wrote: > > >>> >>> >>>>>> > > >>> >>> >>>>>>> I'm +1 for the label as well. > > >>> >>> >>>>>>> > > >>> >>> >>>>>>>> On Dec 14, 2017, at 12:29 PM, Robert Butts < > > >>> >>> >>>> [email protected] > > >>> >>> >>>>>> > > >>> >>> >>>>>>> wrote: > > >>> >>> >>>>>>>> > > >>> >>> >>>>>>>> +1 on a "changelog" label. Seems like that would make it > > a lot > > >>> >>> >>>> easier > > >>> >>> >>>>>> for > > >>> >>> >>>>>>>> the person writing it up. Easier to skip things like > code > > >>> >>> >>>> maintenance > > >>> >>> >>>>>>> that > > >>> >>> >>>>>>>> have no interface effect. > > >>> >>> >>>>>>>> > > >>> >>> >>>>>>>> On Thu, Dec 14, 2017 at 10:14 AM, Dewayne Richardson < > > >>> >>> >>>>>> [email protected]> > > >>> >>> >>>>>>>> wrote: > > >>> >>> >>>>>>>> > > >>> >>> >>>>>>>>> Another idea would be to include a new CHANGELOG label > > that > > >>> >>> >> you > > >>> >>> >>>>> could > > >>> >>> >>>>>>> tack > > >>> >>> >>>>>>>>> onto specific PR's that you wanted to be included (as > > well as > > >>> >>> >>>>> grouped > > >>> >>> >>>>>>>>> within Milestones) as the high level features that went > > into > > >>> >>> >> the > > >>> >>> >>>>>>> release. > > >>> >>> >>>>>>>>> As for the gotchas, I think those should be Github > issues > > >>> >>> >>> because > > >>> >>> >>>> to > > >>> >>> >>>>>> me > > >>> >>> >>>>>>>>> those were bugs. > > >>> >>> >>>>>>>>> > > >>> >>> >>>>>>>>> -Dew > > >>> >>> >>>>>>>>> > > >>> >>> >>>>>>>>> On Thu, Dec 14, 2017 at 10:01 AM, Jeremy Mitchell < > > >>> >>> >>>>>>> [email protected]> > > >>> >>> >>>>>>>>> wrote: > > >>> >>> >>>>>>>>> > > >>> >>> >>>>>>>>>> I agree. Very readable. I also like the idea of a > either > > >>> >>> >>>> creating a > > >>> >>> >>>>>>>>>> CHANGELOG.md for each component...or one CHANGELOG.md > > with > > >>> >>> >>>> sections > > >>> >>> >>>>>> for > > >>> >>> >>>>>>>>>> each component. > > >>> >>> >>>>>>>>>> > > >>> >>> >>>>>>>>>> I still do like the idea of creating issues with > > milestones > > >>> >>> >> but > > >>> >>> >>>>> I'll > > >>> >>> >>>>>>> let > > >>> >>> >>>>>>>>>> that go. That seems to be a personal preference of > mine. > > >>> >>> >>>>>>>>>> > > >>> >>> >>>>>>>>>> Jeremy > > >>> >>> >>>>>>>>>> > > >>> >>> >>>>>>>>>>> On Thu, Dec 14, 2017 at 9:45 AM, Dave Neuman < > > >>> >>> >>> [email protected] > > >>> >>> >>>>> > > >>> >>> >>>>>>> wrote: > > >>> >>> >>>>>>>>>>> > > >>> >>> >>>>>>>>>>> Have you taken a look at some Changelogs of other > > github > > >>> >>> >>>> projects? > > >>> >>> >>>>>>>>> Here > > >>> >>> >>>>>>>>>>> are a few from other projects we use in Traffic > > Control: > > >>> >>> >>>>>>>>>>> - Docker Compose: https://github.com/docker/ > > >>> >>> >>>>>>>>>> compose/blob/master/CHANGELOG. > > >>> >>> >>>>>>>>>>> md > > >>> >>> >>>>>>>>>>> - InfluxDB: https://github.com/influxdata/ > > >>> >>> >>> influxdb/blob/master/ > > >>> >>> >>>>>>>>>>> CHANGELOG.md > > >>> >>> >>>>>>>>>>> - Grafana: https://github.com/grafana/ > > >>> >>> >>>>> grafana/blob/master/CHANGELOG > > >>> >>> >>>>>> . > > >>> >>> >>>>>>> md > > >>> >>> >>>>>>>>>>> - Ansible: https://github.com/ansible/ > > >>> >>> >>>>> ansible/blob/devel/CHANGELOG. > > >>> >>> >>>>>> md > > >>> >>> >>>>>>>>>>> > > >>> >>> >>>>>>>>>>> See how easy to read those are and how they provide a > > lot > > >>> of > > >>> >>> >>>>>>>>> information > > >>> >>> >>>>>>>>>>> without having to wade through hundreds of issues and > > pull > > >>> >>> >>>>> requests? > > >>> >>> >>>>>>>>>> Some > > >>> >>> >>>>>>>>>>> of them also have links to issues for new features, > as > > well > > >>> >>> >> as > > >>> >>> >>>> bug > > >>> >>> >>>>>>>>> fixes > > >>> >>> >>>>>>>>>>> that are in the current release. I think all of them > > are > > >>> >>> >> easy > > >>> >>> >>>> to > > >>> >>> >>>>>> read > > >>> >>> >>>>>>>>>> and > > >>> >>> >>>>>>>>>>> can give a user a quick overview of what is in the > new > > >>> >>> >>> release. > > >>> >>> >>>> I > > >>> >>> >>>>>>> think > > >>> >>> >>>>>>>>>>> it's fine to add a link to all the issues if we want, > > but I > > >>> >>> >>>> think > > >>> >>> >>>>>>>>>>> ultimately we want to create something like what I > have > > >>> >>> >> linked > > >>> >>> >>>> to > > >>> >>> >>>>>>>>> above. > > >>> >>> >>>>>>>>>>> We might also want to break out our CHANGELOG.md by > > >>> >>> >> component > > >>> >>> >>> to > > >>> >>> >>>>>>>>> provide > > >>> >>> >>>>>>>>>>> even more readability. > > >>> >>> >>>>>>>>>>> > > >>> >>> >>>>>>>>>>> I know our first inclination is to try to automate > > >>> >>> >> everything, > > >>> >>> >>>> but > > >>> >>> >>>>>>>>>>> sometimes it makes sense to do things manually so > that > > you > > >>> >>> >> can > > >>> >>> >>>>>> create > > >>> >>> >>>>>>> a > > >>> >>> >>>>>>>>>>> better output. > > >>> >>> >>>>>>>>>>> > > >>> >>> >>>>>>>>>>> > > >>> >>> >>>>>>>>>>> > > >>> >>> >>>>>>>>>>> On Thu, Dec 14, 2017 at 8:55 AM, Jeremy Mitchell < > > >>> >>> >>>>>>>>> [email protected]> > > >>> >>> >>>>>>>>>>> wrote: > > >>> >>> >>>>>>>>>>> > > >>> >>> >>>>>>>>>>>> What if CHANGLOG.md includes 2 things: > > >>> >>> >>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>> 1. a link to 2.2 issues (i.e. > > >>> >>> >>>>>>>>>>>> https://github.com/apache/incubator-trafficcontrol/ > > >>> >>> >>>>>>>>>>>> issues?q=is%3Aopen+is%3Aissue+milestone%3A2.2.0 > > >>> >>> >>>>>>>>>>>> 2. a bulleted list of 2.2 gotchas (i.e. Traffic Ops > > Golang > > >>> >>> >>>>> doesn't > > >>> >>> >>>>>>>>>>> connect > > >>> >>> >>>>>>>>>>>> to a Riak with self-signed certificates; Riak > security > > >>> >>> >> grant > > >>> >>> >>>>> needs > > >>> >>> >>>>>>>>>>> updated; > > >>> >>> >>>>>>>>>>>> upgrade param needed for ds routing names, etc, > > etc...) > > >>> >>> >>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>> But again this requires everyone to create issues > > (with a > > >>> >>> >>>>>> milestone) > > >>> >>> >>>>>>>>> in > > >>> >>> >>>>>>>>>>>> which one or more PR's can be attached to. > > >>> >>> >>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>> Dave, you said "If you are developing a new feature > > you > > >>> >>> >> could > > >>> >>> >>>>>> easily > > >>> >>> >>>>>>>>>> end > > >>> >>> >>>>>>>>>>> up > > >>> >>> >>>>>>>>>>>> with 5 or more PRs" > > >>> >>> >>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>> So in this case, I'd expect 1 issue and 5 PR's > linked > > to > > >>> >>> >>> that 1 > > >>> >>> >>>>>>>>>> issue... > > >>> >>> >>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>> Jeremy > > >>> >>> >>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>> On Thu, Dec 14, 2017 at 8:40 AM, Dave Neuman < > > >>> >>> >>>> [email protected]> > > >>> >>> >>>>>>>>>> wrote: > > >>> >>> >>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>> I think it's fine to include all of our PRs and > > issues in > > >>> >>> >> a > > >>> >>> >>>>> github > > >>> >>> >>>>>>>>>>>>> milestone, and we should do that, but I don't think > > that > > >>> >>> >> we > > >>> >>> >>>> want > > >>> >>> >>>>>> to > > >>> >>> >>>>>>>>>>>> include > > >>> >>> >>>>>>>>>>>>> every single PR in our changelog. When we have > tried > > >>> that > > >>> >>> >>> in > > >>> >>> >>>>> the > > >>> >>> >>>>>>>>>> past > > >>> >>> >>>>>>>>>>> we > > >>> >>> >>>>>>>>>>>>> have realized that it gets to be so much > information > > that > > >>> >>> >>> it's > > >>> >>> >>>>> not > > >>> >>> >>>>>>>>>>>> useful. > > >>> >>> >>>>>>>>>>>>> A good example of why is a new feature. If you are > > >>> >>> >>> developing > > >>> >>> >>>> a > > >>> >>> >>>>>> new > > >>> >>> >>>>>>>>>>>> feature > > >>> >>> >>>>>>>>>>>>> you could easily end up with 5 or more PRs: one to > > >>> >>> >> introduce > > >>> >>> >>>> the > > >>> >>> >>>>>>>>>>> feature, > > >>> >>> >>>>>>>>>>>>> one to add some more functionality, several to fix > > bugs > > >>> >>> >> with > > >>> >>> >>>> it, > > >>> >>> >>>>>>>>> etc. > > >>> >>> >>>>>>>>>>>>> Instead of having a line in the changelog for each > > one of > > >>> >>> >>>> those > > >>> >>> >>>>>>>>> PRs, > > >>> >>> >>>>>>>>>> we > > >>> >>> >>>>>>>>>>>>> should just have one line that says "introduced > > feature > > >>> X" > > >>> >>> >>>> with > > >>> >>> >>>>>>>>>> maybe a > > >>> >>> >>>>>>>>>>>>> blurb about what it is and any release notes that > an > > >>> >>> >>> operator > > >>> >>> >>>>>> would > > >>> >>> >>>>>>>>>>> need > > >>> >>> >>>>>>>>>>>> to > > >>> >>> >>>>>>>>>>>>> know. This way the file in concise and easy to > > >>> understand > > >>> >>> >>> by > > >>> >>> >>>>>>>>> anyone > > >>> >>> >>>>>>>>>>>>> wanting to use a new version of our product. I > think > > >>> it's > > >>> >>> >>>> also > > >>> >>> >>>>>>>>>>> important > > >>> >>> >>>>>>>>>>>>> to include what bug fixes (since the previous > > release) > > >>> >>> >> that > > >>> >>> >>> we > > >>> >>> >>>>>> have > > >>> >>> >>>>>>>>>>>> fixed. > > >>> >>> >>>>>>>>>>>>> Those are the reasons why I tend to lean towards a > > manual > > >>> >>> >>>>>>>>> changelog. > > >>> >>> >>>>>>>>>>> It > > >>> >>> >>>>>>>>>>>>> gives us the ability to control how much > information > > goes > > >>> >>> >>> into > > >>> >>> >>>>> the > > >>> >>> >>>>>>>>>>>>> changelog and the flexibility to make sure it is > > useful. > > >>> >>> >>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>> On Thu, Dec 14, 2017 at 8:13 AM, Jeremy Mitchell < > > >>> >>> >>>>>>>>>>> [email protected]> > > >>> >>> >>>>>>>>>>>>> wrote: > > >>> >>> >>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>> Why not leverage Github issues/milestones to > > determine > > >>> >>> >> the > > >>> >>> >>>>> scope > > >>> >>> >>>>>>>>> of > > >>> >>> >>>>>>>>>>>> each > > >>> >>> >>>>>>>>>>>>>> release? Per our CONTRIBUTING.md > > >>> >>> >>>>>>>>>>>>>> <https://github.com/apache/ > > >>> >>> >> incubator-trafficcontrol/blob/ > > >>> >>> >>>>>>>>>>>>>> master/CONTRIBUTING.md> > > >>> >>> >>>>>>>>>>>>>> : > > >>> >>> >>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>> "If you have improvements (enhancements or bug > > fixes) > > >>> for > > >>> >>> >>>>> Traffic > > >>> >>> >>>>>>>>>>>>> Control, > > >>> >>> >>>>>>>>>>>>>> start by creating an issue > > >>> >>> >>>>>>>>>>>>>> <https://github.com/apache/ > > incubator-trafficcontrol/ > > >>> >>> >> issues > > >>> >>> >>>>>> ..." > > >>> >>> >>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>> That implies that all PR's should be mapped to an > > issue > > >>> >>> >>>>> although > > >>> >>> >>>>>>>>> we > > >>> >>> >>>>>>>>>>> do > > >>> >>> >>>>>>>>>>>>> not > > >>> >>> >>>>>>>>>>>>>> enforce this but if we did it would be easy to put > > each > > >>> >>> >>> issue > > >>> >>> >>>>>>>>> into > > >>> >>> >>>>>>>>>> a > > >>> >>> >>>>>>>>>>>>>> milestone (2.2 for example) and then pull a github > > >>> report > > >>> >>> >>> at > > >>> >>> >>>>> any > > >>> >>> >>>>>>>>>>> time. > > >>> >>> >>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>> Or....rather than creating an issue, put a good > > >>> >>> >>>>> title/description > > >>> >>> >>>>>>>>>> on > > >>> >>> >>>>>>>>>>>> your > > >>> >>> >>>>>>>>>>>>>> PR and then the PR can be assigned to the > milestone > > >>> >>> >>> instead. > > >>> >>> >>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>> It just seems like that's what milestones are for > > so why > > >>> >>> >>> not > > >>> >>> >>>>> use > > >>> >>> >>>>>>>>>>> them? > > >>> >>> >>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>> Jeremy > > >>> >>> >>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>> On Wed, Dec 13, 2017 at 3:28 PM, Dave Neuman < > > >>> >>> >>>>> [email protected]> > > >>> >>> >>>>>>>>>>>> wrote: > > >>> >>> >>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>>> I am +1 on this approach, I know it's manual and > > there > > >>> >>> >>> could > > >>> >>> >>>>> be > > >>> >>> >>>>>>>>>>>>> conflicts > > >>> >>> >>>>>>>>>>>>>>> and it's a bit of a PITA, but I think it actually > > has > > >>> >>> >> some > > >>> >>> >>>>>>>>>> benefits > > >>> >>> >>>>>>>>>>>> in > > >>> >>> >>>>>>>>>>>>>> that > > >>> >>> >>>>>>>>>>>>>>> a human can actually enter in important release > > notes > > >>> >>> >> that > > >>> >>> >>>> are > > >>> >>> >>>>>>>>>>>> readable > > >>> >>> >>>>>>>>>>>>>> and > > >>> >>> >>>>>>>>>>>>>>> make sense. > > >>> >>> >>>>>>>>>>>>>>> That being said if someone is willing to make an > > >>> >>> >> automated > > >>> >>> >>>>>>>>>> approach > > >>> >>> >>>>>>>>>>>>> work, > > >>> >>> >>>>>>>>>>>>>>> that allows us to keep track of changes at a > > reasonable > > >>> >>> >>>> level > > >>> >>> >>>>>>>>>> (not > > >>> >>> >>>>>>>>>>>> per > > >>> >>> >>>>>>>>>>>>>>> commit, not necessarily even per PR), then I > could > > be > > >>> +1 > > >>> >>> >>> on > > >>> >>> >>>>>>>>> that > > >>> >>> >>>>>>>>>> as > > >>> >>> >>>>>>>>>>>>> well. > > >>> >>> >>>>>>>>>>>>>>> I would need to someone volunteer to make it work > > >>> >>> >> before I > > >>> >>> >>>>> give > > >>> >>> >>>>>>>>>> my > > >>> >>> >>>>>>>>>>> +1 > > >>> >>> >>>>>>>>>>>>>>> though. > > >>> >>> >>>>>>>>>>>>>>> Either way, we REALLY need a changelog that is > > updated > > >>> >>> >>>>>>>>> regularly > > >>> >>> >>>>>>>>>>> with > > >>> >>> >>>>>>>>>>>>>>> important information. > > >>> >>> >>>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>>> --Dave > > >>> >>> >>>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>>> On Wed, Dec 13, 2017 at 3:00 PM, Steve Malenfant > < > > >>> >>> >>>>>>>>>>>> [email protected] > > >>> >>> >>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>>> wrote: > > >>> >>> >>>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>>>> Hey All, > > >>> >>> >>>>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>>>> There has been a vote on not maintaining a > > CHANGELOG > > >>> >>> >> file > > >>> >>> >>>> in > > >>> >>> >>>>>>>>>> the > > >>> >>> >>>>>>>>>>>> past > > >>> >>> >>>>>>>>>>>>>> and > > >>> >>> >>>>>>>>>>>>>>>> seems like we leaned toward an automated > process. > > I > > >>> >>> >>> believe > > >>> >>> >>>>>>>>>> none > > >>> >>> >>>>>>>>>>> of > > >>> >>> >>>>>>>>>>>>>> them > > >>> >>> >>>>>>>>>>>>>>>> had happened (please correct me if not). > > >>> >>> >>>>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>>>> I have been upgrading Traffic Control from 2.1 > to > > 2.2 > > >>> >>> >>> this > > >>> >>> >>>>>>>>> week > > >>> >>> >>>>>>>>>>> and > > >>> >>> >>>>>>>>>>>>>> found > > >>> >>> >>>>>>>>>>>>>>>> numerous gotchas. > > >>> >>> >>>>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>>>> Some examples of things I ran into and luckily I > > was > > >>> >>> >> able > > >>> >>> >>>> to > > >>> >>> >>>>>>>>>> get > > >>> >>> >>>>>>>>>>>> good > > >>> >>> >>>>>>>>>>>>>>>> support from the Slack channels. Here is a few > > example > > >>> >>> >> of > > >>> >>> >>>>>>>>>>> possible > > >>> >>> >>>>>>>>>>>>>>> breaking > > >>> >>> >>>>>>>>>>>>>>>> changes : > > >>> >>> >>>>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>>>> - Delivery Service prefixes disappeared after > > upgrade, > > >>> >>> >>> was > > >>> >>> >>>>>>>>> not > > >>> >>> >>>>>>>>>>>>> handled > > >>> >>> >>>>>>>>>>>>>> in > > >>> >>> >>>>>>>>>>>>>>>> postinstall (requires special attention, this > was > > on > > >>> >>> >> this > > >>> >>> >>>>>>>>> forum > > >>> >>> >>>>>>>>>>> and > > >>> >>> >>>>>>>>>>>>>> well > > >>> >>> >>>>>>>>>>>>>>>> documented on the mailing list) > > >>> >>> >>>>>>>>>>>>>>>> - Traffic Ops Golang doesn't connect to a Riak > > with > > >>> >>> >>>>>>>>> self-signed > > >>> >>> >>>>>>>>>>>>>>>> certificates > > >>> >>> >>>>>>>>>>>>>>>> - Riak security grant needs updated > > >>> >>> >>>>>>>>>>>>>>>> - cdn.conf configuration change > > >>> >>> >>>>>>>>>>>>>>>> - Traffic Portal required for new features (URI > > >>> >>> >> Signing) > > >>> >>> >>>>>>>>>>>>>>>> - cachekey plugin instead of cacheurl > > >>> >>> >>>>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>>>> There was great enhancements made in 2.2 needs > to > > be > > >>> >>> >>>> noticed > > >>> >>> >>>>>>>>> by > > >>> >>> >>>>>>>>>>>>> current > > >>> >>> >>>>>>>>>>>>>>> and > > >>> >>> >>>>>>>>>>>>>>>> new users. If we are looking to get more > > engagement, > > >>> >>> >>>> that's > > >>> >>> >>>>>>>>>>>> probably > > >>> >>> >>>>>>>>>>>>>> the > > >>> >>> >>>>>>>>>>>>>>>> #1 thing to do. I usually go and read about all > > the > > >>> >>> >> other > > >>> >>> >>>>>>>>>>>> components > > >>> >>> >>>>>>>>>>>>>>> which > > >>> >>> >>>>>>>>>>>>>>>> we use around the Traffic Control CDN (Influx, > > >>> Elastic, > > >>> >>> >>>>>>>>>> Grafana, > > >>> >>> >>>>>>>>>>>>>> etc...) > > >>> >>> >>>>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>>>> So let me re-quote what Dave has sent and ask > the > > same > > >>> >>> >>>>>>>>> question > > >>> >>> >>>>>>>>>>>>> again. > > >>> >>> >>>>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>>>> ====== > > >>> >>> >>>>>>>>>>>>>>>> Hey All, > > >>> >>> >>>>>>>>>>>>>>>> One thing we discussed at the meetup was the > > addition > > >>> >>> >> of > > >>> >>> >>> a > > >>> >>> >>>>>>>>>>>>> CHANGELOG.md > > >>> >>> >>>>>>>>>>>>>>>> file to the project. This file will contain > > changes > > >>> >>> >>> that > > >>> >>> >>>>>>>>> are > > >>> >>> >>>>>>>>>>> made > > >>> >>> >>>>>>>>>>>>> to > > >>> >>> >>>>>>>>>>>>>>> the > > >>> >>> >>>>>>>>>>>>>>>> project including bug fixes and new features. > > (e.g. > > >>> >>> >>>>>>>>>>>>>>>> https://github.com/influxdata/ > > influxdb/blob/master/ > > >>> >>> >>>>>>>>>> CHANGELOG.md > > >>> >>> >>>>>>>>>>> ). > > >>> >>> >>>>>>>>>>>>>>> Adding > > >>> >>> >>>>>>>>>>>>>>>> this file means that we will now require each PR > > to > > >>> >>> >>> contain > > >>> >>> >>>>>>>>> an > > >>> >>> >>>>>>>>>>>> update > > >>> >>> >>>>>>>>>>>>>> to > > >>> >>> >>>>>>>>>>>>>>>> the CHANGELOG.md file, and our documentation > will > > need > > >>> >>> >> to > > >>> >>> >>>> be > > >>> >>> >>>>>>>>>>>> updated > > >>> >>> >>>>>>>>>>>>>>>> accordingly. > > >>> >>> >>>>>>>>>>>>>>>> I thought it would be good to open a vote for > > adding > > >>> >>> >> this > > >>> >>> >>>>>>>>> file, > > >>> >>> >>>>>>>>>>> and > > >>> >>> >>>>>>>>>>>>> if > > >>> >>> >>>>>>>>>>>>>> it > > >>> >>> >>>>>>>>>>>>>>>> passes, I will update the documentation and add > a > > >>> >>> >>>>>>>>> CHANGELOG.md > > >>> >>> >>>>>>>>>>>> file. > > >>> >>> >>>>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>>>> Thanks, > > >>> >>> >>>>>>>>>>>>>>>> Dave > > >>> >>> >>>>>>>>>>>>>>>> ====== > > >>> >>> >>>>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>>>> I'm a +1 on CHANGELOG, but I'm not heavy > creating > > PRs > > >>> >>> >>> which > > >>> >>> >>>>>>>>>> kind > > >>> >>> >>>>>>>>>>>>>>> influence > > >>> >>> >>>>>>>>>>>>>>>> my vote. > > >>> >>> >>>>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>>>> Steve > > >>> >>> >>>>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>>> > > >>> >>> >>>>>>>>>>>> > > >>> >>> >>>>>>>>>>> > > >>> >>> >>>>>>>>>> > > >>> >>> >>>>>>>>> > > >>> >>> >>>>>>> > > >>> >>> >>>>>> > > >>> >>> >>>>> > > >>> >>> >>>> > > >>> >>> >>> > > >>> >>> >> > > >>> >>> > > >>> >>> > > >>> > > >
