From: Robert M. <rob...@gm...> - 2012-06-27 21:01:24
|
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 |
From: Victor B. <vi...@fu...> - 2012-06-27 22:32:58
|
+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 > |
From: Robert M. <rob...@gm...> - 2012-06-28 08:30:16
|
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 <vi...@fu...> 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 <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 > > > > ------------------------------------------------------------------------------ > 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 > -- Sent from my (old) computer |
From: Damien R. <dam...@me...> - 2012-06-28 10:07:13
|
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 > <rob...@gm... > <mailto: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 |
From: Victor B. <vi...@fu...> - 2012-07-01 20:43:23
|
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 <dam...@me...>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 > > <rob...@gm... > > <mailto: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 > |
From: Robert M. <rob...@gm...> - 2012-07-08 08:01:59
|
On Sun, Jul 1, 2012 at 11:43 PM, Victor Boctor <vi...@fu...> 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 <dam...@me...> > 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 >> > <rob...@gm... >> > <mailto: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 > > > > ------------------------------------------------------------------------------ > 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 > -- Sent from my (old) computer |
From: John R. <jo...@no...> - 2012-07-08 15:30:23
|
Now you do. On Sun, Jul 8, 2012 at 1:01 AM, Robert Munteanu <rob...@gm...> wrote: > On Sun, Jul 1, 2012 at 11:43 PM, Victor Boctor <vi...@fu...> 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 <dam...@me...> >> 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 >>> > <rob...@gm... >>> > <mailto: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 >> >> >> >> ------------------------------------------------------------------------------ >> 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 >> > > > > -- > 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 -- John Reese noswap.com |
From: Robert M. <rob...@gm...> - 2012-07-31 20:08:05
|
On Sun, Jul 8, 2012 at 6:30 PM, John Reese <jo...@no...> 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 > <rob...@gm...> wrote: >> On Sun, Jul 1, 2012 at 11:43 PM, Victor Boctor <vi...@fu...> 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 <dam...@me...> >>> 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 >>>> > <rob...@gm... >>>> > <mailto: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 >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> 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 >>> >> >> >> >> -- >> 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 > > > > -- > 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 > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev -- Sent from my (old) computer |