On Tue, 2018-03-20 at 18:01 +0100, Carlos Soriano wrote:
> If you are a maintainer and you consider some issue in the migration
> process or GitLab itself a big problem for your project...
Hi,
while I begun my concerns dealing directly with Carlos I've been told I
should move it to public, because others may have answers and/or can
help when Carlos is busy with other things. So here I am.
I'd like to verify one thing, which I'm not able to test myself, but
which is pretty bad from my point of view for many reasons. It is:
When I write into the comment: "looks like issue #123", or "similar to
#123", or such, just like comments which bug-squad used to write when
triaging, then it really doesn't mean that everyone from #123 should be
added into this issue, neither the #123 should be anyhow updated with
"mentioned in #333" or the like (though more important is copy of the
subscribers to the other issue). Those are only hints for developers
and further investigation. Does GitLab really include everyone into
#123 and/or from #123 into this issue? I'll be happy to help with
testing, just let me know.
Detailed steps would be:
a) have issue #123 with subscribers A and B
b) have issue #345 with subscribers C and D
c) be user E, whom writes into #345 comment "looks like issue #123"
Will any or both issues suddenly contain all 5 users?
No subscribers are auto-added. Only user E will be subscribed to #345, because they commented there.
The whole auto-subscribe or even "Mentioned in issue #123" auto-
comments doesn't really work for me. Look at:
https://bugzilla.gnome.org/show_bug.cgi?id=794569#c4
I mentioned "bug #790632", in that comment twice, but I do not want to
have said in that bug that I mentioned it in bug #794569. I only wrote
there a reference to a related change which will help to the user, with
no real connection between each other.
I find it more useful to have the "Mentioned in issue #123" item than to not have it. The items are gray in order to be less prominent than actual comments from users, so surely you can just ignore them?
Another thing, I think we did spoke about it, but I do not recall and
I'm not sure. I've looked into [1], but description like "Move issues
between modules" doesn't scale at all for a newbie with GitLab like me.
I often use a bug and reference it in multiple modules. It's practical
for many reasons. For example, when someone requests a change for
evolution-ews, it can also mean to make changes in evolution-data-
server and evolution, thus two other modules can require changes. I do
not duplicate the bugs for other modules, that's waste of space and
time, I rather reference the same bug in all three modules (in a way of
"Bug NNNN - Summary", thus anyone can click it (cgit makes "Bug NNNN"
clickable, with compare of URL in comments, which cannot be clicked)
and see the history, reasons behind the change and so on, not talking
that I can comment like "this caused regression/required follow up
change in bug #123" in bugzilla). I cannot do this simple "closes #NNNN
- Summary" in GitLab, because the #NNNN means something else in each
project. How do I do this now?
You can refer to issues in other projects as evolution-ews#123, gjs#123, Infrastructure/GitLab#123, etc.
Will I paste full issue URL into the end
of the commit message instead, and the commit message summary will be
the issue Summary only, in all modules?
You can also paste the full issue URL and in the web UI it will be shortened to e.g. evolution-ews#123.
How do I reference the commit
in which the change had been done in the comment of the issue? I
suppose the same as before, like here [2], right? Note of the fact that
I use the behavior of bugzilla, that means I let it highlight the
"commit abcd" for the module for which the bug is filled, but add full
links (into cgit) for the other modules while I mangle the
"commit_dcba" (see the underscore) to avoid auto-linking the commit. I
sometimes have up to four modules touched within one bug report.
Prefix the name of the repository and "@": evolution-ews@dcba1234
I found all this out and more, by reading the help page. It is linked at the bottom of every text box, "Markdown and quick actions are supported". This info is at "Special GitLab References" on the "Markdown" help page:
https://gitlab.gnome.org/help/user/markdown#special-gitlab-references
I expect to change my work-flow, that's okay, I'm only afraid of
side-effects which it can have due to auto-closing issues and such,
about which I have no idea at the moment (GitLab is too new for me,
with compare of cgit and bugzilla).
I also read the "Track dependencies between issues" at [1] and the
example link references [3], which results in "404 Not Found" page. How
do I track dependencies between issues in different modules? As you can
see at [2], it's filled for Evolution module, but it blocks a bug for
evolution-ews module. These things are common when you work on
something more complex, split into several modules.
Someone should fix the broken link, but basically you just maintain a list of auto-links in the issue description. E.g.
# Blocked by #
- #123
- #456
- nautilus#789
When the auto-linked issues are closed, they will automatically show up as "#123 (closed)" in the web UI.
[1] https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/GitLabWorkflows
[2] https://bugzilla.gnome.org/show_bug.cgi?id=200907#c37
[3] https://gitlab.gnome.org/GNOME/nautilus/issues/30667
