Regressions Tracker

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Regressions Tracker

doctormo
Dear developers,

One of the discussions we had in Kiel was the potential to host a
tracker to document some of the regressions that we have on GitLab.
While we're keeping the inkscape issues tracker closed for now, I've
created a project to hold the regressions for 1.0. These are mostly for
programmers to document errors and talk between ourselves about
possible solutions, rather than end user issues.

https://gitlab.com/inkscape/regressions

I don't think this'll interfere with anything, but let me know if it
opens too many problems and I'll close it down.

Best Regards, Martin Owens


_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Regressions Tracker

Patrick Storz
Am 17.09.2018 um 17:12 schrieb [hidden email]:
Dear developers,

One of the discussions we had in Kiel was the potential to host a
tracker to document some of the regressions that we have on GitLab.
While we're keeping the inkscape issues tracker closed for now, I've
created a project to hold the regressions for 1.0. These are mostly for
programmers to document errors and talk between ourselves about
possible solutions, rather than end user issues.

https://gitlab.com/inkscape/regressions

I don't think this'll interfere with anything, but let me know if it
opens too many problems and I'll close it down.

Best Regards, Martin Owens

Hi Martin,

personally I'm afraid it will make it even harder to keep track of issues, as it will be a separate/parallel location to report issues next to Launchpad, so we'll have all the problems of separate trackers (most importantly duplication and twice the effort for a single search) with no real gain (at least I did not hear any real arguments for this solution except developers being to "lazy" to search for new regressions in the existing bug tracker, which is a non-issue though, see below).

Two additional things to remember:
  • There's no good way to move individual issues from Launchpad to GitLab, so if our users report a regression on Launchpad it will involve manual effort to move it (or cause duplication) and it will detach the original author from the issue on GitLab.
  • Once we're ready to move away from Launchpad we'll be in a situation where we have not only one but *two* trackers that we need to somehow consolidate into whatever our future bug tracking will be.
I'd prefer if we just used the already existing "regressions" tag on Launchpad [1]. If we want to fully separate older regressions from new ones we can use a suitable milestone or an additional tag like "1.0".

Best Regards,
Patrick


[1] https://bugs.launchpad.net/inkscape/+bugs?field.tag=regression


_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Regressions Tracker

Patrick Storz
Am 17.09.2018 um 18:05 schrieb Patrick Storz:
Am 17.09.2018 um 17:12 schrieb [hidden email]:
Dear developers,

One of the discussions we had in Kiel was the potential to host a
tracker to document some of the regressions that we have on GitLab.
While we're keeping the inkscape issues tracker closed for now, I've
created a project to hold the regressions for 1.0. These are mostly for
programmers to document errors and talk between ourselves about
possible solutions, rather than end user issues.

https://gitlab.com/inkscape/regressions

I don't think this'll interfere with anything, but let me know if it
opens too many problems and I'll close it down.

Best Regards, Martin Owens

Hi Martin,

personally I'm afraid it will make it even harder to keep track of issues, as it will be a separate/parallel location to report issues next to Launchpad, so we'll have all the problems of separate trackers (most importantly duplication and twice the effort for a single search) with no real gain (at least I did not hear any real arguments for this solution except developers being to "lazy" to search for new regressions in the existing bug tracker, which is a non-issue though, see below).

Two additional things to remember:
  • There's no good way to move individual issues from Launchpad to GitLab, so if our users report a regression on Launchpad it will involve manual effort to move it (or cause duplication) and it will detach the original author from the issue on GitLab.
  • Once we're ready to move away from Launchpad we'll be in a situation where we have not only one but *two* trackers that we need to somehow consolidate into whatever our future bug tracking will be.
I'd prefer if we just used the already existing "regressions" tag on Launchpad [1]. If we want to fully separate older regressions from new ones we can use a suitable milestone or an additional tag like "1.0".

Best Regards,
Patrick


[1] https://bugs.launchpad.net/inkscape/+bugs?field.tag=regression


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.


_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Regressions Tracker

doctormo
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


_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Regressions Tracker

Patrick Storz
Am 17.09.2018 um 18:55 schrieb [hidden email]:

> 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


_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Regressions Tracker

Bryce Harrington-3
On Mon, Sep 17, 2018 at 07:55:22PM +0200, Patrick Storz wrote:

> Am 17.09.2018 um 18:55 schrieb [hidden email]:
> > 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


_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Regressions Tracker

Patrick Storz
Am 18.09.2018 um 07:44 schrieb Bryce Harrington:
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.  :-)

Unfortunately we didn't find the time for any "official", exhaustive, let alone conclusive discussion on the topic. However one day during lunchtime a few of us threw around some ideas on how we might proceed with the migration.

