Re: Retiring Phabricator - Migrating tasks to Gitlab

2023-05-22 Thread Wolthera
Great, pretty excited for the tasks to move to issues :)

On Sun, May 21, 2023 at 9:01 PM Ben Cooksley  wrote:
>
> On Sun, May 21, 2023 at 10:10 PM Johnny Jazeix  wrote:
>>
>>
>> Also, some phabricator tasks have hierarchy, is there an equivalent in 
>> gitlab? There are tasks in gitlab too but I'm not sure it is always the 
>> equivalent.
>
>
> Gitlab tasks can be related/linked together (and this can hopefully be 
> brought across), however they cannot be flagged as blocking/being blocked by 
> other tasks.
> The functionality to create a task hierarchy through blocked relationships is 
> only available in Gitlab EE.
>

Gitlab Free (that invent uses) also has the difference between
'Issues' and 'Tasks', the former being the equivalent to Phab tasks,
the latter being intended as an atomic subtask, which allows for one
level of dependency. On top of that, gitlab keeps tack of checklists
in the UI, so some minor amount of hierarchy is possible.

Overall, I've noticed that milestones are best for collecting tasks
related to a release or a defined project (Say, a new tool, importer
or workflow), while the boards are better for if you need to track the
state of multiple issues, because Gitlab Free doesn't allow filtering
of issues on a board (only having columns for a specific issue label),
which effectively makes it a different UI for the issue list. Because
the board columns map to a label, it makes sense to have columns be
converted to labels for the vast majority of projects, yes.

>>
>>
>> Cheers,
>>
>> Johnny
>
>
> Thanks,
> Ben




--
Wolthera


Re: Invent/gitlab, issues and bugzilla

2019-07-04 Thread Wolthera
On Thu, Jul 4, 2019 at 1:02 PM Kai Uwe Broulik  wrote:
> I complained about the same thing but I was told you can replicate most
> of those (OS, platform, etc) using tags/badges and project structures.
> There isn't a 1:1 mapping of fields and tech we got used to from Bugzilla.

For gitlab, mutually exclusive tags(which you'd want for things like
OS) are only in the enterprise edition, and adding labels to
bugreports is something that only members of a project can do. I know
that many github projects don't just have triagers but also people who
handle labelling the issues correctly.

For the larger projects, like in my case Krita, I think we would have
to either have a ton of bots to handle the labelling for us, or we
need to give up on attempting to create any order in the tracker(and
again, who will create those bots?). We just get in too many bugs,
there are not enough people to triage all of them, and even if we
would leverage the community here, I am not sure gitlab's permission
system will allow for people who can label but have no desire to have
access to the git repository.

Also keep in mind that we're not done yet with moving to gitlab.
Adding bugzilla migration to the mix might be too much for the
community to handle, so it is probably more efficient to wait for
bugzilla 6 in any case.

I can't really comment much on the different needs of projects where
they have their bugtracker. The thing that keeps returning is that the
larger projects need bugzilla while the smaller projects would benefit
from the easier usability of gitlab issues, which in turn is something
that doesn't necessarily benefit the larger projects, because these
have enough reach to have reached users who have the ability to type
faster than they think and need a bit more encouragement to think
about what they are typing (repellent ux is one of these options. A
non-hostile solution might be possible but to my knowledge no one has
ever programmed an open source version of it).

For what it is worth, there is some minor bugzilla integration already
possible in gitlab [1]. This would allow dual issue style systems
where the bugzilla bugs are the reported bugs and the phabricator
tasks get replaced by the gitlab issues.
[1]: https://invent.kde.org/help/user/project/integrations/bugzilla.md


--
Wolthera