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 ... > > 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
