You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Vladimir Sitnikov <si...@gmail.com> on 2021/11/25 11:09:38 UTC

DISCUSS: Bugzilla vs JIRA vs GitHub issues

Hi,

Does anybody have a strong opinion regarding Bugzilla vs JIRA vs GitHub
issues?

Frankly speaking, I am inclined to migrate to GitHub Issues or to the ASF
JIRA.

I have no strong opinion between JIRA vs GitHub Issues, however, the
current JMeter development workflow is pull-request centric,
so GitHub Issues would be easier for me.

Let us try the following vote (see https://rangevoting.org/ ):
-1..+1 keep using Bugzilla for issue management
-1..+1 migrate to GitHub Issues
-1..+1 migrate to ASF JIRA

Here's my vote:
-0.8 keep using Bugzilla
+1 migrate to GitHub Issues
+0.8 migrate to ASF JIRA

AFAIK there is no automatic issue migration, so any change would involve
dealing with issues somehow.
AFAIK there are no legal implications, so we can use either issue tracking
system.

Bugzilla:
Pros:
* It worked more-or-less fine for ages
Cons:
* Bugzilla is less widespread at the moment. I think only 10 or so ASF
projects are listed at https://bz.apache.org/bugzilla/enter_bug.cgi
* There's no integration between pull requests and issues

GitHub issues:
Pros:
* GitHub issues integrate well with pull requests and discussions. I think
the vast majority of contributions come via pull requests
* It is probably easier for external contributors. In practice, GitHub is a
de-facto standard now
* Issues integrate well with GitHub Actions. We do not use it extensively,
however, I think we can label issues/prs, and things like that
* Query language is more or less known (for instance, I do use
https://github.com/gradle/gradle/issues a lot)
* Rich comment formatting: code samples, images
Cons:
* Only 20 external collaborators for issue triage (see
https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-AssigningexternalcollaboratorswiththetriageroleonGitHub
 )
* Non-ASF-hosted solution. I think this is a low risk.

JIRA:
Pros:
* Other ASF projects use JIRA. For example, INFRA. So PMCs and committers
can't really avoid JIRA :)
* It works more-or-less well for Apache Calcite (I'm a member of PMC for
Calcite)
* Query language is more or less known
* Search can find similar cases across different ASF projects. For
instance, I used ASF JIRA to figure out how (and which) projects enable
GitHub Discussions.
* Rich comment formatting: code samples, images
* Non-committers can get access to JIRA for issue triage
* ASF-hosted solution. We are safe if GitHub adds limits in the future
(e.g. "no more than 20 repos per organization")
Cons:
* Somebody might think JIRA is "heavyweight", however, it looks like the
last couple of years ASF JIRA works just fine

Vladimir

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

Posted by Vladimir Sitnikov <si...@gmail.com>.
Nice.
It looks like it might be worth trying GitHub issues.

>but what happens if at some step we have to leave github

INFRA team has scripts for importing GitHub history to ASF JIRA.

----

Any thoughts on the migration of the old issues?
Do we need to migrate comments from Bugzilla to GitHub first?
Could we just make Bugzilla read-only and continue with GitHub?

Here's a story how Coq migrated 4000 bugs from Bugzilla to GitHub:
https://www.theozimmermann.net/2017/10/bugzilla-to-github/
They used a beta issue import API (regular APIs have tight rate limits), so
there might be glitches now.
Here's one of the resulting issues: https://github.com/coq/coq/issues/2268

The current JMeter issue summary is
 408 NEW
  30 REOPENED
  94 NEEDINFO
3994 RESOLVED
   6 VERIFIED
 321 CLOSED
4853 Total

Vladimir

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

Posted by Philippe Mouawad <p....@ubik-ingenierie.com>.
Hello,
My discussion "vote" is
+1 keep Bugzilla (not much work for me, and it works for me really well)
-1 JIRA (I find it very slow last time I used it)
+1 Github Issues (but what happens if at some step we have to leave github
provided we don"t loose bugzilla history)

Regards
Philippe

On Thu, Nov 25, 2021 at 5:05 PM Felix Schumacher <
felix.schumacher@internetallee.de> wrote:

> My discussion "vote" is
>
> +1 keep Bugzilla (not much work for me, and it works for me really well)
> -0.8 JIRA (I find it difficult to use)
> +0.5 Github Issues (they seem to be lightweight enough to be
> understandable by me, but I fear, that we would loose a lot of old
> issues (which might be a good thing))
>
> Felix
>
> Am 25.11.21 um 12:09 schrieb Vladimir Sitnikov:
> > Hi,
> >
> > Does anybody have a strong opinion regarding Bugzilla vs JIRA vs GitHub
> > issues?
> >
> > Frankly speaking, I am inclined to migrate to GitHub Issues or to the ASF
> > JIRA.
> >
> > I have no strong opinion between JIRA vs GitHub Issues, however, the
> > current JMeter development workflow is pull-request centric,
> > so GitHub Issues would be easier for me.
> >
> > Let us try the following vote (see https://rangevoting.org/ ):
> > -1..+1 keep using Bugzilla for issue management
> > -1..+1 migrate to GitHub Issues
> > -1..+1 migrate to ASF JIRA
> >
> > Here's my vote:
> > -0.8 keep using Bugzilla
> > +1 migrate to GitHub Issues
> > +0.8 migrate to ASF JIRA
> >
> > AFAIK there is no automatic issue migration, so any change would involve
> > dealing with issues somehow.
> > AFAIK there are no legal implications, so we can use either issue
> tracking
> > system.
> >
> > Bugzilla:
> > Pros:
> > * It worked more-or-less fine for ages
> > Cons:
> > * Bugzilla is less widespread at the moment. I think only 10 or so ASF
> > projects are listed at https://bz.apache.org/bugzilla/enter_bug.cgi
> > * There's no integration between pull requests and issues
> >
> > GitHub issues:
> > Pros:
> > * GitHub issues integrate well with pull requests and discussions. I
> think
> > the vast majority of contributions come via pull requests
> > * It is probably easier for external contributors. In practice, GitHub
> is a
> > de-facto standard now
> > * Issues integrate well with GitHub Actions. We do not use it
> extensively,
> > however, I think we can label issues/prs, and things like that
> > * Query language is more or less known (for instance, I do use
> > https://github.com/gradle/gradle/issues a lot)
> > * Rich comment formatting: code samples, images
> > Cons:
> > * Only 20 external collaborators for issue triage (see
> >
> https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-AssigningexternalcollaboratorswiththetriageroleonGitHub
> >  )
> > * Non-ASF-hosted solution. I think this is a low risk.
> >
> > JIRA:
> > Pros:
> > * Other ASF projects use JIRA. For example, INFRA. So PMCs and committers
> > can't really avoid JIRA :)
> > * It works more-or-less well for Apache Calcite (I'm a member of PMC for
> > Calcite)
> > * Query language is more or less known
> > * Search can find similar cases across different ASF projects. For
> > instance, I used ASF JIRA to figure out how (and which) projects enable
> > GitHub Discussions.
> > * Rich comment formatting: code samples, images
> > * Non-committers can get access to JIRA for issue triage
> > * ASF-hosted solution. We are safe if GitHub adds limits in the future
> > (e.g. "no more than 20 repos per organization")
> > Cons:
> > * Somebody might think JIRA is "heavyweight", however, it looks like the
> > last couple of years ASF JIRA works just fine
> >
> > Vladimir
> >
>
>

-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

Posted by Felix Schumacher <fe...@internetallee.de>.
My discussion "vote" is

+1 keep Bugzilla (not much work for me, and it works for me really well)
-0.8 JIRA (I find it difficult to use)
+0.5 Github Issues (they seem to be lightweight enough to be
understandable by me, but I fear, that we would loose a lot of old
issues (which might be a good thing))

Felix

Am 25.11.21 um 12:09 schrieb Vladimir Sitnikov:
> Hi,
>
> Does anybody have a strong opinion regarding Bugzilla vs JIRA vs GitHub
> issues?
>
> Frankly speaking, I am inclined to migrate to GitHub Issues or to the ASF
> JIRA.
>
> I have no strong opinion between JIRA vs GitHub Issues, however, the
> current JMeter development workflow is pull-request centric,
> so GitHub Issues would be easier for me.
>
> Let us try the following vote (see https://rangevoting.org/ ):
> -1..+1 keep using Bugzilla for issue management
> -1..+1 migrate to GitHub Issues
> -1..+1 migrate to ASF JIRA
>
> Here's my vote:
> -0.8 keep using Bugzilla
> +1 migrate to GitHub Issues
> +0.8 migrate to ASF JIRA
>
> AFAIK there is no automatic issue migration, so any change would involve
> dealing with issues somehow.
> AFAIK there are no legal implications, so we can use either issue tracking
> system.
>
> Bugzilla:
> Pros:
> * It worked more-or-less fine for ages
> Cons:
> * Bugzilla is less widespread at the moment. I think only 10 or so ASF
> projects are listed at https://bz.apache.org/bugzilla/enter_bug.cgi
> * There's no integration between pull requests and issues
>
> GitHub issues:
> Pros:
> * GitHub issues integrate well with pull requests and discussions. I think
> the vast majority of contributions come via pull requests
> * It is probably easier for external contributors. In practice, GitHub is a
> de-facto standard now
> * Issues integrate well with GitHub Actions. We do not use it extensively,
> however, I think we can label issues/prs, and things like that
> * Query language is more or less known (for instance, I do use
> https://github.com/gradle/gradle/issues a lot)
> * Rich comment formatting: code samples, images
> Cons:
> * Only 20 external collaborators for issue triage (see
> https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-AssigningexternalcollaboratorswiththetriageroleonGitHub
>  )
> * Non-ASF-hosted solution. I think this is a low risk.
>
> JIRA:
> Pros:
> * Other ASF projects use JIRA. For example, INFRA. So PMCs and committers
> can't really avoid JIRA :)
> * It works more-or-less well for Apache Calcite (I'm a member of PMC for
> Calcite)
> * Query language is more or less known
> * Search can find similar cases across different ASF projects. For
> instance, I used ASF JIRA to figure out how (and which) projects enable
> GitHub Discussions.
> * Rich comment formatting: code samples, images
> * Non-committers can get access to JIRA for issue triage
> * ASF-hosted solution. We are safe if GitHub adds limits in the future
> (e.g. "no more than 20 repos per organization")
> Cons:
> * Somebody might think JIRA is "heavyweight", however, it looks like the
> last couple of years ASF JIRA works just fine
>
> Vladimir
>


Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

Posted by OUFDOU Anas <ao...@sqli.com>.
my vote

0 keep using Bugzilla
+1 migrate to GitHub Issues
+0.5 migrate to ASF JIRA

On Thu, Nov 25, 2021 at 12:10 PM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:

> Hi,
>
> Does anybody have a strong opinion regarding Bugzilla vs JIRA vs GitHub
> issues?
>
> Frankly speaking, I am inclined to migrate to GitHub Issues or to the ASF
> JIRA.
>
> I have no strong opinion between JIRA vs GitHub Issues, however, the
> current JMeter development workflow is pull-request centric,
> so GitHub Issues would be easier for me.
>
> Let us try the following vote (see https://rangevoting.org/ ):
> -1..+1 keep using Bugzilla for issue management
> -1..+1 migrate to GitHub Issues
> -1..+1 migrate to ASF JIRA
>
> Here's my vote:
> -0.8 keep using Bugzilla
> +1 migrate to GitHub Issues
> +0.8 migrate to ASF JIRA
>
> AFAIK there is no automatic issue migration, so any change would involve
> dealing with issues somehow.
> AFAIK there are no legal implications, so we can use either issue tracking
> system.
>
> Bugzilla:
> Pros:
> * It worked more-or-less fine for ages
> Cons:
> * Bugzilla is less widespread at the moment. I think only 10 or so ASF
> projects are listed at https://bz.apache.org/bugzilla/enter_bug.cgi
> * There's no integration between pull requests and issues
>
> GitHub issues:
> Pros:
> * GitHub issues integrate well with pull requests and discussions. I think
> the vast majority of contributions come via pull requests
> * It is probably easier for external contributors. In practice, GitHub is a
> de-facto standard now
> * Issues integrate well with GitHub Actions. We do not use it extensively,
> however, I think we can label issues/prs, and things like that
> * Query language is more or less known (for instance, I do use
> https://github.com/gradle/gradle/issues a lot)
> * Rich comment formatting: code samples, images
> Cons:
> * Only 20 external collaborators for issue triage (see
>
> https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-AssigningexternalcollaboratorswiththetriageroleonGitHub
>  )
> * Non-ASF-hosted solution. I think this is a low risk.
>
> JIRA:
> Pros:
> * Other ASF projects use JIRA. For example, INFRA. So PMCs and committers
> can't really avoid JIRA :)
> * It works more-or-less well for Apache Calcite (I'm a member of PMC for
> Calcite)
> * Query language is more or less known
> * Search can find similar cases across different ASF projects. For
> instance, I used ASF JIRA to figure out how (and which) projects enable
> GitHub Discussions.
> * Rich comment formatting: code samples, images
> * Non-committers can get access to JIRA for issue triage
> * ASF-hosted solution. We are safe if GitHub adds limits in the future
> (e.g. "no more than 20 repos per organization")
> Cons:
> * Somebody might think JIRA is "heavyweight", however, it looks like the
> last couple of years ASF JIRA works just fine
>
> Vladimir
>

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

Posted by Vladimir Sitnikov <si...@gmail.com>.
I've conflated "os" labels to All, macOS, Windows, Linux (full OS is
present in text),
I've removed the severity label completely (it is in text only). I keep
just "enhancement" and "regression" as labels.
I've simplified priority labels. They are P1, P2, ... instead of "priority:
P1", "priority: P2", ...
I've removed the resolution label and converted it as follows (I use the
default GitHub labels here):
    INVALID, WORKSFORME -> invalid
    DUPLICATE -> duplicate
    WONTFIX -> wontfix

The migration is running at https://github.com/vlsi/tmp-jmeter-issues/issues

It looks good to me.
Is there anything else we should consider/update during the migration?

Vladimir

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

Posted by G Russell <gr...@ham1.co.uk>.
Firstly, thanks for all your work on this!

1) I agree, we should combine them (if it's not too much effort).
The exact details e.g. versions (and architecture) should be in the bug anyway?
Or maybe, remove them completely (just keep it in the text)?
Does anyone use them for filtering?

2) I would agree to simplify, but again, maybe just drop them both (just keep them in the text)?
Does anyone use them now?

Graham

On Tue, 16 Aug 2022, at 21:07, Vladimir Sitnikov wrote:
> Update:
> * I've implemented Bugzilla milestones -> GitHub milestones conversion
> * I've added links to GitHub profiles
> * I've removed issue headers, and moved attachments to comment footers, so
> issues look pretty much the same as if they were manually created at GitHub
> * I've removed "bugzilla" label as it was more like a noise
> * I've removed "status" label as we do not need statuses like closed, open,
> reopened, etc (GitHub already shows if the issue is open or not). The only
> status I convey now is "need-info"
> * I've added the links from each comment in GitHub to the comment in
> Bugzilla. I think it might be handy if the markup conversion wents bad for
> some issues.
>
> ---
>
> I do not fully like the set of generated labels though.
>
> Remember, that only committers and explicitly mentioned collaborators would
> be able to adjust labels in GitHub.
>
> 1) Bugzilla has many values for operating systems, and I do not think
> labels like "os: Mac OS X 10.3" make sense for GitHub issues.
> I'm inclined to conflate the set of values to something like "os: macOS",
> "os: Windows", "os: GNU/Linux".
>
> 2) I'm not sure we need both priority (P1, P2,...), and severity (major,
> minor, ...)
> Any thoughts here? I'm inclined to drop severity label, and keep it within
> issue footer only.
>
> ---
>
> The Infra team suggests they would create "asfimport" user and they would
> share a token with me so I would do the migration myself.
>
>
> Vladimir

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

Posted by Vladimir Sitnikov <si...@gmail.com>.
Update:
* I've implemented Bugzilla milestones -> GitHub milestones conversion
* I've added links to GitHub profiles
* I've removed issue headers, and moved attachments to comment footers, so
issues look pretty much the same as if they were manually created at GitHub
* I've removed "bugzilla" label as it was more like a noise
* I've removed "status" label as we do not need statuses like closed, open,
reopened, etc (GitHub already shows if the issue is open or not). The only
status I convey now is "need-info"
* I've added the links from each comment in GitHub to the comment in
Bugzilla. I think it might be handy if the markup conversion wents bad for
some issues.

---

I do not fully like the set of generated labels though.

Remember, that only committers and explicitly mentioned collaborators would
be able to adjust labels in GitHub.

1) Bugzilla has many values for operating systems, and I do not think
labels like "os: Mac OS X 10.3" make sense for GitHub issues.
I'm inclined to conflate the set of values to something like "os: macOS",
"os: Windows", "os: GNU/Linux".

2) I'm not sure we need both priority (P1, P2,...), and severity (major,
minor, ...)
Any thoughts here? I'm inclined to drop severity label, and keep it within
issue footer only.

