Re: [arch-dev-public] SDR package naming
[2020-06-05 15:30:54 +0100] Filipe Laíns via arch-dev-public: > No consensus came from my attempt at > contacting him. And there was no discussion, it was one sided, so I > feel like this issue is not resolved. There are still relevant points > that I want to see addressed. It looks to me like Kyle answered your questions and then had better things to do than continue debating naming conventions, especially as the only kind of "solution" you appear to seek is compliance with your demands. But if you do not accept that a consensus is emerging from replies to your question by Kyle, Eli and myself, do you wish to call for a vote? Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] SDR package naming
On Fri, 2020-06-05 at 10:19 -0400, Eli Schwartz via arch-dev-public wrote: > On 6/5/20 9:04 AM, Filipe Laíns via arch-dev-public wrote: > > My main concern here is that it is not as simple as it just being > > Kyle's decision, it sets a precedent. I believe the naming is > > incorrect, and as such, should be fixed. I have tried initiating a > > conversation with the maintainer but with that didn't result in > > anything. > > It did result in something: he said "no". > > > I really don't want to step in anyone's toes, I have postponed this > > email as much as I could. Giving the lack of the reply from Kyle, one > > can only assume he does not care that much about the issue. I am fine > > with waiting one or two weeks before taking action to make sure he has > > time to reply, if there are no objections. > > "I don't agree with this, it fails to be memorable and using the > upstream shortname is confusing and does a disservice to users" sure > sounds like he objects to me. Hi Eli, Sorry, I wasn't clear, my bad. No consensus came from my attempt at contacting him. And there was no discussion, it was one sided, so I feel like this issue is not resolved. There are still relevant points that I want to see addressed. Cheers, Filipe Laíns signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] SDR package naming
On 6/5/20 9:04 AM, Filipe Laíns via arch-dev-public wrote: > My main concern here is that it is not as simple as it just being > Kyle's decision, it sets a precedent. I believe the naming is > incorrect, and as such, should be fixed. I have tried initiating a > conversation with the maintainer but with that didn't result in > anything. It did result in something: he said "no". > I really don't want to step in anyone's toes, I have postponed this > email as much as I could. Giving the lack of the reply from Kyle, one > can only assume he does not care that much about the issue. I am fine > with waiting one or two weeks before taking action to make sure he has > time to reply, if there are no objections. "I don't agree with this, it fails to be memorable and using the upstream shortname is confusing and does a disservice to users" sure sounds like he objects to me. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] SDR package naming
On Thu, 2020-06-04 at 22:43 -1000, Gaetan Bisson via arch-dev-public wrote: > [2020-06-04 23:03:23 +0100] Filipe Laíns via arch-dev-public: > > 1) Rename libuhd to uhd > > 2) Use the gr- prefix instead of gnuradio- for GNURadio[2] blocks > > Your proposed changes indeed seem the correct thing to do, but Kyle > appears to have done a good job maintaining those packages over the > years. Do you really think it is worth bypassing his decision using a > community vote for something of almost no consequence? Hi Gaetan, My main concern here is that it is not as simple as it just being Kyle's decision, it sets a precedent. I believe the naming is incorrect, and as such, should be fixed. I have tried initiating a conversation with the maintainer but with that didn't result in anything. I really don't want to step in anyone's toes, I have postponed this email as much as I could. Giving the lack of the reply from Kyle, one can only assume he does not care that much about the issue. I am fine with waiting one or two weeks before taking action to make sure he has time to reply, if there are no objections. I have delayed bringing new GNURadio blocks to [community] due to the naming issue. I would like to have this resolved soon. > If we are to work together, we must sometimes learn to accept others' > decisions we don't 100% agree with... All I am trying to do is work together, but failing. As I said above, this decision affects more than Kyle's packages. Nobody is denying him of him opinion or decision rights, he is free to speak up at any time. I would be very happy to have a discussion with him about the issue :) Cheers, Filipe Laíns signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] SDR package naming
[2020-06-04 23:03:23 +0100] Filipe Laíns via arch-dev-public: > 1) Rename libuhd to uhd > 2) Use the gr- prefix instead of gnuradio- for GNURadio[2] blocks Your proposed changes indeed seem the correct thing to do, but Kyle appears to have done a good job maintaining those packages over the years. Do you really think it is worth bypassing his decision using a community vote for something of almost no consequence? If we are to work together, we must sometimes learn to accept others' decisions we don't 100% agree with... Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] SDR package naming
Hi all,
I want to bring up two issues relating Kyle Keen's packages. I tried to
contact him and got an initial reply but I have not heard from him
since. It has been almost 4 months and I have sent him 3 different
followup emails. Since it was not super urgent I let a pretty
significant amount of time pass but I would like to have this resolved.
Here are the two issues I seek resolution:
1) Rename libuhd to uhd
UHD[1] is the upstream name. The software is pretty well known by that
name. I have only ever seen it being addressed as libuhd when talking
about the library it provides specifically, but even then UHD is the
standard. It also provides some tools alongside the library.
Following the Arch philosophy I think the package should be named
"uhd".
2) Use the gr- prefix instead of gnuradio- for GNURadio[2] blocks
The GNURadio ecosystem has a pretty well established prefix for
GNURadio blocks, which is gr-. Similarly to the previous issue, I have
never seen them being refereed as gnuradio-something. The upstream
names are gr-something. The gnuradio- prefix might seem to make things
more clear to new users, and even then I have my doubts, but it
definitely makes things more confusing for actual users of the project.
Previewing some counter-arguments to this, as I have discussed it with
people previously. This is totally different than, for eg., the python
ecosystem where we use the python- prefix. The gr- is given by the
upstream and is the *de facto* naming scheme for the project.
If you don't agree with the use of the gr- prefix, I think that
variation of the name should *at least* be present in provides.
These might seem like nitpicks, but I do very much care about them and
I believe they should be corrected.
You can find my attempt at communication with Kyle below.
I am very conflicted about this, but I think before I end the email I
should note that Kyle is packaging and he appears to have replied to
other team member(s). I am not sure if I have done something wrong or
behaved in an improper manner. I don't think I did, but if that's the
case please let me know.
[1] https://github.com/EttusResearch/uhd
[2] https://github.com/gnuradio
Cheers,
Filipe Laíns
On Thu, 2020-02-06 at 09:42 +, Filipe Laíns wrote:
> On Wed, 2020-02-05 at 23:21 -0500, keenerd wrote:
> > Sometimes my automatic email filing puts things in the wrong place,
> > but searching across all folders finds no emails from you about this.
> > How did you try to contact me before?
> >
> > UHD I am ambivalent on. However several other distros also call it
> > "libuhd" and it is a library after all.
> >
> > Gnuradio vs gr I don't agree with. A project needs to be very notable
> > for a two-letter naming convention. Python, for example, is
> > sufficient. Internally the Gnuradio project uses "gr" because, well,
> > they type it hundreds of times every day. Outside of their project,
> > it is less helpful and more confusing.
> >
> > There are several people deeply involved with Gnuradio who are also
> > Arch users. I more or less started packaging Gnuradio for them, and
> > their input was instrumental in making our packages the way they are.
> > They've never raised any of these issues.
> >
> > You did not provide any reasoning for why you think changes are necessary?
> >
> > -Kyle
> >
> > On 2/4/20, Filipe Laíns wrote:
> > > Hey Kyle,
> > >
> > > I think I have contacted out about this already but without much
> > > success. I would like to adjust the names of some SDR packages. I
> > > believe `libuhd` should be called `uhd` and packages that
> > > provide GNU
> > > Radio blocks should be named `gr-name` instead of `gnuradio-name`
> > > (this
> > > affects `gnuradio-{fcdproplus,iqbal,osmosdr}`).
> > >
> > > Can we adjust the naming? What do you think?
> > >
> > > Thank you,
> > > Filipe Laíns
> > >
>
> Sorry, my bad.
>
> Regarding uhd, that's what Debian does, not us. uhd is the upstream
> name and we should honor it. If you want examples just look at [1],
> from a quick browse I wasn't able to find any instances of packages
> where we add the lib prefix.
>
> Regarding GNU Radio blocks, it more of a grey area so I understand and
> respect your position. My reasoning is that the gr- prefix comes from
> the upstream, and AFAIK everybody else on earth uses it. When I started
> using Arch it was a bit confusing why the packages had different names,
> especially for a distribution that tries to keep as close to the
> upstream as possible. Do you think it would make sense to ask the GNU
> Radio guys what they think? Either way, it's ultimately your call.
> But if you don't want to rename it could we add the gr- prefixed name
> to provides/conflicts?
>
> Just some other unrelated things, I am bringing a few more SDR packages
> to Arch. I just pushed the necessary bits for Adalm-Pluto support, I am
> working on srsLTE (actually, almost finished, just waiting for some
> replies from the upstream) and I want
