Skip to content

RFC: Migrating the issue tracker to Bugzilla #2865

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
bstrie opened this issue Jul 10, 2012 · 4 comments
Closed

RFC: Migrating the issue tracker to Bugzilla #2865

bstrie opened this issue Jul 10, 2012 · 4 comments

Comments

@bstrie
Copy link
Contributor

bstrie commented Jul 10, 2012

There's been some frustration with the Github issue tracker in the past, and I've witnessed some idle talk of migrating the issues to Bugzilla. According to Graydon, the biggest problem with the present issue tracker is the absence of the ability to denote dependencies between bugs.

Fortunately, it looks like migration to Bugzilla would be easy to achieve: one need only harvest the issue data in JSON format from the Github API, write a script to convert the data to the XML format that Bugzilla accepts, and import. I've only taken a cursory look at it, but I think it would be possible to preserve everything: comments, tags, and other metadata such as date filed and date closed.

I don't know enough about Bugzilla to comment on the pros, but here are some potential cons of switching away from the present issue tracker:

  1. It's a one-way trip. I don't know of any means to import data into Github's issue tracker.
  2. A higher barrier of entry to participation. Unlike internally-hosted bug trackers, Github accounts are ubiquitous.
  3. There will still be two bug trackers, since new pull requests will still be filed under Github's issue tracker. Drive-by contributors will also probably elect to use the issue tracker on Github in the absence of prominent instructions to the contrary.
  4. Loss of Github integration, though I think that much of the git integration is potentially recoverable via commit hooks.
  5. One more channel of communication to monitor.

If this direction is affirmed, I volunteer to harvest the issues and write the conversion script (which involves reverse engineering the Bugzilla XML format).
@erickt
Copy link
Contributor

erickt commented Jul 11, 2012

Regarding point 3, we could turn off github's issue app, which avoids the issue of having two bug trackers.

@Dretch
Copy link
Contributor

Dretch commented Jul 11, 2012

A higher barrier of entry to participation. Unlike internally-hosted bug trackers, Github accounts are ubiquitous.

Its pretty subjective of course, but I think Github's issue tracker is more pleasant to use (for my purposes as very occasional contributor, so YMMV) than bugzilla. The only other system I have used much is Jira, which I would rate higher than bugzilla but lower than github.

@kingcons
Copy link

The cost of points 2 and 5 seem to outweigh the potential benefits to me but I'm not actively using the language yet and, obviously, defer to the core Rust hackers.

@catamorphism
Copy link
Contributor

We discussed this in the weekly meeting a week ago: https://etherpad.mozilla.org/Meeting-weekly-2012-07-03

I actually missed that part, but it sounds like the consensus was not to switch to Bugzilla yet. (I am personally pro-switching, but it sounds like @graydon wasn't.)

Closing, since we just discussed this, but feel free to revisit this in a couple of months.

RalfJung pushed a commit to RalfJung/rust that referenced this issue May 11, 2023
@bors
Auto merge of rust-lang#2865 - Vanille-N:tb-perf, r=RalfJung
7fb4332 
Thorough merge after GC: fix of rust-lang#2863

Context: rust-lang#2863.

`perf report`s of `MIRIFLAGS=-Zmiri-tree-borrows cargo +miri miri test test_invalid_name_lengths` in crate `http`:

### Pre
```
  91.06%  rustc    miri                                 [.] miri::borrow_tracker::tree_borrows::tree::Tree::keep_only_needed
   2.99%  rustc    miri                                 [.] miri::borrow_tracker::tree_borrows::tree::TreeVisitor::traverse_parents_this
   0.91%  rustc    miri                                 [.] miri::borrow_tracker::tree_borrows::tree::Tree::perform_access
   0.62%  rustc    miri                                 [.] miri::range_map::RangeMap<T>::iter_mut
   0.17%  rustc    libc.so.6                            [.] realloc
   0.14%  rustc    miri                                 [.] miri::concurrency::thread::EvalContextExt::run_threads
   0.13%  rustc    miri                                 [.] rustc_const_eval::interpret::operand::<impl rustc_const_eval::interpret::eva
   0.13%  rustc    miri                                 [.] hashbrown::raw::RawTable<T,A>::remove_entry
   0.10%  rustc    miri                                 [.] miri::intptrcast::GlobalStateInner::alloc_base_addr
   0.08%  rustc    librustc_driver-c82c1dc22c817a10.so  [.] <rustc_middle::mir::Body>::source_info
```
Interrupted after 3min 30s.

### Post
```
  20.75%  rustc    miri                                 [.] miri::borrow_tracker::tree_borrows::tree::TreeVisitor::traverse_parents_this
  18.50%  rustc    miri                                 [.] miri::borrow_tracker::tree_borrows::tree::Tree::keep_only_needed
   6.49%  rustc    miri                                 [.] miri::borrow_tracker::tree_borrows::tree::Tree::perform_access
   4.25%  rustc    miri                                 [.] miri::range_map::RangeMap<T>::iter_mut
   1.91%  rustc    libc.so.6                            [.] realloc
   1.79%  rustc    miri                                 [.] miri::concurrency::thread::EvalContextExt::run_threads
   1.40%  rustc    miri                                 [.] rustc_const_eval::interpret::operand::<impl rustc_const_eval::interpret::eva
   1.40%  rustc    miri                                 [.] miri::range_map::RangeMap<T>::merge_adjacent_thorough
   1.34%  rustc    miri                                 [.] miri::intptrcast::GlobalStateInner::alloc_base_addr
   0.90%  rustc    librustc_driver-c82c1dc22c817a10.so  [.] <rustc_middle::ty::context::CtxtInterners>::intern_ty
```
Terminates after 1min 13s.

No significant changes to `./miri bench` in either direction: on small benches not enough garbage accumulates for this to be relevant.
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
@matthiaskrgr @zhassan-aws
expect() does not take format strings (rust-lang#2865)
0bde3ea 
This would just print 
````
Function `{func}` should've been declared before usage'
````
on panic, it just now occurred to me that `func` is supposed to be
content of a var 😄

Co-authored-by: Zyad Hassan <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@erickt @kingcons @catamorphism @bstrie @Dretch