---

The Infra team suggests they would create "asfimport" user and they would
share a token with me so I would do the migration myself.


Vladimir

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

Posted by Milamber <mi...@apache.org>.
Hi Vladimir,

I review the doc, looks good for me (+1). Thanks for you work.

Milamber

On 05/08/2022 11:31, Vladimir Sitnikov wrote:
> I've created a draft migration plan, comments are welcome:
> https://docs.google.com/document/d/1kUN9wMFR1CEydq345Nh_ohrPkCsQdaHjSUYpPAUfw6I/edit#heading=h.xm5w7ls8nz2w
> https://issues.apache.org/jira/browse/INFRA-23553
>
> Vladimir
>


Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

Posted by Vladimir Sitnikov <si...@gmail.com>.
I've created a draft migration plan, comments are welcome:
https://docs.google.com/document/d/1kUN9wMFR1CEydq345Nh_ohrPkCsQdaHjSUYpPAUfw6I/edit#heading=h.xm5w7ls8nz2w
https://issues.apache.org/jira/browse/INFRA-23553

Vladimir

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

Posted by Vladimir Sitnikov <si...@gmail.com>.
Some updates: I've implemented cross-references (duplidates, duplicated by,
depends on, blocks)
On top of that, every "bug 2323" mention is replaced with GitHub URL, so
navigation between issues works.

