[pacman-dev] [PATCH] Do not refer to FlySpray numbers
These references to bug numbers assume we will forever be using that bug tracker and all did not provide any information beyond the comment and commit message. Signed-off-by: Allan McRae <allan@archlinux.org> --- Left that FS numbers in the test suite as that requries a much larger clean-up. lib/libalpm/add.c | 2 +- lib/libalpm/dload.c | 2 +- scripts/makepkg.sh.in | 2 +- src/pacman/sync.c | 2 +- src/pacman/util.c | 4 ++-- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/lib/libalpm/add.c b/lib/libalpm/add.c index 8ef9ef0..df39274 100644 --- a/lib/libalpm/add.c +++ b/lib/libalpm/add.c @@ -516,7 +516,7 @@ static int commit_single_pkg(alpm_handle_t *handle, alpm_pkg_t *newpkg, } /* prepare directory for database entries so permission are correct after - changelog/install script installation (FS#12263) */ + changelog/install script installation */ if(_alpm_local_db_prepare(db, newpkg)) { alpm_logaction(handle, ALPM_CALLER_PREFIX, "error: could not create database entry %s-%s\n", diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c index 342afbc..8537b3d 100644 --- a/lib/libalpm/dload.c +++ b/lib/libalpm/dload.c @@ -466,7 +466,7 @@ static int curl_download_internal(struct dload_payload *payload, /* disconnect relationships from the curl handle for things that might go out * of scope, but could still be touched on connection teardown. This really - * only applies to FTP transfers. See FS#26327 for an example. */ + * only applies to FTP transfers. */ curl_easy_setopt(curl, CURLOPT_NOPROGRESS, 1L); curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, (char *)NULL); diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 06f7c25..e95e9a0 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -389,7 +389,7 @@ download_file() { extract_file() { local file=$1 - # fix flyspray #6246 + # do not rely on extension for file type local file_type=$(file -bizL "$file") local ext=${file##*.} local cmd='' diff --git a/src/pacman/sync.c b/src/pacman/sync.c index fc1314b..04c8f86 100644 --- a/src/pacman/sync.c +++ b/src/pacman/sync.c @@ -639,7 +639,7 @@ static int process_targname(alpm_list_t *dblist, const char *targname, { alpm_pkg_t *pkg = alpm_find_dbs_satisfier(config->handle, dblist, targname); - /* #FS#23342 - skip ignored packages when user says no */ + /* skip ignored packages when user says no */ if(alpm_errno(config->handle) == ALPM_ERR_PKG_IGNORED) { pm_printf(ALPM_LOG_WARNING, _("skipping target: %s\n"), targname); return 0; diff --git a/src/pacman/util.c b/src/pacman/util.c index 23c4009..9eb0042 100644 --- a/src/pacman/util.c +++ b/src/pacman/util.c @@ -1094,7 +1094,7 @@ double humanize_size(off_t bytes, const char target_unit, int precision, *label = labels[index]; } - /* fix FS#27924 so that it doesn't display negative zeroes */ + /* do not display negative zeroes */ if(precision >= 0 && val < 0.0 && val > (-0.5 / simple_pow(10, precision))) { val = 0.0; @@ -1531,7 +1531,7 @@ static int question(short preset, const char *format, va_list args) } /* if stdin is piped, response does not get printed out, and as a result - * a \n is missing, resulting in broken output (FS#27909) */ + * a \n is missing, resulting in broken output */ if(!isatty(fd_in)) { fprintf(stream, "%s\n", response); } -- 1.8.3.2
On Sun, Jul 14, 2013 at 11:16 PM, Allan McRae <allan@archlinux.org> wrote:
These references to bug numbers assume we will forever be using that bug tracker and all did not provide any information beyond the comment and commit message.
Signed-off-by: Allan McRae <allan@archlinux.org> ---
Left that FS numbers in the test suite as that requries a much larger clean-up.
I am OK with this in the code, but I'm not sure I buy your logic for the test suite. If a test can be directly attributed to a bug report, why would we not want to do so? This is the same reason I refer to these numbers in the NEWS file. Note that bugs like https://bugs.archlinux.org/task/6246 which were referred to below predated the move to git when we were still in CVS; thus the idea of a commit message or any sane log mechanism was non-existent. Even if Flyspray goes away, I doubt we would want to lose it completely for some time. There is too much historical data in there that might be useful.
lib/libalpm/add.c | 2 +- lib/libalpm/dload.c | 2 +- scripts/makepkg.sh.in | 2 +- src/pacman/sync.c | 2 +- src/pacman/util.c | 4 ++-- 5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/lib/libalpm/add.c b/lib/libalpm/add.c index 8ef9ef0..df39274 100644 --- a/lib/libalpm/add.c +++ b/lib/libalpm/add.c @@ -516,7 +516,7 @@ static int commit_single_pkg(alpm_handle_t *handle, alpm_pkg_t *newpkg, }
/* prepare directory for database entries so permission are correct after - changelog/install script installation (FS#12263) */ + changelog/install script installation */ if(_alpm_local_db_prepare(db, newpkg)) { alpm_logaction(handle, ALPM_CALLER_PREFIX, "error: could not create database entry %s-%s\n", diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c index 342afbc..8537b3d 100644 --- a/lib/libalpm/dload.c +++ b/lib/libalpm/dload.c @@ -466,7 +466,7 @@ static int curl_download_internal(struct dload_payload *payload,
/* disconnect relationships from the curl handle for things that might go out * of scope, but could still be touched on connection teardown. This really - * only applies to FTP transfers. See FS#26327 for an example. */ + * only applies to FTP transfers. */ curl_easy_setopt(curl, CURLOPT_NOPROGRESS, 1L); curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, (char *)NULL);
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 06f7c25..e95e9a0 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -389,7 +389,7 @@ download_file() {
extract_file() { local file=$1 - # fix flyspray #6246 + # do not rely on extension for file type local file_type=$(file -bizL "$file") local ext=${file##*.} local cmd='' diff --git a/src/pacman/sync.c b/src/pacman/sync.c index fc1314b..04c8f86 100644 --- a/src/pacman/sync.c +++ b/src/pacman/sync.c @@ -639,7 +639,7 @@ static int process_targname(alpm_list_t *dblist, const char *targname, { alpm_pkg_t *pkg = alpm_find_dbs_satisfier(config->handle, dblist, targname);
- /* #FS#23342 - skip ignored packages when user says no */ + /* skip ignored packages when user says no */ if(alpm_errno(config->handle) == ALPM_ERR_PKG_IGNORED) { pm_printf(ALPM_LOG_WARNING, _("skipping target: %s\n"), targname); return 0; diff --git a/src/pacman/util.c b/src/pacman/util.c index 23c4009..9eb0042 100644 --- a/src/pacman/util.c +++ b/src/pacman/util.c @@ -1094,7 +1094,7 @@ double humanize_size(off_t bytes, const char target_unit, int precision, *label = labels[index]; }
- /* fix FS#27924 so that it doesn't display negative zeroes */ + /* do not display negative zeroes */ if(precision >= 0 && val < 0.0 && val > (-0.5 / simple_pow(10, precision))) { val = 0.0; @@ -1531,7 +1531,7 @@ static int question(short preset, const char *format, va_list args) }
/* if stdin is piped, response does not get printed out, and as a result - * a \n is missing, resulting in broken output (FS#27909) */ + * a \n is missing, resulting in broken output */ if(!isatty(fd_in)) { fprintf(stream, "%s\n", response); } -- 1.8.3.2
On 15/07/13 23:28, Dan McGee wrote:
On Sun, Jul 14, 2013 at 11:16 PM, Allan McRae <allan@archlinux.org> wrote:
These references to bug numbers assume we will forever be using that bug tracker and all did not provide any information beyond the comment and commit message.
Signed-off-by: Allan McRae <allan@archlinux.org> ---
Left that FS numbers in the test suite as that requries a much larger clean-up.
I am OK with this in the code, but I'm not sure I buy your logic for the test suite. If a test can be directly attributed to a bug report, why would we not want to do so? This is the same reason I refer to these numbers in the NEWS file.
Note that bugs like https://bugs.archlinux.org/task/6246 which were referred to below predated the move to git when we were still in CVS; thus the idea of a commit message or any sane log mechanism was non-existent.
Even if Flyspray goes away, I doubt we would want to lose it completely for some time. There is too much historical data in there that might be useful.
My idea is to have the files self contained. So we should provide details in the code or test suite of what the bug is that is being fixed or tested. That way, we do not need to reply on Flyspray remaining available, or being accessible. I find it really annoying to have to open a web browser and navigate to the right bug report when I need to understand something. Allan
participants (2)
-
Allan McRae
-
Dan McGee