headers
Robert Munteanu | 27 Jun 2012 23:01
Picon
Gravatar

Upstream dependencies

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' )
(Continue reading)

Permalink | Reply |
headers
Victor Boctor | 28 Jun 2012 00:32
Picon

Re: Upstream dependencies

+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 <robert.munteanu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
mantisbt-dev-5NWGOfrQmnc@public.gmane.orgurceforge.net
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

------------------------------------------------------------------------------
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
mantisbt-dev@...
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
Permalink | Reply |
headers
Robert Munteanu | 28 Jun 2012 10:30
Picon
Gravatar

Re: Upstream dependencies

Agreed. Let's see how this plays out with nusoap. Can you create the
nusoap repository under mantisbt? I will then import it and do the
legwork for getting this into master / master-1.2.x .

Robert

On Thu, Jun 28, 2012 at 1:32 AM, Victor Boctor <victor <at> futureware.com.au> wrote:
> +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 <robert.munteanu <at> gmail.com>
> 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
>> mantisbt-dev <at> lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>
>
>
> ------------------------------------------------------------------------------
> 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
> mantisbt-dev <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>

--

-- 
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
mantisbt-dev <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
Permalink | Reply |
headers
Damien Regad | 28 Jun 2012 12:06
Favicon
Gravatar

Re: Upstream dependencies

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.

On 28/06/12 00:32, Victor Boctor wrote:
> +1 I think I suggested something similar earlier.

You are probably referring to this...

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

Damien

On 28/06/12 00:32, Victor Boctor wrote:
> +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
> <robert.munteanu@...
> <mailto:robert.munteanu@...>> 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/
Permalink | Reply |
headers
Victor Boctor | 1 Jul 2012 22:43
Picon

Re: Upstream dependencies

Looks like we have a plan here, right?  The first candidates are adodb and phpmailer.

On Thu, Jun 28, 2012 at 3:06 AM, Damien Regad <damien.regad-5ypYqlS8vzm41k5uCYKmRQ@public.gmane.org> wrote:
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.

On 28/06/12 00:32, Victor Boctor wrote:
> +1 I think I suggested something similar earlier.

You are probably referring to this...

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

Damien


On 28/06/12 00:32, Victor Boctor wrote:
> +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
> <robert.munteanu <at> gmail.com
> <mailto:robert.munteanu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> 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
mantisbt-dev-5NWGOfrQmnc@public.gmane.orgurceforge.net
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

------------------------------------------------------------------------------
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
mantisbt-dev@...
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
Permalink | Reply |
headers
Robert Munteanu | 8 Jul 2012 10:01
Picon
Gravatar

Re: Upstream dependencies

On Sun, Jul 1, 2012 at 11:43 PM, Victor Boctor
<victor@...> wrote:
> Looks like we have a plan here, right?  The first candidates are adodb and
> phpmailer.

I'd also like to include nusoap ( my original reason for this posting ).

I've opened and assigned to myself

14458: Track third party libs as github repos
http://www.mantisbt.org/bugs/view.php?id=14458

but can you Victor ( or someone else ) create the repos in the
mantisbt org? I don't have rights to do that.

Robert

>
>
> On Thu, Jun 28, 2012 at 3:06 AM, Damien Regad <damien.regad@...>
> wrote:
>>
>> 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.
>>
>> On 28/06/12 00:32, Victor Boctor wrote:
>> > +1 I think I suggested something similar earlier.
>>
>> You are probably referring to this...
>>
>> 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
>> > github.
>> > 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)
>>
>> Damien
>>
>>
>> On 28/06/12 00:32, Victor Boctor wrote:
>> > +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
>> > <robert.munteanu@...
>> > <mailto:robert.munteanu@...>> 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
>> mantisbt-dev@...
>> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>
>
>
> ------------------------------------------------------------------------------
> 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
> mantisbt-dev@...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>

--

-- 
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/
Permalink | Reply |
headers
John Reese | 8 Jul 2012 17:30
Favicon
Gravatar

Re: Upstream dependencies

Now you do.