Here's a sample issue: https://github.com/vlsi/tmp-jmeter-issues/issues/1188

The import takes ~3.5 hours, and it will complete in an hour.

I am not sure regarding the labels though. I create a lot of labels (os,
status, severity, etc), and I would like to hear what others think.

The missing bits are:
* create milestones
* use links for GitHub profiles

Vladimir

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

Posted by Vladimir Sitnikov <si...@gmail.com>.
Drew from Infra fetched and sanitized the dump, and I was able use it
directly instead of fetching the data from UI.

I ran the first import, and here's how it looks:
https://github.com/vlsi/tmp-jmeter-issues/issues

It looks more-or-less fine to me.
Note: last time I imported, there was a connection reset, so there will be
only 3710 or so bugs in GitHub this time.
The full import would take several hours (we would need to make both
Bugzilla and GitHub read-only during that time)

Images are displayed inline. You could try searching issues with images via
https://github.com/vlsi/tmp-jmeter-issues/issues?q=is%3Aissue+attachment+png
Small text files are displayed inline as well. You could find them via
https://github.com/vlsi/tmp-jmeter-issues/issues?q=is%3Aissue+attachment+preview
Sample issue: https://github.com/vlsi/tmp-jmeter-issues/issues/1457

I plan to improve some things, however, it would be great if you could
check the conversion results and let me know what could be improved.
Please consider reporting the issues via
https://github.com/vlsi/bugzilla2github (or
https://forms.gle/3DzVsre2ytismoxx6)

