I see some drawbacks Before opening a new issue, I would like to search for similar issues (and in particular if there are already solutions, workarcounds, more information about the environment etc.). Where should I search? First du a Jira search, then a GitHub search? If I find something in Jira, but it is not yet in GH, how could I refer to it? Put in some link to Jira in some new GH issue manually. This is not recognised by Jira, so linking between related issues in the two systems get lost). Well, you can build some GH Action around it, but its complicated and error prone as it is hard do formalize. If people ignore the hint in Jira that the issue was moved to GH and keep on commenting, things become inconsistent as this something like a split brain on issue level. Can this be prevented for single issues as soon as they are migrated, but left open for non-migrated Jira issues (I doubt that it is possible)? If a user or contributor wants to comment or work/elaborate on an issue which is not yet migrated they first might need to find/convince a committer to migrate it.
That said, I think partial migration (on issue-by-issue) could be semi-automated: Open a new GH issue with a particular template providing the Jira issue number. Then have a GH Action to perform the migration (and first check whether the issue is not yet migrated; then directly close the new issue as duplicate). > On 12. Dec 2024, at 12:05, Sylwester Lachiewicz <slachiew...@gmail.com> wrote: > > Yes, make sense - also +1 > > Sylwester > > czw., 12 gru 2024, 11:50 użytkownik Guillaume Nodet <gno...@apache.org> > napisał: > >> I'm also +1 on this way forward. >> >> Le jeu. 12 déc. 2024 à 10:58, Slawomir Jaranowski <s.jaranow...@gmail.com> >> a écrit : >> >>> Hi, >>> >>> On Thu, 12 Dec 2024 at 10:15, Christoph Läubrich <m...@laeubi-soft.de> >>> wrote: >>>> >>>> I just wanted to note with Eclipse moved form Bugzilla > Github it was >>>> done the following way: >>>> >>>> 1. We have had a script adding a comment to each open issue in Bugzilla >>>> like this [1] >>>> 2. Then each developer that finds an issue important enough has >> migrated >>>> it manually with a link to the old. >>> >>> This is also my favorite way :-) >>> - enable GitHub Issues in project >>> - we can add a comment to open issues by bulk operation in jira >>> - disable creating new issues in jira >>> - do it project by project ... >>> >>>> 3. Close the the Bugzilla with a link to github >>>> >>>> This was actually a good thing, as a lot of old stuff no one cared >>>> anymore about is not ported to github, and still people can see the >>>> "link" for relevant discussions and if anyone wants to pickup it can be >>>> done anytime later. >>>> >>>> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=502349#c11 >>>> >>>> Am 12.12.24 um 09:42 schrieb Olivier Lamy: >>>>> Agree too. >>>>> We can leave them open in Jira with a comment including the link to >>>>> the GH issue. >>>>> And if the people involved in the issue are really still interested >>>>> (few issues might be already fixed but we haven;t done triage because >>>>> it's too much work) they can participate in the GH issue. >>>>> Then we can have some tooling suh GHA stale [1] with some dedicated >>>>> parameters so this will cleanup some issues. >>>>> >>>>> Cheers >>>>> Olivier >>>>> >>>>> [1] https://github.com/actions/stale >>>>> >>>>> On Thu, 12 Dec 2024 at 02:41, Tamás Cservenák <ta...@cservenak.net> >>> wrote: >>>>>> >>>>>> Moving would exactly make things faster. This thread diverged quite >> a >>>>>> bit, but AFAIR the opener of this thread (or the other mail >> referenced >>>>>> by opener of this thread) is exactly about problems _with_ JIRA. >>>>>> >>>>>> And I also say leave them opened (migrate, leave them as they were >>>>>> left in JIRA). Not to close them. >>>>>> >>>>>> So migration would not be a waste, as JIRA is just an obstacle. In >>>>>> fact, this whole thread was started for that purpose (to migrate), >> and >>>>>> not to discuss "what should we do with a huge pile of open issues". >>>>>> >>>>>> Just migrate all, and leave it alone, as they were left for the last >>> 10 years. >>>>>> >>>>>> Thanks >>>>>> T >>>>>> >>>>>> On Wed, Dec 11, 2024 at 5:13 PM Elliotte Rusty Harold >>>>>> <elh...@ibiblio.org> wrote: >>>>>>> >>>>>>> Non PMC committees certainly can close jira issues. I do this all >>> the time. >>>>>>> >>>>>>> Also if we want to conserve volunteer time we should not spend time >>> moving >>>>>>> to GitHub. That’s extra work compared to simply continuing with >> jira. >>>>>>> Leaving a bug open costs nothing until someone is ready to address >>> it. >>>>>>> >>>>>>> On Wed, Dec 11, 2024 at 9:06 AM Tamás Cservenák < >> ta...@cservenak.net> >>> wrote: >>>>>>> >>>>>>>> Are you all sure this is how _an open source project having >>>>>>>> volunteers-only is supposed to work?_ (maybe better as: "spend >> it's >>>>>>>> scarce resources"?) >>>>>>>> >>>>>>>> As if we'd all be in some company, working on some company >> product, >>>>>>>> then yes, I agree wholeheartedly, this is "how things should be >>> done". >>>>>>>> >>>>>>>> But in reality, I see nobody out of those 17 active PMCs [1] (as >>>>>>>> committers have no karma to close issues AFAIK) who will do this. >>>>>>>> >>>>>>>> Moreover, spending resources on THIS (bookkeeping) than any OTHER >>>>>>>> effort is IMO waste. >>>>>>>> >>>>>>>> For example, who is testing Maven4, that is soon rc-2? As not >>> testing >>>>>>>> it will cause even more issues, that will result in even more >>>>>>>> bookkeeping... a devil's circle. >>>>>>>> >>>>>>>> IMO, we should "lump" migrate all and just move on, keep this pile >>>>>>>> open, and leave it rotting as it has been rotting so far. On GH at >>>>>>>> least committers could close issues as well. >>>>>>>> >>>>>>>> [1] >>>>>>>> >>> >> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-committers-stats.html >>>>>>>> >>>>>>>> My 5 cents. >>>>>>>> >>>>>>>> Thanks >>>>>>>> T >>>>>>>> >>>>>>>> On Wed, Dec 11, 2024 at 2:48 PM Maarten Mulders < >>> mthmuld...@apache.org> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On 11/12/2024 12:29, Elliotte Rusty Harold wrote: >>>>>>>>>> On Tue, Dec 10, 2024 at 5:10 PM Slawomir Jaranowski >>>>>>>>>> <s.jaranow...@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> On Tue, 10 Dec 2024 at 17:42, Sylwester Lachiewicz >>>>>>>>>>> <slachiew...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Michale proposed closing all issues that have not been active >>> for >>>>>>>> more >>>>>>>>>>>> than 3 years, so there will be less to maintain/migrate. >>>>>>>>>>> >>>>>>>>>>> Maybe we can limit the age during import. >>>>>>>>>>> Maybe we should make a decision for each project. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -10 >>>>>>>>>> >>>>>>>>>> When this was last proposed 5 years ago, I went through Jira and >>> made >>>>>>>>>> sure that every issue older than the cutoff date had some sort >> of >>>>>>>>>> recent activity so nothing was eligible for automatic closure. >> I'd >>>>>>>>>> rather not have to hack the process like this again. I routinely >>> find >>>>>>>>>> and sometimes fix bugs that go back to the oldest ones in JIra. >> If >>>>>>>>>> more devs spent more time triaging old bugs, they'd find more >> too. >>>>>>>>> >>>>>>>>> I agree with this! From a reporter point-of-view, it is extremely >>>>>>>>> demotivating to see a report that you wrote getting ignored for a >>> couple >>>>>>>>> of years only to be closed for "administration reasons". Don't do >>> this. >>>>>>>>> It made me stop contributing (by reporting issues) to a few >>> projects >>>>>>>>> already, because they basically didn't seem to care. >>>>>>>>> >>>>>>>>>> I'd also like to encourage people to deliberately close bugs >> that >>> are >>>>>>>>>> in fact invalid, unwise, or already fixed. Surprisingly often I >>> find a >>>>>>>>>> final comment from an active committer or PMC member that lays >>> out in >>>>>>>>>> detail how the bug has been addressed or why it shouldn't be >>>>>>>>>> addressed, but they have not pressed the button to close the >> bug. >>>>>>>>>> Please press the button. However, this needs to be done issue by >>>>>>>>>> issue, not as a bulk close of all issues older than some >> arbitrary >>>>>>>>>> date. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Rather do this. If we are sure something is not a bug, take the >>> time to >>>>>>>>> explain it and then close it. If the reporter thinks we're wrong, >>> they >>>>>>>>> can always re-open. Closing an issue with solid reasoning is much >>> better >>>>>>>>> than closing it because it was opened more than X years ago. >>>>>>>>> >>>>>>>>> >>>>>>>>> Maarten >>>>>>>>> >>>>>>>>> >>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>>>> >>>>>>>> >>>>>>>> >>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>>> >>>>>>>> -- >>>>>>> Elliotte Rusty Harold >>>>>>> elh...@ibiblio.org >>>>>> >>>>>> >> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>> >>> >>> -- >>> Sławomir Jaranowski >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >> >> -- >> ------------------------ >> Guillaume Nodet >> -- Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) +49/173/3264070 -- g...@aschemann.net -- http://www.aschemann.net
