I don't plan on ignoring bugzilla in the near term, so I'll be keeping an eye on both. I just feel migrating the 756 open issues, most of which will never be addressed, creates an immediate mess in the project. I don't have the cycles to review all 756 to see which subset might be fixed, or which are good for first timers. Whereas the github project is almost a clean slate at the moment and maybe can be kept on top of now in that state.
It took me an extra week just now to get commit rights to the repository, bugzilla migration feels like a can of worms I don't want to get into right now (maybe in the future, who knows). Wherever users raise issues, I will be taking a look. In some good news, I've already processed a couple of PRs against the github project, so that is working now and someone kindly added the github action support so builds are now happening! Exciting https://github.com/eclipse/org.aspectj/actions?query=workflow%3A%22Java+CI+with+Maven%22 cheers, Andy On Sat, 1 Aug 2020 at 21:02, Alexander Kriegisch <alexan...@kriegisch.name> wrote: > Talk is cheap, I am aware of that. So if I request Bugzilla issues to be > migrated to GitHub issues and on top of that also request redirection, I > know I am not the guy who has to do all the work. My argument here is > that old issues are still a valuable source of information, even closed > ones. IMO they are just as important as documentation, especially > because documentation has not been updated for so long and everything > about new features or bugfixes in AspectJ is only documented as release > notes pointing to lists of issues. > > It looks like others have done such migrations before, here are a few > links, [1] pointing to [2] and also mentioning re-using information > created during the migration in order to implement redirection. [2] also > mentions a dry-run option and links to some derivative tools based in > itself. Maybe something there could be useful. > > The Python script under [3] looks more simplistic, I do not know if it > would be adequate. > > There are also some answers under [4], maybe one of them could be > helpful. > > [1] https://www.theozimmermann.net/2017/10/bugzilla-to-github/ > [2] https://github.com/berestovskyy/bugzilla2github > [3] > https://github.com/wilzbach/bugzilla-migration/blob/master/bugzilla2github.py > [4] https://stackoverflow.com/q/7281304/1082681 > > -- > Alexander Kriegisch > https://scrum-master.de > > > Andy Clement schrieb am 02.08.2020 07:09 (GMT +07:00): > > > > > > I didn't dive into the details with the webmaster (yet) - he simply > > offered archiving our bugzilla or continuing to use bugzilla - no > > migration mentioned but I wouldn't want a full migration anyway, there is > > too much old irrelevant stuff in there. I haven't spoken to him about > > possible forwarding options either. If I could coordinate 'open bugzillas > > updated in the last 1-2 years' or something like that for a migration, > I'd > > possibly try that. > > > > My current plan (obviously the laziest option) is just to continue with > > both and gradually folks will stop using bugzilla, it doesn't get a ton > of > > traffic anyway. Github issues are the future from my point of view. The > > README on the project should indicate that and anywhere else I can > mention > > it should also get updated to indicate that. > > > > cheers, > > Andy > > > > > > On Fri, 31 Jul 2020 at 20:17, Alexander Kriegisch > > <alexan...@kriegisch.name <mailto:alexan...@kriegisch.name> > > > wrote: > > > >> This is good news indeed, Andy. Thank you and everyone involved for > >> this. > >> > >> For now there are no existing issues there, so I would like to know if > >> in the future there will be two issue tracking systems or if there is > >> any plan to migrate the Bugzilla issues to GitHub too. Or maybe Bugzilla > >> will stay the leading system? Bugzilla contains lots of historical, but > >> still relevant information, release notes, mailing list discussions and > >> StackOverflow comments/answers are pointing there etc. But it is ugly, > >> difficult to use, there is no text formatting etc. So migrating > >> everything to GitHub in a batch process and automatically adding links > >> (even if only as comments) from the Bugzilla issue to the corresponding > >> GitHub issue would be a good thing to do. Automatic redirection would be > >> even better, but probably difficult technically. In any case Bugzilla > >> could stay active in a read-only mode. > >> > >> Having said that and reading it again, it sounds way more difficult than > >> just migrating the Git repo. > >> > >> Best regards > >> -- > >> Alexander Kriegisch > >> https://scrum-master.de > >> > >> > >> Andy Clement schrieb am 31.07.2020 22:23 (GMT +07:00): > >> > > >> > > >> > Up until yesterday what was on Github was a mirror for AspectJ. This > >> meant > >> > you couldn't raise issues against it (you had to go back to bugzilla), > >> > also any PRs that were submitted were very difficult to handle because > >> > project committers couldn't process them easily. > >> > > >> > > >> > Today, the copy of aspectj at > >> > https://github.com/eclipse/org.aspectj should be a full > >> > proper, Github repo! Woohoo! The issues tab is alive and PRs should > >> work > >> > properly. > >> > > >> > > >> > cheers, > >> > > >> > Andy > >> > > >> > > >> > >> _______________________________________________ > >> aspectj-users mailing list > >> aspectj-users@eclipse.org > >> <mailto:aspectj-users@eclipse.org> > >> To unsubscribe from this list, visit > >> https://www.eclipse.org/mailman/listinfo/aspectj-users > > > > _______________________________________________ > aspectj-users mailing list > aspectj-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/aspectj-users >
_______________________________________________ aspectj-users mailing list aspectj-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/aspectj-users
