Hi,
thank you for your summary, which contains every argument I think.
I'm with you and ask for a vote. We all know by the req. Java version
discussion where this will lead if we don't do this (seenoevil)
Am 15.12.2024 um 19:11 schrieb Slawomir Jaranowski:
Hi,
I try summary our discussion about Switch issues to GitHub, so:
At beginning we have a propositions:
1/ try to migrate issues and make JIRA read only
2/ make all our JIRA projects unable to create new issues and new
issues would be raised on GH
3/ do not change JIRA but slowly switch to GH
I see:
- it will be a difficult to do it in all project at one time, so we
need switching one by one
- ASF jira instance will be available for long time - so migration of
all issues is not required for switching
- cleanups issues, backlog must be done manually, issues should be not
closed automatically only depends on age
- migration tools - Sandra work on it - thanks - so we can use for
project that migration will be really needed
I see that the best will be option 2 - but do it one by one, enable
GitHub issue, disable of creating new in jira
We can continue such discussions for a very long time without making
everybody happy.
I would like to start a general vote about switching issues to GitHub.
If passed we can make a decision one by one on how specific projects
should be switched - with or without migration.
We also should approve simple rules for how we want to work with GitHub issues.
https://github.com/apache/maven-site/pull/588
I know that some of the tasks can be automated ... but if we will
discuss forever we will not go forward.
After it we can switch some of the simple projects and we will see how
it works and what should be improved.
On Sat, 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 ...
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
