I'd like to propose we drop support for `goose down` in terms of doing
a Traffic Ops downgrade.
Right now whenever you upgrade Traffic Ops you also need to run
`db/admin.pl upgrade` to migrate the DB to the latest version. This
step runs all unapplied migrations since the last DB migration was
app
I'll be honest, I think the simplest thing is still to just require a changelog
message, added to a central file, to be included in the commit. We've been
going over and over this for months instead of actually writing change logs.
Let's just propose it and put it to a vote.
> On Oct 18, 2018,
I'm +1 on squashing and merging, but I think we need a combination of
a number of things to really have a decent changelog. Even if we have
awesome commit messages and squashed PRs, there's still way too many
PRs in a release to just generate a decent changelog from the PR
titles and/or commit mess
mine, too.. down to 400 now..
On Thu, Oct 18, 2018 at 9:00 AM Jan van Doorn wrote:
> Thanks Jeremy - Did mine.
>
> Cheers,
> JvD
>
>
> > On Oct 18, 2018, at 07:34, Dave Neuman wrote:
> >
> > Thanks Jeremy,
> > I will take a look at my issues today.
> >
> > On Wed, Oct 17, 2018 at 8:52 PM Jerem
> On Oct 18, 2018, at 7:40 AM, Dave Neuman wrote:
>
> Hey All,
> I want to follow up on something that was briefly discussed at the summit
> this week. Many people do not like the Changelog and feel like it can be a
> PITA to deal with. One of the reasons we have the changelog is because
> t
is there a setting in github to enable "squash and merge" vs "rebase and
merge"?
i do have a couple of concerns however:
1. what happens when 2+ people contribute to a PR? This is a pretty common
scenario. If Bob and Sam both work on PR#1 is all the commit history for
Sam lost?
2. i can see benef
I updated mine as well
-Dew
On Thu, Oct 18, 2018 at 9:00 AM Jan van Doorn wrote:
> Thanks Jeremy - Did mine.
>
> Cheers,
> JvD
>
>
> > On Oct 18, 2018, at 07:34, Dave Neuman wrote:
> >
> > Thanks Jeremy,
> > I will take a look at my issues today.
> >
> > On Wed, Oct 17, 2018 at 8:52 PM Jeremy
Well, our "curated" changelogs are missing A LOT of information on what
actually went into the release, which therefore makes it not useful. If we
were better about commit messages and used squash and merge, then we would
at least have something for every PR that was merged.
On Thu, Oct 18, 2018
Thanks Jeremy - Did mine.
Cheers,
JvD
> On Oct 18, 2018, at 07:34, Dave Neuman wrote:
>
> Thanks Jeremy,
> I will take a look at my issues today.
>
> On Wed, Oct 17, 2018 at 8:52 PM Jeremy Mitchell
> wrote:
>
>> To reiterate what we discussed at the ATC Summit regarding open issues, I
>> w
> I think this just shifts the burden from writing a changelog entry to writing
> a good commit entry.
I agree, and I think that’s where that burden belongs. (And I _really_ hate
merge conflicts).
> There might be fewer commit entries if we squash and merge, but I’m doubtful
> that it would
I think this just shifts the burden from writing a changelog entry to writing a
good commit entry.
There might be fewer commit entries if we squash and merge, but I’m doubtful
that it would be as valuable as our “curated” changelogs.
> On Oct 18, 2018, at 9:40 AM, Dave Neuman wrote:
>
>
Hey All,
I want to follow up on something that was briefly discussed at the summit
this week. Many people do not like the Changelog and feel like it can be a
PITA to deal with. One of the reasons we have the changelog is because
there are so many commits in a given release, that it is hard to com
Thanks Jeremy,
I will take a look at my issues today.
On Wed, Oct 17, 2018 at 8:52 PM Jeremy Mitchell
wrote:
> To reiterate what we discussed at the ATC Summit regarding open issues, I
> would suggest that everyone start by reviewing the issues created by them.
>
> https://github.com/apache/traf
13 matches
Mail list logo
