On Mon, Feb 04, 2008, Jeff Johnson wrote:

> On Feb 4, 2008, at 1:59 PM, Ralf S. Engelschall wrote:
>> On Mon, Feb 04, 2008, Jeff Johnson wrote:
>>
>>>   Modified files:           (Branch: rpm-5_0)
>>>     rpm                     CHANGES macros.in
>>> [...]
>>>   -%patch(b:p:P:REz:F:d:) \
>>>   +%patch(b:p:P:REz:F:d:) %{shrink:\
>>> [...]
>>
>> Be careful. This I think is now broken as %{shrink:..} and
>> other new features were not merged onto rpm-5_0.
>
> Thanks for noticing. I'll check-in the macro.c builtin changes momentarily
> ...
>
>> Ok, shrink might be harmless to merge, but in general I think we should
>> not merge new features back into rpm-5_0...
>
> For "no-brainers" like %{realpath:...} and %{getenv:...} and %{shrink:...}
> I think we're better off being aggressive in order to have common
> functionality.

IMHO there is no need to have any common functionality. It is just fine
if something is missing in 5.0. Because if we merge too many things to
5.0, 5.1 will never be used and its release is just delayed.

New features should be not merged back as this both destabilizes already
stable code _and_ at the same time reduces the community interest in
the forthcoming release(s).

So, this time it is already too late: merge %{shrink}, of course. But in
general I strongly recommend to _not_ merge back any "features" at all
-- independent whether they are based on trivial implementations or not.
Because there is always something one overlooks and a 5.0.X has to be a
100% drop-in replacement for 5.0.(X-k). By merging back changes this is
not the case...

> All else depends on what is signified by "new" and "feature" or implied by
> "bug".

Sure, it's a nasty definition issue...

> The rationale for pushing back "#%patch" should be obvious however. Stoopid
> issue ...

Sure, so let's merge it, of course.

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com