Re: [mantisbt-dev] Upstream dependencies

[Victor B. <vi...@fu...>]

+1 I think I suggested something similar earlier.  Here are some
suggestions:

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).

Disadvantage:

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
<rob...@gm...>wrote:

> Hi,
>
> 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
> http://www.mantisbt.org/bugs/view.php?id=14157
>
> 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
> themselves.
>
> Here's my proposal on how to do it and I'd like to prototype it for nusoap
>
> 1. Import ( or fork ) the 3rd party sources into a github repo under
> mantisbt
> 2. the upstream branch is named 'vendor' and versions are tagged with
> 'vendor-x.y.z'
> 3. the master branch contains the code found in the master branch in
> mantisbt
> 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' )
>
> WDYT?
>
> Robert
> --
> 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
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>