Looks like we have a plan here, right? The first candidates are adodb and phpmailer.
I agree with Robert's suggestion.
I also believe that Victor's proposal to use git submodules is the right
way to do it, although it will take some getting used to and we need to
be careful working with them to avoid a few caveats.
You are probably referring to this...
On 28/06/12 00:32, Victor Boctor wrote:
> +1 I think I suggested something similar earlier.
On 25/10/11 19:41, Victor Boctor wrote:> I think for 3rd party libraries
we should report upstream. If the bug
> is important and needs to be addressed sooner than the likelihood of
> getting the upstream fix, then I believe we should fix it in our
> codebase. However, we should make sure that we can discover these fixes
> and re-apply the appropriate ones when we apply a new version of the
> library (in this case ADODB).
> My suggestion is to consider doing that through git sub-modules. In
> such case, we will do the following:
> 1. Fork the ADODB git repository if available, otherwise, create one on
> 2. Apply our fixes there on a branch (e.g. mantisbt-1.2.x,
> mantisbt-1.1x, etc).
> 3. Link our ADODB repository into our mantisbt repository.
> This will allow us to get the flexibility we need, be able to easily
> enumerate our changes, have different changes per major branch, and will
> also allow other teams to potentially use our version of ADODB if that
> makes sense to them. It will also allow us to easily send pull-requests
> for those who support it.
As I've been doing some work on fixing ADOdb library myself (mostly bugs
and compatibility issues with Oracle and PostgreSQL), I think it would
also be a good candidate for this model (at least until
next/2.0/whateveritwillbecalled finally ditches this library)
On 28/06/12 00:32, Victor Boctor wrote:
> +1 I think I suggested something similar earlier. Here are some
> 1. I would like to think of the repository as an upstream repository or
> a fork of it. In such case, it should have branches / tags for master,
> master-x.y.z, etc for its own branches and releases.
> 2. Whether number one is an import or a fork, we should create branches
> as fixes-for-x.y.z that contain our fixes on top of master-x.y.z.
> 3. In MantisBT repo, depending on the branch we add a submodule that
> refers the Nusoap repository, appropriate branch, appropriate change
> set. If both master and master-1.2.x use the same nusoap version x.y.z,
> then they will both point to mantisbt\nusoap\fixes-for-x.y.z. Once
> master uses a newer version, then at that point, the reference will be
> updated accordingly.
> Advantages to the above model:
> 1. The branch names are very clear in projects like Nusoap and others.
> 2. In case Nusoap is a fork (rather than important), we are likely to
> cause confusion by names like master and master-1.2.x.
> 3. If master / master-1.2.x are using the same version, then we only
> need to fix the bug once.
> 4. If others want to consume our repositories and contribute to it, they
> will contribute to the right branches (e.g. fixes-for-x.y.z).
> 1. We will have to use recursive clone rather than clone to have the
> sub-modules expanded (see
> http://stackoverflow.com/questions/3796927/how-to-git-clone-including-submodules )
> On Wed, Jun 27, 2012 at 2:01 PM, Robert Munteanu
> <mailto:email@example.com>> wrote:
> Once again, we're being bit by upstream dependencies. The following
> bug is an error in NuSOAP which is only triggered in PHP 5.4 .
> 14157: Array to string conversion error on soap request with PHP 5.4
> I really want to fix this bug in a manner which makes sense for our
> development model and which does not waste a lot of time.
> Currently, we're integrators. We take 3rd party libs and dump them
> into our tree and that makes us responsible for them. It does not make
> sense to ship unchanged sources if they are buggy or insecure. My
> opinion is that we should _always_ patch the third party lib and make
> it trivial for integrators ( like Fedora ) to apply the patches
> Here's my proposal on how to do it and I'd like to prototype it for
> 1. Import ( or fork ) the 3rd party sources into a github repo under
> 2. the upstream branch is named 'vendor' and versions are tagged with
> 3. the master branch contains the code found in the master branch in
> 4. the master-1.2.x branch contains the code found in the master-1.2.x
> branch in mantisbt
> 5. mantisbt releases are tagged with 'mantisbt-a.b.c'
> 6. in the mantisbt repo we have a DISTRIBUTORS file which clearly
> states how the upstream sources are modified and how to get the
> changes ( e.g. git format-patch vendor-x-y-z..mantisbt-a.b.c' )
> Sent from my (old) computer
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
mantisbt-dev mailing list