> On 14. Dec 2024, at 18:16, Slawomir Jaranowski <s.jaranow...@gmail.com> wrote: > > On Fri, 13 Dec 2024 at 12:12, Gerd Aschemann <g...@aschemann.net> wrote: >> >> 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). >> > > We always have similar problems ... every time we will have a > duplicate issue, duplicate comments and so on ...
Well, I had the assumption, that once you migrate a project from Jira to GitHub (completely), the respective Jira project is set to read-only (no more changes possible, except perhaps for administrators). This would make GitHub the active issue asset and every work would be done there. And yes, that would be a reason to perform a complete migration (per project), not a partial one. Technically, Jira projects could also be archived, but then becoming more or less invisible, making a lot of links on the Internet immediately invalid besides other drawbacks. > >>> 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 >> > > > -- > Sławomir Jaranowski > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) +49/173/3264070 -- g...@aschemann.net -- http://www.aschemann.net
