GitLab Issues Tracker

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

GitLab Issues Tracker

Martin Owens-2
Dear Bug hunters and Developers,

GitLab contact Connor Shea has asked us what we might need in the
GitLab issues tracker to consider using it as our bug tracker instead
of launchpad.

After talking with su_v and bryce on IRC, I've drafted this possible
email detailing some of the issues:

https://inkscape.org/en/paste/11094/

We need your input too, if there are things that the launchpad system
does, or even if there are things you wish it did but GitLab could do.
Or if there are specific issues with the GitLab user interface. We can
detail them here and send them to GitLab.

I've love specifically to hear more from Mc and jazzynico as they've
done a lot of bug work.

Thanks for your help.

Best Regards, Martin Owens

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: GitLab Issues Tracker

Eduard Braun
Some thoughts:
 
 
2. Comment edits aren't recorded, so bug trackers don't know if details have been changed. We don't know if there are notifications for edits, so we can't know if a bug requires attention. Could editing comments be turned off project wide?
 
The lack of editing support in Launchpad was one of the things that bugged me most! It was most annoying when I realized I copied the wrong bug number, linked the wrong commit or just made a typo and knew it would stay wrong forever... I agree that keeping track of changes would be desirable, but even if a history wasn't posible I'd vote in favor of editing anytime!
 
 
4. Bug dependence, currently we can't see a way to set one issue as requiring another issue to be completed. But this might just be task lists and we're not used to how this works.
 
We didn't have that in Launchpad as far as I know and I never missed it. I can't even think of any bugs where this would have been applicable right now. For me this would be a very low priority.
More interesting would be tracking upstream bugs! Does GitLab have this concept? Even if it was only a field like in bugzilla it often would be very helpful to link other bugs (most of the time in other bugtrackers). Launchpad had at least rudimentary support for that ("bug watches" if I remember correctly)
 
 
5. We get a lot of wishlist items, so we'd probably want to filter these out. Not sure if issues can be approved before being committed, or if closing many many bug reports is the way to go. If we had the ability to move bugs between projects, then we'd probably set up an inkscape-reporter project to capture public bug reports before moving real ones to the inkscape project itself.
 
In my opinion wishlist items are just fine as long as they're clearly tagged/prioritized as such. Why would I want to filter them out? They're mostly valid concerns that other users are likely to share and people are likely to search for reports in *one* place (otherwise they might just not search at all and report a new bug right away to let "the project people" handle it themselves).
A splitting of issue and feature tracker will only result in more duplicates that need to be handled and will make it a lot harder to triage reports (often it's not obvious if an issue is a bug or feature, especially for users who just want to report a limitation they're facing).
The only thing that I would ask for (so far I didn't find that functionality) is an "invalid" bug state, that excludes the bug from searches (but only for report's that are in fact invalid and therfore of no use to anybody!).
 
 
One additional thing (related to 3. but different and probably much more important for us): What about bugs that affect multiple milestones? As far as I see one can only assign one milestone. If GitLab works as I'm used to from GitHub a commit to master might well close a bug as fixed that still exists in the stable branch. I we have to track this with labels it would be not only a lot of manual work but obviously prone to human error (i.e. bugs that were fixed but never backported to the stable branch).
 
Regards,
Eduard
 
 
 
 
 

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: GitLab Issues Tracker

Maximilian Gaukler
In reply to this post by Martin Owens-2
Hi Martin,

I would like to bring up the point of "bug workflow", which Launchpad
tracks pretty nice, even with editing permissions for the average user.

The main routes are:

Successful bug report:
New -> Confirmed -> (Patch attached) -> Fix committed -> Fix Released.

Report was okay, but didn't help:
New -> Wontfix/Duplicate.

Low-quality report, user should resubmit in higher quality:
New -> Invalid/Unreproducible/Incomplete [-> New]

I'm not sure how this should be handled in Gitlab. It can somehow be
approximated via tags, such as in the link below, but there is no nice
overview as on Launchpad.
Compare Gitlab:
https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues?scope=all&sort=priority&state=opened
with Launchpad:
https://bugs.launchpad.net/inkscape/



Another point is the "moderation" you mentioned, with the intention to
fend off low-quality reports:
> If we had the ability to move bugs between projects, then we'd probably set up an inkscape-reporter project to capture public bug reports before moving real ones to the inkscape project itself.

