Re: Salsa repository request

[Fabian Wolff <fabi.wolff@arcor.de>]

On Sun, Jun 17, 2018 at 07:02:15PM -0400, Sergio Durigan Junior wrote:
> I see a few problems here; some I need you to address before moving
> forward, and others can be tackled later.  Let me make a list:
> 
> 1) You're basically removing functionalities from the upstream project,
> so I think you should detail what's being removed (and why) on
> d/README.Debian.
> 
> 2) I also think it's a good idea to proper license your code, because it
> will be redistributed along with the project.  I'd suggest choosing the
> same license as the project.
> 
> These two problems are easy enough to fix, and I think that uploading a
> package without having them addressed first is not going to work.

I have added a README.Debian as well as copyright and license notices
in antlr3convertutf.*.

> Other things worth doing:
> 
> 3) IANAL, but this issue seems serious enough to justify contacting
> upstream and reporting the problem to them.

  https://github.com/antlr/antlr3/issues/193

I don't have much hope though; the most recent activity in the
runtime/C/ folder of the repository seems to date back to more than
four years ago.

> 4) I see that src/antlr3string.c is the only user of the
> ConvertUTF16toUTF8 function.  What do you think of declaring the
> function inside the file?  This way we'd get rid of the problematic
> files, which is a good thing, since we'll not export their API anymore.

In principle, I agree. In fact, the declaration of ConvertUTF16toUTF8
is already in antlr3string.c (and not in the header file). However,
moving the *definition* of the function into antlr3string.c (which is
probably what you meant) is not possible because it is a C++ function,
and antlr3string.c is written in C.

Also, the remaining content of the header file (the typedefs and
preprocessor definitions) are used in other parts of the code, too (in
antlr3inputstream.c, for instance).

> Great.  I see you did the experimental work on the master branch.  I
> personally don't think it's a good idea, because eventually you'll have
> to release the package on stable, and d/changelog doesn't need to have
> entries reflecting experimental releases.  What I usually do is create a
> separate branch ("debian-experimental" or some such) and do the
> experimental work there.  This way, when it's time to merge, it's
> easier.
> 
> There's a nice write-up of this workflow here:
> 
>   https://wiki.debian.org/PackagingWithGit#Merging_a_debian-experimental_branch_into_master_for_sid
> 
> But bear in mind, you don't need to fix this before I upload.  Actually,
> if you prefer you can keep your experimental work on the master branch,
> no problem at all.

Thanks for the info. I have now continued my work on the
debian-experimental branch.

> > Sergio, would you be willing to sponsor this upload? I would also be
> > glad if you could assist me with the rest of the transition process.
> 
> Yeah, I'd be happy too.  It will be my first time monitoring a
> transition :-).  Just let me know when you have addressed the two issues
> I mentioned above, and I'll upload the package right away.

I have pushed my changes to the Salsa repository (on the
debian-experimental branch), and I've also reuploaded the package to
Mentors.

Best regards,
Fabian