Developers List
Subject: Re: GH issues and GH discussions
I am pretty sure if that happens (terms&conditions changes, GH not an
option), we have plenty of time to migrate.
The same has happened multiple times in the past: SourceForge, BerliOS,
Google Code...
Now it is ASF JIRA and maybe some day we wil
I am pretty sure if that happens (terms&conditions changes, GH not an
option), we have plenty of time to migrate.
The same has happened multiple times in the past: SourceForge, BerliOS,
Google Code...
Now it is ASF JIRA and maybe some day we will be migrating away from GitHub
Issues to something el
On Tue, 30 May 2023 at 01:44, Hervé Boutemy wrote:
>
> Le lundi 29 mai 2023, 13:50:58 CEST Karl Heinz Marbaise a écrit :
> > To fulfill the formalism (also have documented the decision here on the
> > ML) we should start simply a VOTE to get an in general decision about
> > moving to GH-issues to
On Mon, 29 May 2023 at 21:51, Karl Heinz Marbaise wrote:
>
> Hi,
>
> I would suggest to create an umbrella project like:
>
> apache-maven-project
>
> on github and make it the central starting point for users... to ask
> question (discussions) and optionally reroute them to the appropriate
> githu
On Tue, 30 May 2023 at 00:04, Gary Gregory wrote:
>
> GH has the notion of "projects". Can't we use that?
>
this is something very different. It's used to be a sort of project
version in where to add issues/PRs you want to be done to finalize the
project/version. (as an example look how it is use
Le lundi 29 mai 2023, 13:50:58 CEST Karl Heinz Marbaise a écrit :
> To fulfill the formalism (also have documented the decision here on the
> ML) we should start simply a VOTE to get an in general decision about
> moving to GH-issues to leave JIRA behind... (not about the details) that
> can be don
Hi,
On 29.05.23 15:50, Christoph Läubrich wrote:
I must confess "another central project" do not feels right:
1) there already is a "central" one everyone can easily find if
searching for "maven github": https://github.com/apache/maven/
That does not help here because that project is Maven it
GH has the notion of "projects". Can't we use that?
Gary
On Mon, May 29, 2023, 09:50 Christoph Läubrich wrote:
> I must confess "another central project" do not feels right:
>
> 1) there already is a "central" one everyone can easily find if
> searching for "maven github": https://github.com/ap
I must confess "another central project" do not feels right:
1) there already is a "central" one everyone can easily find if
searching for "maven github": https://github.com/apache/maven/
2) for "subprojects" its usually better to discuss things close where
the code is
Please note that some f
Hi,
On 29.05.23 14:07, Michael Osipov wrote:
Am 2023-05-29 um 13:50 schrieb Karl Heinz Marbaise:
Hi,
I would suggest to create an umbrella project like:
apache-maven-project
on github and make it the central starting point for users... to ask
question (discussions) and optionally reroute them
Am 2023-05-29 um 13:50 schrieb Karl Heinz Marbaise:
Hi,
I would suggest to create an umbrella project like:
apache-maven-project
on github and make it the central starting point for users... to ask
question (discussions) and optionally reroute them to the appropriate
github repos...
In gener
Hi,
I would suggest to create an umbrella project like:
apache-maven-project
on github and make it the central starting point for users... to ask
question (discussions) and optionally reroute them to the appropriate
github repos...
In general I agree to the tendency to use GH issues etc. inst
On Sun, 28 May 2023 at 04:53, Michael Osipov wrote:
>
> Am 2023-05-27 um 12:10 schrieb Tamás Cservenák:
> > Howdy,
> >
> > I do agree with Lukasz here...but
> >
> > In general, my intention with bringing up this on Slack was motivated by
> > following reasons:
> > - we do have ML (signup needed),
tinue to assume coding takes no time.
-Original Message-
From: Michael Osipov
Sent: Saturday, May 27, 2023 4:31 PM
To: dev@maven.apache.org
Subject: Re: GH issues and GH discussions
Am 2023-05-27 um 22:21 schrieb Jeremy Landis:
> Not sure if was mentioned. Spring moved all their legacy
Am 2023-05-27 um 22:21 schrieb Jeremy Landis:
Not sure if was mentioned. Spring moved all their legacy Jira for all their
projects entirely to GitHub Issues. Believe it was done with everything.
https://spring.io/blog/2019/01/15/spring-framework-s-migration-from-jira-to-github-issues
Now con
ernatives due to complexity. This was true of the old hosting sites too, old
days were very hard to be casual contributor. The easier it is, the more
likely more contributors are engaged.
-Original Message-
From: Michael Osipov
Sent: Saturday, May 27, 2023 2:53 PM
To: dev@m
Am 2023-05-27 um 12:10 schrieb Tamás Cservenák:
Howdy,
I do agree with Lukasz here...but
In general, my intention with bringing up this on Slack was motivated by
following reasons:
- we do have ML (signup needed),
- we do have JIRA (ask + approval + signup needed),
But all this is a high barri
I am +1 to move to GH issues.
In Apache BookKeeper and Pulsar we had a script that did the migration
pretty seamlessly and I used that script also for other OSS projects
outside of the ASF. (I can't find it now, but it should be buried in some
git repo somewhere)
Enrico
Il Sab 27 Mag 2023, 13:02
> It occurs to me that not that long ago, Jira used to be open signup.
> is there a specific reason it changed? Does that reason still apply?
It's still open and self-serving at [1]. Just need one more moderate step
from committers or PMC members. To reduce spam, yes.
Best,
tison.
[1] https://se
So much spam got into jira, it had to be locked down. You should see the
junk I mod out of the Xalan lists...
Gary
On Sat, May 27, 2023, 06:55 Elliotte Rusty Harold
wrote:
> On Sat, May 27, 2023 at 6:11 AM Tamás Cservenák
> wrote:
>
> > In general, my intention with bringing up this on Slack w
How does StackOverflow fit in if at all? Any pros and cons to share?
Gary
On Sat, May 27, 2023, 06:43 tison wrote:
> > single point of entrance
>
> One last comment - it's a maintainer strategy to reduce the burden of
> monitoring multiple channels, and users generally gather to where their
> q
On Sat, May 27, 2023 at 6:11 AM Tamás Cservenák wrote:
> In general, my intention with bringing up this on Slack was motivated by
> following reasons:
> - we do have ML (signup needed),
> - we do have JIRA (ask + approval + signup needed),
>
Good points all around.
It occurs to me that not tha
> single point of entrance
One last comment - it's a maintainer strategy to reduce the burden of
monitoring multiple channels, and users generally gather to where their
questions can be answered. But it's not a user strategy; they ask on the
platform they are used to or closest to where the issue
I agree with Tamas' suggestion about the single point of entrance. Here are
several examples I experienced:
1. Apache SkyWalking[1] uses a single GH Issue to track all its issues and
Discussions for user questions and some rough ideas.
2. Apache Pulsar[2] (I'm one of its committers) uses multiple
As a Maven user experiencing finding issue tracker recently[1][2], here are
my two coins:
1. GitHub Issues help to get issues reported at the exact code repo.
I found a usage question for ASF parent pom and find the code repo at[3],
no GitHub Issues and I jump to the linked JIRA project MPOM, whi
Howdy,
I do agree with Lukasz here...but
In general, my intention with bringing up this on Slack was motivated by
following reasons:
- we do have ML (signup needed),
- we do have JIRA (ask + approval + signup needed),
But all this is a high barrier for "one off" users, many of our users want
to
I have no strong feelings, however relying too much on single service
vendor is never a good idea. In this case if one day, by some
terms&condition changes, github repos are not an option any more, we are
fine with ASF infrastructure. But we can't do same thing for issues
which are embedded in
Le vendredi 26 mai 2023, 19:41:53 CEST Benjamin Marwell a écrit :
> Big +1, as more and more projects are already migrating (including Apache
> Shiro).
>
> I'd vote for maven-jlink-plugin: Not many issues currently.
>
> > not having to create an issue if a PR exists first
>
> I'd at least make m
on testing GH issues migration from Jira: yes
cache-extension [1] looks like an interesting example, given it has a small
history with its Jira content
we also have mvnd which uses GH issues from the start: testing and making
clear practices on release and release notes could also be worked ther
Big +1, as more and more projects are already migrating (including Apache
Shiro).
I'd vote for maven-jlink-plugin: Not many issues currently.
> not having to create an issue if a PR exists first
I'd at least make milestones mandatory in that case.
It is far less work than maintaining an issue.
30 matches
Mail list logo
