@Conan-Kudo: we differ on what a serious patch is: both zstd and LMDB were
shooting fish in a barrel.
Give them a bit of a break ... from what? Ignoring issues takes zero effort.
I am not on iirc, it's a waste of time for me.
--
You are receiving this because you are subscribed to this
> You have discarded serious patches that I have submitted to your code.
This is not true. Both zstd and LMDB support are major contributions that have
been merged into rpm.org from you. If nothing else, this proves that we're
willing to take proposed code. Just please do the modicum of effort
I'd rather work on code as well.
I understand workload and the need for community transparency.
However, the delays on submitted patches are beginning to be measured in months
and years.
The comments are unhelpful to submitters as well, and are usually one of the
following:
0) where is the
@n3npq : As for not getting comments to your tickets, the problem is that
you're simply filing *way* too many of them. We cannot let one person's tickets
and interests dominate our time, and we'd really rather work on code than
tickets anyway. We're working to clear the backlog and will try to
The macro stacks are a internal implementation detail that we really do not
want to expose as part of the syntax - further than it is already. In the
future we may change the way macro definitions work to something sane like
local name spaces. Adding this feature would make such changes to the
Closed #503.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/503#event-179778___
Rpm-maint mailing list
Get a copy of RPM5 rpmio/macro.c (the cvs is browsable at http://rpm5.org even
if the interface is clunky).
Look for "stackarray", the variable that controls the functionality.
There are basically 3 uses:
1) initialize to zero
2) set by parsing/detecting a %{M:S} construct
3) if stackarray is
> I can/will point you to the 20-30 lines of code in rpm5 and tell you where to
> put them in rpm4 rpmio/macro.c if you wish to "play".
So point me to.
> before in rpm.org issues in the past year
Sorry, you are opening so many of them so I just can't keep up with reading all
of them ;)
--
I can/will point you to the 20-30 lines of code in rpm5 and tell you where to
put them in rpm4 rpmio/macro.c if you wish to "play".
There is too little interest for me to justify the work involved in a PR
however: the functionality has been mentioned before in rpm.org issues in the
past year.
As I stated above, I'm interested to see patch and play a bit with it. So if
you have one -- feel free to open PR and I will test it out.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
We have had this discussion before: I have no reason to believe that any code I
submit will be accepted, and I have multiple instances to indicate that any
code I submit will be rejected.
Hence RFEs for comments, of which so far there are almost zero comments.
--
You are receiving this
Well, send a PR. Submitting gazillions of RFEs doesn't help without patches.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Adding %{split:...} and %{join:...} primitives as syntactical sugar for
multiple %define operations, implemented through argv routines, are obvious
extensions to handling tuples within macro instantiation and expansion.
--
You are receiving this because you are subscribed to this thread.
Reply
There are three archetypal forms in computer languages: scalars,
lists/tuples/arrays, and maps.
RPM macros only implement scalar key:value assignments. This RFE is a suggested
extension to permit macro values to add syntax to expand a stack into a list
with a common separator.
The suggested
14 matches
Mail list logo