Known issues:
* "reporter and commenter" is the same everywhere. It will be ASF robot
account or something like that.
Unfortunately, this can't be fixed, as INFRA says we can't ask for GitHub
support, so real reporters and commenters are included in the first lines.

* reporters and commenters are not linked to their GitHub accounts.
I will add the username to email mapping soon, so if you want to have your
GitHub profile linked,
please submit your GitHub username via https://forms.gle/zjnrGUo4VWPoWMVh9
 (see https://lists.apache.org/thread/x8hwob37pvwrwk2xslpk3ton76bkr5o9 )

* "cross-references" (e.g. issue#x duplicates issue#y) are not represented
for now.
The problem is the exact issue id is not known before the issue is
imported, so it is hard to print all those "duplicates/duplicated by"
references.
We might probably workaround that by assuming the ids will be sequential,
then we could try waiting for each issue import to fully complete.

* formatting is weird sometimes. Of course, we can't fix all the cases,
however, it might be worth adding workarounds if possible.

* milestones are not imported yet. I think we could try creating milestones
(~fixed in version) in GitHub, and use them for issues that have "target
milestone" set.

The attachments live in a separate repository (
https://github.com/vlsi/tmp-jmeter-attachments), so issues could reference
them.
Note: the attachments repository would be read-only, and it is only for
attachments migrated from Bugzilla.

Vladimir

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

Posted by Vladimir Sitnikov <si...@gmail.com>.
I've raised https://issues.apache.org/jira/browse/INFRA-23475 to fetch
Bugzilla dump.

Vladimir

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

Posted by Vladimir Sitnikov <si...@gmail.com>.
>* Maybe we could dump the data from the MySQL database, import in into a
clone and work from that instance instead through the UI?

This might indeed be a better idea. It is great I did not invest much time
in scraping the UI.
The sad thing is the dump contains sensitive information, so I would have
to nullify it somehow during the development.

>* What kind of processing do you want to do on the text with regexps?

Mainly I'm planning to add code blocks (e.g. format stacktraces as code
blocks) and cleanup the comments like in
https://github.com/llvm/bugzilla2gitlab/blob/829f1554462ddb80f4986fdacda57948ba3c8c2d/bugzilla2gitlab/utils.py#L135-L151

>What type of attachements can be used on Github directly (I am really
lazy, haven't used it before and haven't tried)?

In GitHub you can reference images via URL (e.g. png, SVG, etc) and other
files via regular HTML links.
For instance, JMeter's README.md already references images:
https://github.com/apache/jmeter#what-is-it
I know many bugs have screenshots, so it would be nice if we could make the
screenshots be rendered automatically.

https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/attaching-files

Vladimir

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

Posted by Felix Schumacher <fe...@internetallee.de>.
Am 11.07.22 um 17:50 schrieb Vladimir Sitnikov:
> I've made progress on Bugzilla -> GitHub migration.
>
> Frankly speaking, I'm not comfortable refactoring/maintaining Python code
> (which is what many projects use to migrate off Bugzilla),
> so I created Kotlin-based project so the data and fields are typed:
> https://github.com/vlsi/bugzilla2github
>
> For now, it can download bugs and it can parse XML.
> It stores the summary in a local database (
> https://github.com/JetBrains/xodus), so it can skip bugs based on change
> date.
> It is tempting to spawn a web UI that would serve the received bugs from
> the same database :)
>
> The next steps I plan to follow are:
> * Implement batched downloader (ASF imposes 45 requests per 180 seconds
> limit), so it downloads 100 or 500 bugs in a single HTTP request
> I'm going to use multi-bug requests like
> https://bz.apache.org/bugzilla/show_bug.cgi?id=59681&id=48542&ctype=xml
> * Add authorization (Bugzilla returns truncated results for unauthorized
> requests)
> * Add regexp processing so JMeter bugs look better in GitHub formatting.
> * Do something with attachments. We could either link files via
> bz.apache.org/... URLs (I don't know if it would work),
> or we could create a separate jmeter-bug-attachments repository, we could
> migrate Bugzilla attachments there,
> and then we reference the images and files from that repository via
> raw.githubusercontent.com.
> Creating jmeter-bug-attachments repo would require slightly more work,
> however, then we lose nothing if Bugzilla dies.
>
> Let me know if you want to get your hands dirty on that.

* Maybe we could dump the data from the MySQL database, import in into a 
clone and work from that instance instead through the UI?

* What kind of processing do you want to do on the text with regexps?

* What type of attachements can be used on Github directly (I am really 
lazy, haven't used it before and haven't tried)?

Felix

>
> Vladimir
>

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

Posted by Vladimir Sitnikov <si...@gmail.com>.
I've made progress on Bugzilla -> GitHub migration.

Frankly speaking, I'm not comfortable refactoring/maintaining Python code
(which is what many projects use to migrate off Bugzilla),
so I created Kotlin-based project so the data and fields are typed:
https://github.com/vlsi/bugzilla2github

For now, it can download bugs and it can parse XML.
It stores the summary in a local database (
https://github.com/JetBrains/xodus), so it can skip bugs based on change
date.
It is tempting to spawn a web UI that would serve the received bugs from
the same database :)

The next steps I plan to follow are:
* Implement batched downloader (ASF imposes 45 requests per 180 seconds
limit), so it downloads 100 or 500 bugs in a single HTTP request
I'm going to use multi-bug requests like
https://bz.apache.org/bugzilla/show_bug.cgi?id=59681&id=48542&ctype=xml
* Add authorization (Bugzilla returns truncated results for unauthorized
requests)
* Add regexp processing so JMeter bugs look better in GitHub formatting.
* Do something with attachments. We could either link files via
bz.apache.org/... URLs (I don't know if it would work),
or we could create a separate jmeter-bug-attachments repository, we could
migrate Bugzilla attachments there,
and then we reference the images and files from that repository via
raw.githubusercontent.com.
Creating jmeter-bug-attachments repo would require slightly more work,
however, then we lose nothing if Bugzilla dies.

Let me know if you want to get your hands dirty on that.

Vladimir

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

Posted by Vladimir Sitnikov <si...@gmail.com>.
>That's a annoying if my understanding is correct, how do we distinguish
>reporters comments from dev/committers ones ?

Comments on GitHub would start with "${username} commented: ${comment}"

>Does it means bugzilla would still be up ? What is the point then ?

It will be read-only for historical/archival reasons.

>Do the downsides vs benefit worth the migration ?

The migration is worth doing anyway.
It is worth doing even if we skip issue migration, and just make Bugzilla
read-only,
and ask everybody to open new issues in GitHub.

Vladimir

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

Posted by Philippe Mouawad <p....@ubik-ingenierie.com>.
Hello,
Find my answers inline below.

Regards

On Tue, Dec 28, 2021 at 7:34 AM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:

> Unfortunately, infra says GitHub can't help us with the migration:
> https://issues.apache.org/jira/browse/INFRA-22618
>
> So what we can do is to follow
> https://github.com/Quuxplusone/BugzillaToGithub
>
> The downsides would be:
> a) All comments will be authored by the "asf-git" (or a similar bot-like
> account)
>
That's a annoying if my understanding is correct, how do we distinguish
reporters comments from dev/committers ones ?

b) Attachments won't be copied (we could hyperlink to the Bugzilla instance
> though)
>
Does it means bugzilla would still be up ? What is the point then ?

Do the downsides vs benefit worth the migration ?

>
> Vladimir
>


-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

Posted by Vladimir Sitnikov <si...@gmail.com>.
Unfortunately, infra says GitHub can't help us with the migration:
https://issues.apache.org/jira/browse/INFRA-22618

So what we can do is to follow
https://github.com/Quuxplusone/BugzillaToGithub

The downsides would be:
a) All comments will be authored by the "asf-git" (or a similar bot-like
account)
b) Attachments won't be copied (we could hyperlink to the Bugzilla instance
though)

