Inkscape release schedule and project items
Hey all,
First, an official Happy New Year to you all! I'm breaking down this email into a few sections below.
Releases: A newer release of Inkscape will be going into the next distro release cycle. Whether this is 0.46.1 or 0.47 is what needs to be determined. I know that with at least a handful of us, there is a great desire to make it 0.47. However, this may not be feasible (or preferable) for any number of reasons. A vote is definitely in order for this. We should have some sort of brief discussion about what are the most compelling reasons to either make it 0.47 or not 0.47. (I am aware that 0.46.1 has been discussed before, I've unfortunately had health issues preventing me from actively working on it, but with my current doctor downtime, should be doable)
Build Systems: Discussion of the possibility of switching build systems to cmake or btool has resurfaced again recently. It seems like the obvious goals should be that we use one build system on all platforms and it be something that is maintainable by multiple individuals. From my understanding all three build systems in the mix are crossplatform. Is there an updated comparison list of the benefits and drawbacks of each? Personal experiences? Given that I almost exclusively build on linux these days, it doesn't impact me greatly and I don't really have a preference.
Version Control: In the past we also discussed potentially switching to a dvcs such as git or bzr. I'm pretty sure we all know the benefits of using a dvcs, and it seems (I may be wrong) that a modern dvcs is a little friendlier with tags and branches (which would be nice to use more in the future). We have a handful of people who I know are working with bzr on a regular basis, would anyone like to chime in on if it seems like a good "successor" to svn for our project and if it would be a worthwhile switch? Bryce, Ted, Mental, Kees? Anyone think git would be a better choice?
Future Releases: After this extremely long development cycle, and the amount of future refactoring we're still looking to do, I think we need a new stable/devel branching strategy for the future. Or at the very least, a bleeding edge branch for GSoCers and the like in addition to main devel. Also, it would be great to have regular releases that tie into the distro release cycles (with minimal benefit of easy PR). Anyone else care to chime in?
That's all for now... I think the next release should be the top priority to vote on and discuss now, because if people want it to be 0.47, we need to get crackin'.
Cheers, Josh
On Mon, 2009-01-05 at 18:55 -0700, Josh Andler wrote:
First, an official Happy New Year to you all! I'm breaking down this email into a few sections below.
Happy New Year to you too!
Releases: A newer release of Inkscape will be going into the next distro release cycle. Whether this is 0.46.1 or 0.47 is what needs to be determined.
I'd really like to see us move towards a 0.47. Even if that means missing the various distro deadlines, I think that's a better goal. I'm not sure that it has to derail any 0.46.1 work, I just don't think there are a lot of users that would upgrade to a new point release.
Build Systems: Discussion of the possibility of switching build systems to cmake or btool has resurfaced again recently. It seems like the obvious goals should be that we use one build system on all platforms and it be something that is maintainable by multiple individuals.
I'm still not that interested in switching. I believe that there have been contributions to make autotools work for win32 builds... It seems to me at least from the CVS mailing list that the CMake effort has stalled (Johan mentioned some issues). So, I think this can be tabled.
Version Control: In the past we also discussed potentially switching to a dvcs such as git or bzr.
My feeling here is that we should switch after the 0.47 release, when ever we decide that should be. (or 0.48). I don't think this is pressing, as long as I don't screw up a commit again :)
Future Releases: After this extremely long development cycle, and the amount of future refactoring we're still looking to do, I think we need a new stable/devel branching strategy for the future. Or at the very least, a bleeding edge branch for GSoCers and the like in addition to main devel. Also, it would be great to have regular releases that tie into the distro release cycles (with minimal benefit of easy PR). Anyone else care to chime in?
I think that's an interesting idea. I think that a DVCS would help here. The problem with having multiple branches is that they get different levels of testing. So by having a single trunk we end up with limited testing of people on several branches. But, I think if people can use branches effectively, they will. We should be able to branch off a release earlier though. I don't know. That wasn't coherent.
--Ted
Ted Gould wrote:
On Mon, 2009-01-05 at 18:55 -0700, Josh Andler wrote:
First, an official Happy New Year to you all! I'm breaking down this email into a few sections below.
Happy New Year to you too!
Releases: A newer release of Inkscape will be going into the next distro release cycle. Whether this is 0.46.1 or 0.47 is what needs to be determined.
I'd really like to see us move towards a 0.47. Even if that means missing the various distro deadlines, I think that's a better goal. I'm not sure that it has to derail any 0.46.1 work, I just don't think there are a lot of users that would upgrade to a new point release.
Agreed.
Build Systems: Discussion of the possibility of switching build systems to cmake or btool has resurfaced again recently. It seems like the obvious goals should be that we use one build system on all platforms and it be something that is maintainable by multiple individuals.
I'm still not that interested in switching. I believe that there have been contributions to make autotools work for win32 builds... It seems to me at least from the CVS mailing list that the CMake effort has stalled (Johan mentioned some issues). So, I think this can be tabled.
Autotools is a well tested and popular system there can be no argument about that. I've tried a few times to dive in and fix bugs or add features to the autotools build system unsuccessfully. And even after asking I was not able to find a single individual willing to offer advice. Autotools is an impediment for novice developers. I will stop complaining if some of the more experienced devs will step forward to document how we use autotools and offer to train others.
Future Releases: After this extremely long development cycle, and the amount of future refactoring we're still looking to do, I think we need a new stable/devel branching strategy for the future. Or at the very least, a bleeding edge branch for GSoCers and the like in addition to main devel. Also, it would be great to have regular releases that tie into the distro release cycles (with minimal benefit of easy PR). Anyone else care to chime in?
I think that's an interesting idea. I think that a DVCS would help here. The problem with having multiple branches is that they get different levels of testing. So by having a single trunk we end up with limited testing of people on several branches. But, I think if people can use branches effectively, they will. We should be able to branch off a release earlier though. I don't know. That wasn't coherent.
Testing is one issue. My biggest worry is the amount of work it takes to maintain two branches. We've attempted this a few times with bug fix releases now. And I think the experience shows that it will be difficult to find people who can do the branch maintenance work and keep it up for any amount of time without burnout.
Aaron Spike
Autotools is a well tested and popular system there can be no argument about that. I've tried a few times to dive in and fix bugs or add features to the autotools build system unsuccessfully. And even after asking I was not able to find a single individual willing to offer advice. Autotools is an impediment for novice developers. I will stop complaining if some of the more experienced devs will step forward to document how we use autotools and offer to train others.
I'm going to have to agree with Aaron here. Finding a guy who truly understands Autotools is like finding a guy who can dowse water in a desert. Most of us C&P adjust and pray it works. Autotools are well tested and popular on Linux and BSD platforms but, you can count the number of projects that use it on Windows OS on one hand. A quick googling reveals none. Also this will most likely require developer to install Perl as well. Not a super big burden for developers since Bob is normally nice enough to bundle all the libs and extras up.
For the record I'm not saying Cmake is perfect but I can find more project using it truly cross-platform than Autotools. KDE being the biggest name off- hand and here is a List http://www.cmake.org/Wiki/CMake_Projects don't forget lib2geom uses it also.
I have nothing against btool either its pretty easy to setup and also works across platforms, I have less experience with it so I can't say much more.
Joshua L. Blocher verbalshadow
participants (4)
-
Aaron Spike -
Josh Andler -
Joshua L. Blocher -
Ted Gould