Inkscape 0.40 release planning
At the beginning of this month we kicked around the idea of doing an interim release, because even though we're not 100% done with the goals, there's a lot of new features and the time feels right for a new release. :-)
We considered either calling it 0.39.5 and keeping with the roadmap as is, or calling it 0.40 and bumping the roadmap a bit. I believe there was a rough concensus for the latter at the time - this still true?
In any case, the two tasks facing us right now are the same:
1. Finish up current work
2. Fix bugs (esp. the more noticeable ones)
Like we've done in past releases, I'll begin posting critical bug summaries daily from now until the release so we can track our progress. How do we want to track it?
* Fix X % of the critical bugs (e.g. fix 50% of crits)?
* Reduce the bug list to a threshhold (e.g. 100?)?
* Identify N specific bugs to fix?
I browsed through the bug list yesterday, and we seem to be in fairly good shape (thanks most likely to the continuing attention the bug list receives). There are fewer crash bugs listed than we've had in the past, and most of those occur only in special situations (such as Win32-only), but some of the remaining bugs are particularly hard ones to fix.
In any case, let me know what you think we should set as the goal for this release, and I'll start posting our progress on that by the 26th.
Bryce
We considered either calling it 0.39.5 and keeping with the roadmap as is, or calling it 0.40 and bumping the roadmap a bit. I believe there was a rough concensus for the latter at the time - this still true?
I think few people will bother downloading 0.39.5. It sounds way too much like a bugfix release - not everyone reads Release Notes. Besides, long and unwieldy release numbers are a pain. 0.38.1 was enough to find that out :)
I browsed through the bug list yesterday, and we seem to be in fairly good shape (thanks most likely to the continuing attention the bug list receives).
I disagree. Our bug tracker is frightening. Lots of mysterious bugs which I don't know how they are possible at all. Lots of unconfirmed bugs. Lots of just plain very hard to fix bugs.
Not surprisingly, as very little attention was paid to the bugs in the last couple months.
We need more help with that. I want to ask everyone who is capable of running current CVS to browse the bug list and comment on as many bugs as possible. Just test it and report if you can reproduce it or not, and if you can, provide as much details as possible. Focus on crasher bugs, but also on any bugs without comments or with comments to the effect of "can't reproduce". We need as much feedback as possible, so this will be a real help to the project. Please try to not post anonymously, simply because if you leave a comment with your SF username the tracker will send you further comments on that bug, which is very convenient for discussions and asking for more information.
There are fewer crash bugs listed than we've had in the past, and most of those occur only in special situations (such as Win32-only),
I don't think Windows users will agree to be treated as a "special situation" :)
bulia byak wrote:
We considered either calling it 0.39.5 and keeping with the roadmap as is, or calling it 0.40 and bumping the roadmap a bit. I believe there was a rough concensus for the latter at the time - this still true?
I think few people will bother downloading 0.39.5. It sounds way too much like a bugfix release - not everyone reads Release Notes. Besides, long and unwieldy release numbers are a pain. 0.38.1 was enough to find that out :)
Yeah, IMO 0.40 is better and definitely a deserved full-point release. Inkscape's full point released are like many projects +10 point releases. It would be good as well to spend some time looking over the roadmap to see where things are heading and also, to shift some things around. Bryce, do you think your GTKMM stuff will go in next release in full force? Others?
I browsed through the bug list yesterday, and we seem to be in fairly good shape (thanks most likely to the continuing attention the bug list receives).
I disagree. Our bug tracker is frightening. Lots of mysterious bugs which I don't know how they are possible at all. Lots of unconfirmed bugs. Lots of just plain very hard to fix bugs.
Not surprisingly, as very little attention was paid to the bugs in the last couple months.
We need more help with that. I want to ask everyone who is capable of running current CVS to browse the bug list and comment on as many bugs as possible. Just test it and report if you can reproduce it or not, and if you can, provide as much details as possible. Focus on crasher bugs, but also on any bugs without comments or with comments to the effect of "can't reproduce". We need as much feedback as possible, so this will be a real help to the project. Please try to not post anonymously, simply because if you leave a comment with your SF username the tracker will send you further comments on that bug, which is very convenient for discussions and asking for more information.
So whats the procedure. Go into bug fix mode on the weekend, and then try to hammer out a release the following weekend after a freeze?
There are fewer crash bugs listed than we've had in the past, and most of those occur only in special situations (such as Win32-only),
I don't think Windows users will agree to be treated as a "special situation" :)
Yes, win32 needs some love :)
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
--- Jon Phillips <jon@...235...> wrote:
bulia byak wrote:
I think few people will bother downloading 0.39.5. It sounds way too much like a bugfix release
Yeah, IMO 0.40 is better and definitely a deserved full-point release.
agree with both of you, theres quite a bit of new functionality in there, enough to justify the full point in my opinion.
I disagree. Our bug tracker is frightening. Lots of mysterious bugs which I don't know how they are possible at all. Lots of unconfirmed bugs. Lots of just plain very hard to fix bugs.
Not surprisingly, as very little attention was paid to the bugs in
the
last couple months.
We need more help with that. I want to ask everyone who is capable
of
running current CVS to browse the bug list and comment on as many
bugs
as possible. Just test it and report if you can reproduce it or
not,
and if you can, provide as much details as possible. Focus on
crasher
bugs, but also on any bugs without comments or with comments to the effect of "can't reproduce".
Will see if i can have a try at reproducing all the non locale dependant windows ones in the next few days, although I havent got a printer atm so cant do any print ones either.
There are fewer crash bugs listed than we've had in the past, and most of those occur only in special situations (such as Win32-only),
I don't think Windows users will agree to be treated as a "special
situation" :)
Yes, win32 needs some love :)
and from the SF dl stats windows could be as much as 1/2 our userbase, I know this is distorted by the autopackage, aptget etc dls that linux users do, but that will be balanced somewhat by the nightly builds of ishmals. Whatever the actual figure is, 10,000 dls is a lot to be considering a special situation. Admittedly tho, its kinda hard to fix windows bugs when theres virtually no one developing actively on it. Feel free to ask me for help testing any specifics, I'm not the best programmer in the world, but if you want someone to try breaking stuff, I'm your man :)
Sim
_______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com
On Mon, 25 Oct 2004, John Cliff wrote:
I disagree. Our bug tracker is frightening. Lots of mysterious bugs which I don't know how they are possible at all. Lots of unconfirmed bugs. Lots of just plain very hard to fix bugs.
There are fewer crash bugs listed than we've had in the past, and most of those occur only in special situations (such as Win32-only),
I don't think Windows users will agree to be treated as a "special
situation" :)
Yes, win32 needs some love :)
and from the SF dl stats windows could be as much as 1/2 our userbase, Whatever the actual figure is, 10,000 dls is a lot to be considering a special situation. Admittedly tho, its kinda hard to fix windows bugs when theres virtually no one developing actively on it.
Of course what I meant was "Special situations like appearing only on a single platform." Although I'd also agree with the interpretation that uses 'special' in the 'special ed' sense, as regards Windows. ;-)
Also, I think my point about the character of the bugs was missed. Yes there are a lot of bug reports, and yes they're mysterious / hard / unconfirmed, but this is an improvement over past releases where we've had overt showstopper crash bugs that afflicted everyone. My point is that the ratio of bugs that affect everyone all the time to bugs that occur only sometimes on some platforms has noticeably improved from the past, which means we're starting from a better point than before. That's a good thing. Doesn't mean that the listed bugs don't need to be fixed.
Anyway, my question about how to measure when we've achieved our bug fixing goal for this release has not received any answer. How do we determine when we've fixed enough bugs, or the correct set of bugs, to be able to do a release? It is easier to get folks motivated to do bug fixing if there is a tangible goal we can focus on.
Bryce
On Mon, Oct 25, 2004 at 11:53:48AM -0700, Bryce Harrington wrote:
Anyway, my question about how to measure when we've achieved our bug fixing goal for this release has not received any answer. How do we determine when we've fixed enough bugs, or the correct set of bugs, to be able to do a release? It is easier to get folks motivated to do bug fixing if there is a tangible goal we can focus on.
How about getting bug count down to 95 open? We were just at 124 open, so that's a good goal, I think. And I think we should close all the non-reproducible/non-responding bug reports that are older than the 0.39 release date.
Oh, and all "level 9" bugs must get closed/recategorized.
Thoughts?
On Mon, 25 Oct 2004, Kees Cook wrote:
On Mon, Oct 25, 2004 at 11:53:48AM -0700, Bryce Harrington wrote:
Anyway, my question about how to measure when we've achieved our bug fixing goal for this release has not received any answer. How do we determine when we've fixed enough bugs, or the correct set of bugs, to be able to do a release? It is easier to get folks motivated to do bug fixing if there is a tangible goal we can focus on.
How about getting bug count down to 95 open? We were just at 124 open, so that's a good goal, I think. And I think we should close all the non-reproducible/non-responding bug reports that are older than the 0.39 release date.
John suggested that if we close 150 'points' worth of bugs, we should in theory get down to 100 or below. Of course, bugs will continue to be submitted while we go, so we'll see.
Invalidating the older bugs that cannot be reproduced today is a good idea, although I think they probably shouldn't count towards our score, just to keep us honest. I would suggest posting a request for an update to bugs that look non-reproducible and give someone a few days to respond, and if there are no responses then close it.
Oh, and all "level 9" bugs must get closed/recategorized.
Note that a few of the level 9 bugs are _really hard_, and I'm not sure there's sufficient time to rework the code enough to adequately address them... But yes, we definitely need to focus on the high priority bugs.
Update on the bugs...
Bug ID Pts Title ------------------------------------------------------------------------ 1000350 9 --print option can attempt to open dialogs and segfault 1041757 (dup) undefined symbol: gdk_threads_lock 993294 9 RDF improperly exported with plain SVG 1024915 9 glib-2.5.2: crashes on clicking fill and stroke dialog ======================================================================== Total: 27 Goal: 150pts (18% towards goal)
(The --print bug was the extensions code trying to pop up a UI error alert box when running from cmdline; I changed it to a g_warning.)
Bryce
Kees Cook wrote:
On Mon, Oct 25, 2004 at 11:53:48AM -0700, Bryce Harrington wrote:
Anyway, my question about how to measure when we've achieved our bug fixing goal for this release has not received any answer. How do we determine when we've fixed enough bugs, or the correct set of bugs, to be able to do a release? It is easier to get folks motivated to do bug fixing if there is a tangible goal we can focus on.
How about getting bug count down to 95 open? We were just at 124 open, so that's a good goal, I think. And I think we should close all the non-reproducible/non-responding bug reports that are older than the 0.39 release date.
Oh, and all "level 9" bugs must get closed/recategorized.
Thoughts?
Yeah, that sounds reasonable, but we should place more emphasis on bug fixes for our more stable 0.42. After this 0.40 release, I'm sure we will introduce and find a slew of bugs while working on 0.41, but maybe we should try to stabilize Inkscape further on 0.42.
Bryce, your updates to the roadmap look good.
Jon
On Mon, 25 Oct 2004, Jon Phillips wrote:
bulia byak wrote:
We considered either calling it 0.39.5 and keeping with the roadmap as is, or calling it 0.40 and bumping the roadmap a bit. I believe there was a rough concensus for the latter at the time - this still true?
I think few people will bother downloading 0.39.5. It sounds way too much like a bugfix release - not everyone reads Release Notes. Besides, long and unwieldy release numbers are a pain. 0.38.1 was enough to find that out :)
Yeah, IMO 0.40 is better and definitely a deserved full-point release.
Very well, 0.40 it is. I'll update the roadmap.
around. Bryce, do you think your GTKMM stuff will go in next release in full force? Others?
I don't know if I'd use the term 'full force' but yes it should go in after this release. I haven't been able to put as much time into it as I'd like this month but now that the warm weather's all gone, I expect that between now and the end of the year it looks like I'm going to have a more time again.
Most of the work that remains for Gtkmm is straightforward conversion stuff. If anyone would be interested in joining me on this after the release, just ask. We need both people to work on individual widgets and dialogs, and people to work at more meta-level across all dialogs. The only knowledge required is basic C++ and the ability to read the gtkmm.org website. ;-)
I don't think Windows users will agree to be treated as a "special situation" :)
Yes, win32 needs some love :)
Since we have a lot of Win32 users but a precious few Win32 developers, what could we do to increase the quantity of Win32 devs to better match the need? Would user-funded bug bounties help?
Bryce
On Mon, 25 Oct 2004, Bryce Harrington wrote:
On Mon, 25 Oct 2004, Jon Phillips wrote:
bulia byak wrote:
We considered either calling it 0.39.5 and keeping with the roadmap as is, or calling it 0.40 and bumping the roadmap a bit. I believe there was a rough concensus for the latter at the time - this still true?
I think few people will bother downloading 0.39.5. It sounds way too much like a bugfix release - not everyone reads Release Notes. Besides, long and unwieldy release numbers are a pain. 0.38.1 was enough to find that out :)
Yeah, IMO 0.40 is better and definitely a deserved full-point release.
Very well, 0.40 it is. I'll update the roadmap.
I've updated the roadmap to insert this new 0.40 release and bumped everything forward.
Bryce
Bryce Harrington wrote:
Since we have a lot of Win32 users but a precious few Win32 developers, what could we do to increase the quantity of Win32 devs to better match the need? Would user-funded bug bounties help?
Well... given that the code differences are not that much, I'm not sure if we need a bounty.
However, testing is one phase. Once I'm setup to cross-compile I could do a lot more, but I'd still need a person to run under Windows XP to do the actual testing.
I was thinking that we kinda need a QA group. We don't need as many developers as we do good people on Win32 who can run things down in different scenarios and help to get things reproduceable. Seems to me that the main hurdle for the Win32 bugs is in tracking them down in enough detail and getting them reproduceable.
However... if bounties could get a few of us basic Windows machines to do testing on... :-D
On Mon, 25 Oct 2004, Jon A. Cruz wrote:
Bryce Harrington wrote:
Since we have a lot of Win32 users but a precious few Win32 developers, what could we do to increase the quantity of Win32 devs to better match the need? Would user-funded bug bounties help?
Well... given that the code differences are not that much, I'm not sure if we need a bounty.
However, testing is one phase. Once I'm setup to cross-compile I could do a lot more, but I'd still need a person to run under Windows XP to do the actual testing.
I was thinking that we kinda need a QA group. We don't need as many developers as we do good people on Win32 who can run things down in different scenarios and help to get things reproduceable. Seems to me that the main hurdle for the Win32 bugs is in tracking them down in enough detail and getting them reproduceable.
Okay, that's good to know. Testers are probably tons easier to find, too, so this sounds much more feasible. What would the procedure for them to follow be?
However... if bounties could get a few of us basic Windows machines to do testing on... :-D
Hmm, well we may be able to get Linux folk to donate unneeded WinXP, etc. licenses/CD's. dealsdepot.com has cheap refurbished machines that may be sufficient for Windows testing, in the $50-200 range (sans monitor), and I would assume we could get a couple dozen Windows users to donate $10-20 if it will help in the fight against Windows bugs.
Bryce
Okay, that's good to know. Testers are probably tons easier to find, too, so this sounds much more feasible. What would the procedure for them to follow be?
Ties into last message... let me know what kind of testing you need done and I'm all over it... like ice cream on a kids face. (hopefully not as messy though)
However... if bounties could get a few of us basic Windows machines
to
do testing on... :-D
Hmm, well we may be able to get Linux folk to donate unneeded WinXP, etc. licenses/CD's. dealsdepot.com has cheap refurbished machines
that
may be sufficient for Windows testing, in the $50-200 range (sans monitor), and I would assume we could get a couple dozen Windows users to donate $10-20 if it will help in the fight against Windows bugs.
IIRC, the issues with the licensing on XP is it's non-transferrable unless the machine it's attached to is transferred as well (not separating the two though). Meaning... from the technicality standpoint if I buy a new BIG BRAND box, wipe it and throw Linux on there, it's still not within my legal right to donate that copy of XP & license for use on another machine (damn EULAs), as it bound to that hardware. However, if you guys are willing to ignore that technicality, I believe I may know a person or 2 using Linux who would be more than happy to donate their copies of XP.
-Josh
On Mon, 25 Oct 2004, Joshua A. Andler wrote:
Okay, that's good to know. Testers are probably tons easier to find, too, so this sounds much more feasible. What would the procedure for them to follow be?
Ties into last message... let me know what kind of testing you need done and I'm all over it... like ice cream on a kids face. (hopefully not as messy though)
Okay, I'll send out a howto once the details are worked out.
However... if bounties could get a few of us basic Windows machines
to
do testing on... :-D
Hmm, well we may be able to get Linux folk to donate unneeded WinXP, etc. licenses/CD's. dealsdepot.com has cheap refurbished machines
that
may be sufficient for Windows testing, in the $50-200 range (sans monitor), and I would assume we could get a couple dozen Windows users to donate $10-20 if it will help in the fight against Windows bugs.
IIRC, the issues with the licensing on XP is it's non-transferrable unless the machine it's attached to is transferred as well (not separating the two though). Meaning... from the technicality standpoint if I buy a new BIG BRAND box, wipe it and throw Linux on there, it's still not within my legal right to donate that copy of XP & license for use on another machine (damn EULAs), as it bound to that hardware. However, if you guys are willing to ignore that technicality, I believe I may know a person or 2 using Linux who would be more than happy to donate their copies of XP.
Man, that bites... Well, about the last thing we want is for Inkscape to get into a legal tussle with Microsoft. If that's true that there's no way to transfer XP licenses, then that ends that idea. If anyone finds a legal solution for recycling XP licenses, though, shout.
Looks like a barebones new athlon or celeron with an XP license could be had for about $450.
Bryce
Bryce Harrington wrote:
On Mon, 25 Oct 2004, Joshua A. Andler wrote:
Okay, that's good to know. Testers are probably tons easier to find, too, so this sounds much more feasible. What would the procedure for them to follow be?
Ties into last message... let me know what kind of testing you need done and I'm all over it... like ice cream on a kids face. (hopefully not as messy though)
Okay, I'll send out a howto once the details are worked out.
However... if bounties could get a few of us basic Windows machines
to
do testing on... :-D
Hmm, well we may be able to get Linux folk to donate unneeded WinXP, etc. licenses/CD's. dealsdepot.com has cheap refurbished machines
that
may be sufficient for Windows testing, in the $50-200 range (sans monitor), and I would assume we could get a couple dozen Windows users to donate $10-20 if it will help in the fight against Windows bugs.
IIRC, the issues with the licensing on XP is it's non-transferrable unless the machine it's attached to is transferred as well (not separating the two though). Meaning... from the technicality standpoint if I buy a new BIG BRAND box, wipe it and throw Linux on there, it's still not within my legal right to donate that copy of XP & license for use on another machine (damn EULAs), as it bound to that hardware. However, if you guys are willing to ignore that technicality, I believe I may know a person or 2 using Linux who would be more than happy to donate their copies of XP.
Man, that bites... Well, about the last thing we want is for Inkscape to get into a legal tussle with Microsoft. If that's true that there's no way to transfer XP licenses, then that ends that idea. If anyone finds a legal solution for recycling XP licenses, though, shout.
Looks like a barebones new athlon or celeron with an XP license could be had for about $450.
I think this sounds like an interesting idea, but I think we just need to send out a call for testers to many mailing lists and could say that the person who turns out the most could get this prize of a testing a box. That would encourage testers. I think windows testers will come out of the woodwork.
We need to setup the donations system to take a collection for the box as well.
Anyone have any extra boxes they would donate as a prize? Man, if I was back in SD, I have a couple of boxes...ugh...anyway...
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Bryce Harrington wrote:
Okay, that's good to know. Testers are probably tons easier to find, too, so this sounds much more feasible. What would the procedure for them to follow be?
Not sure of all details off-hand... but we might want to just try to craft things so that it's easy to get reproduction of bugs much easier. And perhaps track things to try to get as much platform coverage as possible.
Given our current bug rates, I'd even volunteer to send thank-you postcards to people who help us reproduce busg and then ensure they get properly squashed.
Heh. I could probably even get them postmarked from Disneyland. :-)
Most of the work that remains for Gtkmm is straightforward conversion stuff. If anyone would be interested in joining me on this after the release, just ask. We need both people to work on individual widgets and dialogs, and people to work at more meta-level across all dialogs. The only knowledge required is basic C++ and the ability to read the gtkmm.org website. ;-)
As I've said before, I really want to start helping with the Gtkmm stuff, and have done a couple of the tutorials on the website. However my C++ is extremely basic and quite rusty. So, after the .40 release, I should be able to devote some time to getting completely up to snuff on the Gtkmm side, and start helping to convert those dialogs. As always though, it's been that "free time" thing that's a killer. =)
Since we have a lot of Win32 users but a precious few Win32
developers,
what could we do to increase the quantity of Win32 devs to better
match
the need? Would user-funded bug bounties help?
Since most of my contributions on the developing side will probably end with the finishing of the gtkmm conversion, what can someone who only has very basic C++ skills do? I can always contribute more dialogs in the future (I'd love to help with UI stuff if the team can use it). And as stated before, I'm just waiting for the project to start accepting donations, and I'll start sending them (which I guess relates to the user-funded bug bounties).
OT... and not that you probably don't already have enough people offering, but if you need help with any standards compliant webdesign I'm down to help with that too. Otherwise I will continue to help confirm bugs in the tracker, try to see if any RFEs should be combined/closed (duplicates), etc and report what I can in the meantime.
-Josh
On Mon, 25 Oct 2004, Joshua A. Andler wrote:
Since most of my contributions on the developing side will probably end with the finishing of the gtkmm conversion, what can someone who only has very basic C++ skills do? I can always contribute more dialogs in the future (I'd love to help with UI stuff if the team can use it). And as stated before, I'm just waiting for the project to start accepting donations, and I'll start sending them (which I guess relates to the user-funded bug bounties).
OT... and not that you probably don't already have enough people offering, but if you need help with any standards compliant webdesign I'm down to help with that too. Otherwise I will continue to help confirm bugs in the tracker, try to see if any RFEs should be combined/closed (duplicates), etc and report what I can in the meantime.
Yes, right now and for the coming couple weeks, confirming bugs will be the most useful thing to do. Keeping an eye on the RFE list is also helpful since the developers may not be looking at that very frequently.
I don't think we're ready for a website redesign, but the site could definitely use some content attention. For example, bringing things like the faq up to date, adding new screenshots, adding more documentation for the documentation page (html versions of the tutorials would be quite keen), etc. Also, I tend to be pretty naughty about not validating the HTML, so validating the site (at least the front page and archives.php) can be worthwhile. If you're interested lemme know.
Regarding donations... yeah we probably ought to set something up. Looks like we'd need to set up an inkscape_paypal@ email address, sign up for a biz paypal account, and then have the four admins opt-in for donations. I can get this set up if everyone's ok with this approach.
Bryce
Bryce Harrington wrote:
On Mon, 25 Oct 2004, Joshua A. Andler wrote:
Since most of my contributions on the developing side will probably end with the finishing of the gtkmm conversion, what can someone who only has very basic C++ skills do? I can always contribute more dialogs in the future (I'd love to help with UI stuff if the team can use it). And as stated before, I'm just waiting for the project to start accepting donations, and I'll start sending them (which I guess relates to the user-funded bug bounties).
OT... and not that you probably don't already have enough people offering, but if you need help with any standards compliant webdesign I'm down to help with that too. Otherwise I will continue to help confirm bugs in the tracker, try to see if any RFEs should be combined/closed (duplicates), etc and report what I can in the meantime.
Yes, right now and for the coming couple weeks, confirming bugs will be the most useful thing to do. Keeping an eye on the RFE list is also helpful since the developers may not be looking at that very frequently.
I don't think we're ready for a website redesign, but the site could definitely use some content attention. For example, bringing things like the faq up to date, adding new screenshots, adding more documentation for the documentation page (html versions of the tutorials would be quite keen), etc. Also, I tend to be pretty naughty about not validating the HTML, so validating the site (at least the front page and archives.php) can be worthwhile. If you're interested lemme know.
Regarding donations... yeah we probably ought to set something up. Looks like we'd need to set up an inkscape_paypal@ email address, sign up for a biz paypal account, and then have the four admins opt-in for donations. I can get this set up if everyone's ok with this approach.
Yeah, that sounds good...I want admin acces ;) The other option that Ted and I talked about is how to setup an Inkscape org that is nonprofit. He said this can be done cheap. Ted, could you chime in on this?
Jon
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
adding new screenshots,
I was planning to do several, but please hold this off for a while, because currently the layer widget at the bottom is in a very transitional state, rather unfit for a public display. As soon as Mental finishes it, we'll welcome any screenshots you can send.
We need more help with that. I want to ask everyone who is capable of running current CVS to browse the bug list and comment on as many bugs as possible. Just test it and report if you can reproduce it or not, and if you can, provide as much details as possible. Focus on crasher bugs, but also on any bugs without comments or with comments to the effect of "can't reproduce". We need as much feedback as possible, so this will be a real help to the project. Please try to not post anonymously, simply because if you leave a comment with your SF username the tracker will send you further comments on that bug, which is very convenient for discussions and asking for more information.
There are fewer crash bugs listed than we've had in the past, and most of those occur only in special situations (such as Win32-only),
I don't think Windows users will agree to be treated as a "special situation" :)
Since most of my inkscape usage is in Windows, I will hit up the tracker for Win32 bugs as well as general bugs. I'll see what ways I can help as suggested above (trying to reproduce, feedback, etc.), and I'll make sure to be logged into SF. Also, if my build is from the 22nd, do I NEED to upgrade to newest cvs first or will it suffice (I'm having some problems building from CVS in Windows, and usually grab from either Daniel or Bob's Win32 Builds)?
On Mon, 25 Oct 2004, Joshua A. Andler wrote:
Since most of my inkscape usage is in Windows, I will hit up the tracker for Win32 bugs as well as general bugs. I'll see what ways I can help as suggested above (trying to reproduce, feedback, etc.), and I'll make sure to be logged into SF. Also, if my build is from the 22nd, do I NEED to upgrade to newest cvs first or will it suffice (I'm having some problems building from CVS in Windows, and usually grab from either Daniel or Bob's Win32 Builds)?
Generally for bug checking, the more recent your build the better, because a developer may have fixed the bug just recently. The 22nd is fairly recent, but you'll want to plan on refreshing your build periodically as we go.
Bryce
On Sun, 24 Oct 2004, Bryce Harrington wrote:
In any case, let me know what you think we should set as the goal for this release, and I'll start posting our progress on that by the 26th.
Here's an idea proposed by John Cliff I like:
Keep track of the total of the priority points of closed bugs and shoot for a total score of 150. High priority bugs count 9, med 6, and low 3.
In theory, this will allow us to reduce the bug count to <100, assuming few new bug reports get added.
Does this approach sound good? If so we can start the count from today (10/25).
Bryce
Bryce Harrington wrote:
On Sun, 24 Oct 2004, Bryce Harrington wrote:
In any case, let me know what you think we should set as the goal for this release, and I'll start posting our progress on that by the 26th.
Here's an idea proposed by John Cliff I like:
Keep track of the total of the priority points of closed bugs and shoot for a total score of 150. High priority bugs count 9, med 6, and low 3.
In theory, this will allow us to reduce the bug count to <100, assuming few new bug reports get added.
Does this approach sound good? If so we can start the count from today (10/25).
That is a novel idea. That is news worthy on the website...
Jon
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, 26 Oct 2004, Jon Phillips wrote:
Here's an idea proposed by John Cliff I like:
Keep track of the total of the priority points of closed bugs and shoot for a total score of 150. High priority bugs count 9, med 6, and low 3.
In theory, this will allow us to reduce the bug count to <100, assuming few new bug reports get added.
Does this approach sound good? If so we can start the count from today (10/25).
That is a novel idea. That is news worthy on the website...
Jon
I've added a note about it to the website.
Bug ID Pts Title ------------------------------------------------------------------------ 1038932 6 Export silently fails when file cannot be created 984854 9 crashes with non-existent gradient in gradient editor 1000350 9 --print option can attempt to open dialogs and segfault 1041757 (dup) undefined symbol: gdk_threads_lock 993294 9 RDF improperly exported with plain SVG 1024915 9 glib-2.5.2: crashes on clicking fill and stroke dialog ======================================================================== Total: 42 Goal: 150pts (28% towards goal)
I suppose once we hit 150, we enter freeze and push for a release? Seems like we're going to be able to release pretty quickly here - is there any things that we must not miss for this release (must fix bugs, etc.)?
Bryce
On Mon, 2004-10-25 at 22:31, Bryce Harrington wrote:
I suppose once we hit 150, we enter freeze and push for a release? Seems like we're going to be able to release pretty quickly here - is there any things that we must not miss for this release (must fix bugs, etc.)?
I need to finish the layer selector, and some of the layer-related verbs.
-mental
How long will it take you to do this? From chatting with Bryce and JC, seems like we could knock out a release in a weeks time. Is that doable for your work...sorry to push, but we need to feed the vector graphics massives...
Jon
MenTaLguY wrote:
On Mon, 2004-10-25 at 22:31, Bryce Harrington wrote:
I suppose once we hit 150, we enter freeze and push for a release? Seems like we're going to be able to release pretty quickly here - is there any things that we must not miss for this release (must fix bugs, etc.)?
I need to finish the layer selector, and some of the layer-related verbs.
-mental
On Tue, 2004-10-26 at 03:12, Jon Phillips wrote:
How long will it take you to do this? From chatting with Bryce and JC, seems like we could knock out a release in a weeks time. Is that doable for your work...sorry to push, but we need to feed the vector graphics massives...
I would estimate two weeks, not counting QA. There is some unrelated work that needs to be done also, but it's not anywhere near as involved; I'm trying to put those things on the roadmap as I remember them.
-mental
Is it worth waiting two weeks for this to be fully implemented (this is to everyone)? How can we grease the wheels to get the layers implemented...send some red bulls to your house? Just kidding...
Anxious to get a release out...been a while...
Jon
MenTaLguY wrote:
On Tue, 2004-10-26 at 03:12, Jon Phillips wrote:
How long will it take you to do this? From chatting with Bryce and JC, seems like we could knock out a release in a weeks time. Is that doable for your work...sorry to push, but we need to feed the vector graphics massives...
I would estimate two weeks, not counting QA. There is some unrelated work that needs to be done also, but it's not anywhere near as involved; I'm trying to put those things on the roadmap as I remember them.
-mental
On Wed, 27 Oct 2004 10:31:29 +0900, Jon Phillips <jon@...235...> wrote:
Is it worth waiting two weeks for this to be fully implemented (this is to everyone)?
We've been teasing people with a promise of layers for too long. We must deliver this time.
Mental, to speed this up, can you try to describe what is _supposed_ to work already, so we could start testing those bits? I'm especially interested in the visible and locked toggles - can you enable them now and then continue working on the rest of it?
On Wed, 2004-10-27 at 05:57, bulia byak wrote:
Mental, to speed this up, can you try to describe what is _supposed_ to work already, so we could start testing those bits? I'm especially interested in the visible and locked toggles - can you enable them now and then continue working on the rest of it?
Creating layers and switching between them (using the old selector) should work currently. I'm going to have to
Actually, I've got the new layer selector to a point now where it's no more broken than the old one, so I've dropped the old one, but I've been unable to commit so far due to SF issues.
MOST of my time up until this point has been learning the new TreeView API. It's very nice, but very different from anything I've done in Gtk before. I think I'm finally over that hurdle now, anyway.
The big thing that remains to be done, as far as the layer selector goes, is updating the selector appropriately when layers are reordered, removed, or added (e.g. via the XML editor). There are of course also the cosmetic issues we've previously discussed.
For the remainder of issues, the entries in Roadmap should pretty much cover them. Anything with (DONE) on it should work now.
Something we do need to discuss is what "move to {prev,next} layer" should do. Should it move the current selection to the next/previous layer, or simply switch layers without moving the selection anywhere?
(in the latter case, it should probably unselect the selection, unless we want to drop the most-recent-selection-selects-current-layer rule)
Alternateively, should we have a separate arrangement for shuffling things beteen layers, or what?
-mental
The big thing that remains to be done, as far as the layer selector goes, is updating the selector appropriately when layers are reordered, removed, or added (e.g. via the XML editor). There are of course also the cosmetic issues we've previously discussed.
For the remainder of issues, the entries in Roadmap should pretty much cover them. Anything with (DONE) on it should work now.
So have you enabled the visibility support? Can you make the visible/locked buttons functional already?
Something we do need to discuss is what "move to {prev,next} layer" should do. Should it move the current selection to the next/previous layer, or simply switch layers without moving the selection anywhere?
I think it should move the selection. It would be counterintuitive to have menu commands for something which can be done simply by clicking on the layer widget. Menu commands are supposed to do some "real" changes. So I think these commands should be called "Raise to next layer"/"Lower to previous layer" in line with other raise/lower commands.
Alternateively, should we have a separate arrangement for shuffling things beteen layers, or what?
In principle it's doable by copy/paste but having a dedicated couple of commands for moving things across layers is convenient.
On Thu, 2004-10-28 at 11:52, bulia byak wrote:
So have you enabled the visibility support?
Yes, I implemented it that other night while we were talking about it. Sorry, I didn't mean to leave you with the impression that the conversation was merely hypothetical. ^^;
Try setting the visibility:hidden; property in style=, and the item in question should become invisible.
As indicated on the roadmap, there are still some things that need to be done in the "get object at point" code and so forth to make the tools behave as expected. (It's a little disconcerting to have an invisible object that's still selectable.)
You may find SPDesktop::itemIsHidden() (just comitted) helpful for fixing that.
Can you make the visible/locked buttons functional already?
Yes, though I'd like to implement a few more SPObject accessor/mutator methods first.
-mental
On Tue, 2004-10-26 at 21:31, Jon Phillips wrote:
Is it worth waiting two weeks for this to be fully implemented (this is to everyone)?
Yes, we at least need to get the layer selector and layer verbs finished. I've been seeing upset emails from folks who expected more from layers in 0.39.
I'm punting on a full layers dialog for this release though.
-mental
So this is the 1 Year Anniversary Release
Jon
Bryce Harrington wrote:
On Tue, 26 Oct 2004, Jon Phillips wrote:
Here's an idea proposed by John Cliff I like:
Keep track of the total of the priority points of closed bugs and shoot for a total score of 150. High priority bugs count 9, med 6, and low 3.
In theory, this will allow us to reduce the bug count to <100, assuming few new bug reports get added.
Does this approach sound good? If so we can start the count from today (10/25).
That is a novel idea. That is news worthy on the website...
Jon
I've added a note about it to the website.
Bug ID Pts Title
1038932 6 Export silently fails when file cannot be created 984854 9 crashes with non-existent gradient in gradient editor 1000350 9 --print option can attempt to open dialogs and segfault 1041757 (dup) undefined symbol: gdk_threads_lock 993294 9 RDF improperly exported with plain SVG 1024915 9 glib-2.5.2: crashes on clicking fill and stroke dialog ======================================================================== Total: 42 Goal: 150pts (28% towards goal)
I suppose once we hit 150, we enter freeze and push for a release? Seems like we're going to be able to release pretty quickly here - is there any things that we must not miss for this release (must fix bugs, etc.)?
Bryce
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (8)
-
Bryce Harrington -
bulia byak -
John Cliff -
Jon A. Cruz -
Jon Phillips -
Joshua A. Andler -
Kees Cook -
MenTaLguY