I was asking how do we let Fedora know if we have applied a vendor patch to our distro that has not yet been released by the vendor in an official version but will be part of their next release (some when). Is there an official way to let you know what the patches are? Possibly just a notice in our readme sighting vendor versions and or revision numbers from their VCS?<div>
<br></div><div>Regards,<br><div><div><br></div><div>Drak<br><br><div class="gmail_quote">On 21 May 2010 21:08, Paul W. Frields <span dir="ltr"><<a href="mailto:stickster@gmail.com">stickster@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="h5">On Fri, May 21, 2010 at 07:57:52PM +0545, Drak wrote:<br>
> On 21 May 2010 19:51, Paul W. Frields <[1]<a href="mailto:stickster@gmail.com" class="vt-p">stickster@gmail.com</a>> wrote:<br>
><br>
> On Fri, May 21, 2010 at 09:36:11AM +0545, Drak wrote:<br>
> > Off-topic maybe: What is the policy to using vendor fixes that have<br>
> not<br>
> > yet been released?<br>
> > Drak<br>
><br>
> Good question, Drak. I think it's acceptable for us to include<br>
> patches in a RPM that are backported fixes expected to be in the next<br>
> upstream release. This happens frequently in the kernel, for example,<br>
> especially where Fedora contributors are providing said patches. The<br>
> goal is always to reduce those fixes/patches to zero, or as close to<br>
> zero as possible.<br>
><br>
> What is the procedure for letting you guys know the packaging<br>
> requirements? Is there something we can add to our continuous integration<br>
> process? We could build it automatically... <br>
> Drak <br>
<br>
</div></div>Hi Drak,<br>
<br>
What packaging requirements are you referring to? I'm not sure I'm<br>
clear on what you're asking.<br>
<br>
Normally the maintainers of a Fedora package keep tabs on upstream<br>
releases, and when there's a new one, or if there's a good reason to<br>
patch and rebuild, the maintainer would do that in Fedora. One of our<br>
distro requirements is to be fully self-hosting, so builds need to<br>
happen in the Fedora build system. However, any upstream developer<br>
with a FAS account should be able to anonymously check out our package<br>
source tree, trivially fiddle with the spec file to use new sources,<br>
and send a "scratch build" request to our system. (A scratch build is<br>
basically a test build that will not be published for general use, but<br>
is good for temporary testing use.)<br>
<br>
Does this help clarify at all?<br>
<div><div></div><div class="h5"><br>
--<br>
Paul W. Frields <a href="http://paul.frields.org/" target="_blank" class="vt-p">http://paul.frields.org/</a><br>
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717<br>
<a href="http://redhat.com/" target="_blank" class="vt-p">http://redhat.com/</a> - - - - <a href="http://pfrields.fedorapeople.org/" target="_blank" class="vt-p">http://pfrields.fedorapeople.org/</a><br>
Where open source multiplies: <a href="http://opensource.com" target="_blank" class="vt-p">http://opensource.com</a><br>
_______________________________________________<br>
logistics mailing list<br>
<a href="mailto:logistics@lists.fedoraproject.org" class="vt-p">logistics@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/logistics" target="_blank" class="vt-p">https://admin.fedoraproject.org/mailman/listinfo/logistics</a><br>
</div></div></blockquote></div><br></div></div></div>