Fedora Insight weekly Meeting
Paul W. Frields
stickster at gmail.com
Fri May 21 15:23:23 UTC 2010
On Fri, May 21, 2010 at 07:57:52PM +0545, Drak wrote:
> On 21 May 2010 19:51, Paul W. Frields <stickster at gmail.com> wrote:
> On Fri, May 21, 2010 at 09:36:11AM +0545, Drak wrote:
> > Off-topic maybe: What is the policy to using vendor fixes that have
> > yet been released?
> > Drak
> Good question, Drak. I think it's acceptable for us to include
> patches in a RPM that are backported fixes expected to be in the next
> upstream release. This happens frequently in the kernel, for example,
> especially where Fedora contributors are providing said patches. The
> goal is always to reduce those fixes/patches to zero, or as close to
> zero as possible.
> What is the procedure for letting you guys know the packaging
> requirements? Is there something we can add to our continuous integration
> process? We could build it automatically...
What packaging requirements are you referring to? I'm not sure I'm
clear on what you're asking.
Normally the maintainers of a Fedora package keep tabs on upstream
releases, and when there's a new one, or if there's a good reason to
patch and rebuild, the maintainer would do that in Fedora. One of our
distro requirements is to be fully self-hosting, so builds need to
happen in the Fedora build system. However, any upstream developer
with a FAS account should be able to anonymously check out our package
source tree, trivially fiddle with the spec file to use new sources,
and send a "scratch build" request to our system. (A scratch build is
basically a test build that will not be published for general use, but
is good for temporary testing use.)
Does this help clarify at all?
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
Where open source multiplies: http://opensource.com
More information about the logistics