On Sun, Jul 8, 2012 at 1:01 AM, Robert Munteanu
<robert.munteanu@...> wrote:
> On Sun, Jul 1, 2012 at 11:43 PM, Victor Boctor
<victor@...> wrote:
>> Looks like we have a plan here, right?  The first candidates are adodb and
>> phpmailer.
>
> I'd also like to include nusoap ( my original reason for this posting ).
>
> I've opened and assigned to myself
>
> 14458: Track third party libs as github repos
> http://www.mantisbt.org/bugs/view.php?id=14458
>
> but can you Victor ( or someone else ) create the repos in the
> mantisbt org? I don't have rights to do that.
>
> Robert
>
>>
>>
>> On Thu, Jun 28, 2012 at 3:06 AM, Damien Regad <damien.regad@...>
>> wrote:
>>>
>>> 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.
>>>
>>> On 28/06/12 00:32, Victor Boctor wrote:
>>> > +1 I think I suggested something similar earlier.
>>>
>>> You are probably referring to this...
>>>
>>> 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
>>> > github.
>>> > 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)
>>>
>>> Damien
>>>
>>>
>>> On 28/06/12 00:32, Victor Boctor wrote:
>>> > +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
>>> > <robert.munteanu@...
>>> > <mailto:robert.munteanu@...>> 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
>>> mantisbt-dev@...
>>> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> mantisbt-dev@...
>> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>>
>
>
>
> --
> 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
> mantisbt-dev@...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

--

-- 
John Reese
noswap.com

------------------------------------------------------------------------------
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/
Permalink | Reply |
headers
Robert Munteanu | 31 Jul 2012 22:07
Picon
Gravatar

Re: Upstream dependencies

On Sun, Jul 8, 2012 at 6:30 PM, John Reese <john@...> wrote:
> Now you do.

Thanks!

So here's a belated update:

I've created the mantisbt/nusoap repo [1] with the following refs:

- master is the main tracking branch for the nusoap repository,
following all upstream releases
- nusoap-0.9.5 is the tag for the upstream 0.9.5 release
- fixes-for-0.9.5 contains our fixes ( just one so far ) applied for
the 0.9.5 release

I would then pull in the current HEAD of fixes-for-0.9.5 [2] as a git
submodule for both the master and master-1.2.x branches of the
mantisbt repo.

Does that match everyone's expectations? The email thread is less
clear to me now than it was a month ago .

Cheers,

Robert

[1]: https://github.com/mantisbt/nusoap
[2]: 2673df6fcd2635245aa4c90f1682f067d6f6ac6e to be more precise

>
> On Sun, Jul 8, 2012 at 1:01 AM, Robert Munteanu
> <robert.munteanu@...> wrote:
>> On Sun, Jul 1, 2012 at 11:43 PM, Victor Boctor
<victor@...> wrote:
>>> Looks like we have a plan here, right?  The first candidates are adodb and
>>> phpmailer.
>>
>> I'd also like to include nusoap ( my original reason for this posting ).
>>
>> I've opened and assigned to myself
>>
>> 14458: Track third party libs as github repos
>> http://www.mantisbt.org/bugs/view.php?id=14458
>>
>> but can you Victor ( or someone else ) create the repos in the
>> mantisbt org? I don't have rights to do that.
>>
>> Robert
>>
>>>
>>>
>>> On Thu, Jun 28, 2012 at 3:06 AM, Damien Regad <damien.regad@...>
>>> wrote:
>>>>
>>>> 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.
>>>>
>>>> On 28/06/12 00:32, Victor Boctor wrote:
>>>> > +1 I think I suggested something similar earlier.
>>>>
>>>> You are probably referring to this...
>>>>
>>>> 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
>>>> > github.
>>>> > 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)
>>>>
>>>> Damien
>>>>
>>>>
>>>> On 28/06/12 00:32, Victor Boctor wrote:
>>>> > +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
>>>> > <robert.munteanu@...
>>>> > <mailto:robert.munteanu@...>> 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
>>>> mantisbt-dev@...
>>>> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>> mantisbt-dev@...
>>> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>>>
>>
>>
>>
>> --
>> 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
>> mantisbt-dev@...
>> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>
>
>
> --
> John Reese
> noswap.com
>
> ------------------------------------------------------------------------------
> 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
> mantisbt-dev@...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

--

-- 
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/
Permalink | Reply |

Gmane