You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Olivier Lamy <ol...@apache.org> on 2023/05/26 07:44:00 UTC
GH issues and GH discussions
Hi,
This has been already discussed in the past.
But due to recent changes in ASF Jira infrastructure (limitation of
Jira users, validation of account creation).
Maybe we could reconsider moving from Jira to GH issues and why not
simplify the workflow as well.
I imagine not having to create an issue if a PR exists first (sounds
like duplicate work).
By the way, release notes will be automatically created from PRs.
(could be manually modified if a change doesn't have a PR).
Regarding migration, we can start project by project.
Few options:
- extreme simplicity, do not migrate any data (just mark the Jira
project as read only with a banner/link to corresponding gh issues).
If someone really needs an issue to get fixed he will clone it to GH
- middle complexity, migrate only open issues (components moved as a label)
- extreme complexity, migrate all issues of a project (components
moved as a label and version created)
We can start by small projects such as cache-extension and one plugin
(compiler?)
Regarding GH discussions, maybe we can open discussions for
https://github.com/apache/maven which sounds like a natural place for
users to go. (discussions could be mirrored to a ML)
I do not have a strong opinion here, but I feel like opening
discussions for every single repo will be complicated to follow up.
WDYT?
cheers
Olivier
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: GH issues and GH discussions
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi all,
I really like GH issues and discussions ... they lower the bar for contribution quite a bit and feel a lot more inviting for newer contributors. At least have we seen a significant increase in contributions since we switched to GH Issues and are currently starting to use GH Discussions in PLC4X.
And I should mention that I just recently had an Apache Infra PR of mine merged, which make it possible to format the subjects of the auto-generated GH emails to make them usable in normal email clients (Pior to that merge, the GH Discusssion emails were not configurable)
I documented the settings we use quite successfully in PLC4X and StreamPipes here:
https://github.com/apache/comdev-site/blob/main/source/contributors/mailing-lists.md
Hope that helps,
Chrs
________________________________
From: Benjamin Marwell <bm...@apache.org>
Sent: Tuesday, May 30, 2023 5:04:51 PM
To: Maven Developers List <de...@maven.apache.org>
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 will be migrating away from GitHub
Issues to something else?
But even then, there will be an archive and there will be a migration tool.
None of the above migrations
lost any data AFAIK.
Am Sa., 27. Mai 2023 um 11:24 Uhr schrieb Łukasz Dywicki <
luke@code-house.org>:
> 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 GH database. If you ever found a google code
> project migrated into github/gitlab issues you know what I mean.
>
> While policies imposed on JIRA account creation, are without doubt a
> bearer to contribute first bug report, JIRA itself helps us keeping all
> ASF information together. Just to be clear - I keep being lost with new
> JIRA user interface, I'm just reflecting my personal thoughts.
>
> Best,
> Łukasz
>
>
Re: GH issues and GH discussions
Posted by Benjamin Marwell <bm...@apache.org>.
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 else?
But even then, there will be an archive and there will be a migration tool.
None of the above migrations
lost any data AFAIK.
Am Sa., 27. Mai 2023 um 11:24 Uhr schrieb Łukasz Dywicki <
luke@code-house.org>:
> 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 GH database. If you ever found a google code
> project migrated into github/gitlab issues you know what I mean.
>
> While policies imposed on JIRA account creation, are without doubt a
> bearer to contribute first bug report, JIRA itself helps us keeping all
> ASF information together. Just to be clear - I keep being lost with new
> JIRA user interface, I'm just reflecting my personal thoughts.
>
> Best,
> Łukasz
>
>
Re: GH issues and GH discussions
Posted by Gary Gregory <ga...@gmail.com>.
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 <el...@ibiblio.org>
wrote:
> On Sat, May 27, 2023 at 6:11 AM Tamás Cservenák <ta...@cservenak.net>
> 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 that long ago, Jira used to be open signup.
> is there a specific reason it changed? Does that reason still apply?
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: GH issues and GH discussions
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Sat, May 27, 2023 at 6:11 AM Tamás Cservenák <ta...@cservenak.net> 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 that long ago, Jira used to be open signup.
is there a specific reason it changed? Does that reason still apply?
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: GH issues and GH discussions
Posted by Enrico Olivelli <eo...@gmail.com>.
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 tison <wa...@gmail.com> ha scritto:
> > 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://selfserve.apache.org/jira-account.html
>
>
> Gary Gregory <ga...@gmail.com> 于2023年5月27日周六 18:55写道：
>
> > How does StackOverflow fit in if at all? Any pros and cons to share?
> >
> > Gary
> >
> > On Sat, May 27, 2023, 06:43 tison <wa...@gmail.com> 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
> > > 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 happens.
> > >
> > > So we may not say "a specific channel is _not_ supported, you should
> not
> > > ask there", but "most of the critical mass answering questions on
> > platform
> > > X". Users make their choice reflected to where the critical mass work
> > > instead of being forced there.
> > >
> > > Best,
> > > tison.
> > >
> > >
> > > tison <wa...@gmail.com> 于2023年5月27日周六 18:36写道：
> > >
> > > > 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 GH
> Issues
> > > > for different repos, while for the tightly coupled site repo[3], I
> > merge
> > > > the Issue tracker to the main repo. Single Discussions instance for
> all
> > > > "Pulsar" related questions.
> > > > 3. Apache Flink[3] (I'm one of its committers) uses a single JIRA
> > project
> > > > for all its repos issue trackers, and only user@ and user-zh@
> mailing
> > > > lists for user questions. Given their high responsiveness, it works
> > well
> > > > for most of its users. Although other unofficial channels (with PMC
> > > members
> > > > there) (like DingTalk group or Slack workspace) exist to answer
> > > questions,
> > > > most users can be guided to the mailing list since it's still the
> most
> > > > active channel.
> > > >
> > > > Maven has a more complex repo cluster[4], and decisions can differ.
> > > >
> > > > Best,
> > > > tison.
> > > >
> > > > [1] https://github.com/apache/skywalking
> > > > [2] http://github.com/apache/pulsar
> > > > [3] http://github.com/apache/pulsar-site
> > > > [4] https://maven.apache.org/scm.html
> > > >
> > > >
> > > > tison <wa...@gmail.com> 于2023年5月27日周六 18:28写道：
> > > >
> > > >> 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, while
> the
> > > >> maintainer tells me it's not the correct place.
> > > >>
> > > >> I'm familiar with the mailing list way so it's not quite a trouble
> to
> > > ask
> > > >> here. But as time goes on, more and more developers and users get
> used
> > > to
> > > >> the GitHub platform. No matter if it's a good thing, it's a fact[4].
> > > >>
> > > >> So, for lowering the bar for user participation, I agree we can give
> > GH
> > > >> issues and GH discussions a try.
> > > >>
> > > >> 2. GitHub is a proprietary service that is unreliable in an
> > > >> organization's view.
> > > >>
> > > >> I agree.
> > > >>
> > > >> Part of them can be resolved by we sync all traffic back to an ASF
> > > >> mailing list, like most of the ASF projects I participated in[5]. We
> > can
> > > >> thus archive most of the context but since they are for archiving
> > only,
> > > the
> > > >> readability can be bad.
> > > >>
> > > >> To sum up, as new generation developers and users grow and they are
> > more
> > > >> familiar with the GitHub platform, before we find a competitor to
> > > compare
> > > >> with, and since we can more or less sync the conversation back to
> ASF
> > > >> INFRA, I'm +1 for giving GH issue and GH discussion a chance.
> > > >>
> > > >> But, in the other hand, if we can link the JIRA project and the code
> > > repo
> > > >> properly, given that our mailing list's and JIRA's responsiveness is
> > > high,
> > > >> it's good enough for me that we use GH PR for the patching process
> > only,
> > > >> keep issues on JIRA and make most significant discussion on the
> > mailing
> > > >> list only. While, GH discussions is a net win as a user forum just
> > like
> > > a
> > > >> stack overflow tag - we can ensure no development decision is made
> > there
> > > >> and everything is back to the mailing list.
> > > >>
> > > >> Best,
> > > >> tison.
> > > >>
> > > >> [1] https://issues.apache.org/jira/browse/MPOM-418
> > > >> [2]
> https://lists.apache.org/thread/t1f5wws6o4moy0p9kt4726ng5tsgzgln
> > > >> [3] https://github.com/apache/maven-apache-parent
> > > >>
> > > >> [4] https://www.goodreads.com/en/book/show/54140556
> > > >>
> > > >> [5]
> > > >>
> > >
> >
> https://github.com/apache/pulsar/blob/a953027aad38c9f54e952133949280ec2f4c04e8/.asf.yaml#L84-L88
> > > >>
> > > >>
> > > >> Tamás Cservenák <ta...@cservenak.net> 于2023年5月27日周六 18:10写道：
> > > >>
> > > >>> 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 ASK us about something, so going through hoops and loops above
> > (and
> > > >>> coming back 2 yr after with "please unsub me...") only to post a
> > > question
> > > >>> is just a very bad experience.
> > > >>>
> > > >>> Moreover, we are very fragmented repository-wide, and I bet that a
> > > novice
> > > >>> user will simply be lost:
> > > >>> - WHERE (as in which Maven-* GH repo) to ask
> > > >>> - WHERE (as in which Maven-* GH repo) to report issue
> > > >>> - etc
> > > >>>
> > > >>> This is why I recommended "single entry point", a kind of
> dispatcher
> > > >>> (discussion) repo/GH project, where one off users can hop on, ASK
> > > things
> > > >>> and disappear if they like, receive answers where to go, and so on.
> > And
> > > >>> if
> > > >>> they feel like it, they could join ML or register to JIRA,
> something
> > > >>> TODAY
> > > >>> EVERYONE WHO WANTS TO REACH OUT TO US must do. Hence, most "one off
> > > >>> askers"
> > > >>> would not go so far even.
> > > >>>
> > > >>> For me, most reasonable would be a new "discussion only" project,
> for
> > > >>> example "apache/maven-project" on GH, that would contain no source,
> > no
> > > >>> issues, only discussions enabled and would serve as a "low barrier
> > > lobby"
> > > >>> for newcomers.
> > > >>>
> > > >>> Opening discussions in _existing repository_ is unwise IMHO, as
> > > "general"
> > > >>> discussions/questions do not belong to apache/maven, nor
> > > >>> apache/maven-clean-plugin, nor any other existing repo.
> > > >>>
> > > >>> Thanks
> > > >>> T
> > > >>>
> > > >>> On Sat, May 27, 2023 at 11:24 AM Łukasz Dywicki <
> luke@code-house.org
> > >
> > > >>> wrote:
> > > >>>
> > > >>> > 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 GH database. If you ever found a google
> code
> > > >>> > project migrated into github/gitlab issues you know what I mean.
> > > >>> >
> > > >>> > While policies imposed on JIRA account creation, are without
> doubt
> > a
> > > >>> > bearer to contribute first bug report, JIRA itself helps us
> keeping
> > > all
> > > >>> > ASF information together. Just to be clear - I keep being lost
> with
> > > new
> > > >>> > JIRA user interface, I'm just reflecting my personal thoughts.
> > > >>> >
> > > >>> > Best,
> > > >>> > Łukasz
> > > >>> >
> > > >>> > On 27.05.2023 09:30, Hervé Boutemy wrote:
> > > >>> > > 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 milestones mandatory in that case.
> > > >>> > > AFAIK, GH Milestones are useful when you want to assign an
> issue
> > > >>> that is
> > > >>> > not
> > > >>> > > yet fixed
> > > >>> > > see for example
> https://github.com/apache/maven-mvnd/milestones
> > > >>> > >
> > > >>> > > But it does not seem absolutely necessary, since GH Release
> Notes
> > > >>> will
> > > >>> > get the
> > > >>> > > release content once the issue is fixed
> > > >>> > > example: https://github.com/apache/maven-mvnd/releases
> > > >>> > >
> > > >>> > > We'll need to define which GH Labels are available, and how the
> > > >>> release
> > > >>> > notes
> > > >>> > > drafter use it to have better release notes
> > > >>> > > https://github.com/apache/maven-mvnd/labels
> > > >>> > >
> > > >>> > >> It is far less work than maintaining an issue.
> > > >>> > >>
> > > >>> > >> Am Fr., 26. Mai 2023 um 09:44 Uhr schrieb Olivier Lamy <
> > > >>> > olamy@apache.org>:
> > > >>> > >>> Hi,
> > > >>> > >>> This has been already discussed in the past.
> > > >>> > >>> But due to recent changes in ASF Jira infrastructure
> > (limitation
> > > of
> > > >>> > >>> Jira users, validation of account creation).
> > > >>> > >>> Maybe we could reconsider moving from Jira to GH issues and
> why
> > > not
> > > >>> > >>> simplify the workflow as well.
> > > >>> > >>> I imagine not having to create an issue if a PR exists first
> > > >>> (sounds
> > > >>> > >>> like duplicate work).
> > > >>> > >>> By the way, release notes will be automatically created from
> > PRs.
> > > >>> > >>> (could be manually modified if a change doesn't have a PR).
> > > >>> > >>>
> > > >>> > >>> Regarding migration, we can start project by project.
> > > >>> > >>> Few options:
> > > >>> > >>> - extreme simplicity, do not migrate any data (just mark the
> > Jira
> > > >>> > >>> project as read only with a banner/link to corresponding gh
> > > >>> issues).
> > > >>> > >>> If someone really needs an issue to get fixed he will clone
> it
> > to
> > > >>> GH
> > > >>> > >>> - middle complexity, migrate only open issues (components
> moved
> > > as
> > > >>> a
> > > >>> > >>> label)
> > > >>> > >>> - extreme complexity, migrate all issues of a project
> > (components
> > > >>> > >>> moved as a label and version created)
> > > >>> > >>>
> > > >>> > >>> We can start by small projects such as cache-extension and
> one
> > > >>> plugin
> > > >>> > >>> (compiler?)
> > > >>> > >>>
> > > >>> > >>> Regarding GH discussions, maybe we can open discussions for
> > > >>> > >>> https://github.com/apache/maven which sounds like a natural
> > > place
> > > >>> for
> > > >>> > >>> users to go. (discussions could be mirrored to a ML)
> > > >>> > >>> I do not have a strong opinion here, but I feel like opening
> > > >>> > >>> discussions for every single repo will be complicated to
> follow
> > > up.
> > > >>> > >>>
> > > >>> > >>> WDYT?
> > > >>> > >>>
> > > >>> > >>> cheers
> > > >>> > >>> Olivier
> > > >>> > >>>
> > > >>> > >>>
> > > >>>
> ---------------------------------------------------------------------
> > > >>> > >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > >>> > >>> For additional commands, e-mail: dev-help@maven.apache.org
> > > >>> > >
> > > >>> > >
> > > >>> > >
> > > >>> > >
> > > >>> > >
> > > >>> > >
> > > ---------------------------------------------------------------------
> > > >>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > >>> > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >>> > >
> > > >>> >
> > > >>> >
> > ---------------------------------------------------------------------
> > > >>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > >>> > For additional commands, e-mail: dev-help@maven.apache.org
> > > >>> >
> > > >>> >
> > > >>>
> > > >>
> > >
> >
>
Re: GH issues and GH discussions
Posted by tison <wa...@gmail.com>.
> 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://selfserve.apache.org/jira-account.html
Gary Gregory <ga...@gmail.com> 于2023年5月27日周六 18:55写道：
> How does StackOverflow fit in if at all? Any pros and cons to share?
>
> Gary
>
> On Sat, May 27, 2023, 06:43 tison <wa...@gmail.com> 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
> > 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 happens.
> >
> > So we may not say "a specific channel is _not_ supported, you should not
> > ask there", but "most of the critical mass answering questions on
> platform
> > X". Users make their choice reflected to where the critical mass work
> > instead of being forced there.
> >
> > Best,
> > tison.
> >
> >
> > tison <wa...@gmail.com> 于2023年5月27日周六 18:36写道：
> >
> > > 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 GH Issues
> > > for different repos, while for the tightly coupled site repo[3], I
> merge
> > > the Issue tracker to the main repo. Single Discussions instance for all
> > > "Pulsar" related questions.
> > > 3. Apache Flink[3] (I'm one of its committers) uses a single JIRA
> project
> > > for all its repos issue trackers, and only user@ and user-zh@ mailing
> > > lists for user questions. Given their high responsiveness, it works
> well
> > > for most of its users. Although other unofficial channels (with PMC
> > members
> > > there) (like DingTalk group or Slack workspace) exist to answer
> > questions,
> > > most users can be guided to the mailing list since it's still the most
> > > active channel.
> > >
> > > Maven has a more complex repo cluster[4], and decisions can differ.
> > >
> > > Best,
> > > tison.
> > >
> > > [1] https://github.com/apache/skywalking
> > > [2] http://github.com/apache/pulsar
> > > [3] http://github.com/apache/pulsar-site
> > > [4] https://maven.apache.org/scm.html
> > >
> > >
> > > tison <wa...@gmail.com> 于2023年5月27日周六 18:28写道：
> > >
> > >> 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, while the
> > >> maintainer tells me it's not the correct place.
> > >>
> > >> I'm familiar with the mailing list way so it's not quite a trouble to
> > ask
> > >> here. But as time goes on, more and more developers and users get used
> > to
> > >> the GitHub platform. No matter if it's a good thing, it's a fact[4].
> > >>
> > >> So, for lowering the bar for user participation, I agree we can give
> GH
> > >> issues and GH discussions a try.
> > >>
> > >> 2. GitHub is a proprietary service that is unreliable in an
> > >> organization's view.
> > >>
> > >> I agree.
> > >>
> > >> Part of them can be resolved by we sync all traffic back to an ASF
> > >> mailing list, like most of the ASF projects I participated in[5]. We
> can
> > >> thus archive most of the context but since they are for archiving
> only,
> > the
> > >> readability can be bad.
> > >>
> > >> To sum up, as new generation developers and users grow and they are
> more
> > >> familiar with the GitHub platform, before we find a competitor to
> > compare
> > >> with, and since we can more or less sync the conversation back to ASF
> > >> INFRA, I'm +1 for giving GH issue and GH discussion a chance.
> > >>
> > >> But, in the other hand, if we can link the JIRA project and the code
> > repo
> > >> properly, given that our mailing list's and JIRA's responsiveness is
> > high,
> > >> it's good enough for me that we use GH PR for the patching process
> only,
> > >> keep issues on JIRA and make most significant discussion on the
> mailing
> > >> list only. While, GH discussions is a net win as a user forum just
> like
> > a
> > >> stack overflow tag - we can ensure no development decision is made
> there
> > >> and everything is back to the mailing list.
> > >>
> > >> Best,
> > >> tison.
> > >>
> > >> [1] https://issues.apache.org/jira/browse/MPOM-418
> > >> [2] https://lists.apache.org/thread/t1f5wws6o4moy0p9kt4726ng5tsgzgln
> > >> [3] https://github.com/apache/maven-apache-parent
> > >>
> > >> [4] https://www.goodreads.com/en/book/show/54140556
> > >>
> > >> [5]
> > >>
> >
> https://github.com/apache/pulsar/blob/a953027aad38c9f54e952133949280ec2f4c04e8/.asf.yaml#L84-L88
> > >>
> > >>
> > >> Tamás Cservenák <ta...@cservenak.net> 于2023年5月27日周六 18:10写道：
> > >>
> > >>> 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 ASK us about something, so going through hoops and loops above
> (and
> > >>> coming back 2 yr after with "please unsub me...") only to post a
> > question
> > >>> is just a very bad experience.
> > >>>
> > >>> Moreover, we are very fragmented repository-wide, and I bet that a
> > novice
> > >>> user will simply be lost:
> > >>> - WHERE (as in which Maven-* GH repo) to ask
> > >>> - WHERE (as in which Maven-* GH repo) to report issue
> > >>> - etc
> > >>>
> > >>> This is why I recommended "single entry point", a kind of dispatcher
> > >>> (discussion) repo/GH project, where one off users can hop on, ASK
> > things
> > >>> and disappear if they like, receive answers where to go, and so on.
> And
> > >>> if
> > >>> they feel like it, they could join ML or register to JIRA, something
> > >>> TODAY
> > >>> EVERYONE WHO WANTS TO REACH OUT TO US must do. Hence, most "one off
> > >>> askers"
> > >>> would not go so far even.
> > >>>
> > >>> For me, most reasonable would be a new "discussion only" project, for
> > >>> example "apache/maven-project" on GH, that would contain no source,
> no
> > >>> issues, only discussions enabled and would serve as a "low barrier
> > lobby"
> > >>> for newcomers.
> > >>>
> > >>> Opening discussions in _existing repository_ is unwise IMHO, as
> > "general"
> > >>> discussions/questions do not belong to apache/maven, nor
> > >>> apache/maven-clean-plugin, nor any other existing repo.
> > >>>
> > >>> Thanks
> > >>> T
> > >>>
> > >>> On Sat, May 27, 2023 at 11:24 AM Łukasz Dywicki <luke@code-house.org
> >
> > >>> wrote:
> > >>>
> > >>> > 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 GH database. If you ever found a google code
> > >>> > project migrated into github/gitlab issues you know what I mean.
> > >>> >
> > >>> > While policies imposed on JIRA account creation, are without doubt
> a
> > >>> > bearer to contribute first bug report, JIRA itself helps us keeping
> > all
> > >>> > ASF information together. Just to be clear - I keep being lost with
> > new
> > >>> > JIRA user interface, I'm just reflecting my personal thoughts.
> > >>> >
> > >>> > Best,
> > >>> > Łukasz
> > >>> >
> > >>> > On 27.05.2023 09:30, Hervé Boutemy wrote:
> > >>> > > 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 milestones mandatory in that case.
> > >>> > > AFAIK, GH Milestones are useful when you want to assign an issue
> > >>> that is
> > >>> > not
> > >>> > > yet fixed
> > >>> > > see for example https://github.com/apache/maven-mvnd/milestones
> > >>> > >
> > >>> > > But it does not seem absolutely necessary, since GH Release Notes
> > >>> will
> > >>> > get the
> > >>> > > release content once the issue is fixed
> > >>> > > example: https://github.com/apache/maven-mvnd/releases
> > >>> > >
> > >>> > > We'll need to define which GH Labels are available, and how the
> > >>> release
> > >>> > notes
> > >>> > > drafter use it to have better release notes
> > >>> > > https://github.com/apache/maven-mvnd/labels
> > >>> > >
> > >>> > >> It is far less work than maintaining an issue.
> > >>> > >>
> > >>> > >> Am Fr., 26. Mai 2023 um 09:44 Uhr schrieb Olivier Lamy <
> > >>> > olamy@apache.org>:
> > >>> > >>> Hi,
> > >>> > >>> This has been already discussed in the past.
> > >>> > >>> But due to recent changes in ASF Jira infrastructure
> (limitation
> > of
> > >>> > >>> Jira users, validation of account creation).
> > >>> > >>> Maybe we could reconsider moving from Jira to GH issues and why
> > not
> > >>> > >>> simplify the workflow as well.
> > >>> > >>> I imagine not having to create an issue if a PR exists first
> > >>> (sounds
> > >>> > >>> like duplicate work).
> > >>> > >>> By the way, release notes will be automatically created from
> PRs.
> > >>> > >>> (could be manually modified if a change doesn't have a PR).
> > >>> > >>>
> > >>> > >>> Regarding migration, we can start project by project.
> > >>> > >>> Few options:
> > >>> > >>> - extreme simplicity, do not migrate any data (just mark the
> Jira
> > >>> > >>> project as read only with a banner/link to corresponding gh
> > >>> issues).
> > >>> > >>> If someone really needs an issue to get fixed he will clone it
> to
> > >>> GH
> > >>> > >>> - middle complexity, migrate only open issues (components moved
> > as
> > >>> a
> > >>> > >>> label)
> > >>> > >>> - extreme complexity, migrate all issues of a project
> (components
> > >>> > >>> moved as a label and version created)
> > >>> > >>>
> > >>> > >>> We can start by small projects such as cache-extension and one
> > >>> plugin
> > >>> > >>> (compiler?)
> > >>> > >>>
> > >>> > >>> Regarding GH discussions, maybe we can open discussions for
> > >>> > >>> https://github.com/apache/maven which sounds like a natural
> > place
> > >>> for
> > >>> > >>> users to go. (discussions could be mirrored to a ML)
> > >>> > >>> I do not have a strong opinion here, but I feel like opening
> > >>> > >>> discussions for every single repo will be complicated to follow
> > up.
> > >>> > >>>
> > >>> > >>> WDYT?
> > >>> > >>>
> > >>> > >>> cheers
> > >>> > >>> Olivier
> > >>> > >>>
> > >>> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> > >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >>> > >>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>> > >
> > >>> > >
> > >>> > >
> > >>> > >
> > >>> > >
> > >>> > >
> > ---------------------------------------------------------------------
> > >>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >>> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >>> > >
> > >>> >
> > >>> >
> ---------------------------------------------------------------------
> > >>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >>> > For additional commands, e-mail: dev-help@maven.apache.org
> > >>> >
> > >>> >
> > >>>
> > >>
> >
>
Re: GH issues and GH discussions
Posted by Gary Gregory <ga...@gmail.com>.
How does StackOverflow fit in if at all? Any pros and cons to share?
Gary
On Sat, May 27, 2023, 06:43 tison <wa...@gmail.com> 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
> 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 happens.
>
> So we may not say "a specific channel is _not_ supported, you should not
> ask there", but "most of the critical mass answering questions on platform
> X". Users make their choice reflected to where the critical mass work
> instead of being forced there.
>
> Best,
> tison.
>
>
> tison <wa...@gmail.com> 于2023年5月27日周六 18:36写道：
>
> > 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 GH Issues
> > for different repos, while for the tightly coupled site repo[3], I merge
> > the Issue tracker to the main repo. Single Discussions instance for all
> > "Pulsar" related questions.
> > 3. Apache Flink[3] (I'm one of its committers) uses a single JIRA project
> > for all its repos issue trackers, and only user@ and user-zh@ mailing
> > lists for user questions. Given their high responsiveness, it works well
> > for most of its users. Although other unofficial channels (with PMC
> members
> > there) (like DingTalk group or Slack workspace) exist to answer
> questions,
> > most users can be guided to the mailing list since it's still the most
> > active channel.
> >
> > Maven has a more complex repo cluster[4], and decisions can differ.
> >
> > Best,
> > tison.
> >
> > [1] https://github.com/apache/skywalking
> > [2] http://github.com/apache/pulsar
> > [3] http://github.com/apache/pulsar-site
> > [4] https://maven.apache.org/scm.html
> >
> >
> > tison <wa...@gmail.com> 于2023年5月27日周六 18:28写道：
> >
> >> 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, while the
> >> maintainer tells me it's not the correct place.
> >>
> >> I'm familiar with the mailing list way so it's not quite a trouble to
> ask
> >> here. But as time goes on, more and more developers and users get used
> to
> >> the GitHub platform. No matter if it's a good thing, it's a fact[4].
> >>
> >> So, for lowering the bar for user participation, I agree we can give GH
> >> issues and GH discussions a try.
> >>
> >> 2. GitHub is a proprietary service that is unreliable in an
> >> organization's view.
> >>
> >> I agree.
> >>
> >> Part of them can be resolved by we sync all traffic back to an ASF
> >> mailing list, like most of the ASF projects I participated in[5]. We can
> >> thus archive most of the context but since they are for archiving only,
> the
> >> readability can be bad.
> >>
> >> To sum up, as new generation developers and users grow and they are more
> >> familiar with the GitHub platform, before we find a competitor to
> compare
> >> with, and since we can more or less sync the conversation back to ASF
> >> INFRA, I'm +1 for giving GH issue and GH discussion a chance.
> >>
> >> But, in the other hand, if we can link the JIRA project and the code
> repo
> >> properly, given that our mailing list's and JIRA's responsiveness is
> high,
> >> it's good enough for me that we use GH PR for the patching process only,
> >> keep issues on JIRA and make most significant discussion on the mailing
> >> list only. While, GH discussions is a net win as a user forum just like
> a
> >> stack overflow tag - we can ensure no development decision is made there
> >> and everything is back to the mailing list.
> >>
> >> Best,
> >> tison.
> >>
> >> [1] https://issues.apache.org/jira/browse/MPOM-418
> >> [2] https://lists.apache.org/thread/t1f5wws6o4moy0p9kt4726ng5tsgzgln
> >> [3] https://github.com/apache/maven-apache-parent
> >>
> >> [4] https://www.goodreads.com/en/book/show/54140556
> >>
> >> [5]
> >>
> https://github.com/apache/pulsar/blob/a953027aad38c9f54e952133949280ec2f4c04e8/.asf.yaml#L84-L88
> >>
> >>
> >> Tamás Cservenák <ta...@cservenak.net> 于2023年5月27日周六 18:10写道：
> >>
> >>> 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 ASK us about something, so going through hoops and loops above (and
> >>> coming back 2 yr after with "please unsub me...") only to post a
> question
> >>> is just a very bad experience.
> >>>
> >>> Moreover, we are very fragmented repository-wide, and I bet that a
> novice
> >>> user will simply be lost:
> >>> - WHERE (as in which Maven-* GH repo) to ask
> >>> - WHERE (as in which Maven-* GH repo) to report issue
> >>> - etc
> >>>
> >>> This is why I recommended "single entry point", a kind of dispatcher
> >>> (discussion) repo/GH project, where one off users can hop on, ASK
> things
> >>> and disappear if they like, receive answers where to go, and so on. And
> >>> if
> >>> they feel like it, they could join ML or register to JIRA, something
> >>> TODAY
> >>> EVERYONE WHO WANTS TO REACH OUT TO US must do. Hence, most "one off
> >>> askers"
> >>> would not go so far even.
> >>>
> >>> For me, most reasonable would be a new "discussion only" project, for
> >>> example "apache/maven-project" on GH, that would contain no source, no
> >>> issues, only discussions enabled and would serve as a "low barrier
> lobby"
> >>> for newcomers.
> >>>
> >>> Opening discussions in _existing repository_ is unwise IMHO, as
> "general"
> >>> discussions/questions do not belong to apache/maven, nor
> >>> apache/maven-clean-plugin, nor any other existing repo.
> >>>
> >>> Thanks
> >>> T
> >>>
> >>> On Sat, May 27, 2023 at 11:24 AM Łukasz Dywicki <lu...@code-house.org>
> >>> wrote:
> >>>
> >>> > 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 GH database. If you ever found a google code
> >>> > project migrated into github/gitlab issues you know what I mean.
> >>> >
> >>> > While policies imposed on JIRA account creation, are without doubt a
> >>> > bearer to contribute first bug report, JIRA itself helps us keeping
> all
> >>> > ASF information together. Just to be clear - I keep being lost with
> new
> >>> > JIRA user interface, I'm just reflecting my personal thoughts.
> >>> >
> >>> > Best,
> >>> > Łukasz
> >>> >
> >>> > On 27.05.2023 09:30, Hervé Boutemy wrote:
> >>> > > 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 milestones mandatory in that case.
> >>> > > AFAIK, GH Milestones are useful when you want to assign an issue
> >>> that is
> >>> > not
> >>> > > yet fixed
> >>> > > see for example https://github.com/apache/maven-mvnd/milestones
> >>> > >
> >>> > > But it does not seem absolutely necessary, since GH Release Notes
> >>> will
> >>> > get the
> >>> > > release content once the issue is fixed
> >>> > > example: https://github.com/apache/maven-mvnd/releases
> >>> > >
> >>> > > We'll need to define which GH Labels are available, and how the
> >>> release
> >>> > notes
> >>> > > drafter use it to have better release notes
> >>> > > https://github.com/apache/maven-mvnd/labels
> >>> > >
> >>> > >> It is far less work than maintaining an issue.
> >>> > >>
> >>> > >> Am Fr., 26. Mai 2023 um 09:44 Uhr schrieb Olivier Lamy <
> >>> > olamy@apache.org>:
> >>> > >>> Hi,
> >>> > >>> This has been already discussed in the past.
> >>> > >>> But due to recent changes in ASF Jira infrastructure (limitation
> of
> >>> > >>> Jira users, validation of account creation).
> >>> > >>> Maybe we could reconsider moving from Jira to GH issues and why
> not
> >>> > >>> simplify the workflow as well.
> >>> > >>> I imagine not having to create an issue if a PR exists first
> >>> (sounds
> >>> > >>> like duplicate work).
> >>> > >>> By the way, release notes will be automatically created from PRs.
> >>> > >>> (could be manually modified if a change doesn't have a PR).
> >>> > >>>
> >>> > >>> Regarding migration, we can start project by project.
> >>> > >>> Few options:
> >>> > >>> - extreme simplicity, do not migrate any data (just mark the Jira
> >>> > >>> project as read only with a banner/link to corresponding gh
> >>> issues).
> >>> > >>> If someone really needs an issue to get fixed he will clone it to
> >>> GH
> >>> > >>> - middle complexity, migrate only open issues (components moved
> as
> >>> a
> >>> > >>> label)
> >>> > >>> - extreme complexity, migrate all issues of a project (components
> >>> > >>> moved as a label and version created)
> >>> > >>>
> >>> > >>> We can start by small projects such as cache-extension and one
> >>> plugin
> >>> > >>> (compiler?)
> >>> > >>>
> >>> > >>> Regarding GH discussions, maybe we can open discussions for
> >>> > >>> https://github.com/apache/maven which sounds like a natural
> place
> >>> for
> >>> > >>> users to go. (discussions could be mirrored to a ML)
> >>> > >>> I do not have a strong opinion here, but I feel like opening
> >>> > >>> discussions for every single repo will be complicated to follow
> up.
> >>> > >>>
> >>> > >>> WDYT?
> >>> > >>>
> >>> > >>> cheers
> >>> > >>> Olivier
> >>> > >>>
> >>> > >>>
> >>> ---------------------------------------------------------------------
> >>> > >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> > >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>> > >
> >>> > >
> >>> > >
> >>> > >
> >>> > >
> >>> > >
> ---------------------------------------------------------------------
> >>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> > > For additional commands, e-mail: dev-help@maven.apache.org
> >>> > >
> >>> >
> >>> > ---------------------------------------------------------------------
> >>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> > For additional commands, e-mail: dev-help@maven.apache.org
> >>> >
> >>> >
> >>>
> >>
>
Re: GH issues and GH discussions
Posted by tison <wa...@gmail.com>.
> 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 happens.
So we may not say "a specific channel is _not_ supported, you should not
ask there", but "most of the critical mass answering questions on platform
X". Users make their choice reflected to where the critical mass work
instead of being forced there.
Best,
tison.
tison <wa...@gmail.com> 于2023年5月27日周六 18:36写道：
> 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 GH Issues
> for different repos, while for the tightly coupled site repo[3], I merge
> the Issue tracker to the main repo. Single Discussions instance for all
> "Pulsar" related questions.
> 3. Apache Flink[3] (I'm one of its committers) uses a single JIRA project
> for all its repos issue trackers, and only user@ and user-zh@ mailing
> lists for user questions. Given their high responsiveness, it works well
> for most of its users. Although other unofficial channels (with PMC members
> there) (like DingTalk group or Slack workspace) exist to answer questions,
> most users can be guided to the mailing list since it's still the most
> active channel.
>
> Maven has a more complex repo cluster[4], and decisions can differ.
>
> Best,
> tison.
>
> [1] https://github.com/apache/skywalking
> [2] http://github.com/apache/pulsar
> [3] http://github.com/apache/pulsar-site
> [4] https://maven.apache.org/scm.html
>
>
> tison <wa...@gmail.com> 于2023年5月27日周六 18:28写道：
>
>> 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, while the
>> maintainer tells me it's not the correct place.
>>
>> I'm familiar with the mailing list way so it's not quite a trouble to ask
>> here. But as time goes on, more and more developers and users get used to
>> the GitHub platform. No matter if it's a good thing, it's a fact[4].
>>
>> So, for lowering the bar for user participation, I agree we can give GH
>> issues and GH discussions a try.
>>
>> 2. GitHub is a proprietary service that is unreliable in an
>> organization's view.
>>
>> I agree.
>>
>> Part of them can be resolved by we sync all traffic back to an ASF
>> mailing list, like most of the ASF projects I participated in[5]. We can
>> thus archive most of the context but since they are for archiving only, the
>> readability can be bad.
>>
>> To sum up, as new generation developers and users grow and they are more
>> familiar with the GitHub platform, before we find a competitor to compare
>> with, and since we can more or less sync the conversation back to ASF
>> INFRA, I'm +1 for giving GH issue and GH discussion a chance.
>>
>> But, in the other hand, if we can link the JIRA project and the code repo
>> properly, given that our mailing list's and JIRA's responsiveness is high,
>> it's good enough for me that we use GH PR for the patching process only,
>> keep issues on JIRA and make most significant discussion on the mailing
>> list only. While, GH discussions is a net win as a user forum just like a
>> stack overflow tag - we can ensure no development decision is made there
>> and everything is back to the mailing list.
>>
>> Best,
>> tison.
>>
>> [1] https://issues.apache.org/jira/browse/MPOM-418
>> [2] https://lists.apache.org/thread/t1f5wws6o4moy0p9kt4726ng5tsgzgln
>> [3] https://github.com/apache/maven-apache-parent
>>
>> [4] https://www.goodreads.com/en/book/show/54140556
>>
>> [5]
>> https://github.com/apache/pulsar/blob/a953027aad38c9f54e952133949280ec2f4c04e8/.asf.yaml#L84-L88
>>
>>
>> Tamás Cservenák <ta...@cservenak.net> 于2023年5月27日周六 18:10写道：
>>
>>> 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 ASK us about something, so going through hoops and loops above (and
>>> coming back 2 yr after with "please unsub me...") only to post a question
>>> is just a very bad experience.
>>>
>>> Moreover, we are very fragmented repository-wide, and I bet that a novice
>>> user will simply be lost:
>>> - WHERE (as in which Maven-* GH repo) to ask
>>> - WHERE (as in which Maven-* GH repo) to report issue
>>> - etc
>>>
>>> This is why I recommended "single entry point", a kind of dispatcher
>>> (discussion) repo/GH project, where one off users can hop on, ASK things
>>> and disappear if they like, receive answers where to go, and so on. And
>>> if
>>> they feel like it, they could join ML or register to JIRA, something
>>> TODAY
>>> EVERYONE WHO WANTS TO REACH OUT TO US must do. Hence, most "one off
>>> askers"
>>> would not go so far even.
>>>
>>> For me, most reasonable would be a new "discussion only" project, for
>>> example "apache/maven-project" on GH, that would contain no source, no
>>> issues, only discussions enabled and would serve as a "low barrier lobby"
>>> for newcomers.
>>>
>>> Opening discussions in _existing repository_ is unwise IMHO, as "general"
>>> discussions/questions do not belong to apache/maven, nor
>>> apache/maven-clean-plugin, nor any other existing repo.
>>>
>>> Thanks
>>> T
>>>
>>> On Sat, May 27, 2023 at 11:24 AM Łukasz Dywicki <lu...@code-house.org>
>>> wrote:
>>>
>>> > 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 GH database. If you ever found a google code
>>> > project migrated into github/gitlab issues you know what I mean.
>>> >
>>> > While policies imposed on JIRA account creation, are without doubt a
>>> > bearer to contribute first bug report, JIRA itself helps us keeping all
>>> > ASF information together. Just to be clear - I keep being lost with new
>>> > JIRA user interface, I'm just reflecting my personal thoughts.
>>> >
>>> > Best,
>>> > Łukasz
>>> >
>>> > On 27.05.2023 09:30, Hervé Boutemy wrote:
>>> > > 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 milestones mandatory in that case.
>>> > > AFAIK, GH Milestones are useful when you want to assign an issue
>>> that is
>>> > not
>>> > > yet fixed
>>> > > see for example https://github.com/apache/maven-mvnd/milestones
>>> > >
>>> > > But it does not seem absolutely necessary, since GH Release Notes
>>> will
>>> > get the
>>> > > release content once the issue is fixed
>>> > > example: https://github.com/apache/maven-mvnd/releases
>>> > >
>>> > > We'll need to define which GH Labels are available, and how the
>>> release
>>> > notes
>>> > > drafter use it to have better release notes
>>> > > https://github.com/apache/maven-mvnd/labels
>>> > >
>>> > >> It is far less work than maintaining an issue.
>>> > >>
>>> > >> Am Fr., 26. Mai 2023 um 09:44 Uhr schrieb Olivier Lamy <
>>> > olamy@apache.org>:
>>> > >>> Hi,
>>> > >>> This has been already discussed in the past.
>>> > >>> But due to recent changes in ASF Jira infrastructure (limitation of
>>> > >>> Jira users, validation of account creation).
>>> > >>> Maybe we could reconsider moving from Jira to GH issues and why not
>>> > >>> simplify the workflow as well.
>>> > >>> I imagine not having to create an issue if a PR exists first
>>> (sounds
>>> > >>> like duplicate work).
>>> > >>> By the way, release notes will be automatically created from PRs.
>>> > >>> (could be manually modified if a change doesn't have a PR).
>>> > >>>
>>> > >>> Regarding migration, we can start project by project.
>>> > >>> Few options:
>>> > >>> - extreme simplicity, do not migrate any data (just mark the Jira
>>> > >>> project as read only with a banner/link to corresponding gh
>>> issues).
>>> > >>> If someone really needs an issue to get fixed he will clone it to
>>> GH
>>> > >>> - middle complexity, migrate only open issues (components moved as
>>> a
>>> > >>> label)
>>> > >>> - extreme complexity, migrate all issues of a project (components
>>> > >>> moved as a label and version created)
>>> > >>>
>>> > >>> We can start by small projects such as cache-extension and one
>>> plugin
>>> > >>> (compiler?)
>>> > >>>
>>> > >>> Regarding GH discussions, maybe we can open discussions for
>>> > >>> https://github.com/apache/maven which sounds like a natural place
>>> for
>>> > >>> users to go. (discussions could be mirrored to a ML)
>>> > >>> I do not have a strong opinion here, but I feel like opening
>>> > >>> discussions for every single repo will be complicated to follow up.
>>> > >>>
>>> > >>> WDYT?
>>> > >>>
>>> > >>> cheers
>>> > >>> Olivier
>>> > >>>
>>> > >>>
>>> ---------------------------------------------------------------------
>>> > >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > >>> For additional commands, e-mail: dev-help@maven.apache.org
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > ---------------------------------------------------------------------
>>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > > For additional commands, e-mail: dev-help@maven.apache.org
>>> > >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>> >
>>> >
>>>
>>
Re: GH issues and GH discussions
Posted by tison <wa...@gmail.com>.
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 GH Issues for
different repos, while for the tightly coupled site repo[3], I merge the
Issue tracker to the main repo. Single Discussions instance for all
"Pulsar" related questions.
3. Apache Flink[3] (I'm one of its committers) uses a single JIRA project
for all its repos issue trackers, and only user@ and user-zh@ mailing lists
for user questions. Given their high responsiveness, it works well for most
of its users. Although other unofficial channels (with PMC members there)
(like DingTalk group or Slack workspace) exist to answer questions, most
users can be guided to the mailing list since it's still the most active
channel.
Maven has a more complex repo cluster[4], and decisions can differ.
Best,
tison.
[1] https://github.com/apache/skywalking
[2] http://github.com/apache/pulsar
[3] http://github.com/apache/pulsar-site
[4] https://maven.apache.org/scm.html
tison <wa...@gmail.com> 于2023年5月27日周六 18:28写道：
> 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, while the
> maintainer tells me it's not the correct place.
>
> I'm familiar with the mailing list way so it's not quite a trouble to ask
> here. But as time goes on, more and more developers and users get used to
> the GitHub platform. No matter if it's a good thing, it's a fact[4].
>
> So, for lowering the bar for user participation, I agree we can give GH
> issues and GH discussions a try.
>
> 2. GitHub is a proprietary service that is unreliable in an organization's
> view.
>
> I agree.
>
> Part of them can be resolved by we sync all traffic back to an ASF mailing
> list, like most of the ASF projects I participated in[5]. We can thus
> archive most of the context but since they are for archiving only, the
> readability can be bad.
>
> To sum up, as new generation developers and users grow and they are more
> familiar with the GitHub platform, before we find a competitor to compare
> with, and since we can more or less sync the conversation back to ASF
> INFRA, I'm +1 for giving GH issue and GH discussion a chance.
>
> But, in the other hand, if we can link the JIRA project and the code repo
> properly, given that our mailing list's and JIRA's responsiveness is high,
> it's good enough for me that we use GH PR for the patching process only,
> keep issues on JIRA and make most significant discussion on the mailing
> list only. While, GH discussions is a net win as a user forum just like a
> stack overflow tag - we can ensure no development decision is made there
> and everything is back to the mailing list.
>
> Best,
> tison.
>
> [1] https://issues.apache.org/jira/browse/MPOM-418
> [2] https://lists.apache.org/thread/t1f5wws6o4moy0p9kt4726ng5tsgzgln
> [3] https://github.com/apache/maven-apache-parent
>
> [4] https://www.goodreads.com/en/book/show/54140556
>
> [5]
> https://github.com/apache/pulsar/blob/a953027aad38c9f54e952133949280ec2f4c04e8/.asf.yaml#L84-L88
>
>
> Tamás Cservenák <ta...@cservenak.net> 于2023年5月27日周六 18:10写道：
>
>> 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 ASK us about something, so going through hoops and loops above (and
>> coming back 2 yr after with "please unsub me...") only to post a question
>> is just a very bad experience.
>>
>> Moreover, we are very fragmented repository-wide, and I bet that a novice
>> user will simply be lost:
>> - WHERE (as in which Maven-* GH repo) to ask
>> - WHERE (as in which Maven-* GH repo) to report issue
>> - etc
>>
>> This is why I recommended "single entry point", a kind of dispatcher
>> (discussion) repo/GH project, where one off users can hop on, ASK things
>> and disappear if they like, receive answers where to go, and so on. And if
>> they feel like it, they could join ML or register to JIRA, something TODAY
>> EVERYONE WHO WANTS TO REACH OUT TO US must do. Hence, most "one off
>> askers"
>> would not go so far even.
>>
>> For me, most reasonable would be a new "discussion only" project, for
>> example "apache/maven-project" on GH, that would contain no source, no
>> issues, only discussions enabled and would serve as a "low barrier lobby"
>> for newcomers.
>>
>> Opening discussions in _existing repository_ is unwise IMHO, as "general"
>> discussions/questions do not belong to apache/maven, nor
>> apache/maven-clean-plugin, nor any other existing repo.
>>
>> Thanks
>> T
>>
>> On Sat, May 27, 2023 at 11:24 AM Łukasz Dywicki <lu...@code-house.org>
>> wrote:
>>
>> > 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 GH database. If you ever found a google code
>> > project migrated into github/gitlab issues you know what I mean.
>> >
>> > While policies imposed on JIRA account creation, are without doubt a
>> > bearer to contribute first bug report, JIRA itself helps us keeping all
>> > ASF information together. Just to be clear - I keep being lost with new
>> > JIRA user interface, I'm just reflecting my personal thoughts.
>> >
>> > Best,
>> > Łukasz
>> >
>> > On 27.05.2023 09:30, Hervé Boutemy wrote:
>> > > 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 milestones mandatory in that case.
>> > > AFAIK, GH Milestones are useful when you want to assign an issue that
>> is
>> > not
>> > > yet fixed
>> > > see for example https://github.com/apache/maven-mvnd/milestones
>> > >
>> > > But it does not seem absolutely necessary, since GH Release Notes will
>> > get the
>> > > release content once the issue is fixed
>> > > example: https://github.com/apache/maven-mvnd/releases
>> > >
>> > > We'll need to define which GH Labels are available, and how the
>> release
>> > notes
>> > > drafter use it to have better release notes
>> > > https://github.com/apache/maven-mvnd/labels
>> > >
>> > >> It is far less work than maintaining an issue.
>> > >>
>> > >> Am Fr., 26. Mai 2023 um 09:44 Uhr schrieb Olivier Lamy <
>> > olamy@apache.org>:
>> > >>> Hi,
>> > >>> This has been already discussed in the past.
>> > >>> But due to recent changes in ASF Jira infrastructure (limitation of
>> > >>> Jira users, validation of account creation).
>> > >>> Maybe we could reconsider moving from Jira to GH issues and why not
>> > >>> simplify the workflow as well.
>> > >>> I imagine not having to create an issue if a PR exists first (sounds
>> > >>> like duplicate work).
>> > >>> By the way, release notes will be automatically created from PRs.
>> > >>> (could be manually modified if a change doesn't have a PR).
>> > >>>
>> > >>> Regarding migration, we can start project by project.
>> > >>> Few options:
>> > >>> - extreme simplicity, do not migrate any data (just mark the Jira
>> > >>> project as read only with a banner/link to corresponding gh issues).
>> > >>> If someone really needs an issue to get fixed he will clone it to GH
>> > >>> - middle complexity, migrate only open issues (components moved as a
>> > >>> label)
>> > >>> - extreme complexity, migrate all issues of a project (components
>> > >>> moved as a label and version created)
>> > >>>
>> > >>> We can start by small projects such as cache-extension and one
>> plugin
>> > >>> (compiler?)
>> > >>>
>> > >>> Regarding GH discussions, maybe we can open discussions for
>> > >>> https://github.com/apache/maven which sounds like a natural place
>> for
>> > >>> users to go. (discussions could be mirrored to a ML)
>> > >>> I do not have a strong opinion here, but I feel like opening
>> > >>> discussions for every single repo will be complicated to follow up.
>> > >>>
>> > >>> WDYT?
>> > >>>
>> > >>> cheers
>> > >>> Olivier
>> > >>>
>> > >>>
>> ---------------------------------------------------------------------
>> > >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > >>> For additional commands, e-mail: dev-help@maven.apache.org
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > For additional commands, e-mail: dev-help@maven.apache.org
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>
Re: GH issues and GH discussions
Posted by tison <wa...@gmail.com>.
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, while the
maintainer tells me it's not the correct place.
I'm familiar with the mailing list way so it's not quite a trouble to ask
here. But as time goes on, more and more developers and users get used to
the GitHub platform. No matter if it's a good thing, it's a fact[4].
So, for lowering the bar for user participation, I agree we can give GH
issues and GH discussions a try.
2. GitHub is a proprietary service that is unreliable in an organization's
view.
I agree.
Part of them can be resolved by we sync all traffic back to an ASF mailing
list, like most of the ASF projects I participated in[5]. We can thus
archive most of the context but since they are for archiving only, the
readability can be bad.
To sum up, as new generation developers and users grow and they are more
familiar with the GitHub platform, before we find a competitor to compare
with, and since we can more or less sync the conversation back to ASF
INFRA, I'm +1 for giving GH issue and GH discussion a chance.
But, in the other hand, if we can link the JIRA project and the code repo
properly, given that our mailing list's and JIRA's responsiveness is high,
it's good enough for me that we use GH PR for the patching process only,
keep issues on JIRA and make most significant discussion on the mailing
list only. While, GH discussions is a net win as a user forum just like a
stack overflow tag - we can ensure no development decision is made there
and everything is back to the mailing list.
Best,
tison.
[1] https://issues.apache.org/jira/browse/MPOM-418
[2] https://lists.apache.org/thread/t1f5wws6o4moy0p9kt4726ng5tsgzgln
[3] https://github.com/apache/maven-apache-parent
[4] https://www.goodreads.com/en/book/show/54140556
[5]
https://github.com/apache/pulsar/blob/a953027aad38c9f54e952133949280ec2f4c04e8/.asf.yaml#L84-L88
Tamás Cservenák <ta...@cservenak.net> 于2023年5月27日周六 18:10写道：
> 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 ASK us about something, so going through hoops and loops above (and
> coming back 2 yr after with "please unsub me...") only to post a question
> is just a very bad experience.
>
> Moreover, we are very fragmented repository-wide, and I bet that a novice
> user will simply be lost:
> - WHERE (as in which Maven-* GH repo) to ask
> - WHERE (as in which Maven-* GH repo) to report issue
> - etc
>
> This is why I recommended "single entry point", a kind of dispatcher
> (discussion) repo/GH project, where one off users can hop on, ASK things
> and disappear if they like, receive answers where to go, and so on. And if
> they feel like it, they could join ML or register to JIRA, something TODAY
> EVERYONE WHO WANTS TO REACH OUT TO US must do. Hence, most "one off askers"
> would not go so far even.
>
> For me, most reasonable would be a new "discussion only" project, for
> example "apache/maven-project" on GH, that would contain no source, no
> issues, only discussions enabled and would serve as a "low barrier lobby"
> for newcomers.
>
> Opening discussions in _existing repository_ is unwise IMHO, as "general"
> discussions/questions do not belong to apache/maven, nor
> apache/maven-clean-plugin, nor any other existing repo.
>
> Thanks
> T
>
> On Sat, May 27, 2023 at 11:24 AM Łukasz Dywicki <lu...@code-house.org>
> wrote:
>
> > 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 GH database. If you ever found a google code
> > project migrated into github/gitlab issues you know what I mean.
> >
> > While policies imposed on JIRA account creation, are without doubt a
> > bearer to contribute first bug report, JIRA itself helps us keeping all
> > ASF information together. Just to be clear - I keep being lost with new
> > JIRA user interface, I'm just reflecting my personal thoughts.
> >
> > Best,
> > Łukasz
> >
> > On 27.05.2023 09:30, Hervé Boutemy wrote:
> > > 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 milestones mandatory in that case.
> > > AFAIK, GH Milestones are useful when you want to assign an issue that
> is
> > not
> > > yet fixed
> > > see for example https://github.com/apache/maven-mvnd/milestones
> > >
> > > But it does not seem absolutely necessary, since GH Release Notes will
> > get the
> > > release content once the issue is fixed
> > > example: https://github.com/apache/maven-mvnd/releases
> > >
> > > We'll need to define which GH Labels are available, and how the release
> > notes
> > > drafter use it to have better release notes
> > > https://github.com/apache/maven-mvnd/labels
> > >
> > >> It is far less work than maintaining an issue.
> > >>
> > >> Am Fr., 26. Mai 2023 um 09:44 Uhr schrieb Olivier Lamy <
> > olamy@apache.org>:
> > >>> Hi,
> > >>> This has been already discussed in the past.
> > >>> But due to recent changes in ASF Jira infrastructure (limitation of
> > >>> Jira users, validation of account creation).
> > >>> Maybe we could reconsider moving from Jira to GH issues and why not
> > >>> simplify the workflow as well.
> > >>> I imagine not having to create an issue if a PR exists first (sounds
> > >>> like duplicate work).
> > >>> By the way, release notes will be automatically created from PRs.
> > >>> (could be manually modified if a change doesn't have a PR).
> > >>>
> > >>> Regarding migration, we can start project by project.
> > >>> Few options:
> > >>> - extreme simplicity, do not migrate any data (just mark the Jira
> > >>> project as read only with a banner/link to corresponding gh issues).
> > >>> If someone really needs an issue to get fixed he will clone it to GH
> > >>> - middle complexity, migrate only open issues (components moved as a
> > >>> label)
> > >>> - extreme complexity, migrate all issues of a project (components
> > >>> moved as a label and version created)
> > >>>
> > >>> We can start by small projects such as cache-extension and one plugin
> > >>> (compiler?)
> > >>>
> > >>> Regarding GH discussions, maybe we can open discussions for
> > >>> https://github.com/apache/maven which sounds like a natural place
> for
> > >>> users to go. (discussions could be mirrored to a ML)
> > >>> I do not have a strong opinion here, but I feel like opening
> > >>> discussions for every single repo will be complicated to follow up.
> > >>>
> > >>> WDYT?
> > >>>
> > >>> cheers
> > >>> Olivier
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >>> For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
RE: GH issues and GH discussions
Posted by Jeremy Landis <je...@hotmail.com>.
You are correct, never used Polarion. Sounds like that might have been as bad as PVCS compared to nearly all other SCM 😉
IMO simple is better when it comes to that stuff and linking tickets isn't that hard. I've not done anything with gitlab but on GH its trivial, maybe not the best but just dropping comments with URL links hooks things together. Maybe not elegant. But then again I don't have 100s of possible variations of setup. Only improvement in Jira I like is service desk and using it for Kanban. Even then too many clicks to just add a note that I’m doing something, here are details, close it. My day job ruined its general usage though. Has more to do with the customization they added to such an extent that it’s a time tracker and developers now spend more time there then actually coding so management and product teams are happy and they continue to assume coding takes no time.
-----Original Message-----
From: Michael Osipov <mi...@apache.org>
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 Jira for all their projects entirely to GitHub Issues. Believe it was done with everything.
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsprin
> g.io%2Fblog%2F2019%2F01%2F15%2Fspring-framework-s-migration-from-jira-
> to-github-issues&data=05%7C01%7C%7Cd2dc9ef5900c4dfc10e508db5ef14e59%7C
> 84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638208162715371992%7CUnknow
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> JXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Z5DiJtHc5rqBVITjWitrTQ%2FtkhRFCKD%2
> BJ%2F%2FAw6we%2B9Q%3D&reserved=0
>
> Now concerns of MS are unfounded thus far. MS is biggest user of github which is why they bought it. Not sure that is still the case but after some 14 years, issues have not cost anything and moving them back out is about as easy of a process. Plus issues and pull requests are effectively the same thing (at least numbering wise). Comparing to items I've seen mentioned here like google code shutting I don’t think are very fair comparisons. I would lean to look at spring and see their motivation.
>
> Rest is my 2 cents don't feel inclined to read my rambling.
>
> From a plugin owner where all I use issues only, working at a job where Jira has become a time tracking tool, and the fact its so hard to work with any github team that uses jira.... Sure I figured it out with maven but it’s a serious pain....and leads to...how I feel. And I’m sure true for most others are the same. I prefer to not even contribute or be active as a result on any repos that are using jira. Let's be honest here. Atlassian is just doing nothing with their products. Jira looks the same today it did 14 years ago. Bitbucket looks the same as Stash before it with some minor color changes. They are losing market share as a result as they cannot even handle volume. Jira is a bloated mess. If team is trying to do agile, that’s built into github too. Its so much easier to be in one single place. I've heard these arguments that github might go away for years now or MS owning it now might do like Oracle. They did something right here. MS consideration is a lot like Oracle, super heavy handed in what they do but the foundation was set and unlike MS trying to end Slack with ugly Teams, they choose not to do the same with GH. Outside of some assumed "they mess it all up and ruin our lives", I think the benefits far outweight all concerns.
>
> I'd be -1 on only having issues in one place but maybe as a jumping off point to find all the repos. Blame feature doesn't really help, no one sees those. Issues needs turned on for all repos. In fact, if you want to continue jira, fine, but open issues up. If someone as a small concern, only making them raise on mailing lists or jira is a nightmare. This is by far biggest reason I hate bitbucket - no issues, use jira. Too many times and I'm sure I’m not alone, its easier to just ignore the issues outright and try to find alternatives 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.
Interesting, having used JIRA for 10+ years as well as GH and a huge GL installation (300 000+ users), I consider that both GH's and GL's issue handing is just inferior to JIRA. Especially when it comes to linking and alike.
Note: I am looking only from a technical perspective, leaving politics and capitalism aside.
Regarding UI: Though, I don't understand your problem with JIRA UI -- you haven't used Polarion. That has a horrible UI and UX, JIRA is decades ahead. Plus, changing somehing for the sake of the change is just wrong. If something works well, just a bit finetuning. Don't reinvent the wheel.
M
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: GH issues and GH discussions
Posted by Michael Osipov <mi...@apache.org>.
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 concerns of MS are unfounded thus far. MS is biggest user of github which is why they bought it. Not sure that is still the case but after some 14 years, issues have not cost anything and moving them back out is about as easy of a process. Plus issues and pull requests are effectively the same thing (at least numbering wise). Comparing to items I've seen mentioned here like google code shutting I don’t think are very fair comparisons. I would lean to look at spring and see their motivation.
>
> Rest is my 2 cents don't feel inclined to read my rambling.
>
> From a plugin owner where all I use issues only, working at a job where Jira has become a time tracking tool, and the fact its so hard to work with any github team that uses jira.... Sure I figured it out with maven but it’s a serious pain....and leads to...how I feel. And I’m sure true for most others are the same. I prefer to not even contribute or be active as a result on any repos that are using jira. Let's be honest here. Atlassian is just doing nothing with their products. Jira looks the same today it did 14 years ago. Bitbucket looks the same as Stash before it with some minor color changes. They are losing market share as a result as they cannot even handle volume. Jira is a bloated mess. If team is trying to do agile, that’s built into github too. Its so much easier to be in one single place. I've heard these arguments that github might go away for years now or MS owning it now might do like Oracle. They did something right here. MS consideration is a lot like Oracle, super heavy handed in what they do but the foundation was set and unlike MS trying to end Slack with ugly Teams, they choose not to do the same with GH. Outside of some assumed "they mess it all up and ruin our lives", I think the benefits far outweight all concerns.
>
> I'd be -1 on only having issues in one place but maybe as a jumping off point to find all the repos. Blame feature doesn't really help, no one sees those. Issues needs turned on for all repos. In fact, if you want to continue jira, fine, but open issues up. If someone as a small concern, only making them raise on mailing lists or jira is a nightmare. This is by far biggest reason I hate bitbucket - no issues, use jira. Too many times and I'm sure I’m not alone, its easier to just ignore the issues outright and try to find alternatives 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.
Interesting, having used JIRA for 10+ years as well as GH and a huge GL
installation (300 000+ users), I consider that both GH's and GL's issue
handing is just inferior to JIRA. Especially when it comes to linking
and alike.
Note: I am looking only from a technical perspective, leaving politics
and capitalism aside.
Regarding UI: Though, I don't understand your problem with JIRA UI --
you haven't used Polarion. That has a horrible UI and UX, JIRA is
decades ahead. Plus, changing somehing for the sake of the change is
just wrong. If something works well, just a bit finetuning. Don't
reinvent the wheel.
M
RE: GH issues and GH discussions
Posted by Jeremy Landis <je...@hotmail.com>.
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 concerns of MS are unfounded thus far. MS is biggest user of github which is why they bought it. Not sure that is still the case but after some 14 years, issues have not cost anything and moving them back out is about as easy of a process. Plus issues and pull requests are effectively the same thing (at least numbering wise). Comparing to items I've seen mentioned here like google code shutting I don’t think are very fair comparisons. I would lean to look at spring and see their motivation.
Rest is my 2 cents don't feel inclined to read my rambling.
From a plugin owner where all I use issues only, working at a job where Jira has become a time tracking tool, and the fact its so hard to work with any github team that uses jira.... Sure I figured it out with maven but it’s a serious pain....and leads to...how I feel. And I’m sure true for most others are the same. I prefer to not even contribute or be active as a result on any repos that are using jira. Let's be honest here. Atlassian is just doing nothing with their products. Jira looks the same today it did 14 years ago. Bitbucket looks the same as Stash before it with some minor color changes. They are losing market share as a result as they cannot even handle volume. Jira is a bloated mess. If team is trying to do agile, that’s built into github too. Its so much easier to be in one single place. I've heard these arguments that github might go away for years now or MS owning it now might do like Oracle. They did something right here. MS consideration is a lot like Oracle, super heavy handed in what they do but the foundation was set and unlike MS trying to end Slack with ugly Teams, they choose not to do the same with GH. Outside of some assumed "they mess it all up and ruin our lives", I think the benefits far outweight all concerns.
I'd be -1 on only having issues in one place but maybe as a jumping off point to find all the repos. Blame feature doesn't really help, no one sees those. Issues needs turned on for all repos. In fact, if you want to continue jira, fine, but open issues up. If someone as a small concern, only making them raise on mailing lists or jira is a nightmare. This is by far biggest reason I hate bitbucket - no issues, use jira. Too many times and I'm sure I’m not alone, its easier to just ignore the issues outright and try to find alternatives 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 <mi...@apache.org>
Sent: Saturday, May 27, 2023 2:53 PM
To: dev@maven.apache.org
Subject: Re: GH issues and GH discussions
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 barrier for "one off" users, many of our users
> want to ASK us about something, so going through hoops and loops above
> (and coming back 2 yr after with "please unsub me...") only to post a
> question is just a very bad experience.
>
> Moreover, we are very fragmented repository-wide, and I bet that a
> novice user will simply be lost:
> - WHERE (as in which Maven-* GH repo) to ask
> - WHERE (as in which Maven-* GH repo) to report issue
> - etc
>
> This is why I recommended "single entry point", a kind of dispatcher
> (discussion) repo/GH project, where one off users can hop on, ASK
> things and disappear if they like, receive answers where to go, and so
> on. And if they feel like it, they could join ML or register to JIRA,
> something TODAY EVERYONE WHO WANTS TO REACH OUT TO US must do. Hence, most "one off askers"
> would not go so far even.
>
> For me, most reasonable would be a new "discussion only" project, for
> example "apache/maven-project" on GH, that would contain no source, no
> issues, only discussions enabled and would serve as a "low barrier lobby"
> for newcomers.
>
> Opening discussions in _existing repository_ is unwise IMHO, as "general"
> discussions/questions do not belong to apache/maven, nor
> apache/maven-clean-plugin, nor any other existing repo.
I truly do like your idea and also agree with Lukasz -- never give up to control to a single party, especially one like MS.
Upshot: One entry point with an empty repo.
B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB [ X ܚX KK[XZ[
] ][ X ܚX PX] [ \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[
] Z[ X] [ \X K ܙ B
Re: GH issues and GH discussions
Posted by Olivier Lamy <ol...@apache.org>.
On Sun, 28 May 2023 at 04:53, Michael Osipov <mi...@apache.org> 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),
> > - 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 ASK us about something, so going through hoops and loops above (and
> > coming back 2 yr after with "please unsub me...") only to post a question
> > is just a very bad experience.
> >
> > Moreover, we are very fragmented repository-wide, and I bet that a novice
> > user will simply be lost:
> > - WHERE (as in which Maven-* GH repo) to ask
> > - WHERE (as in which Maven-* GH repo) to report issue
> > - etc
> >
> > This is why I recommended "single entry point", a kind of dispatcher
> > (discussion) repo/GH project, where one off users can hop on, ASK things
> > and disappear if they like, receive answers where to go, and so on. And if
> > they feel like it, they could join ML or register to JIRA, something TODAY
> > EVERYONE WHO WANTS TO REACH OUT TO US must do. Hence, most "one off askers"
> > would not go so far even.
> >
> > For me, most reasonable would be a new "discussion only" project, for
> > example "apache/maven-project" on GH, that would contain no source, no
> > issues, only discussions enabled and would serve as a "low barrier lobby"
> > for newcomers.
> >
> > Opening discussions in _existing repository_ is unwise IMHO, as "general"
> > discussions/questions do not belong to apache/maven, nor
> > apache/maven-clean-plugin, nor any other existing repo.
>
> I truly do like your idea and also agree with Lukasz -- never give up to
> control to a single party, especially one like MS.
>
> Upshot: One entry point with an empty repo.
Well in case you didn't know the reason for "locking" Jira user
creation (apart from avoiding spam) is the coming move (not sure if
it's not already done) of Jira to Atlassian cloud (which have users
number limitation that's why there is some cleaning of Jira's user).
This limitation doesn;'t exist using gh.
So this problem of single party is just going away,
Jira has some features such as agile management, time estimation,
sprint planning etc..
But are we really using that? Do we really need that?
As far as I can see the usages are:
1. users or dev report a bug or a feature they would like to see
2. dev create a jira after having created a PR (because we said so....)
Then what do we do with that:
1. dev makes a comment and eventually assigns a fixed version. (which
GH just set a milestone)
2. I propose here to not have to create a Jira if a PR exists because
it is just duplicate paperwork.
just create the PR assign a millestone, everything is in the same
place no need to create another ticket somewhere else with the exact
same description as the PR
Github contributors are just used to that, it's simple and quick
no need to add the burden of creating another entry in the tool which
is not linked to the code you are happy to contribute to.
We should be happy to have people contributing to code directly.
And frankly once there is a PR created all the comments are made in
the PR the jira is not commented anymore at all
Using discussions sounds the same as stackoverflow or anything else,
just another channel of communication.
People have preferences and by the way this is the "mode" effect as
well... (same as https://gitter.im/ was trendy etc..)
It's just a matter of opening another channel, nothing else. Now we
just need to be sure we listen to it and answer it....
I was thinking of opening discussions here
https://github.com/apache/maven as it sounds like a more natural
naming convention Maven is at Apache so that sounds like an easy
typing url.
Users will figure out and probably ask questions as they can do using
user@maven.apache.org and ask questions on core and plugins.
but if you prefer something else why not. I'm just curious to see if
this will really attract people.
For sake of clarity, sending to ML does not need subscription, it's
possible to send an email without being subscribed, the post will only
need to be moderated and people can read answers in archives.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: GH issues and GH discussions
Posted by Michael Osipov <mi...@apache.org>.
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 barrier for "one off" users, many of our users want
> to ASK us about something, so going through hoops and loops above (and
> coming back 2 yr after with "please unsub me...") only to post a question
> is just a very bad experience.
>
> Moreover, we are very fragmented repository-wide, and I bet that a novice
> user will simply be lost:
> - WHERE (as in which Maven-* GH repo) to ask
> - WHERE (as in which Maven-* GH repo) to report issue
> - etc
>
> This is why I recommended "single entry point", a kind of dispatcher
> (discussion) repo/GH project, where one off users can hop on, ASK things
> and disappear if they like, receive answers where to go, and so on. And if
> they feel like it, they could join ML or register to JIRA, something TODAY
> EVERYONE WHO WANTS TO REACH OUT TO US must do. Hence, most "one off askers"
> would not go so far even.
>
> For me, most reasonable would be a new "discussion only" project, for
> example "apache/maven-project" on GH, that would contain no source, no
> issues, only discussions enabled and would serve as a "low barrier lobby"
> for newcomers.
>
> Opening discussions in _existing repository_ is unwise IMHO, as "general"
> discussions/questions do not belong to apache/maven, nor
> apache/maven-clean-plugin, nor any other existing repo.
I truly do like your idea and also agree with Lukasz -- never give up to
control to a single party, especially one like MS.
Upshot: One entry point with an empty repo.
Re: GH issues and GH discussions
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 ASK us about something, so going through hoops and loops above (and
coming back 2 yr after with "please unsub me...") only to post a question
is just a very bad experience.
Moreover, we are very fragmented repository-wide, and I bet that a novice
user will simply be lost:
- WHERE (as in which Maven-* GH repo) to ask
- WHERE (as in which Maven-* GH repo) to report issue
- etc
This is why I recommended "single entry point", a kind of dispatcher
(discussion) repo/GH project, where one off users can hop on, ASK things
and disappear if they like, receive answers where to go, and so on. And if
they feel like it, they could join ML or register to JIRA, something TODAY
EVERYONE WHO WANTS TO REACH OUT TO US must do. Hence, most "one off askers"
would not go so far even.
For me, most reasonable would be a new "discussion only" project, for
example "apache/maven-project" on GH, that would contain no source, no
issues, only discussions enabled and would serve as a "low barrier lobby"
for newcomers.
Opening discussions in _existing repository_ is unwise IMHO, as "general"
discussions/questions do not belong to apache/maven, nor
apache/maven-clean-plugin, nor any other existing repo.
Thanks
T
On Sat, May 27, 2023 at 11:24 AM Łukasz Dywicki <lu...@code-house.org> wrote:
> 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 GH database. If you ever found a google code
> project migrated into github/gitlab issues you know what I mean.
>
> While policies imposed on JIRA account creation, are without doubt a
> bearer to contribute first bug report, JIRA itself helps us keeping all
> ASF information together. Just to be clear - I keep being lost with new
> JIRA user interface, I'm just reflecting my personal thoughts.
>
> Best,
> Łukasz
>
> On 27.05.2023 09:30, Hervé Boutemy wrote:
> > 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 milestones mandatory in that case.
> > AFAIK, GH Milestones are useful when you want to assign an issue that is
> not
> > yet fixed
> > see for example https://github.com/apache/maven-mvnd/milestones
> >
> > But it does not seem absolutely necessary, since GH Release Notes will
> get the
> > release content once the issue is fixed
> > example: https://github.com/apache/maven-mvnd/releases
> >
> > We'll need to define which GH Labels are available, and how the release
> notes
> > drafter use it to have better release notes
> > https://github.com/apache/maven-mvnd/labels
> >
> >> It is far less work than maintaining an issue.
> >>
> >> Am Fr., 26. Mai 2023 um 09:44 Uhr schrieb Olivier Lamy <
> olamy@apache.org>:
> >>> Hi,
> >>> This has been already discussed in the past.
> >>> But due to recent changes in ASF Jira infrastructure (limitation of
> >>> Jira users, validation of account creation).
> >>> Maybe we could reconsider moving from Jira to GH issues and why not
> >>> simplify the workflow as well.
> >>> I imagine not having to create an issue if a PR exists first (sounds
> >>> like duplicate work).
> >>> By the way, release notes will be automatically created from PRs.
> >>> (could be manually modified if a change doesn't have a PR).
> >>>
> >>> Regarding migration, we can start project by project.
> >>> Few options:
> >>> - extreme simplicity, do not migrate any data (just mark the Jira
> >>> project as read only with a banner/link to corresponding gh issues).
> >>> If someone really needs an issue to get fixed he will clone it to GH
> >>> - middle complexity, migrate only open issues (components moved as a
> >>> label)
> >>> - extreme complexity, migrate all issues of a project (components
> >>> moved as a label and version created)
> >>>
> >>> We can start by small projects such as cache-extension and one plugin
> >>> (compiler?)
> >>>
> >>> Regarding GH discussions, maybe we can open discussions for
> >>> https://github.com/apache/maven which sounds like a natural place for
> >>> users to go. (discussions could be mirrored to a ML)
> >>> I do not have a strong opinion here, but I feel like opening
> >>> discussions for every single repo will be complicated to follow up.
> >>>
> >>> WDYT?
> >>>
> >>> cheers
> >>> Olivier
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: GH issues and GH discussions
Posted by Łukasz Dywicki <lu...@code-house.org>.
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 GH database. If you ever found a google code
project migrated into github/gitlab issues you know what I mean.
While policies imposed on JIRA account creation, are without doubt a
bearer to contribute first bug report, JIRA itself helps us keeping all
ASF information together. Just to be clear - I keep being lost with new
JIRA user interface, I'm just reflecting my personal thoughts.
Best,
Łukasz
On 27.05.2023 09:30, Hervé Boutemy wrote:
> 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 milestones mandatory in that case.
> AFAIK, GH Milestones are useful when you want to assign an issue that is not
> yet fixed
> see for example https://github.com/apache/maven-mvnd/milestones
>
> But it does not seem absolutely necessary, since GH Release Notes will get the
> release content once the issue is fixed
> example: https://github.com/apache/maven-mvnd/releases
>
> We'll need to define which GH Labels are available, and how the release notes
> drafter use it to have better release notes
> https://github.com/apache/maven-mvnd/labels
>
>> It is far less work than maintaining an issue.
>>
>> Am Fr., 26. Mai 2023 um 09:44 Uhr schrieb Olivier Lamy <ol...@apache.org>:
>>> Hi,
>>> This has been already discussed in the past.
>>> But due to recent changes in ASF Jira infrastructure (limitation of
>>> Jira users, validation of account creation).
>>> Maybe we could reconsider moving from Jira to GH issues and why not
>>> simplify the workflow as well.
>>> I imagine not having to create an issue if a PR exists first (sounds
>>> like duplicate work).
>>> By the way, release notes will be automatically created from PRs.
>>> (could be manually modified if a change doesn't have a PR).
>>>
>>> Regarding migration, we can start project by project.
>>> Few options:
>>> - extreme simplicity, do not migrate any data (just mark the Jira
>>> project as read only with a banner/link to corresponding gh issues).
>>> If someone really needs an issue to get fixed he will clone it to GH
>>> - middle complexity, migrate only open issues (components moved as a
>>> label)
>>> - extreme complexity, migrate all issues of a project (components
>>> moved as a label and version created)
>>>
>>> We can start by small projects such as cache-extension and one plugin
>>> (compiler?)
>>>
>>> Regarding GH discussions, maybe we can open discussions for
>>> https://github.com/apache/maven which sounds like a natural place for
>>> users to go. (discussions could be mirrored to a ML)
>>> I do not have a strong opinion here, but I feel like opening
>>> discussions for every single repo will be complicated to follow up.
>>>
>>> WDYT?
>>>
>>> cheers
>>> Olivier
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: GH issues and GH discussions
Posted by Hervé Boutemy <he...@free.fr>.
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 milestones mandatory in that case.
AFAIK, GH Milestones are useful when you want to assign an issue that is not
yet fixed
see for example https://github.com/apache/maven-mvnd/milestones
But it does not seem absolutely necessary, since GH Release Notes will get the
release content once the issue is fixed
example: https://github.com/apache/maven-mvnd/releases
We'll need to define which GH Labels are available, and how the release notes
drafter use it to have better release notes
https://github.com/apache/maven-mvnd/labels
> It is far less work than maintaining an issue.
>
> Am Fr., 26. Mai 2023 um 09:44 Uhr schrieb Olivier Lamy <ol...@apache.org>:
> > Hi,
> > This has been already discussed in the past.
> > But due to recent changes in ASF Jira infrastructure (limitation of
> > Jira users, validation of account creation).
> > Maybe we could reconsider moving from Jira to GH issues and why not
> > simplify the workflow as well.
> > I imagine not having to create an issue if a PR exists first (sounds
> > like duplicate work).
> > By the way, release notes will be automatically created from PRs.
> > (could be manually modified if a change doesn't have a PR).
> >
> > Regarding migration, we can start project by project.
> > Few options:
> > - extreme simplicity, do not migrate any data (just mark the Jira
> > project as read only with a banner/link to corresponding gh issues).
> > If someone really needs an issue to get fixed he will clone it to GH
> > - middle complexity, migrate only open issues (components moved as a
> > label)
> > - extreme complexity, migrate all issues of a project (components
> > moved as a label and version created)
> >
> > We can start by small projects such as cache-extension and one plugin
> > (compiler?)
> >
> > Regarding GH discussions, maybe we can open discussions for
> > https://github.com/apache/maven which sounds like a natural place for
> > users to go. (discussions could be mirrored to a ML)
> > I do not have a strong opinion here, but I feel like opening
> > discussions for every single repo will be complicated to follow up.
> >
> > WDYT?
> >
> > cheers
> > Olivier
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: GH issues and GH discussions
Posted by Benjamin Marwell <bm...@apache.org>.
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.
Am Fr., 26. Mai 2023 um 09:44 Uhr schrieb Olivier Lamy <ol...@apache.org>:
> Hi,
> This has been already discussed in the past.
> But due to recent changes in ASF Jira infrastructure (limitation of
> Jira users, validation of account creation).
> Maybe we could reconsider moving from Jira to GH issues and why not
> simplify the workflow as well.
> I imagine not having to create an issue if a PR exists first (sounds
> like duplicate work).
> By the way, release notes will be automatically created from PRs.
> (could be manually modified if a change doesn't have a PR).
>
> Regarding migration, we can start project by project.
> Few options:
> - extreme simplicity, do not migrate any data (just mark the Jira
> project as read only with a banner/link to corresponding gh issues).
> If someone really needs an issue to get fixed he will clone it to GH
> - middle complexity, migrate only open issues (components moved as a label)
> - extreme complexity, migrate all issues of a project (components
> moved as a label and version created)
>
> We can start by small projects such as cache-extension and one plugin
> (compiler?)
>
> Regarding GH discussions, maybe we can open discussions for
> https://github.com/apache/maven which sounds like a natural place for
> users to go. (discussions could be mirrored to a ML)
> I do not have a strong opinion here, but I feel like opening
> discussions for every single repo will be complicated to follow up.
>
> WDYT?
>
> cheers
> Olivier
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: GH issues and GH discussions
Posted by Olivier Lamy <ol...@apache.org>.
On Tue, 30 May 2023 at 00:04, Gary Gregory <ga...@gmail.com> 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 used here
https://github.com/eclipse/jetty.project/projects?query=is%3Aopen )
> Gary
>
> On Mon, May 29, 2023, 09:50 Christoph Läubrich <ma...@laeubi-soft.de> 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/
> > 2) for "subprojects" its usually better to discuss things close where
> > the code is
> >
> > Please note that some feature in GH do not work well across repositories
> > (e.g. embedding code snippets in issues), also I don't see any advantage
> > in scattering things around.
> >
> > Having a "central place "where contributors need to watch out and move
> > things around or need to find out what the topic is about will make
> > things more confusing, usually users are quite familiar with finding the
> > right place.
> >
> > If one wants to group things more, it would be better to have an
> > apache-maven organization on gihub and move all maven related there (the
> > one can also have organization readme, pinned repositories and so on),
> > this works quite well (e.g. Eclipse Foundation uses that approach).
> >
> > Am 29.05.23 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 general I agree to the tendency to use GH issues etc. instead of JIRA
> > > based on the hurdles which exists (for a lot of reasons)...
> > >
> > > I second Hervé's suggestion to write down the needed/practical steps ...
> > > and start going...what about things currently in JIRA and needed to be
> > > migrated moved etc. ..We have a large history in JIRA...
> > >
> > >
> > > 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 done later on...(for example using GH discussions etc.)
> > >
> > > afterwards we can decide with which project we would like to start and
> > > fiddle the details.
> > >
> > >
> > > Kind regards
> > > Karl Heinz Marbaise
> > >
> > > On 27.05.23 09:22, Hervé Boutemy wrote:
> > >> 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
> > >> there [2]
> > >>
> > >> we'll need to write down what practical steps such a migration requires
> > >> => probably a good fit for our Wiki, where we already organized
> > >> equivalent
> > >> updates in the past [3]
> > >>
> > >> on using GH discussions, I suppose this should be an independent next
> > >> discussion
> > >>
> > >>
> > >> [1] https://github.com/apache/maven-build-cache-extension
> > >>
> > >> [2] https://github.com/apache/maven-mvnd
> > >>
> > >> [3]
> > >> https://cwiki.apache.org/confluence/display/MAVEN/Maven+Infrastructure
> > >>
> > >> Le vendredi 26 mai 2023, 09:44:00 CEST Olivier Lamy a écrit :
> > >>> Hi,
> > >>> This has been already discussed in the past.
> > >>> But due to recent changes in ASF Jira infrastructure (limitation of
> > >>> Jira users, validation of account creation).
> > >>> Maybe we could reconsider moving from Jira to GH issues and why not
> > >>> simplify the workflow as well.
> > >>> I imagine not having to create an issue if a PR exists first (sounds
> > >>> like duplicate work).
> > >>> By the way, release notes will be automatically created from PRs.
> > >>> (could be manually modified if a change doesn't have a PR).
> > >>>
> > >>> Regarding migration, we can start project by project.
> > >>> Few options:
> > >>> - extreme simplicity, do not migrate any data (just mark the Jira
> > >>> project as read only with a banner/link to corresponding gh issues).
> > >>> If someone really needs an issue to get fixed he will clone it to GH
> > >>> - middle complexity, migrate only open issues (components moved as a
> > >>> label)
> > >>> - extreme complexity, migrate all issues of a project (components
> > >>> moved as a label and version created)
> > >>>
> > >>> We can start by small projects such as cache-extension and one plugin
> > >>> (compiler?)
> > >>>
> > >>> Regarding GH discussions, maybe we can open discussions for
> > >>> https://github.com/apache/maven which sounds like a natural place for
> > >>> users to go. (discussions could be mirrored to a ML)
> > >>> I do not have a strong opinion here, but I feel like opening
> > >>> discussions for every single repo will be complicated to follow up.
> > >>>
> > >>> WDYT?
> > >>>
> > >>> cheers
> > >>> Olivier
> > >>>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: GH issues and GH discussions
Posted by Gary Gregory <ga...@gmail.com>.
GH has the notion of "projects". Can't we use that?
Gary
On Mon, May 29, 2023, 09:50 Christoph Läubrich <ma...@laeubi-soft.de> 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/
> 2) for "subprojects" its usually better to discuss things close where
> the code is
>
> Please note that some feature in GH do not work well across repositories
> (e.g. embedding code snippets in issues), also I don't see any advantage
> in scattering things around.
>
> Having a "central place "where contributors need to watch out and move
> things around or need to find out what the topic is about will make
> things more confusing, usually users are quite familiar with finding the
> right place.
>
> If one wants to group things more, it would be better to have an
> apache-maven organization on gihub and move all maven related there (the
> one can also have organization readme, pinned repositories and so on),
> this works quite well (e.g. Eclipse Foundation uses that approach).
>
> Am 29.05.23 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 general I agree to the tendency to use GH issues etc. instead of JIRA
> > based on the hurdles which exists (for a lot of reasons)...
> >
> > I second Hervé's suggestion to write down the needed/practical steps ...
> > and start going...what about things currently in JIRA and needed to be
> > migrated moved etc. ..We have a large history in JIRA...
> >
> >
> > 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 done later on...(for example using GH discussions etc.)
> >
> > afterwards we can decide with which project we would like to start and
> > fiddle the details.
> >
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > On 27.05.23 09:22, Hervé Boutemy wrote:
> >> 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
> >> there [2]
> >>
> >> we'll need to write down what practical steps such a migration requires
> >> => probably a good fit for our Wiki, where we already organized
> >> equivalent
> >> updates in the past [3]
> >>
> >> on using GH discussions, I suppose this should be an independent next
> >> discussion
> >>
> >>
> >> [1] https://github.com/apache/maven-build-cache-extension
> >>
> >> [2] https://github.com/apache/maven-mvnd
> >>
> >> [3]
> >> https://cwiki.apache.org/confluence/display/MAVEN/Maven+Infrastructure
> >>
> >> Le vendredi 26 mai 2023, 09:44:00 CEST Olivier Lamy a écrit :
> >>> Hi,
> >>> This has been already discussed in the past.
> >>> But due to recent changes in ASF Jira infrastructure (limitation of
> >>> Jira users, validation of account creation).
> >>> Maybe we could reconsider moving from Jira to GH issues and why not
> >>> simplify the workflow as well.
> >>> I imagine not having to create an issue if a PR exists first (sounds
> >>> like duplicate work).
> >>> By the way, release notes will be automatically created from PRs.
> >>> (could be manually modified if a change doesn't have a PR).
> >>>
> >>> Regarding migration, we can start project by project.
> >>> Few options:
> >>> - extreme simplicity, do not migrate any data (just mark the Jira
> >>> project as read only with a banner/link to corresponding gh issues).
> >>> If someone really needs an issue to get fixed he will clone it to GH
> >>> - middle complexity, migrate only open issues (components moved as a
> >>> label)
> >>> - extreme complexity, migrate all issues of a project (components
> >>> moved as a label and version created)
> >>>
> >>> We can start by small projects such as cache-extension and one plugin
> >>> (compiler?)
> >>>
> >>> Regarding GH discussions, maybe we can open discussions for
> >>> https://github.com/apache/maven which sounds like a natural place for
> >>> users to go. (discussions could be mirrored to a ML)
> >>> I do not have a strong opinion here, but I feel like opening
> >>> discussions for every single repo will be complicated to follow up.
> >>>
> >>> WDYT?
> >>>
> >>> cheers
> >>> Olivier
> >>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: GH issues and GH discussions
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
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 itself (maven
core)... which will produce much more confusion from my POV.
> 2) for "subprojects" its usually better to discuss things close where
> the code is
In general yes ... but unfortunately many people do not see the need
focus for that...(https://maven.apache.org/plugins/) shows every project
with link to appropriate GH projects etc...
>
> Please note that some feature in GH do not work well across repositories
> (e.g. embedding code snippets in issues), also I don't see any advantage
> in scattering things around.
Yes that is a real problem with GH issues etc.
>
> Having a "central place "where contributors need to watch out and move
> things around or need to find out what the topic is about will make
> things more confusing, usually users are quite familiar with finding the
> right place.
I have different experiences...
>
> If one wants to group things more, it would be better to have an
> apache-maven organization on gihub and move all maven related there (the
> one can also have organization readme, pinned repositories and so on),
> this works quite well (e.g. Eclipse Foundation uses that approach).
Yes that might be a better solution going via a Apache Maven Project
Organisation ... +1 for that...
But in the end it will not solve the problem to redirect the people to
the "correct" project....
Kind regards
Karl Heinz Marbase
>
> Am 29.05.23 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 general I agree to the tendency to use GH issues etc. instead of JIRA
>> based on the hurdles which exists (for a lot of reasons)...
>>
>> I second Hervé's suggestion to write down the needed/practical steps ...
>> and start going...what about things currently in JIRA and needed to be
>> migrated moved etc. ..We have a large history in JIRA...
>>
>>
>> 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 done later on...(for example using GH discussions etc.)
>>
>> afterwards we can decide with which project we would like to start and
>> fiddle the details.
>>
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> On 27.05.23 09:22, Hervé Boutemy wrote:
>>> 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
>>> there [2]
>>>
>>> we'll need to write down what practical steps such a migration requires
>>> => probably a good fit for our Wiki, where we already organized
>>> equivalent
>>> updates in the past [3]
>>>
>>> on using GH discussions, I suppose this should be an independent next
>>> discussion
>>>
>>>
>>> [1] https://github.com/apache/maven-build-cache-extension
>>>
>>> [2] https://github.com/apache/maven-mvnd
>>>
>>> [3]
>>> https://cwiki.apache.org/confluence/display/MAVEN/Maven+Infrastructure
>>>
>>> Le vendredi 26 mai 2023, 09:44:00 CEST Olivier Lamy a écrit :
>>>> Hi,
>>>> This has been already discussed in the past.
>>>> But due to recent changes in ASF Jira infrastructure (limitation of
>>>> Jira users, validation of account creation).
>>>> Maybe we could reconsider moving from Jira to GH issues and why not
>>>> simplify the workflow as well.
>>>> I imagine not having to create an issue if a PR exists first (sounds
>>>> like duplicate work).
>>>> By the way, release notes will be automatically created from PRs.
>>>> (could be manually modified if a change doesn't have a PR).
>>>>
>>>> Regarding migration, we can start project by project.
>>>> Few options:
>>>> - extreme simplicity, do not migrate any data (just mark the Jira
>>>> project as read only with a banner/link to corresponding gh issues).
>>>> If someone really needs an issue to get fixed he will clone it to GH
>>>> - middle complexity, migrate only open issues (components moved as a
>>>> label)
>>>> - extreme complexity, migrate all issues of a project (components
>>>> moved as a label and version created)
>>>>
>>>> We can start by small projects such as cache-extension and one plugin
>>>> (compiler?)
>>>>
>>>> Regarding GH discussions, maybe we can open discussions for
>>>> https://github.com/apache/maven which sounds like a natural place for
>>>> users to go. (discussions could be mirrored to a ML)
>>>> I do not have a strong opinion here, but I feel like opening
>>>> discussions for every single repo will be complicated to follow up.
>>>>
>>>> WDYT?
>>>>
>>>> cheers
>>>> Olivier
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: GH issues and GH discussions
Posted by Christoph Läubrich <ma...@laeubi-soft.de>.
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 feature in GH do not work well across repositories
(e.g. embedding code snippets in issues), also I don't see any advantage
in scattering things around.
Having a "central place "where contributors need to watch out and move
things around or need to find out what the topic is about will make
things more confusing, usually users are quite familiar with finding the
right place.
If one wants to group things more, it would be better to have an
apache-maven organization on gihub and move all maven related there (the
one can also have organization readme, pinned repositories and so on),
this works quite well (e.g. Eclipse Foundation uses that approach).
Am 29.05.23 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 general I agree to the tendency to use GH issues etc. instead of JIRA
> based on the hurdles which exists (for a lot of reasons)...
>
> I second Hervé's suggestion to write down the needed/practical steps ...
> and start going...what about things currently in JIRA and needed to be
> migrated moved etc. ..We have a large history in JIRA...
>
>
> 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 done later on...(for example using GH discussions etc.)
>
> afterwards we can decide with which project we would like to start and
> fiddle the details.
>
>
> Kind regards
> Karl Heinz Marbaise
>
> On 27.05.23 09:22, Hervé Boutemy wrote:
>> 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
>> there [2]
>>
>> we'll need to write down what practical steps such a migration requires
>> => probably a good fit for our Wiki, where we already organized
>> equivalent
>> updates in the past [3]
>>
>> on using GH discussions, I suppose this should be an independent next
>> discussion
>>
>>
>> [1] https://github.com/apache/maven-build-cache-extension
>>
>> [2] https://github.com/apache/maven-mvnd
>>
>> [3]
>> https://cwiki.apache.org/confluence/display/MAVEN/Maven+Infrastructure
>>
>> Le vendredi 26 mai 2023, 09:44:00 CEST Olivier Lamy a écrit :
>>> Hi,
>>> This has been already discussed in the past.
>>> But due to recent changes in ASF Jira infrastructure (limitation of
>>> Jira users, validation of account creation).
>>> Maybe we could reconsider moving from Jira to GH issues and why not
>>> simplify the workflow as well.
>>> I imagine not having to create an issue if a PR exists first (sounds
>>> like duplicate work).
>>> By the way, release notes will be automatically created from PRs.
>>> (could be manually modified if a change doesn't have a PR).
>>>
>>> Regarding migration, we can start project by project.
>>> Few options:
>>> - extreme simplicity, do not migrate any data (just mark the Jira
>>> project as read only with a banner/link to corresponding gh issues).
>>> If someone really needs an issue to get fixed he will clone it to GH
>>> - middle complexity, migrate only open issues (components moved as a
>>> label)
>>> - extreme complexity, migrate all issues of a project (components
>>> moved as a label and version created)
>>>
>>> We can start by small projects such as cache-extension and one plugin
>>> (compiler?)
>>>
>>> Regarding GH discussions, maybe we can open discussions for
>>> https://github.com/apache/maven which sounds like a natural place for
>>> users to go. (discussions could be mirrored to a ML)
>>> I do not have a strong opinion here, but I feel like opening
>>> discussions for every single repo will be complicated to follow up.
>>>
>>> WDYT?
>>>
>>> cheers
>>> Olivier
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: GH issues and GH discussions
Posted by Olivier Lamy <ol...@apache.org>.
On Tue, 30 May 2023 at 01:44, Hervé Boutemy <he...@free.fr> 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 leave JIRA behind... (not about the details) that
> > can be done later on...(for example using GH discussions etc.)
> >
> > afterwards we can decide with which project we would like to start and
> > fiddle the details.
>
> I'd do it the exact opposite order:
> - test first Jira to GH for a few projects
> - clarify Users ML replacement with GH Discussion (IIUC, this is what the GH
> discussion looks like, but I did not yet understand fuly: i have no
> experience, sharing examples would be useful)
We cannot replace Users ML; it should stay and be a mirror of GH discussions.
Various reasons:
- subscription to a third party provider is mandatory for GH
discussions whereas you can post a question to uers@ without
registration. Not convenient I agree because you have to wait for
moderation and consult the ML website but some users may still want
freedom of non registration.
- GH is not available in some countries. We will already prevent them
from creating issues because of moving to GH issues so we should leave
them at least one option to reach to us.
>
> and only once we found the right way to do one or the other, vote for making
> the real move
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: GH issues and GH discussions
Posted by Hervé Boutemy <he...@free.fr>.
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 done later on...(for example using GH discussions etc.)
>
> afterwards we can decide with which project we would like to start and
> fiddle the details.
I'd do it the exact opposite order:
- test first Jira to GH for a few projects
- clarify Users ML replacement with GH Discussion (IIUC, this is what the GH
discussion looks like, but I did not yet understand fuly: i have no
experience, sharing examples would be useful)
and only once we found the right way to do one or the other, vote for making
the real move
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: GH issues and GH discussions
Posted by Olivier Lamy <ol...@apache.org>.
On Mon, 29 May 2023 at 21:51, Karl Heinz Marbaise <kh...@gmx.de> 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
> github repos...
>
we can;t really get rid of ML user or dev.
Is it what you mean here?
>
> In general I agree to the tendency to use GH issues etc. instead of JIRA
> based on the hurdles which exists (for a lot of reasons)...
>
> I second Hervé's suggestion to write down the needed/practical steps ...
> and start going...what about things currently in JIRA and needed to be
> migrated moved etc. ..We have a large history in JIRA...
>
>
> 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 done later on...(for example using GH discussions etc.)
>
> afterwards we can decide with which project we would like to start and
> fiddle the details.
>
>
> Kind regards
> Karl Heinz Marbaise
>
> On 27.05.23 09:22, Hervé Boutemy wrote:
> > 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 there [2]
> >
> > we'll need to write down what practical steps such a migration requires
> > => probably a good fit for our Wiki, where we already organized equivalent
> > updates in the past [3]
> >
> > on using GH discussions, I suppose this should be an independent next
> > discussion
> >
> >
> > [1] https://github.com/apache/maven-build-cache-extension
> >
> > [2] https://github.com/apache/maven-mvnd
> >
> > [3] https://cwiki.apache.org/confluence/display/MAVEN/Maven+Infrastructure
> >
> > Le vendredi 26 mai 2023, 09:44:00 CEST Olivier Lamy a écrit :
> >> Hi,
> >> This has been already discussed in the past.
> >> But due to recent changes in ASF Jira infrastructure (limitation of
> >> Jira users, validation of account creation).
> >> Maybe we could reconsider moving from Jira to GH issues and why not
> >> simplify the workflow as well.
> >> I imagine not having to create an issue if a PR exists first (sounds
> >> like duplicate work).
> >> By the way, release notes will be automatically created from PRs.
> >> (could be manually modified if a change doesn't have a PR).
> >>
> >> Regarding migration, we can start project by project.
> >> Few options:
> >> - extreme simplicity, do not migrate any data (just mark the Jira
> >> project as read only with a banner/link to corresponding gh issues).
> >> If someone really needs an issue to get fixed he will clone it to GH
> >> - middle complexity, migrate only open issues (components moved as a label)
> >> - extreme complexity, migrate all issues of a project (components
> >> moved as a label and version created)
> >>
> >> We can start by small projects such as cache-extension and one plugin
> >> (compiler?)
> >>
> >> Regarding GH discussions, maybe we can open discussions for
> >> https://github.com/apache/maven which sounds like a natural place for
> >> users to go. (discussions could be mirrored to a ML)
> >> I do not have a strong opinion here, but I feel like opening
> >> discussions for every single repo will be complicated to follow up.
> >>
> >> WDYT?
> >>
> >> cheers
> >> Olivier
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: GH issues and GH discussions
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
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 to the appropriate
>> github repos...
>>
>>
>> In general I agree to the tendency to use GH issues etc. instead of JIRA
>> based on the hurdles which exists (for a lot of reasons)...
>>
>> I second Hervé's suggestion to write down the needed/practical steps ...
>> and start going...what about things currently in JIRA and needed to be
>> migrated moved etc. ..We have a large history in JIRA...
>>
>>
>> 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 done later on...(for example using GH discussions etc.)
>>
>> afterwards we can decide with which project we would like to start and
>> fiddle the details.
>
> Before we do that, we need to aggressively go through all tickets and
> closes issues which we will never address or are invalid by now.
>
> M
Yep good idea +1 for that.
Kind regards
Karl Heinz Marbaise
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: GH issues and GH discussions
Posted by Michael Osipov <mi...@apache.org>.
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 general I agree to the tendency to use GH issues etc. instead of JIRA
> based on the hurdles which exists (for a lot of reasons)...
>
> I second Hervé's suggestion to write down the needed/practical steps ...
> and start going...what about things currently in JIRA and needed to be
> migrated moved etc. ..We have a large history in JIRA...
>
>
> 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 done later on...(for example using GH discussions etc.)
>
> afterwards we can decide with which project we would like to start and
> fiddle the details.
Before we do that, we need to aggressively go through all tickets and
closes issues which we will never address or are invalid by now.
M
Re: GH issues and GH discussions
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
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. instead of JIRA
based on the hurdles which exists (for a lot of reasons)...
I second Hervé's suggestion to write down the needed/practical steps ...
and start going...what about things currently in JIRA and needed to be
migrated moved etc. ..We have a large history in JIRA...
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 done later on...(for example using GH discussions etc.)
afterwards we can decide with which project we would like to start and
fiddle the details.
Kind regards
Karl Heinz Marbaise
On 27.05.23 09:22, Hervé Boutemy wrote:
> 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 there [2]
>
> we'll need to write down what practical steps such a migration requires
> => probably a good fit for our Wiki, where we already organized equivalent
> updates in the past [3]
>
> on using GH discussions, I suppose this should be an independent next
> discussion
>
>
> [1] https://github.com/apache/maven-build-cache-extension
>
> [2] https://github.com/apache/maven-mvnd
>
> [3] https://cwiki.apache.org/confluence/display/MAVEN/Maven+Infrastructure
>
> Le vendredi 26 mai 2023, 09:44:00 CEST Olivier Lamy a écrit :
>> Hi,
>> This has been already discussed in the past.
>> But due to recent changes in ASF Jira infrastructure (limitation of
>> Jira users, validation of account creation).
>> Maybe we could reconsider moving from Jira to GH issues and why not
>> simplify the workflow as well.
>> I imagine not having to create an issue if a PR exists first (sounds
>> like duplicate work).
>> By the way, release notes will be automatically created from PRs.
>> (could be manually modified if a change doesn't have a PR).
>>
>> Regarding migration, we can start project by project.
>> Few options:
>> - extreme simplicity, do not migrate any data (just mark the Jira
>> project as read only with a banner/link to corresponding gh issues).
>> If someone really needs an issue to get fixed he will clone it to GH
>> - middle complexity, migrate only open issues (components moved as a label)
>> - extreme complexity, migrate all issues of a project (components
>> moved as a label and version created)
>>
>> We can start by small projects such as cache-extension and one plugin
>> (compiler?)
>>
>> Regarding GH discussions, maybe we can open discussions for
>> https://github.com/apache/maven which sounds like a natural place for
>> users to go. (discussions could be mirrored to a ML)
>> I do not have a strong opinion here, but I feel like opening
>> discussions for every single repo will be complicated to follow up.
>>
>> WDYT?
>>
>> cheers
>> Olivier
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: GH issues and GH discussions
Posted by Hervé Boutemy <he...@free.fr>.
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 there [2]
we'll need to write down what practical steps such a migration requires
=> probably a good fit for our Wiki, where we already organized equivalent
updates in the past [3]
on using GH discussions, I suppose this should be an independent next
discussion
[1] https://github.com/apache/maven-build-cache-extension
[2] https://github.com/apache/maven-mvnd
[3] https://cwiki.apache.org/confluence/display/MAVEN/Maven+Infrastructure
Le vendredi 26 mai 2023, 09:44:00 CEST Olivier Lamy a écrit :
> Hi,
> This has been already discussed in the past.
> But due to recent changes in ASF Jira infrastructure (limitation of
> Jira users, validation of account creation).
> Maybe we could reconsider moving from Jira to GH issues and why not
> simplify the workflow as well.
> I imagine not having to create an issue if a PR exists first (sounds
> like duplicate work).
> By the way, release notes will be automatically created from PRs.
> (could be manually modified if a change doesn't have a PR).
>
> Regarding migration, we can start project by project.
> Few options:
> - extreme simplicity, do not migrate any data (just mark the Jira
> project as read only with a banner/link to corresponding gh issues).
> If someone really needs an issue to get fixed he will clone it to GH
> - middle complexity, migrate only open issues (components moved as a label)
> - extreme complexity, migrate all issues of a project (components
> moved as a label and version created)
>
> We can start by small projects such as cache-extension and one plugin
> (compiler?)
>
> Regarding GH discussions, maybe we can open discussions for
> https://github.com/apache/maven which sounds like a natural place for
> users to go. (discussions could be mirrored to a ML)
> I do not have a strong opinion here, but I feel like opening
> discussions for every single repo will be complicated to follow up.
>
> WDYT?
>
> cheers
> Olivier
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org