You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
in order to preemptively resolve duplicates and conflicts prior to the release process
(CC @alexanderbez )
bez [2:18 PM]
unpopular opinion: We ditch clog/pending.md
fp4k [2:19 PM]
In favour of constant merge conflicts on Changelog.md? (that sounds like crap, unless there is another alternative?)
bez [2:21 PM]
yes in favor
fp4k [2:21 PM]
That is an unpopular opinion hahaha
bez [2:21 PM]
conflicts should not be terrible
fp4k [2:21 PM]
But why, I really like clog
bez [2:21 PM]
its not like we're merging a million PRs a week
i dont
fp4k [2:22 PM]
what don’t you like about it?
Maybe we can find a common solution
bez [2:23 PM]
It's overcomplicated now that we have a single canonical branch
I don't get a holistic view
To elaborate on (2). Throughout the course of introducing changes and features, it can very well be the case that a feature is introduced, then modified, and then removed completely all in the course of a single release and all with each own's respective pending log entry.
So in such a case, you'd have 3+ pending log entries when really only 1 or even 0 may be needed. This requires groking through the final log
fede [2:24 PM]
You’re right with 1.
bez [2:24 PM]
which only I do
having a single place for this makes this so much easier
/rant
sorry lol
fp4k [2:24 PM]
🙂
bez [2:24 PM]
I know this probably isn't going to change, but I just wanted to share my thoughts
e.g.
this PR #4573
I now have to grok through and remove 2 pending log entries
granted, the author could do it, but then the onus is on them to even know (edited)
fp4k [2:26 PM]
I understand the problem… it seems as though a real problem is just making sure that we make modifications to other pending entries on each individual merge (as opposed to just the release) it’s difficult to do that right now because there isn’t a nice overview layout to see what else is in the pending log
bez [2:26 PM]
exactly
fp4k [2:27 PM]
Although I’ll mention that this process has also historically been a problem, simply because folks don’t always bother to modify other entries even when everything was a part of the same file
bez [2:28 PM]
yeah true. I'll just need to keep these in mind when prepping the release
ok, grabbing coffee and reviewing everything supply related
bez [2:31 PM]
@fp4k did you get a chance to peek at the events PR?
fp4k [2:32 PM]
It would nice to have the holistic view somehow while keeping pending entries. Without re-introducing the pending file, the best thing I can imagine is use a preview for the changelog and ideally actually have a bot post that as a PR comment… so much for complexity though…
bez [2:32 PM]
yeah not a bad idea actually
although it would add a lot of noise to the PR comment thread?
fp4k [2:33 PM]
A single post on each PR? not any more noise than CodeCov (which isn’t much)
The text was updated successfully, but these errors were encountered:
rigelrozanski
changed the title
Autopost a Changelog Preview
CI Bot: Autopost a Changelog Preview
Jun 26, 2019
in order to preemptively resolve duplicates and conflicts prior to the release process
(CC @alexanderbez )
bez [2:18 PM]
unpopular opinion: We ditch clog/pending.md
fp4k [2:19 PM]
In favour of constant merge conflicts on
Changelog.md
? (that sounds like crap, unless there is another alternative?)bez [2:21 PM]
yes in favor
fp4k [2:21 PM]
That is an unpopular opinion hahaha
bez [2:21 PM]
conflicts should not be terrible
fp4k [2:21 PM]
But why, I really like clog
bez [2:21 PM]
its not like we're merging a million PRs a week
i dont
fp4k [2:22 PM]
what don’t you like about it?
Maybe we can find a common solution
bez [2:23 PM]
To elaborate on (2). Throughout the course of introducing changes and features, it can very well be the case that a feature is introduced, then modified, and then removed completely all in the course of a single release and all with each own's respective pending log entry.
So in such a case, you'd have 3+ pending log entries when really only 1 or even 0 may be needed. This requires groking through the final log
fede [2:24 PM]
You’re right with 1.
bez [2:24 PM]
which only I do
having a single place for this makes this so much easier
/rant
sorry lol
fp4k [2:24 PM]
🙂
bez [2:24 PM]
I know this probably isn't going to change, but I just wanted to share my thoughts
e.g.
this PR
#4573
I now have to grok through and remove 2 pending log entries
granted, the author could do it, but then the onus is on them to even know (edited)
fp4k [2:26 PM]
I understand the problem… it seems as though a real problem is just making sure that we make modifications to other pending entries on each individual merge (as opposed to just the release) it’s difficult to do that right now because there isn’t a nice overview layout to see what else is in the pending log
bez [2:26 PM]
exactly
fp4k [2:27 PM]
Although I’ll mention that this process has also historically been a problem, simply because folks don’t always bother to modify other entries even when everything was a part of the same file
bez [2:28 PM]
yeah true. I'll just need to keep these in mind when prepping the release
ok, grabbing coffee and reviewing everything supply related
bez [2:31 PM]
@fp4k did you get a chance to peek at the events PR?
fp4k [2:32 PM]
It would nice to have the holistic view somehow while keeping pending entries. Without re-introducing the pending file, the best thing I can imagine is use a preview for the changelog and ideally actually have a bot post that as a PR comment… so much for complexity though…
bez [2:32 PM]
yeah not a bad idea actually
although it would add a lot of noise to the PR comment thread?
fp4k [2:33 PM]
A single post on each PR? not any more noise than CodeCov (which isn’t much)
The text was updated successfully, but these errors were encountered: