Re: A few NonGNU ELPA package proposals

["Bozhidar Batsov" <bozhidar@batsov.dev>]

[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]

I'm not familiar with some of those packages, but I don't see anything concerning about them either. I guess you know that the author of most of those packages is reliable, which is good enough for me. 

On Mon, Jul 4, 2022, at 1:35 AM, Philip Kaludercic wrote:
> Philip Kaludercic <philipk@posteo.net> writes:
> 
> > Stefan Monnier <monnier@iro.umontreal.ca> writes:
> >
> >>>> >> Hope there are no objections to these additions.
> >>>> > What are the criteria for objections in this case?
> >>>> If someone thinks that there are technical issues with the package
> >>> What kind of technical issues would be relevant in these cases?
> >>
> >> E.g. if one of those packages depends on a package which is not in
> >> (Non)GNU ELPA?
> 
> Yes, or something like deprecated dependencies that can be fixed, in
> case I missed something.
> 
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >>> there is a better alternative to some package I propose that we
> >>> should add instead of what I suggested to avoid duplication.
> >>
> >> This last criterion I don't think I understand.  I was under the
> >> impression that we are not supposed to limit admission of packages
> >> just because there are alternatives to what they do.
> >>
> >> For example, symbol-overlay seems to do what hi-lock-mode does.  But
> >> my understanding was that this fact shouldn't preclude symbol-overlay
> >> from being admitted.  Now you seem to be saying that we shouldn't add
> >> such packages?
> >>
> >> Bottom line: I'm still confused.
> 
> To my knowledge these aren't fixed rules, and as I say "avoid" doesn't
> mean prevent by all means.  There are already examples like project and
> projectile that are pretty similar.  In this case it seems to me that
> symbol-overlay is sufficiently different from hi-lock-mode to make the
> addition worthwhile, but of course that is exactly the point I wanted to
> discuss.
> 
> The general intention is to allow for comments before adding new
> packages.
> 
> 

[-- Attachment #2: Type: text/html, Size: 3066 bytes --]