I disagree with this idea from my personal standpoint as an "outsider":
I sometimes fix bugs in open source software I use, but don't spend a
significant part of my life with that. Certainly, psychology is an
important factor in the decision whether I will spend my time on
Inkscape or rather do something else.

As a user, it makes me feel welcome and well-respected that I can
directly input bug reports and don't hang in some kind of moderation
queue or "two-class society". The easier and the more directly
accessible a project's reporting system is, the more I am inclined to
spend time reporting bugs and possibly also patching some easier ones.
(and of course, this is not about me personally, but more meant as an
example for many users out there).


To avoid junk reports, I think it is the best to provide some kind of
template which is shown when a bug report is created. Gitlab can do this
via "description templates":
https://gitlab.com/help/user/project/description_templates.md


Best Regards,

Max

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: GitLab Issues Tracker

Bryce Harrington-3
In reply to this post by Martin Owens-2
On Tue, Jun 13, 2017 at 02:17:37PM -0400, Martin Owens wrote:

> Dear Bug hunters and Developers,
>
> GitLab contact Connor Shea has asked us what we might need in the
> GitLab issues tracker to consider using it as our bug tracker instead
> of launchpad.
>
> After talking with su_v and bryce on IRC, I've drafted this possible
> email detailing some of the issues:
>
> https://inkscape.org/en/paste/11094/

Not particular to bug tracking exactly, but it would be nice if when
people request access to the devel team, if it could automatically check
that they fulfil the two patch rule.

Like, maybe, the emails sent to the admins could append a list of recent
patches that were accepted and landed in trunk from the developee.  It'd
save some time having to verify they satisfy the requirements.


Bryce

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: GitLab Issues Tracker

Maren Hachmann
Bryce, JFYI:

Gitlab has a couple more levels of access, e.g. Guest and Reporter (in
addition to Developer, Master and Owner) status. Reporter status means
they can manage bugs, but don't have access to the code.

Guest means they can look at things that someone allowed them to look
at. It's kind of an 'honorary' or non-developing, non-bug-managing member.

More info here:
https://gitlab.com/help/user/permissions.md

i.e. if someone does not fulfill the 2-patch-rule, they could still
become a project member - if project policy wants to make use of the
different levels that are available. (btw. I think I do have push
access..., not that I'd ever make use of it, of course.)

Also, there's a distinction between group members and project members.

E.g. I am a member with Developer status of the Inkscape group, which
contains a couple of projects, that can have their own, additional
members. The higher level of access status decides which permissions one
has - e.g. I have at least developer status for any sub-project, and
have master status on some sub-projects.

So policy would need to decide whether to add new Inkscape code
developers just to the /inkscape/inkscape project, or to the whole
/inkscape group, giving them access also to translations, website,
manual and possible other subprojects (not a bad thing, as long as
critical stuff, like the branches the website pulls from, are still
specially protected - and I don't think that vice versa is a good idea -
i.e. someone makes two contributions to po files, and gets developer
access to everything... so perhaps having the same level for all would
be more consistent).

Maren

Am 14.06.2017 um 01:35 schrieb Bryce Harrington:

> On Tue, Jun 13, 2017 at 02:17:37PM -0400, Martin Owens wrote:
>> Dear Bug hunters and Developers,
>>
>> GitLab contact Connor Shea has asked us what we might need in the
>> GitLab issues tracker to consider using it as our bug tracker instead
>> of launchpad.
>>
>> After talking with su_v and bryce on IRC, I've drafted this possible
>> email detailing some of the issues:
>>
>> https://inkscape.org/en/paste/11094/
>
> Not particular to bug tracking exactly, but it would be nice if when
> people request access to the devel team, if it could automatically check
> that they fulfil the two patch rule.
>
> Like, maybe, the emails sent to the admins could append a list of recent
> patches that were accepted and landed in trunk from the developee.  It'd
> save some time having to verify they satisfy the requirements.
>
>
> Bryce
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Inkscape-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: GitLab Issues Tracker

Maren Hachmann
Am 14.06.2017 um 02:09 schrieb Maren Hachmann:
> so perhaps having the same level for all would
> be more consistent).

What I meant to say with this is: giving everyone access to the parts
they need to have access to.

> Maren

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel