Bryce Harrington wrote:
On Mon, Jul 23, 2007 at 12:31:39PM -0500, Aaron Spike wrote:
Bryce Harrington wrote:
That said, I think if you wish to merge this branch into main, it would be wisest to make your code only relies on a released version of lib2geom (which may mean working to get a release of lib2geom.)
Such a requirement is going to force lib2geom to release new versions weekly or even more rapidly.
You trimmed it out, but I said this could be achieved with svn extern.
Yes, I trimmed it on purpose. Starting with svn extern seems like a premature optimisation to me. Aditionally I've never used svn extern before and I wouldn't feel comfortable trying it for the first time on a project like Inkscape. So my vote goes for two separate svn checkouts.
I never said making it depend on released versions was a requirement, just that it would be a wiser approach.
I agree it is wisest.
But please note that linking svn's ALSO places a burden on lib2geom in that it would instead require that lib2geom svn remain always buildable. In theory that should not ever be an issue, but imagine if a build issue does enter into lib2geom; since only lib2geom developers with commit access to that project's svn would be able to fix it, it could result in a situation where inkscape development would effectively grind to a halt waiting for a fix.
Of course, this will likely never happen because lib2geom developers would never commit build errors into svn. It is fortunate that a few inkscape developers have commit access into lib2geom; hopefully they will take the responsibility of quickly fixing issues if they are identified, and this issue will never become a problem.
I could be wrong but I think all of the lib2geom developers have commit access to both projects. I have personally witnessed times when both lib2geom developers and inkscape developers have made unbuildable commits. It is going to happen. But I think grinding halts will be much rarer occasions (only when one of us makes an unbuildable commit and then goes on vacation).
I hope we can get more inkscape developers involved in lib2geom. Actually more developers period.
I imagine there could also be other potential glitches. Both projects use different svn providers, so now instead of just relying on inkscape svn being functional, we now require two svn servers to be up and functioning at the same time. And so on. In theory, everything will work perfectly, but in practice...
Both projects use sourceforge svn; we'll be down at the same time.
This is why I feel that when possible, it is wiser to rely on stable releases. This doesn't mean forcing upstream to release frequently; it means being organized in when features are rolled out that require features only available in the upstream SVN. It's the same philosophy we would apply with relying on cairo, gtkmm, or other upstream library changes. If everyone feels that it is not possible to apply this philosophy in this case, well then this would be an allowable exception.
Development will grind to a halt while we wait for the next lib2geom release to fix a bug in the new feature we want to commit. I think this stance is necessary with large established projects like gtkmm and cairo. They have their own culture and established release systems. But at the same time I do feel that we are hindered slightly sometimes as we wait for fixes and features to come back downstream to us (waiting not because those projects are sluggish, but because we lack a strong inkscape advocate as an involved party). Lib2geom shares much Inkscape culture and I imagine they will be rather flexible to work with us in syncing release etc.
To be honest it doesn't really matter to me; I've been too busy with the new job to work on Inkscape anyway. If those who are actively developing on this are willing to experiment with linking svn's with an external project, then if the above concerns are legitimate, I'm sure they'll make themselves clear and people can deal with them then. Patch first, discuss later as we always say. ;-)
Is it possible to compromise? Can we strive to depend on a released lib2geom as much as possible but allow minimal well publicised periods of dependance on svn? or is that too much complication?
Aaron