Vladimir

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

Posted by Vladimir Sitnikov <si...@gmail.com>.
I'm inclined to "Bugzilla -> Gitlab -> GitHub" approach, so I asked INFRA
if they can help with requesting GitHub support:
https://issues.apache.org/jira/browse/INFRA-22618

Does anybody want to try https://github.com/llvm/bugzilla2gitlab/tree/llvm
with JMeter's Bugzilla?
Gitlab could probably be launched via Docker, so there's no rate limiting
and so on.

Vladimir

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

Posted by Vladimir Sitnikov <si...@gmail.com>.
It looks like LLVM migration to GitHub is done.

The approach is described in
https://groups.google.com/g/llvm-dev/c/vum4_czZ13E/m/o4kxxOgQCAAJ
What they did was they migrated Bugzilla -> Gitlab, and then they used
GitHub Enterprise Migration API to migrate from Gitlab dump to GitHub.

Gitlab approach enables to keep attachments, and the local Gitlab instances
are not rate-limited,
so it allows for fast iterations.

There's an alternative script that exports data from Bugzilla and imports
it to GitHub:
https://github.com/Quuxplusone/BugzillaToGithub
However, there's no public way to keep the attachments.
On the other hand, we can hyperlink attachment to bz.apache.org instead of
copying them to GitHub.

