There is a file called "!PLEASE DON'T MAKE CHANGES IN THESE FILES.README" in the 2geom directory. It says that 2geom code should be changed in 2geom SVN instead of in the Inkscape SVN, because changes will be destroyed otherwise. Is this warning still intact?
Regards, Krzysztof Kosiński
Krzysztof Kosiński wrote:
There is a file called "!PLEASE DON'T MAKE CHANGES IN THESE FILES.README" in the 2geom directory. It says that 2geom code should be changed in 2geom SVN instead of in the Inkscape SVN, because changes will be destroyed otherwise. Is this warning still intact?
Regards, Krzysztof Kosiński
Yes, it is. 2geom is in fact a separate library that we carry in tree for easy of updating, a lot of 2geom is headers/inlines, and it's not currently packaged on any distros to my knowledge.
You may join the lib2geom-devel ML or lib2geom@ conference.gristle.org on Jabber/XMPP for discussing issues/changes you have.
Joshua L. Blocher verbalshadow
Joshua L. Blocher wrote:
Yes, it is. 2geom is in fact a separate library that we carry in tree for easy of updating (...)
That's contradictory for me. If updating the library in the Inkscape tree is allowed then the warning is not intact, because it says not to update files. I know that lib2geom is a separate library, but are the changes from Inkscape tree merged back into the lib2geom tree, or are they discarded whenever an upstream change happens?
Regards, Krzysztof Kosiński
Krzysztof Kosiński wrote:
Joshua L. Blocher wrote:
Yes, it is. 2geom is in fact a separate library that we carry in tree for easy of updating (...)
That's contradictory for me. If updating the library in the Inkscape tree is allowed then the warning is not intact, because it says not to update files. I know that lib2geom is a separate library, but are the changes from Inkscape tree merged back into the lib2geom tree, or are they discarded whenever an upstream change happens?
Regards, Krzysztof Kosiński
Krzysztof,
Joshua (the other one) pointed out that there are no distros that anyone is aware of carrying lib2geom yet, so it is a necessity for us to carry it in-tree currently. If changes need to be made in 2geom, they need to get made upstream and then the modified file(s) pulled into Inkscape SVN.
The comment about ease of updating is because things in 2geom have changed quite a bit since the transition to it within Inkscape had begun. Not having it in-tree (with the library being so young) then forces another dependency on our nightly/svn users and testers (for all platforms), which given the transition and testing at hand, will cause bug reporting and testing issues because the rev of 2geom would get out of sync on different users systems.
It won't always be the case for it to be in-tree... but that's just the way it is for the time being.
Cheers, Josh
On Mon, 2008-10-27 at 16:51 -0700, Josh Andler wrote:
Joshua (the other one) pointed out that there are no distros that anyone is aware of carrying lib2geom yet, so it is a necessity for us to carry it in-tree currently. If changes need to be made in 2geom, they need to get made upstream and then the modified file(s) pulled into Inkscape SVN.
2geom made a 0.2.0 release. I'm working on making a package for it, and I will change the build to use the system installed version. People are welcome to install it from tarball, or to use a package. I don't think there is any reason to have it in our tree anymore.
--Ted
On Tue, Oct 28, 2008 at 09:35:02PM -0500, Ted Gould wrote:
On Mon, 2008-10-27 at 16:51 -0700, Josh Andler wrote:
Joshua (the other one) pointed out that there are no distros that anyone is aware of carrying lib2geom yet, so it is a necessity for us to carry it in-tree currently. If changes need to be made in 2geom, they need to get made upstream and then the modified file(s) pulled into Inkscape SVN.
2geom made a 0.2.0 release. I'm working on making a package for it, and I will change the build to use the system installed version. People are welcome to install it from tarball, or to use a package. I don't think there is any reason to have it in our tree anymore.
Cool, let me know if you need help with that.
Bryce
On Tue, 2008-10-28 at 21:34 -0700, Bryce Harrington wrote:
On Tue, Oct 28, 2008 at 09:35:02PM -0500, Ted Gould wrote:
On Mon, 2008-10-27 at 16:51 -0700, Josh Andler wrote:
Joshua (the other one) pointed out that there are no distros that anyone is aware of carrying lib2geom yet, so it is a necessity for us to carry it in-tree currently. If changes need to be made in 2geom, they need to get made upstream and then the modified file(s) pulled into Inkscape SVN.
2geom made a 0.2.0 release. I'm working on making a package for it, and I will change the build to use the system installed version. People are welcome to install it from tarball, or to use a package. I don't think there is any reason to have it in our tree anymore.
Cool, let me know if you need help with that.
The packaging is here:
https://code.launchpad.net/~ted-gould/lib2geom/ubuntu-packaging
I've got the basic "it builds" now I need to fix all of the descriptions and such and figure out the dependencies. Patches or merge requests welcome :) We can move ownership to a group also.
--Ted
2008/10/29 Ted Gould <ted@...11...>
On Tue, 2008-10-28 at 21:34 -0700, Bryce Harrington wrote:
On Tue, Oct 28, 2008 at 09:35:02PM -0500, Ted Gould wrote:
On Mon, 2008-10-27 at 16:51 -0700, Josh Andler wrote:
Joshua (the other one) pointed out that there are no distros that
anyone
is aware of carrying lib2geom yet, so it is a necessity for us to
carry
it in-tree currently. If changes need to be made in 2geom, they need
to
get made upstream and then the modified file(s) pulled into Inkscape
SVN.
2geom made a 0.2.0 release. I'm working on making a package for it,
and
I will change the build to use the system installed version. People
are
welcome to install it from tarball, or to use a package. I don't think there is any reason to have it in our tree anymore.
Cool, let me know if you need help with that.
The packaging is here:
https://code.launchpad.net/~ted-gould/lib2geom/ubuntu-packaging
I've got the basic "it builds" now I need to fix all of the descriptions and such and figure out the dependencies. Patches or merge requests welcome :) We can move ownership to a group also.
--Ted
Wasnt half the point of having it in our tree that we're using bleeding edge SVN 2geom with our guys making fairly regular changes? Why screw around with whats working? Plus what does this do to non linux builds? Can we please think about this properly before we break the build/make life harder for people to fix bugs.
Cheers
John
On Wed, 2008-10-29 at 08:25 +0000, john cliff wrote:
Wasnt half the point of having it in our tree that we're using bleeding edge SVN 2geom with our guys making fairly regular changes? Why screw around with whats working? Plus what does this do to non linux builds? Can we please think about this properly before we break the build/make life harder for people to fix bugs.
Well, you can make that argument for any library. Should we include libc? GTK? What about gcc bugs? :)
The reality that including a library is like crack, the longer it is in the more people that go "I can't work any other way" when it should be removed. Also the higher the likelyhood that internal APIs get used and/or changes are actually made the library itself so then it can never be removed.
When the decision was made to include lib2geom it was because there wasn't a release to build on. There is now. If the 2geom folks have bugs, I'm sure they'll do a bugfix release. And we should encourage that as then the Scribus guys and other users of the library will get those benefits also.
I'm not committing this change today. I'm building up to it. I consider this fair warning to packagers on other platforms to start getting their platform in shape for the change.
--Ted
On Wed, Oct 29, 2008 at 4:03 PM, Ted Gould wrote:
I'm not committing this change today. I'm building up to it. I consider this fair warning to packagers on other platforms to start getting their platform in shape for the change.
Are 2geom developers building up to releasing more often? :-)
Alexandre
2008/10/29 Ted Gould <ted@...11...>
On Wed, 2008-10-29 at 08:25 +0000, john cliff wrote:
Wasnt half the point of having it in our tree that we're using bleeding edge SVN 2geom with our guys making fairly regular changes? Why screw around with whats working? Plus what does this do to non linux builds? Can we please think about this properly before we break the build/make life harder for people to fix bugs.
Well, you can make that argument for any library. Should we include libc? GTK? What about gcc bugs? :)
That statements just daft, none of those are spinoffs of inkscape, none of them share a number of devs with us and non of them are being modified on a regular basis to fix bugs exposed by their use in our codebase.
The reality that including a library is like crack, the longer it is in the more people that go "I can't work any other way" when it should be removed. Also the higher the likelyhood that internal APIs get used and/or changes are actually made the library itself so then it can never be removed.
k, that ones even dafter. the guys using it are the same guys developing it. Their the people defining the APIs, and what to expose etc, so I really dont see the point of this statement. Again, this isnt a lib we're getting from strangers...
When the decision was made to include lib2geom it was because there wasn't a release to build on. There is now. If the 2geom folks have bugs, I'm sure they'll do a bugfix release. And we should encourage that as then the Scribus guys and other users of the library will get those benefits also.
Why would we want to add a shedload of complication to SVN? both inkscape and 2geom are undergoing an interlinked dev cycle, why try and formalise changes by making them role out a new release every time a bug gets fixed. Again, daft idea.
I'm not committing this change today. I'm building up to it. I consider this fair warning to packagers on other platforms to start getting their platform in shape for the change.
--Ted
I really think this shouldnt be done till we hit freeze for 0.47, before then all your doing is making the guys lives more difficult. I actually think hard freeze would be the time to do it, and then sync a 2geom release and the inkscape one.
Cheers
John
john cliff wrote:
I really think this shouldnt be done till we hit freeze for 0.47, before then all your doing is making the guys lives more difficult. I actually think hard freeze would be the time to do it, and then sync a 2geom release and the inkscape one.
This sounds quite reasonable to me. But we'll want the ability to switch there before the freeze so the mechanism can be tested. If possible, I think it would be great to have a configure flag that tells Inkscape to ignore the in-tree 2geom and search the platform.
Aaron Spike
2008/10/29 Aaron Spike <aaron@...749...>
john cliff wrote:
I really think this shouldnt be done till we hit freeze for 0.47, before then all your doing is making the guys lives more difficult. I actually think hard freeze would be the time to do it, and then sync a 2geom release and the inkscape one.
This sounds quite reasonable to me. But we'll want the ability to switch there before the freeze so the mechanism can be tested. If possible, I think it would be great to have a configure flag that tells Inkscape to ignore the in-tree 2geom and search the platform.
Aaron Spike
How about we do that at soft freeze?
john cliff wrote:
2008/10/29 Aaron Spike <aaron@...749... mailto:aaron@...749...>
john cliff wrote: > I really think this shouldnt be done till we hit freeze for 0.47, before > then all your doing is making the guys lives more difficult. > I actually think hard freeze would be the time to do it, and then sync a > 2geom release and the inkscape one. This sounds quite reasonable to me. But we'll want the ability to switch there before the freeze so the mechanism can be tested. If possible, I think it would be great to have a configure flag that tells Inkscape to ignore the in-tree 2geom and search the platform. Aaron SpikeHow about we do that at soft freeze?
I can't think of a reason to wait. A configure time flag that is off by default should be minimally disruptive. It seems like a good compromise.
Aaron
On Wed, 2008-10-29 at 12:56 -0500, Aaron Spike wrote:
This sounds quite reasonable to me. But we'll want the ability to switch there before the freeze so the mechanism can be tested. If possible, I think it would be great to have a configure flag that tells Inkscape to ignore the in-tree 2geom and search the platform.
Agreed. We need to keep pushing the separation to the extent that we reasonably can.
-mental
On Thu, 2008-10-30 at 18:03 -0400, MenTaLguY wrote:
On Wed, 2008-10-29 at 12:56 -0500, Aaron Spike wrote:
This sounds quite reasonable to me. But we'll want the ability to switch there before the freeze so the mechanism can be tested. If possible, I think it would be great to have a configure flag that tells Inkscape to ignore the in-tree 2geom and search the platform.
Agreed. We need to keep pushing the separation to the extent that we reasonably can.
Okay, so let's talk dates. Josh and I threw a few of these around. I think it's reasonable to say that we'd need approximately 2 months before the release. Josh believes there is no way that we'll release this year, so it doesn't need to be done now.
The reality is that it'd be nice to get into the next rounds of Fedora and Ubuntu -- which means we need to be at or close to a release by the end of February. Which, working the numbers back, means that we'd need a stable release to target of lib2geom by the end of the year.
Now, I'm not saying this needs to be API static, but it needs to be at a point that we expect projects to use it. Also, it would probably be good to version the include directories and libraries. I noticed that the CMake scripts are doing neither of those now.
--Ted
Ted Gould wrote:
On Thu, 2008-10-30 at 18:03 -0400, MenTaLguY wrote:
On Wed, 2008-10-29 at 12:56 -0500, Aaron Spike wrote:
This sounds quite reasonable to me. But we'll want the ability to switch there before the freeze so the mechanism can be tested. If possible, I think it would be great to have a configure flag that tells Inkscape to ignore the in-tree 2geom and search the platform.
Agreed. We need to keep pushing the separation to the extent that we reasonably can.
Okay, so let's talk dates. Josh and I threw a few of these around. I think it's reasonable to say that we'd need approximately 2 months before the release.
Oh how my hopes have been shaken since we last talked. As much as it would be nice to get in the next round of distro releases, a goal I still hope we can possibly achieve, my experience in the day and a half since we talked has been very bad. I've discovered numerous new crash bugs in that timeframe (2 of which, when more than one inkscape window is open results in data loss). Another factor here is I believe that Josh (verbalshadow... not me in the 3rd person ;) ) stated that there is still somewhere around 4,600 lines in the codebase that need to be 2geomified... which will almost definitely make numerous more bugs in Inkscape and 2geom come to the surface. Oh, and with him and Johan really being the primary people making this happen, it's not terribly fair to tell them to "hurry up".
As has been talked about in a different discussion, SVN is currently more unstable than it's ever been. I do think some aspects of the next release should be discussed sooner rather than later so everyone can cite concerns and goals. One of my concerns, given how bad things are stability-wise, we're probably going to need to set a goal for bug points that is a bit higher than it's been in the past. This is mainly because so many more bugs have been introduced in this dev cycle (not a complaint, it was bound to happen with how much stuff is being replaced/refactored). The biggest concern I have with that proposition is that we've seen things stagnate in the past during the pre-release bug fixing spree.
Just my .02 in the middle of the night... I should go back to sleep. :)
Cheers, Josh
On Fri, Oct 31, 2008 at 8:28 AM, Josh Andler <scislac@...400...> wrote:
cite concerns and goals. One of my concerns, given how bad things are stability-wise, we're probably going to need to set a goal for bug points that is a bit higher than it's been in the past.
Points are good, but they don't quite give the feel of readiness. Last time, we still waited a long time after the points were achieved. I propose the following: each person with commit rights has the right to name any number of blocking bugs, without having to argue for them (simply by the personal annoy factor). Of course we should try to be reasonable in our requests, but once everyone's pet peeves are gone it will be easier to get the collective determination to release, and it might happen even faster than raising a given number of points on random bugs (or we can do this right after the points run). Of course we will also need a coordinator to keep track of the blockers.
On Fri, Oct 31, 2008 at 12:41:01PM -0300, bulia byak wrote:
On Fri, Oct 31, 2008 at 8:28 AM, Josh Andler <scislac@...400...> wrote:
cite concerns and goals. One of my concerns, given how bad things are stability-wise, we're probably going to need to set a goal for bug points that is a bit higher than it's been in the past.
Points are good, but they don't quite give the feel of readiness. Last
The purpose of the points system is primarily to help people shift focus towards QA in general, to increase the number of people giving attention to bugs and working on fixing them.
time, we still waited a long time after the points were achieved. I
The reason for the wait was not due to the point system, but rather due to being blocked on bugs that were not getting worked on very rapidly (or not being worked on at all). No matter what release system you use, blocker bugs are going to be the main time factor for the release.
propose the following: each person with commit rights has the right to name any number of blocking bugs, without having to argue for them (simply by the personal annoy factor). Of course we should try to be reasonable in our requests, but once everyone's pet peeves are gone it will be easier to get the collective determination to release.
"All bugs annoy me, so as someone with commit access, I'd like to name every bug in the bug tracker as a blocker." ;-)
Certainly it's annoying having to argue with a release manager to accept a bug as a blocker - believe it or not it's even more frustrating for the release manager. Obviously there has to be some criteria and checks and balances for what bugs are suitable candidates, usually including not only the severity of the issue, but whether someone is available to work on it, the amount of destabilization the fix would introduce, etc. Else you end up with a blocker list that requires an impossible amount of work to get through and you burn out your RM.
might happen even faster than raising a given number of points on random bugs (or we can do this right after the points run). Of course we will also need a coordinator to keep track of the blockers.
I have served this role for all the Inkscape releases up 'til now, but I'm pretty tired of doing it. I talked with Scislac and he said he'd be happy to take over the role henceforth.
Bryce
Ted Gould wrote:
On Mon, 2008-10-27 at 16:51 -0700, Josh Andler wrote:
Joshua (the other one) pointed out that there are no distros that anyone is aware of carrying lib2geom yet, so it is a necessity for us to carry it in-tree currently. If changes need to be made in 2geom, they need to get made upstream and then the modified file(s) pulled into Inkscape SVN.
2geom made a 0.2.0 release. I'm working on making a package for it, and I will change the build to use the system installed version. People are welcome to install it from tarball, or to use a package. I don't think there is any reason to have it in our tree anymore.
--Ted
FYI, I've committed a port of the 0.2.0 release of lib2geom to MacPorts as well. It should be available after the next server sync (next hour or so.)
I also agree that it makes sense to separate it from the Inkscape tree now that it is being released on its own. This would avoid the problem of keeping a copy in the tree in sync with the external release.
Dave
-----Original Message----- From: Ted Gould [mailto:ted@...11...] Sent: woensdag 29 oktober 2008 3:35 To: Josh Andler Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] 2geom SVN warning
On Mon, 2008-10-27 at 16:51 -0700, Josh Andler wrote:
Joshua (the other one) pointed out that there are no distros that anyone is aware of carrying lib2geom yet, so it is a
necessity for us
to carry it in-tree currently. If changes need to be made in 2geom, they need to get made upstream and then the modified
file(s) pulled into Inkscape SVN.
2geom made a 0.2.0 release. I'm working on making a package for it, and I will change the build to use the system installed version. People are welcome to install it from tarball, or to use a package. I don't think there is any reason to have it in our tree anymore.
The release does not change anything for Inkscape. Since Inkscape needs bleeding edge 2geom, we have to carry it in our SVN. For example, if we were to use the latest release, there will be a bug concerning ellipses that I fixed very recently. We really need almost SVN head 2geom, which is not too hard to keep doing as there is a number of people who are aware of 2geom changes and keep Inkscape up to date. Like the warning file says: it's just a copy of 2geom files.
Note that 2geom integration has not been completed !!! Since this integration has been (and still is somewhat) a big driving force for 2geom development, 2geom will change and Inkscape needs that change.
So there is still a strong reason to keep it in our tree, and I see no alternative.
Regards, Johan
On Wed, Oct 29, 2008 at 9:21 AM, <J.B.C.Engelen@...1578...> wrote:
The release does not change anything for Inkscape. Since Inkscape needs bleeding edge 2geom, we have to carry it in our SVN.
I think Johan, as a 2geom devel, has the ultimate say on this. It's not a bad thing to put up a separate 2geom package, so that distros and people start getting used to its existence. But we should not break anything in the current Inkscape/2geom linkage until all 2geom developers approve that.
bulia byak wrote:
On Wed, Oct 29, 2008 at 9:21 AM, <J.B.C.Engelen@...1578...> wrote:
The release does not change anything for Inkscape. Since Inkscape needs bleeding edge 2geom, we have to carry it in our SVN.
I think Johan, as a 2geom devel, has the ultimate say on this. It's not a bad thing to put up a separate 2geom package, so that distros and people start getting used to its existence. But we should not break anything in the current Inkscape/2geom linkage until all 2geom developers approve that.
I completely agree.
On Wed, 2008-10-29 at 12:17 -0300, bulia byak wrote:
On Wed, Oct 29, 2008 at 9:21 AM, <J.B.C.Engelen@...1578...> wrote:
The release does not change anything for Inkscape. Since Inkscape needs bleeding edge 2geom, we have to carry it in our SVN.
I think Johan, as a 2geom devel, has the ultimate say on this. It's not a bad thing to put up a separate 2geom package, so that distros and people start getting used to its existence. But we should not break anything in the current Inkscape/2geom linkage until all 2geom developers approve that.
Makes sense. But I don't think that "bug free" should be the goal. It will never be 100% bug free. It should be API stable. Which I believe, from the release notes is what the goal of 0.2.0 was:
After a busy year with johan, verbalshadow and mgsloan working on the inkscape port to 2geom; jfbarraud and marco developing some sophisticated new geometric operations; acspike writing a python binding; cilix, pjrm and goriccardo checking details and mental doing everything in between, we are releasing a new release for distributions and in particular, inkscape and scribus to target.
WRT people who want to use development versions of 2geom with Inkscape, there is already a well established way to do that. You can change your PKG Config directories to point to any version you'd like. As long as the Inkscape build uses PKG Config correctly it'll pick that version up.
--Ted
On Wed, Oct 29, 2008 at 07:11:36PM +0000, Ted Gould wrote:
On Wed, 2008-10-29 at 12:17 -0300, bulia byak wrote:
On Wed, Oct 29, 2008 at 9:21 AM, <J.B.C.Engelen@...1578...> wrote:
The release does not change anything for Inkscape. Since Inkscape needs bleeding edge 2geom, we have to carry it in our SVN.
I think Johan, as a 2geom devel, has the ultimate say on this. It's not a bad thing to put up a separate 2geom package, so that distros and people start getting used to its existence. But we should not break anything in the current Inkscape/2geom linkage until all 2geom developers approve that.
Makes sense. But I don't think that "bug free" should be the goal. It will never be 100% bug free. It should be API stable. Which I believe, from the release notes is what the goal of 0.2.0 was:
This release comes out of a discussion I had with Nathan while he was visiting the other weekend. The reasoning I gave for starting to do releases was *not* to fix Inkscape to a particular version, but rather to get it into distros, and to help people outside the 2geom/inkscape get familiar with it.
In particular, by selecting a version number <1.0.0, this communicates that the API definitely is *not* stable yet. This may indeed mean that the 2geom code cannot be broken out yet as an external dependency... but it gets us on a path where we *will* be able to do that some day.
WRT people who want to use development versions of 2geom with Inkscape, there is already a well established way to do that. You can change your PKG Config directories to point to any version you'd like. As long as the Inkscape build uses PKG Config correctly it'll pick that version up.
I think this is good to know, and an arrangement worth getting to at some point, but let's take care not to rush into this quite yet. I agree with bulia that we should wait until the 2geom developers feel it's time to break the current Inkscape/2geom linkages, and for now just encourage them to continue making frequent releases.
Bryce
On Wed, 2008-10-29 at 13:41 -0700, Bryce Harrington wrote:
Makes sense. But I don't think that "bug free" should be the goal. It will never be 100% bug free. It should be API stable. Which I believe, from the release notes is what the goal of 0.2.0 was:
This release comes out of a discussion I had with Nathan while he was visiting the other weekend. The reasoning I gave for starting to do releases was *not* to fix Inkscape to a particular version, but rather to get it into distros, and to help people outside the 2geom/inkscape get familiar with it.
In particular, by selecting a version number <1.0.0, this communicates that the API definitely is *not* stable yet. This may indeed mean that the 2geom code cannot be broken out yet as an external dependency... but it gets us on a path where we *will* be able to do that some day.
Something which really needs to be underscored here is that right now 2geom is (among other things) still very much a research project. We can't promise API stability simply because we don't even know what an ideal API looks like yet (although we are getting an increasingly clear picture), and freezing the API at this time would actually destroy its research value.
-mental
Krzysztof Kosiński wrote:
Joshua L. Blocher wrote:
Yes, it is. 2geom is in fact a separate library that we carry in tree for easy of updating (...)
That's contradictory for me. If updating the library in the Inkscape tree is allowed then the warning is not intact, because it says not to update files. I know that lib2geom is a separate library, but are the changes from Inkscape tree merged back into the lib2geom tree, or are they discarded whenever an upstream change happens?
Regards, Krzysztof Kosiński
When Johan, me or one of the other guys update inkscape svn anything not in the 2geom svn is "discarded", yes. The changes are excepted in the lib2geom svn and flow into the inkscape svn as needed to update/fix issues. It is simpler than having to work out diffs and merge them, even though many people work on both projects.
Joshua L. Blocher verbalshadow
participants (12)
-
unknown＠example.com -
Aaron Spike -
Alexandre Prokoudine -
Bryce Harrington -
bulia byak -
David Evans -
john cliff -
Josh Andler -
Joshua L. Blocher -
Krzysztof Kosiński -
MenTaLguY -
Ted Gould