Fedora Insight weekly Meeting

[David Nalley]

2010/5/24 Toshio Kuratomi <a.badger at gmail.com>:
> On Mon, May 24, 2010 at 09:43:42AM -0400, Paul W. Frields wrote:
>> On Sat, May 22, 2010 at 09:05:16AM +0545, Drak wrote:
>> >    2010/5/22 Toshio Kuratomi <[1]a.badger at gmail.com>
>> >
>> >      On Sat, May 22, 2010 at 02:03:06AM +0545, Drak wrote:
>> >      > 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?
>> >      >
>> >      I'm not sure what all your referencing:
>> >      * Who is we?
>> >      * What is our distro?
>> >      * Who is the vendor?
>> >      * Who is the you that you're letting know?
>> >
>> >    Ok plain English time :-P
>> >    When we Zikula need to add a vendor patch for a vendor library we
>> >    distribute with Zikula, we Zikula need to let you know what the vendor
>> >    patch is so your packagers know what to patch.  How do we let you know
>> >    what the correct patch is officially.  Vendor patch means a patch
>> >    committed to their VCS but not yet released in an official version.
>> >    e.g. Zikula uses Smarty.  Smarty fixes something important to us, but
>> >    hasnt yet released a version that includes that fix.  So we checkout
>> >    revision X from their source control or file y from revision X and patch
>> >    the version of Smarty we distribute.  How do we let you know if we have in
>> >    fact needed to do this.
>> >    This particular example is fictitious but the way, but could very well
>> >    happen.
>> >    Drak
>>
>> OK, thanks for that clarification Drak.
>>
>> Recall that Fedora doesn't use bundled libraries, in part so that we
>> can scale software maintenance across a wider group of participants.
>> In this case, you'd likely want to notify the maintaners of both
>> Zikula and the Smarty library to notify them of the situation and the
>> specific patch needed.
>>
>> At that time, my understanding is the Smarty maintainer would want to
>> check the Smarty upstream for intention to release the patch.  (You
>> could provide references if desired to make this process faster.)
>> That way we're only using patches that have buy-in from upstream --
>> which seems likely in the case you describe.
>>
> (And hopefully the smarty packager would add the vendor patch to our
> smarty package).
>
> For me the best medium for this is bugzilla -- but it could be that
> communicating the needs to the zikula maintainer and letting him open the
> bugzilla ticket to the smarty/php/etc maintainers is the best workflow...
> What does ke4qq think?
>
> -Toshio
>


+1 for bugzilla.
That said, it's not necessarily trivial work, and would require much
coordination.
I'd personally urge Zikula (and any other software project) to work
fervently with upstream to get the patch into a release before
releasing if at all possible. (notice that this doesn't mean stopping
the development branch). That said, some upstreams are slower than
others about releases. But do try and understand the level of work, if
15 bundled libraries require patches, it may mean as many as 15 people
may have to check with upstreams, then package, release, and so on.
That assumes that the packager wants to, it could be that the packager
might choose to only maintain un-patched upstream releases to minimize
maintenance burden. All of this can factor in to delay or it being
well night impossible for an update to get pushed (as seen with the
recent almost 6 month delay for 1.2.x versions delay, and requiring an
exception from FESCo)