On Fri, Jan 25, 2019 at 10:06:18PM -0200, Carlos Donizete Froes wrote:
> Hi Tobias,
>
> > Sorry, that I have again to be the game spoiler, but as I asked you
> > already on diffeent software but on quite a similiar situation:
> >
> > _Why_ did you fork this?
> >
> > There are no obvious reasons, upstream[1] is very active (and has
> > actually released a newer version than yours) and your changes to the
> > source code are fixing typos, and those mostly in comments. I could not
> > find any difference that. That does NOT make you the upstream author.
> >
> > Maybe I was not explict enough: Such forks are damaging to the FLOSS
> > ecosystem. Forks should ONLY done for severe reasons.
> >
> > Forks like this one might be even seen as quite offensive, as it
> > looks like that you want to take credits where credits are not due.
> >
> > Work with upstream. Do not fork without *severe* reasons.
> >
> > IMHO, if we include blastem, than from [1].
>
> As the upstream is working with Mercurial, at the moment we were talking about migrating to my
> GitLab account and the procedure to start the packaging and permission to make small changes to
> reduce the huge amount of lintian errors and warnings.
So, ok; but this is not a reason to say:
Upstream Author : Carlos Donizete Froes <coringao@riseup.net>
in #919540 and setting your gitlab repository as upstream repository in
the packaging. Actually, this is misleading and I also find this unfair
to Michael Pavone.
You can really alienate upstreams by claiming their work
is yours. You surely understand that this is bad and against the
spirit of Open Source and Debian.
From the posted mails in #919540 I cannot see that upstream agreed to
move everything to your repository, his words were, which IMHO as quite
different meaning and does not even touch the topic you seem to read out
of it:
"I realize Mercurial is a bit unfashionable these days, but I believe
there is a bridge that allows git to interop with it. Pulling from the
public repo will make it easier for me to accept your changes upstream.
Assuming that's what you want anyway."
(And I wonder why you set the gitlab as upstream repository, while you
seem to collaborate on github)
> Please follow the email contacts I had with the upstream.[1]
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919540
>
> I'm sorry for giving you a poor opinion that I only make corrections for typos in my comments,
> please check my comments again. :(
I did a complete diff against upstream [1] and your repo [2], both
"trunk" for that. And the only behaviourl change seems to be
--- blastem-ba3fb7a3be6b/zlib/gzlib.c 2019-01-23 06:15:38.000000000 +0100
+++ blastem/zlib/gzlib.c 2019-01-25 20:15:47.852968532 +0100
@@ -291,6 +291,7 @@
gzFile gz;
if (fd == -1 || (path = (char *)malloc(7 + 3 * sizeof(int))) == NULL)
+ free(path);
return NULL;
#if !defined(NO_snprintf) && !defined(NO_vsnprintf)
(void)snprintf(path, 7 + 3 * sizeof(int), "<fd:%d>", fd);
diff -Naur blastem-ba3fb7a3be6b/zlib/trees.c blastem/zlib/trees.c
(which introduces a bug, as the return is no longer conditional.)
So either I'm right and there are no siginifant changes, or upstream has
merged everything you have provided, but that means that upstream is [2]
not you.
[1] https://gitlab.com/coringao/blastem
[2] https://www.retrodev.com/repos/blastem
> I do not want to be the author of the software. All the work I do, I'm always communicating with the
> upstream. The reason is to help the upstream get their software in Debian. :)
Then do not claim being the upstream author in the first place.
> BlastEm (0.6.2-1) found in mentors.d.o[2] is the most current one with some fixes for which the
> upstream itself made the changes to start Debian packaging.[3][4]
Ok, then this is an good occasion to fix those issues.
> [2] https://mentors.debian.net/package/blastem
>
> [3] https://gitlab.com/coringao/blastem/commits/master
>
> [4] https://www.retrodev.com/repos/blastem
>
> Thanks!
>
> --
> ⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
> ⣾⠁⢠⠒⠀⣿⡁ - https://wiki.debian.org/coringao
> ⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
> ⠈⠳⣄⠀⠀⠀ 2157 630B D441 A775 BEFF D35F FA63 ADA6 B638 B780
Attachment:
signature.asc
Description: PGP signature