A page in your DokuWiki was added or changed. Here are the details:
Browser : Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36
IP Address : 62.96.26.163
Hostname : 62.96.26.163
Old Revision : https://wiki.x2go.org/doku.php/wiki:bugs?rev=1719851616
New Revision : https://wiki.x2go.org/doku.php/wiki:bugs
Date of New Revision: 2024/07/01 16:35
Edit Summary :
User : uli42
There may be newer changes after this revision. If this
happens, a message will be shown on the top of the rev page.
@@ -11,10 +11,12 @@
Before X2Go had a bug tracker, the quest was: we need a BTS that is easily
scriptable and a BTS that fully maps issue tracking to the developers' mail
clients. Furthermore, we did not want a bug tracker that could be fed with
content by clicking around on a web page.
The choice has been well thought of, you may find that there are better bug
tracking systems in the world. For X2Go, we think we have found what we wanted.
+ </del>
===== Viewing Bug History =====
+ <del>
If you know either the X2Go component or the bug number you can also access
the information directly:
* http://bugs.x2go.org/<nnn> (where <nnn> is the bug number)
@@ -22,19 +24,25 @@
A complete list of X2Go components with open/closed bugs can be viewed with
this URL:
* [[http://bugs.x2go.org/cgi-bin/pkgindex.cgi?indexon=src]]
+
+ </del>
===== Reporting Bugs =====
+ <del>
How to report a bug is fully explained
[[http://bugs.x2go.org/Reporting.html|here]]. In a nutshell send a mail like
the one below (everything that is written in <pointed-brackets> needs being
replaced by some proper value. Please review our
[[#gdpr_notice_privacy_policy|GDPR Notice/Privacy Policy for reporting bugs]]
before submitting a bug report.
**We strongly encourage you to subscribe to the X2Go-Dev mailing list before
submitting your bug.** Its subscription page is here:
http://lists.x2go.org/listinfo/x2go-dev
Subscribing has the following advantages:
- Your bug report will show up on X2Go-Dev immediately, as opposed to being
queued for moderation and manual inspection by a list admin (which may take a
few days, as it is a volunteer task)
- You will receive all the relevant discussion regarding your report, even
if someone forgets to CC the bug tracker in their reply
+ </del>
+
==== Plain bug submission ====
+ <del>
Definition of fields/formatting requirements:
<code>
To: [email protected]
@@ -94,9 +102,12 @@
- The server's version of the x2goserver-xsession package
- The server's version of the nxagent package
- The server's version of any other relevant packages (e.g., if the bug as
about MATE integration, the version of x2gomatebindings)
- Any relevant settings in X2GoServer (that you changed from the defaults)
+ </del>
+
==== Bug submission with a Patch ====
+ <del>
In case you can provide a patch with your bug report, please attach the patch
to your bug report. Do __not__ copy+paste the patch into the mail body, as the
result will not be usable!!!
Create patches for master branch and send them in git format. The
documentation about creating git patches can be found
[[http://www.git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project#Public-Large-Project|here]]
@@ -116,10 +127,12 @@
<your-not-too-long-description-of-the-discovered-problem>
Attachment: <your-patch.diff>
</code>
+ </del>
==== Feature requests / Wishlist bugs ====
+ <del>
Feature requests are also handled via the X2Go BTS system. Feature requests
are bugs with severity ,,wishlist". See example below.
<code>
@@ -133,22 +146,28 @@
<your-not-too-long-description-of-the-discovered-problem>
</code>
+ </del>
===== Controlling Bugs =====
+ <del>
The full control command set is documented
[[http://bugs.x2go.org/server-control.html|here]].
Very common control sequences are shown below.
+ </del>
==== Bug has been fixed in X2Go Git ====
+ <del>
Marking bugs being fixed in X2Go Git has been automatized.
**Important notice for developers:** Every X2Go source project uses
''/debian/changelog'' as (upstream!) changelog file. If you fix a bug make sure
to add a »(Fixes: #<nnn>)« at the end of the changelog entry (where #<nnn> is
the bug number, e.g. #186). If you commit a bug fix in that way, a script will
notice that and send a mail to the bug's mail address in X2Go BTS. The bug will
be tagged as »pending« and some information is added (changelog diff, link to
the commit in X2Go Git's WebUI).
+ </del>
==== New version with a bug fixed has been released ====
+ <del>
As part of the X2Go release workflow, bugs that have been fixed for this
release have to be closed. Normally, most bugs are already marked (tagged) as
pending.
Some pending bugs, though, may only have been fixed on the master branch, but
not yet on a release branch. If the release is taken from a release branch,
take a look at the //Fixed in:// field of the bug report and check if the
version to be released is mentioned in that field. If unsure, also cross-check
with the X2Go component's changelog.
@@ -164,10 +183,12 @@
Thanks for reporting this issue,
<my-name>
</code>
+ </del>
==== Bug has been reported against the wrong X2Go Component ====
+ <del>
Even for X2Go power-users and developers it is not always easy to tell, what
X2Go component causes a certain buggy behaviour in X2Go. Once a problem has
been narrowed down, we might need to reassign a bug to another X2Go component.
<code>
@@ -184,10 +205,12 @@
Thanks for reporting this issue,
<my-name>
</code>
+ </del>
==== Bug submitter used a non-appropriate title ====
+ <del>
People sometimes use inappropriate titles when submitting bugs. Also, the
summarizing title of a bug can be improved, once we know what the reason for
the occuring error really is.
<code>
@@ -202,10 +225,12 @@
Thanks for reporting this issue,
<my-name>
</code>
+ </del>
==== Cloning bugs ====
+ <del>
While fixing a Bug we might become aware of another issue arising in some
other X2Go Component that is related to the bug we just fixed. In such a case
we have to clone the bug.
<code>
@@ -224,26 +249,34 @@
Best,
<my-name>
</code>
+ </del>
===== GDPR Notice/Privacy Policy =====
+ <del>
This is the Privacy Policy that applies when submitting a bug report via
E-Mail.
+ </del>
==== HERE'S WHERE YOUR BUG REPORT WILL BE STORED AND VISIBLE TO THE PUBLIC
====
+ <del>
Reporting a bug means that your E-Mail address, as well as the content of
your message, will immediately be visible to everyone viewing the public bug
tracker of X2Go (https://bugs.x2go.org/). After subscribing to the x2go-dev
mailing list (which you really should do, so the bug report is noticed by a
larger audience), it will also be visible to everyone subscribed to the
x2go-dev mailing list, and to everyone viewing its public archive
(http://lists.x2go.org/pipermail/x2go-dev).
+ </del>
==== HERE'S HOW WE HANDLE YOUR E-MAIL ADDRESS DATA ====
+ <del>
Please understand that we need to keep your E-Mail address stored in our
public bug tracker, so others can contact you about the bug you reported or
commented on. This is a justifiable cause as set forth in Article 6 (1) b) of
the GDPR https://gdpr-info.eu/.
If you want to keep your real E-Mail address secret from the public,
we suggest you either refrain from submitting the bug, or to submit it using
a temporary, "burner" E-Mail address you created specifically for that purpose.
+ </del>
==== HERE'S HOW TO REQUEST MESSAGE DELETION ====
+ <del>
You have the right to withdraw your consent at any time, as per Article 7 (3)
of the GDPR. If you believe an E-Mail you sent should be purged from the
public bug tracker or the public archive that we operate (see the link above),
please contact the list administrators at
[email protected]
--
This mail was generated by DokuWiki at
https://wiki.x2go.org/
_______________________________________________
x2go-commits mailing list
[email protected]
https://lists.x2go.org/listinfo/x2go-commits
