Sounds like it could backfire in some cases creating busy work: What happens when I commit to 2.x for code that has been deprecated or removed in 3.x? Certainly we don't want to create tickets for those. Do I have to remember to put a special comment in the commit message?
Gary On Tue, Jan 3, 2023, 04:01 Volkan Yazıcı <vol...@yazi.ci> wrote: > That sounds like a great sweet spot to settle on. We can periodically > (hourly?) run a GitHub Actions workflow that checks if all `release-2.x` > commits older than 24 hours have a subject-matching counterpart in `master` > (and vice versa), if not, creates a GitHub Issue assigned to the author of > the commit and referencing to the commit. > > Anybody else objecting, except Ralph? > > On Mon, Jan 2, 2023 at 11:19 PM Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: > > > Hi Volkan, > > > > On Mon, 2 Jan 2023 at 09:50, Volkan Yazıcı <vol...@yazi.ci> wrote: > > > Suggestion: Shall we harness GitHub Actions to create a GitHub Issue > > > telling commit X needs to be reflected on branch Y whenever a commit > > lands > > > on branch Z? > > > > > > If you all agree, I volunteer to set this up. > > > > If you can add a time delay, that would be fantastic. > > > > I imagine some logic like: if 24 hours have passed and the commit with > > a subject line "Hello World!" on `release-2.x` does not have a commit > > in `master` with the same subject, create an issue. Commits that need > > a subject change (like "Deprecate for removal" -> "Remove") are rare > > and a committer can always close those issues manually. > > > > Piotr > > >
