On Fri, Nov 26, 2010 at 9:02 PM, till <t...@php.net> wrote:
>
> How often does it happen that CouchDB has to patch/modify software
> like Mochiweb? And what are the chances to push the patches to
> upstream prior to releasing CouchDB. I realize this could slow down
> the release process, but it would make a cleaner build.

With ibrowse it happened very often lately.
Sometimes serious bugs take weeks or months to get applied (yeah, it's
not just bug reports, it's bug report + patch). Like for e.g:

https://github.com/cmullaparthi/ibrowse/issues#issue/20  (not yet applied)
https://github.com/cmullaparthi/ibrowse/issues/closed#issue/17
https://github.com/cmullaparthi/ibrowse/issues/closed#issue/7





>
> Till
>
> On Fri, Nov 26, 2010 at 9:44 PM, Noah Slater <nsla...@apache.org> wrote:
>> The release artefact absolutely should not, ever, pull down files from the 
>> network. However, I can see a way forward by having the bootstrap script 
>> manage the bundling of external dependancies. The bootstrap script should 
>> only ever be run from a checkout of the code. Whatever it downloaded and 
>> prepared would be included as part of the release artefact.
>>
>> But assuming we got this working, we face the problem of not being able to 
>> apply our own patches. Also, the software it downloads might have some bug 
>> in it that was introduced a week, day, or hour before the release was made. 
>> How would we defend ourselves against this?
>>
>> On 26 Nov 2010, at 20:38, Adam Kocoloski wrote:
>>
>>> Hi all, there's a discussion in the 1.0.2 voting thread about better 
>>> tracking of upstream dependencies like mochiweb.  One point that keeps 
>>> getting brought up is that build systems should not need network access.  
>>> Is that a rule which applies to building from an SCM repo, or only to 
>>> builds of release artifacts?
>>>
>>> I think we might be able to make our lives easier if we only bundled 
>>> upstream dependencies at release generation time, and otherwise relied on 
>>> the build system to retrieve them.  For a concrete example, BigCouch 
>>> recently switched to using rebar for dependency resolution.  The main repo 
>>> at https://github.com/cloudant/bigcouch only has the couch OTP application 
>>> in it, the other dependencies are pulled from forked git repositories 
>>> containing CouchDB-specific branches and tags such as 
>>> https://github.com/cloudant/ibrowse/tree/CouchDB-1.0.1
>>>
>>> If the no-network-access rule does apply to SCM builds, we might consider 
>>> bundling full git repos instead of doing the source code copy/paste dance.  
>>> At least this would allow a clearer indication of where we stand w.r.t 
>>> upstream.  Best,
>>>
>>> Adam
>>
>>
>



-- 
Filipe David Manana,
fdman...@gmail.com, fdman...@apache.org

"Reasonable men adapt themselves to the world.
 Unreasonable men adapt the world to themselves.
 That's why all progress depends on unreasonable men."

Reply via email to