While opinions certainly differ regarding the details I think there were some general points we seemed to agree upon:
  • Nobody thinks it's a good idea to migrate the ~5000 bugs in Launchpad as-is into a new tracker.
  • Everybody sounded content with moving to GitLab
  • As there does not seem to be a possibility to make the Launchpad tracker read-only people agreed it would make sense to migrate them into a separate (likely GitLab) tracker for safekeeping and future reference, so Launchpad can be properly redirected to whatever our new official bugtracker will be.
  • Most of us agreed it would be desirable to separate the issue reporting for users from the actual developer-facing bug tracker which will be used for triaging and working on bugs. The latter should only include well-written bugs which clearly state the issue and which can be confirmed and reproduced. If these conditions are not met, bugs should be closed consequently.

The areas were opinions differed most were:

  • Do we close old bugs? Or do we silently forget about them?
  • If we close bugs, how do we close them? Should we mark them as "moved" (like e.g. GNOME and Freedesktop did) giving the impression they'd still be active? Or should we specifically tell users they were closed and need to be re-tested and re-filed in the new instance? An interesting idea was to exploit the 1.0 release to tell people that we needed their help to re-test against 1.0 and that we were closing old bugs at this time, as many of them are likely not relevant for the shiny new release anymore.
  • What do we do with the old bugs? Should we never touch them again? Or shall we try to migrate them manually as time permits, potentially recruiting new bug wranglers for the job?
  • Who would be allowed to file / edit bugs in the developer-facing tracker? Only developers? All members of the project? Everybody?
  • How should the user-facing issue reporting look? Do we use the current tracker as a "catch all"? Or do we create something new?
  • How do we avoid making the user-facing tracker a second class support only rarely frequented by developers and other members of the project?

I hope I catched most of the discussion, feel free to add notes if I missed / misinterpreted anything.

Regarding the topic of this mail thread, the "Regressions tracker": The first I heard of it was Thursday afternoon when Marc presented his suggestions for the 1.0 roadmap. I'm not aware of any discussion on it and think it's not a good idea to implement one for the reasons outlined before.


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.

Martin actually pointed me towards https://gitlab.com/doctormo/lpout during the hackfest.
Can you comment on what the current state of this project is Martin, i.e. what needs to be done to use this script for exporting/importing bugs?

Best Regards,
Patrick



_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Regressions Tracker

doctormo
I've gone ahead and moved my regression bug to `inkscape-website` since
it's the only bug tracker that I feel confident it won't confuse the
bug manager (i.e. me)

> a few of us threw around some ideas on how we might proceed
> with the migration.

The one think missing from Patrick's pretty good coverage is that we
talked about spending time hunting for and promoting the role of "Bug
Manager", it would be a role in the project that would come with esteem
and I think at least a yearly basket of fruit.

But the idea is that bugs are a bit dead since SuV moved on. So we're
in need a of a replacement (although there is no replacing suv's
amazing work) and that sort of domain ownership might allow us to
develop the bug system that helps developers and users cope with the
large number of areas in the project and depth of versions.

> Martin actually pointed me towards https://gitlab.com/doctormo/lpout
> during the hackfest.
> Can you comment on what the current state of this project is Martin,
> i.e. what needs to be done to use this script for exporting/importing
> bugs?

It'll do a basic migration, but it's kind of experimental and all that
implies. Do you want to create an archive project and have a go at a
migration?

It might be possible to code the output into json, so we can create a
git repository for the issues rather than populating an actual bug
tracker.

Best Regards, Martin Owens


_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Regressions Tracker

Patrick Storz
Am 18.09.2018 um 21:25 schrieb [hidden email]:
>> Martin actually pointed me towards https://gitlab.com/doctormo/lpout
>> during the hackfest.
>> Can you comment on what the current state of this project is Martin,
>> i.e. what needs to be done to use this script for exporting/importing
>> bugs?
> It'll do a basic migration, but it's kind of experimental and all that
> implies. Do you want to create an archive project and have a go at a
> migration?

I gave it a try yesterday but while it initially seemed to work and I
could make it start downloading bugs I hit a road-block not much later:
While bugs where downloading on one bug one attachment reliably
triggered a 404, although other attachments downloaded fine and it was
available when downloading manually.
Usually I'm happy to investigate, but here three implementations unknown
to me clashed (some browser module, launchpadlib and your script) and I
had a hard time even understanding what was going on, let alone
debugging or fixing it, so I'm not sure whether I'll find the motivation
to revisit it any time soon :-/.
I kind of hoped you'd be thrilled to finish lpout ;-).

> It might be possible to code the output into json, so we can create a
> git repository for the issues rather than populating an actual bug
> tracker.

Well, we can certainly do this in parallel to make sure we store all the
available data, but from a practical standpoint it would be less useful
than just deleting the launchpad tracker: Nobody will be able to make
use of plain export data. If we don't feed the bugs back into GitLab
eventually it'll just be lost effort...

Regards
Patrick


_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Regressions Tracker

doctormo
On Wed, 2018-09-19 at 21:46 +0200, Patrick Storz wrote:
> I kind of hoped you'd be thrilled to finish lpout ;-).

Not really 😉 I was hoping it would just work. Although with a larg
e number of bugs, it's hard to imagine it working without an issue.

I'd also be willing to fix the issue, but you'll have to create an
issue so I can see what's going on. It probably just needs some tr.

Best Regards, Martin OWens


_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel