On Tue, Sep 14, 2010 at 1:46 PM, Troy A. Griffitts <scr...@crosswire.org> wrote: > Thanks for the email link Greg. Yeah, the submitted changes in question > from project A were filter updates, and we do specifically state in that > email that filter updates are allowed in a stable branch. It was kindof an > odd situation. The updates merely added css classes to a few of the html > tags which are outputted from the filters, none of the projects involved > thought adding css classes would break anyone.
Huh, I can understand why! (btw - is it anything that broke Bibletime? I haven't heard of these breakages, so I would guess not) > > One of the things in head currently which isn't mentioned in that email is > binding improvements and also your additional cmake make system. I'm not > sure how I feel about binding improvements being included in a stable > branch, but I don't see an issue including an additional make system. Any > thoughts? IMO, it would be the other way. If people see a CMake system they will probably think it's exactly like the autotools, which is not easy to guarantee. I would think CMake should be held off for a feature update release and the bindings fixes should be included. My alterations in the bindings directory aren't adding new functionality - it's fixes for functionality which was there but long broken. I would hesitate to include those changes though, until we've heard from the BPBible team. I've asked a few times since I made the changes and haven't seen any comments from them on here. Either they don't use SVN HEAD in their development, or they haven't noticed any breakage. --Greg > > Troy > > On 9/14/2010 6:49 PM, Greg Hellings wrote: >> >> On Tue, Sep 14, 2010 at 12:43 PM, Troy A. Griffitts >> <scr...@crosswire.org> wrote: >>> >>> Understood going forward. >>> >>> There were a few factors which made this a slightly non-standard >>> situation. >>> First, this wasn't exactly a bug fix. It was a workaround for a bug in >>> a >>> version of libcurl. I was hoping libcurl would be patched. And no, I >>> personally didn't report the issue to the curl team, which I should have. >>> Secondly, one of our frontend projects submitted a small update which >>> changed something another of our frontends depended on. The second >>> project >>> had updated their code to still work with the new change, but they hadn't >>> released yet. If they had released then everyone would be happy with us >>> releasing SVN as is. As it stands right now 1 of the 2 projects will >>> need >>> to patch SVN for their frontend to work. So delaying was a hopeful but >>> unfruitful exercise. It was a choice we made to with the best >>> information >>> we had at the time. >> >> Not knowing the nature of the changes, etc, I don't mean to provide >> this as a comment on that, but I'd just like to bring back up this >> email: >> >> http://www.crosswire.org/pipermail/sword-devel/2009-June/032108.html >> >> and see if that's still the plan? If you're actually changing how >> things are working inside (in the sense of enhancing for new modules >> and content like the NASB and not just for fixing bugs), then maybe it >> is time to branch and allow for bug fixing/feature branches to develop >> separately until 1.7 is made? >> >> --Greg >> >> _______________________________________________ >> sword-devel mailing list: sword-devel@crosswire.org >> http://www.crosswire.org/mailman/listinfo/sword-devel >> Instructions to unsubscribe/change your settings at above page > > > _______________________________________________ > sword-devel mailing list: sword-devel@crosswire.org > http://www.crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page > _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
