![]() ![]() I’d personally like to see how easy its going to be to find those I want and to see “what is new” in that area and “what I might work on next”įor me I’d like people to specifically log bugs against “clang-format” and not the old “Formatter” that it was in bugzilla so I’m interested to understand how in the future it might look and if there is any opportunity to “clean” the data as we migrate.Client = Migrator(config_path="/path/to/config") Are separate areas just labels? can we filter down to see just the areas we want? Over the weekend we tried to perform a “dry-run” migration –Ĭonversion of all 51k+ bugzilla issues to a temporary GitHub project.ĭo we feel there could be value in sharing access to this temporary GitHub project with a wider audience so we can see how the issues would look? This might raise interest and excitement but also might help to ensure we don’t land something that people find hard to work with.įor example, I’m only interested in a very specific subset of the “bugs” (clang-format), how easy will that be for me to see just those. Pretty good, but he can fill in more details about what the issues have been so far. Anton has done some test migrations and to me they look If we don't hear anything by then, we will decide Is there somewhere that has more details about the progress/problems/plans/etc for this migration? (a bug, some other mailing list, discourse-group, whatever.)Ĭurrent status is we are waiting until the middle of next week to get a responseįrom GitHub to some of our questions. The whole reason we're not doing that (seems to be) is that we want to preserve the low bug numbers for 1-to-1 correspondence purposes. Or we could simply close creation of *new* bugzilla bugs, and start all new traffic on github without waiting for a migration at all. If nothing else, without it we could migrate a subset of bugs which happen to migrate cleanly, and then come back and handle the ones with issues at a arbitrarily later point. Is the ID mapping really the only issue keeping us back though? With an imperfect system than waiting any longer. I strongly believe we are better off moving now I may be missing something about other advantages of mapping 1-1?Ĭontinuing to hold back the transition of new bugs to github is causing It is even better than this: if we can generate a map of old IDs to new IDs when doing the conversion, it really isn’t difficult to keep the existing URL working (redirecting to the right migrated GitHub issue). Mattering fairly quickly after the transition With a link to the other, but this is a minimal badness, and stops This requires a bit of extra ugliness in terms of needing to add a comment to every bug (both copies) Mapping, but the numbers can be distinct. I believe we should drop the goal of keeping bug numbers in sync between I’ve raised this point once before, but I think it’s time to raise it again. After the real migration Bugzilla will be put into read-only modeįor next few months to allow possible migration of any missed data. I'd estimate that we will need to shut down / put bugzilla into After step 3 we will decide on the roadmap of the actual migration. Make big cosmetic changes at that moment, however, we will try to fixīugs / usability problems should they appear. If step 2 will yield the content of adequate quality, we will After the migration we will perform the final check of theĬontents: labels, users, cross-links, attachments, etc.ģ. Please let me know if you'dĮncounter any side-effects of such migration, e.g. PRs into a dummy project later this week. I'd expect that we will perform a test migration of ~3k bugzilla Here is the sequence of events that will likelyġ. However now I believe we are very close to That the overall migration process is quite non-trivial given theĪmount of data, all kinds of restrictions, rules and regulations we I do apologize for the radio silence on the bugzilla migration and Iĭo certainly appreciate your patience on this topic. ![]()
0 Comments
Leave a Reply. |