On Mon, 16 Mar 2020 at 15:08, Tom Stellard <tstel...@redhat.com> wrote:
> On 03/16/2020 08:00 AM, James Henderson wrote: > > > > > > On Mon, 16 Mar 2020 at 14:44, Tom Stellard via cfe-dev < > cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>> wrote: > > > > On 02/10/2020 07:40 PM, Tom Stellard wrote: > > > On 01/30/2020 12:47 PM, David Major wrote: > > >> Would it make sense to wait until 10.0.0 is released, in order to > keep all the blockers in one place? > > >> > > > > > > Yes, I think this makes sense, let's postpone until then. > > > > > > > Hi, > > > > 10.0.0-rc4 was just released, and I think we are at the point in the > release cycle > > where it is safe to begin the migration to GitHub issues. > > > > I would like to propose doing the migration in one week (March 23). > This means > > making the existing bugzilla read-only, and updating the > documentation to tell users > > to file issues at GitHub. > > > > > > Don't forget to update the URL used in crash messages to point at the > right location. > > > > > > We are still trying to figure out the best way to import bugs > > from bugzilla into GitHub, so this step will be done at a later date. > > > > > > Making bugzilla read-only seems like a bad idea until all existing > issues have been migrated. What if people need to update an existing bug > once the migration to using Github issues has happened before importing has > also happened? > > > > This was a mistake on my part. The plan is to disable creation of new > bugs in bugzilla and not > to make it read-only. If you look at the original RFC, it says GitHub > issues > would be used for new issues, and existing issues will continue to be > updated in bugzilla, > and this is what I'm proposing. > > > > > > > For the initial list of tags, I propose we generate the list based > on the most commonly > > used categories in bugzilla. This should be enough to get us > started and we can always > > add more tags as we go. > > > > > > I'd like this list to be fleshed out before migration is agreed. I'm > concerned different people will have wildly different ideas of what > "commonly used" might mean, which could in turn have an impact on the > viability of this tag list. > > > > Most commonly used here means categories with the most bugs. So, this > would be > based on raw bug counts and not just someone's opinion. > > -Tom > That's what I thought might be the case, and where I take issue with it. I've said this on several previous occasions - I think it makes sense for tags/bugzilla components etc. to exist for each individual executable, as well as the various libraries. Let's say I'm a user of a tool like llvm-size and I find a bug. If there wasn't a tag for llvm-size, I wouldn't know where to file it (and no, I don't think a catch-all "binutils" tag is useful - not every developer will know what counts as a "binutils" tag). At the time of writing there are exactly three bugs for llvm-size. That presumably isn't going to meet any threshold imposed, so this tag wouldn't be created, and I wouldn't know where to file my bug, so I probably would either guess (and quite likely get it wrong), or not add a tag, which means that developers who are focused on developing the binutils (and would therefore have subscribed to this tag) won't see the issue. I might even not file the bug at all. > > > > > > I've also implemented a notification system using GitHub actions > that will make > > it possible to subscribe to individual issue tags, so we would > enable this on Monday > > as well. > > > > What does everyone think? > > > > Thanks, > > Tom > > > > > > > -Tom > > > > > >> > > >> > > >> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev < > llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> <mailto: > llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>>> wrote: > > >> > > >> On 01/30/2020 10:24 AM, Aaron Ballman wrote: > > >> > On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev > > >> > <cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> > <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>>> wrote: > > >> >> > > >> >> On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote: > > >> >>> We held a round-table at the llvm dev conference about > what other pieces of Github infrastructure we may want to use. This thread > in particular is about switching to github issue tracking. Use of other > parts of Github functionality was also discussed -- but that should be for > other email threads. > > >> >>> > > >> >>> Most of the ideas here were from other people. I > /believe/ this proposal represents the overall feeling of the folks at the > round-table, in spirit if not in exact details, but nobody else has > reviewed this text, so I can't make any specific such claim as to who the > "we" represents, other than myself. Just assume all the good ideas here > were from others, and all the bad parts I misremembered or invented. > > >> >>> > > >> >>> > > >> >> > > >> >> Hi, > > >> >> > > >> >> I want to restart this discussion. There seemed to be > support for this, > > >> >> but we got held up trying to decide on the appropriate set > of tags to > > >> >> use to classify issues. > > >> >> > > >> >> I propose that we move forward with this proposal and > disable creation of > > >> >> new bugs in bugzilla on Feb 11, and require all new bugs > be filed via GitHub > > >> >> issues from that date forward. > > >> >> > > >> >> I think that for choosing the tags to use, we should just > take requests > > >> >> from the community over the next week and add whatever is > asked for. The main > > >> >> purpose of adding tags is so we can setup cc lists for > bugs, so I think this > > >> >> is a good way to ensure that we have tags people care > about. We can always > > >> >> add more tags later if necessary. > > >> >> > > >> >> What does everyone think about this? > > >> > > > >> > What did we decide to do with all the existing issues in > Bugzilla? > > >> > > > >> > > >> This is undecided. The first step of this proposal only > affects new issues. > > >> Existing issues will remain in bugzilla and will be updated > there too. At > > >> some point in the future bugzilla will become read-only > and/or the issues will > > >> be migrated somewhere else, but no decision has been made > about how to do that yet. > > >> > > >> -Tom > > >> > > >> > ~Aaron > > >> > > > >> >> > > >> >> -Tom > > >> >> > > >> >> > > >> >>> Background > > >> >>> ---- > > >> >>> Our bugzilla installation is...not great. It's been > not-great for a long time now. > > >> >>> > > >> >>> Last year, I argued against switching to github issues. I > was somewhat optimistic that it was possible to improve our bugzilla in > some incremental ways...but we haven't. Additionally, the upstream bugzilla > project was supposed to make a new release of bugzilla ("harmony"), based > on bugzilla.mozilla.org <http://bugzilla.mozilla.org> < > http://bugzilla.mozilla.org> <http://bugzilla.mozilla.org>'s fork, which > is much nicer. I thought we would be able to upgrade to that. But there has > been no such release, and not much apparent progress towards such. I can't > say with any confidence that there will ever be. I no longer believe it > really makes sense to continue using bugzilla. > > >> >>> > > >> >>> This year, we again discussed switching. This time, > nobody really spoke up in opposition. So, this time, instead of debating > /whether/ we should switch, we discussed /how/ we should switch. And came > up with a plan to switch quickly. > > >> >>> > > >> >>> GitHub issues may not be perfect, but I see other > similarly-large projects using it quite successfully (e.g. rust-lang/rust) > -- so I believe it should be good for us, as well. Importantly, Github > Issues is significantly less user-hostile than our bugzilla is, for new > contributors and downstream developers who just want to tell us about bugs! > > >> >>> > > >> >>> > > >> >>> Proposal > > >> >>> ---- > > >> >>> We propose to enable Github issues for the llvm-project > repository in approximately two weeks from now, and instruct everyone to > start filing new issues there, rather than in bugzilla. > > >> >>> > > >> >>> Some things we'd like to get in place before turning on > Github's Issue tracker: > > >> >>> 1. Updated documentation. > > >> >>> 2. An initial set of issue tags we'd like to use for > triaging/categorizing issues. > > >> >>> 3. Maybe setup an initial issue template. Or maybe > multiple templates. Or maybe not. > > >> >>> > > >> >>> But more important are the things we do /not/ want to > make prerequisites for turning on Github issues: > > >> >>> > > >> >>> We do /not/ yet plan to turn off Bugzilla, and do /not/ > plan to migrate the existing issues to GitHub as a prerequisite for > switching. We will thus expect that people continue using bugzilla for > commenting on the existing bugs -- for the moment. > > >> >>> > > >> >>> We do /not/ want to build supplementary notification > systems to make github issues send additional emails that it is unable to > send itself. We will only support what GitHub supports. That means: > > >> >>> - You can subscribe to notification emails for activity > in the entire llvm-project repository. > > >> >>> - You can subscribe to notification emails on an > individual issue. > > >> >>> - Someone else can CC you on an individual issue to get > your attention, and you will get notifications from that (unless you > opt-out). > > >> >>> - No emails will be sent to llvm-b...@llvm.org <mailto: > llvm-b...@llvm.org> <mailto:llvm-b...@llvm.org <mailto:llvm-b...@llvm.org>> > <mailto:llvm-b...@llvm.org <mailto:llvm-b...@llvm.org> <mailto: > llvm-b...@llvm.org <mailto:llvm-b...@llvm.org>>> for github issues. > > >> >>> - There is no builtin way for users to subscribe to > emails for bugs that have a given label (for example, all "clang" issues, > or all x86 issues). > > >> >>> > > >> >>> Further steps > > >> >>> ---- > > >> >>> After we migrate, there's still things we want to do: > > >> >>> > > >> >>> 1. Discuss and setup new and better procedures around bug > triage and prioritization. > > >> >>> > > >> >>> What we have been doing up until now has not been great > in any case. Switching bug-trackers is a great opportunity to try to do > something better. E.g., like what the rust project has done ( > https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#issue-triage, > https://forge.rust-lang.org/release/triage-procedure.html#issue-triage). > > >> >>> > > >> >>> 2. Bug migration > > >> >>> > > >> >>> /After/ the initial switchover, we do want to investigate > two possibilities for migrating issues and turning off the bugzilla server. > I expect which one is chosen will come down mostly to feasibility of > implementation. > > >> >>> > > >> >>> Possibility 1: Migrate /all/ the existing bugs into a > secondary "llvm-bugs-archive" github repository, and then turn off > bugzilla. Github offers the ability to move bugs from one repository to > another, and so we can use this to move bugs that are still relevant > afterwards (potentially this could be done automatically upon any > activity). Then, shut down bugzilla, and leave behind only a redirect > script. > > >> >>> > > >> >>> Possibility 2: Create the ability to import an individual > bug from Bugzilla into the llvm-project repository by pressing a "migrate > this bug to github" button. Then, leave bugzilla running only as a static > snapshot -- as static as possible while leaving the "migrate this bug to > github" button operational. > > >> >>> > > >> >>> In both cases, we'd want to support a redirect script to > take you from the old bug ids to the migrated bug page. In both cases, we > would /preserve/ the entire archive of existing bugs, but would not import > the entire set into the "llvm-project" github repository. > > >> >>> > > >> >>> > > >> >>> > > >> >>> _______________________________________________ > > >> >>> LLVM Developers mailing list > > >> >>> llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> > <mailto:llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>> > > >> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > >> >>> > > >> >> > > >> >> _______________________________________________ > > >> >> cfe-dev mailing list > > >> >> cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> > <mailto:cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org>> > > >> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > >> > > > >> > > >> _______________________________________________ > > >> LLVM Developers mailing list > > >> llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> > <mailto:llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>> > > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > >> > > > > > > > _______________________________________________ > > cfe-dev mailing list > > cfe-...@lists.llvm.org <mailto:cfe-...@lists.llvm.org> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
