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

Alexey Tourbin alexey.tourbin at gmail.com
Wed Feb 13 14:19:46 UTC 2013

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.

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. :-)

More information about the Rpm-maint mailing list