[Rpm-maint] [PATCH] Check for undefined macros

Panu Matilainen pmatilai at laiskiainen.org
Fri Feb 15 10:18:43 UTC 2013

On 02/13/2013 04:19 PM, Alexey Tourbin wrote:
> On Wed, Feb 13, 2013 at 11:52:58AM +0200, Panu Matilainen wrote:
>> With my Fedora maintainer hat on:
>>  From rpm POV, Fedora 19 is a done deal at this point, except for the
>> inevitable bugfixes / 4.11.x maintenance release updates. The
>> earliest release where changes of this scale could go in would be
>> rpm 4.12 and Fedora 20 really. I've had enough of playing the "we
>> should be able to slip this in just before deadline" games by now,
>> new rpm major versions are only introduced in rawhide around the
>> time previous Fedora version has just gotten branched and the
>> schedule for the next one isn't even set yet, and generally needs to
>> be considered stable well before the next branch occurs. So compared
>> to the average Fedora development activities, we're always trying to
>> be roughly three months early (or for alternative POV, one release
>> late) to almost everybody else in landing new developments. When
>> folks are trying to stabilize the rest of the distro, they dont want
>> to (and shouldn't have to) be dealing with new rpm curveballs. The
>> other side is my own sanity (or what's left of it ;) - I just dont
>> want to play the mad and potentially risky dash to deadline when I
>> can largely avoid it by simply aligning schedules a bit differently.
> It's okay to work toward Fedora 20, although if there were a chance with
> Fedora 19, I would perhaps try harder to incorporate the patches (not by
> merely insisting harder, of course).  Anyway, I see that there are too
> many people involved, and so I'm not making a definite judgement, only
> a suggestion or even a question.

Yup, lots of people, policies and "bureaucracy" involved. Sometimes for 
to good, sometimes less so...

Of course nothing prevents cherry-picking selected bits from git master 
to, say, Fedora 19 already. Except if I do that, people here complain 
and want them in an upstream release instead :) From which we get to 
"upstream release policy" for rpm.org: maintenance releases should never 
introduce things that break builds or otherwise cause incompatibilities 
wrt packages built with the same major branch of rpm.

That means specs that are buildable with, say, 4.11.0 need to be 
buildable with 4.11.5, and the packages built with 4.11.5 must be 
compatible, autogenerated dependencies included, with packages built 
with 4.11.0.

Additional warnings on suspect syntax etc can however be added. So for 
example the "missing whitespace before macro body" patch can pulled into 
4.11.x maintenance release as it doesn't change behavior, only warns. On 
the other hand, the stricter macro substitution syntax patch can not go 
into 4.11.x (at least as-is) as it actually prevents those buggy specs 
from building at all.

> By the way, I was previously involved in a much shorter development cycle:
> - Hack on rpm and get it into the repo.
> - Rebuild the whole repo with new rpm (without actually bumping the
>    release/replacing the packages - only for testing purposes).
> - Compare build logs from previous run, identify and fix regressions.
> The cycle could be as short as one week, with the whole repo rebuild
> taking place at the weekend.  So all these months and schedules seem
> a bit odd to me, at least at first blush. :-)

I figured this might be quite a culture shock coming from AltLinux 
background, hence the "warning" :)

	- Panu -

More information about the Rpm-maint mailing list