My main point was to minimise the number of PRs that are not properly linked to their issues since it risks to keep this issues open even if they are already technically resolved. Imho, with an issue prefix in PR title, as it was before, it’s much easier and faster to verify.
Though, if everybody finds it not useful then we will keep a current behaviour. > On 24 Jun 2022, at 21:40, Robert Bradshaw <[email protected]> wrote: > > #N will automatically link to the issue (or PR), which should > generally show up in the description. I'm not sold on the value of > having to have it in the title. [BEAM-nnnn] was primarily useful > because one had to reference an external system. > > On Fri, Jun 24, 2022 at 12:34 PM Danny McCormick > <[email protected]> wrote: >> >> I don't think a similar "[issue #] title" linking construct exists for >> GitHub. AFAIK the recommended method of linking is to put things in the >> description, and I don't really see a reason that putting the issue number >> in the description is harder or more likely to be forgotten; I kinda expect >> it will just take some time for people to adjust to doing this the new way. >> >> I'm probably ambivalent (or slightly opposed) to mandating an issue in the >> PR title - I mostly just see it as a small extra tax with limited value >> since I do think we should ask for issues in the description to preserve >> linking. With that said, I also haven't been around the project for as long >> and didn't previously build that feature into my regular workflow - others >> might find it more useful. >> >> Thanks, >> Danny >> >> On Fri, Jun 24, 2022 at 1:30 PM Alexey Romanenko <[email protected]> >> wrote: >>> >>> I really liked and used the “feature” that we had before when we asked >>> developers to add a Jira issue ID as a prefix to commit messages/PR titles. >>> >>> What’s about to have a similar thing with Github Issues? As additional >>> bonus we could link (is it possible?) a PR to a corresponding issue (as I >>> can see now, quite often people tend to forget to add this into PR >>> description). >>> >>> — >>> Alexey >>> >>> On 7 Jun 2022, at 16:04, Danny McCormick <[email protected]> wrote: >>> >>> This is definitely possible - if we have a list of the dependencies to >>> ignore we can specify an ignore list, or as they come up you can comment >>> "@dependabot ignore". In this case, having the explicit ignore list >>> probably makes sense. I'll follow up with Tomo to make sure the GCP >>> dependencies get added to the ignore list. >>> >>> Thanks, >>> Danny >>> >>> On Mon, Jun 6, 2022 at 8:10 PM Ahmet Altay <[email protected]> wrote: >>>> >>>> >>>> >>>> On Sat, Jun 4, 2022 at 8:30 PM Sachin Agarwal <[email protected]> wrote: >>>>> >>>>> This is great, thank you so much Danny! I checked my issues and all look >>>>> correct. Thank you! >>>>> >>>>> On Sat, Jun 4, 2022 at 6:40 PM Danny McCormick >>>>> <[email protected]> wrote: >>>>>> >>>>>> All Jiras should now be migrated to Issues*, and the owners should be >>>>>> assigned or tagged. Hopefully this will help us be a more productive >>>>>> community and will make it easier for newcomers! If you see any issues >>>>>> with the migration, or generally with using issues, please let me know. >>>> >>>> >>>> Is it possible to disable dependabot for certain dependencies? GCP >>>> dependencies are managed in a way to happen at a lockstep, based on >>>> specifically validated sets >>>> >>>> /cc @Tomo Suzuki - who did lots of work in that area. >>>> >>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Danny >>>>>> >>>>>> * The "Beam Dependency Report Jiras" were not migrated for 2 reasons. >>>>>> (1) There were >500 of them dating back to Nov 2019, many outdated. (2) >>>>>> Dependabot has been added to the repo and should take care of putting up >>>>>> PRs for outdated dependencies. If that is an issue for any reason let me >>>>>> know, it is not too late to migrate those as well. >>>>>> >>>>>> On Fri, Jun 3, 2022 at 11:14 AM Danny McCormick >>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> Hey Hector, they were just enabled (thanks @Valentyn Tymofieiev for >>>>>>> merging the PR). >>>>>>> >>>>>>> The existing Jiras should be migrated throughout the rest of the day - >>>>>>> this will take a while due to GitHub rate limits, but it should >>>>>>> definitely be done by the end of the weekend (and I expect >>>>>>> significantly earlier). In the meantime, feel free to start opening >>>>>>> issues at https://github.com/apache/beam/issues, and let me know if you >>>>>>> see any issues with the migrated issues. >>>>>>> >>>>>>> Thanks, >>>>>>> Danny >>>>>>> >>>>>>> On Fri, Jun 3, 2022 at 10:42 AM Hector Miuler Malpica Gallegos >>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> When will github issues be enabled? I understood that it would be >>>>>>>> today >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hector Miuler Malpica Gallegos >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> El jue, 2 jun 2022 a la(s) 21:35, Hector Miuler Malpica Gallegos >>>>>>>> ([email protected]) escribió: >>>>>>>>> >>>>>>>>> >>>>>>>>> hahaha!!! excuse me, I'm thinking in the flink project when read the >>>>>>>>> last email, I do not know why. >>>>>>>>> >>>>>>>>> >>>>>>>>> Hector Miuler Malpica Gallegos >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> El jue, 2 jun 2022 a la(s) 18:04, Danny McCormick >>>>>>>>> ([email protected]) escribió: >>>>>>>>>> >>>>>>>>>> Thanks for calling that out Hector - the migration will only migrate >>>>>>>>>> issues from the Beam project (that one is from the Flink project), >>>>>>>>>> so I don't think it should be an issue. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Danny >>>>>>>>>> >>>>>>>>>> On Thu, Jun 2, 2022 at 6:38 PM Hector Miuler Malpica Gallegos >>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>> This migration includes the issues of the component `Kubernetes >>>>>>>>>>> Operator` ? like this issue FLINK-27820 ? this issues correspond to >>>>>>>>>>> the repository https://github.com/apache/flink-kubernetes-operator, >>>>>>>>>>> keep it in mind. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hector Miuler Malpica Gallegos >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> El jue, 2 jun 2022 a la(s) 12:33, Danny McCormick >>>>>>>>>>> ([email protected]) escribió: >>>>>>>>>>>> >>>>>>>>>>>> Given the consensus here, I updated the tool to do this. This >>>>>>>>>>>> means that we won't update the JIRAs to be read-only until after >>>>>>>>>>>> the migration is complete. I'll rerun the tool if any extra jiras >>>>>>>>>>>> come in during the intervening period. The tool will also still >>>>>>>>>>>> write the mapping to the file in case there are unforeseen issues >>>>>>>>>>>> so that we can backfill if needed. >>>>>>>>>>>> >>>>>>>>>>>> Thanks for the suggestion and followup Brian, Ahmet, and Alexey. >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Jun 2, 2022 at 12:16 PM Alexey Romanenko >>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> +1 That would be very helpful for mapping! >>>>>>>>>>>>> >>>>>>>>>>>>> On 2 Jun 2022, at 17:48, Ahmet Altay <[email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Is it possible to add comments on the JIRAs with a link to the >>>>>>>>>>>>> new corresponding github issue? >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Jun 2, 2022 at 8:47 AM Danny McCormick >>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for the feedback, I agree it would be good to keep that >>>>>>>>>>>>>> option open - I updated the tool to write those to a file when >>>>>>>>>>>>>> we create an issue. I'll share that after the migration. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Danny >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Jun 1, 2022 at 7:03 PM Brian Hulette >>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks Danny. Regarding links to GitHub issues, if we could at >>>>>>>>>>>>>>> least save off a record of jira <-> issue mappings we could >>>>>>>>>>>>>>> look at adding the links later. I think it would be nice to >>>>>>>>>>>>>>> have those links so that anyone landing in a jira through a >>>>>>>>>>>>>>> search or an old link can quickly find the current ticket, but >>>>>>>>>>>>>>> I don't think that needs to block the migration. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Jun 1, 2022 at 7:05 AM Danny McCormick >>>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hey Brian, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1. Right now, the plan is to (1) turn on the issues tab, (2) >>>>>>>>>>>>>>>> make the JIRA read only, (3) run the migration tool. Since the >>>>>>>>>>>>>>>> migration tool won't be run until after Jiras are read only, >>>>>>>>>>>>>>>> there shouldn't be issues with making sure everything gets >>>>>>>>>>>>>>>> captured. >>>>>>>>>>>>>>>> 2. That current ordering does mean it's difficult to add a >>>>>>>>>>>>>>>> link to the newly created Issue, and I hadn't built in that >>>>>>>>>>>>>>>> feature. With that said, I will ask Infra if they're able to >>>>>>>>>>>>>>>> put up a banner redirecting people to GitHub for the Beam >>>>>>>>>>>>>>>> project - that should hopefully minimize some of the issues - >>>>>>>>>>>>>>>> and I'll also look into updating the tool to do that in case >>>>>>>>>>>>>>>> the banner isn't doable. I'm also planning on doing a few >>>>>>>>>>>>>>>> passes to update our docs and code comments from Jiras to >>>>>>>>>>>>>>>> issues once the migration is done. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Danny >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, May 31, 2022 at 8:09 PM Brian Hulette >>>>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks Danny, it's great to see this happening! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> A couple of questions: >>>>>>>>>>>>>>>>> - Is there something we can do to remind people creating a >>>>>>>>>>>>>>>>> jira that they should create a bug instead (e.g. a template)? >>>>>>>>>>>>>>>>> If not I suppose we can just re-run the migration tool a few >>>>>>>>>>>>>>>>> times up until jira creation is disabled to make sure >>>>>>>>>>>>>>>>> everything is captured. >>>>>>>>>>>>>>>>> - Will your migration tooling comment on the original jira >>>>>>>>>>>>>>>>> with a link to the new issue in GitHub? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Brian >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Tue, May 31, 2022 at 9:57 AM Robert Bradshaw >>>>>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks for finally making this happen. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, May 31, 2022 at 7:18 AM Sachin Agarwal >>>>>>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thank you Danny! This will help us a lot, especially with >>>>>>>>>>>>>>>>>>> new contributors. Thanks so much! >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Tue, May 31, 2022 at 4:10 AM Danny McCormick >>>>>>>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hey folks, this is a reminder that we will be migrating >>>>>>>>>>>>>>>>>>>> from Jira to GitHub Issues this Friday (6/4). A few key >>>>>>>>>>>>>>>>>>>> details to keep in mind: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 1. All active Jiras will get automatically migrated and >>>>>>>>>>>>>>>>>>>> assigned over the course of the weekend. >>>>>>>>>>>>>>>>>>>> 2. Starting Friday (once the the Issues tab is open), >>>>>>>>>>>>>>>>>>>> please stop creating Jiras and start creating Issues >>>>>>>>>>>>>>>>>>>> instead. You should also reference issues in your PRs and >>>>>>>>>>>>>>>>>>>> commits instead of Jiras. The Jira creation flow will >>>>>>>>>>>>>>>>>>>> eventually be disabled. >>>>>>>>>>>>>>>>>>>> 3. If you encounter any issues that can't be resolved by >>>>>>>>>>>>>>>>>>>> looking at the doc updates, please let me know and/or >>>>>>>>>>>>>>>>>>>> follow up in this thread. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I'm looking forward to seeing how Issues can minimize >>>>>>>>>>>>>>>>>>>> friction for new contributors and I'm hopeful that this >>>>>>>>>>>>>>>>>>>> will be a smooth transition. If you have any last minute >>>>>>>>>>>>>>>>>>>> concerns let me know. For more context, see the original >>>>>>>>>>>>>>>>>>>> thread on this topic. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> Danny >>>>>>>>>>>>> >>>>>>>>>>>>> >>>