Any thoughts?

Vladimir

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

Posted by Vladimir Sitnikov <si...@gmail.com>.
Just in case, LLVM is migrating issues from Bugzilla to GitHub Issues:
https://llvm.discourse.group/t/bugzilla-migration/4848
I guess we could approach the LLVM team after they migrate.

They collected GitHub ids via Google form.
Basically, they asked to submit their "email -> github login" pairs,
and they anonymize unknown mails when importing issues to GitHub.

Vladimir

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

Posted by Mariusz W <ma...@gmail.com>.
 Hi,
For me, it is important to have as few switches as possible. Ideally, jira
was used and integrated with other tools, e.g. bittbucket + confluence (
https://cwiki.apache.org/confluence/display/JMETER/Home ). But since the
code is already in git and discussions can be held there ( reducing the
number of switching operations), my votes:

-0.5 Bugzilla
+1 migrate to GitHub Issues
+0.5 migrate to ASF JIRA

ps.
Apache Pony Mail is under development (
https://github.com/apache/incubator-ponymail) . IHMO If it could handle
images, it would also be a good discussion system (as mailing list layer
eg.: https://lists.apache.org/list.html?user@jmeter.apache.org )

Regards,
Mariusz


On Thu, 25 Nov 2021 at 12:10, Vladimir Sitnikov <si...@gmail.com>
wrote:

> Hi,
>
> Does anybody have a strong opinion regarding Bugzilla vs JIRA vs GitHub
> issues?
>
> Frankly speaking, I am inclined to migrate to GitHub Issues or to the ASF
> JIRA.
>
> I have no strong opinion between JIRA vs GitHub Issues, however, the
> current JMeter development workflow is pull-request centric,
> so GitHub Issues would be easier for me.
>
> Let us try the following vote (see https://rangevoting.org/ ):
> -1..+1 keep using Bugzilla for issue management
> -1..+1 migrate to GitHub Issues
> -1..+1 migrate to ASF JIRA
>
> Here's my vote:
> -0.8 keep using Bugzilla
> +1 migrate to GitHub Issues
> +0.8 migrate to ASF JIRA
>
> AFAIK there is no automatic issue migration, so any change would involve
> dealing with issues somehow.
> AFAIK there are no legal implications, so we can use either issue tracking
> system.
>
> Bugzilla:
> Pros:
> * It worked more-or-less fine for ages
> Cons:
> * Bugzilla is less widespread at the moment. I think only 10 or so ASF
> projects are listed at https://bz.apache.org/bugzilla/enter_bug.cgi
> * There's no integration between pull requests and issues
>
> GitHub issues:
> Pros:
> * GitHub issues integrate well with pull requests and discussions. I think
> the vast majority of contributions come via pull requests
> * It is probably easier for external contributors. In practice, GitHub is a
> de-facto standard now
> * Issues integrate well with GitHub Actions. We do not use it extensively,
> however, I think we can label issues/prs, and things like that
> * Query language is more or less known (for instance, I do use
> https://github.com/gradle/gradle/issues a lot)
> * Rich comment formatting: code samples, images
> Cons:
> * Only 20 external collaborators for issue triage (see
>
> https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-AssigningexternalcollaboratorswiththetriageroleonGitHub
>  )
> * Non-ASF-hosted solution. I think this is a low risk.
>
> JIRA:
> Pros:
> * Other ASF projects use JIRA. For example, INFRA. So PMCs and committers
> can't really avoid JIRA :)
> * It works more-or-less well for Apache Calcite (I'm a member of PMC for
> Calcite)
> * Query language is more or less known
> * Search can find similar cases across different ASF projects. For
> instance, I used ASF JIRA to figure out how (and which) projects enable
> GitHub Discussions.
> * Rich comment formatting: code samples, images
> * Non-committers can get access to JIRA for issue triage
> * ASF-hosted solution. We are safe if GitHub adds limits in the future
> (e.g. "no more than 20 repos per organization")
> Cons:
> * Somebody might think JIRA is "heavyweight", however, it looks like the
> last couple of years ASF JIRA works just fine
>
> Vladimir
>