On Mon, Sep 17, 2018 at 07:55:22PM +0200, Patrick Storz wrote:
Am 17.09.2018 um 18:55 schrieb doctormo@...400...:
Thanks for the feedback Patrick.
On Mon, 2018-09-17 at 18:13 +0200, Patrick Storz wrote:
P.S. Obviously I'd also be open to move away from Launchpad prior to the 1.0 release and to "do it right" as I somehow have the feeling the idea of a separate bugtracker on GitLab is mostly due to developers being keen on finally starting to use GitLab for bug tracking but everybody being aware that the migration is a huge task which probably none of us can finish on their own. If we work together I'm certain we'll be able to accomplish this goal, though.
I'm not entirely sure that a migration is wise, let alone possible.
I'd prefer to put the current issues tracker in a read-only vault and move on.
Best Regards, Martin Owens
I intentionally wrote "move away from Launchpad" as I totally agree we do not want all old bugs migrated as-is.
As discussed on the hackfest I'd be in a favor of a solution where all current bugs are moved to an empty sub-project on GitLab (I guess that's just the read-only vault you're referring to). This allows to browse them and possibly move select bugs to other sub-projects (e.g. documentation / website / extension bugs that are still valid and well-written, but also high-importance bugs affecting Inkscape itself could be easily reviewed / moved and/or copy-edited as needed.
What we should avoid is making this change unwittingly by creating a "regression tracker" now and effectively ending up using it as a developer-only bug-tracker later while having users continue to file bugs in a tracker that's slowly starving to death.
We also discussed that the way we close the old tracker will be decisive in the way users who contributed bugs will perceive the move (i.e. wether we disgruntle them and make it unlikely they'll contribute future reports or wether we explain to them what is happening in a reasonable way which might even encourage them to help with testing and triaging going forward). Therefore we should think this through properly before getting down to action hastily and recklessly (as I know some of us tend to ;-) ).
Best Regards, Patrick
Could you guys fill me in on what was discussed at the hackfest on this topic? I've been involved with most of the discussions so far, so you can skip details, I'm mostly interested in any areas of consensus and any novel ideas that came up. Just catch me up, please. :-)
Patrick makes great points and I agree with his perspective here, although I totally understand the desire to start taking some steps forward, given that we all seem to agree on the overall direction. I love gitlab too, and am anxious to see us move.
I poked around a bit today in the launchpad administrative interface to see what options we have for switching it to a more read-only state. Sadly the amount of configuration options it gives is limited - I'm afraid it is going to constrain our tactics for how migration is done. So, it underscores Patrick's advice to properly think through how we're going to do this.
A few months ago on gitlab I created issues on the Infra Team issue tracker for figuring out five questions relating to the bug tracker migration. While there's been some good ideas collected, I still don't think we have them definitively _answered_, and so would love to see more discussion. In particular, it would be great to augment these reports with the results of thinking from the hackfest.
See issues #1 to #5 here:
https://gitlab.com/inkscape/infra/services/issues
One suggestion for anyone itching to start making progress on this problem, would be to do a test run of converting the LP bugs to a tmp project in gitlab. Googling around there appear to be some example python scripts to do this that could probably be adapted without too much trouble. It looks straightforward to just import bugs rawly, but some complexity enters the picture when considering milestones, blueprints, whether to import closed bugs, what to do about incomplete/new bugs, etc. Honestly, I think we're just going to have to make some tough decisions to discard some stuff in order to make the process easier, but we need someone to actually try out an import and see where the problems are.
Bryce